Smog in China, July 2013
Colorado's flash floods, September 17, 2013
Fukushima Daiichi nuclear disaster, March 2011
Yosemite National Park, August 22, 2013
We don’t want to be there………
………..but we need information
International Conference on ICT Convergence 2013

Integrating Wireless Sensor Network
into Cloud Services for Real-time
Data Collection

Presenter: Rajeev Piyare
Department of Information Electronics Engineering
Mokpo National University
rajeev.piyare@hotmail.com
Outline
•
•
•
•
•
•

Abstract
Prior Work
Proposed Architecture
Connecting Sensor Networks to Cloud
Results and Discussion
Conclusion
Abstract
• This paper presents an extensible and flexible
architecture for integrating Wireless Sensor Networks
with the Cloud.
• For proof of concept, Representational State Transfer
(REST) based Web services on an IP based low power
WSN test bed has been set up, which enables data
accessibility from anywhere.
• The alert feature has also been implemented to notify
users via email or tweets for monitoring data when they
exceed values and events of interest.
Prior Work
Problems:
 Architecture of these systems has been designed in a very
ad hoc fashion.
 Not flexible to adapt to other applications or scenarios
 Decision making process is executed at a single central
point .
 Coordinator is the central point of access for all applications
and sensor contributors where all the sensor data is stored
and analyzed.
 Power consumption.
Solution
 Various decision levels can be implemented onto different
architectural layers.
 Flexible architecture for integrating WSN to Cloud using
REST based Web services as an interoperable application
layer.
 To reduce energy consumption and to increase the network
lifetime, sleep mechanism for battery powered sensor
nodes have been utilized.
 Inclusion of Alert feature
Description of Proposed Architecture
The architecture of the proposed system is divided into three layers:
Sensor Layer, the Coordinator Layer and the Supervision Layer.

Figure 1. Proposed Architecture
Sensor Layer
• consists of sensors that interact with the
environment.
• Mesh network and send the information
gathered by the sensors to the Coordinator
Layer through the sink node called the base
station.
• XBee ZB module has the capability to directly
gather sensor data and transmit it without the
use of an external microcontroller.
–
–
–
–

the overall size of the nodes are reduced.
minimizes weight
reduces power consumption
cheaper
Coordination Layer
• responsible for the management of the data
received from the sensor network.
• temporarily stores the gathered data into buffer
and sends it to the Supervision layer at predefined
intervals.

• serves as a mobile mini application server between
the wireless sensors and the dedicated network
and has more advanced computational resources
compared to the End Devices found in Sensor
Layer.
Base Station
Supervision Layer
• stores the sensor data in a database and
also offers a Web interface for the end
users to manage the sensor data and
generate statistics.
• offers a graphical interface for real-time
monitoring of systems

• Automatic alert and notification to the user
– Email
– Twitter
– SMS
Connecting Sensor Network to Cloud (1)
• the access to Cloud services has to be easy, direct, open
and interoperable.
– to utilize Web services
– Simple Object Access Protocol (SOAP) and Representational State
Transfer (REST).
– REST is a much more lightweight mechanism than SOAP offering
functionality similar to SOAP based Web services.

• Open.Sen.se is an open source “Internet of Things”
application and API to store and retrieve data from things
and sensors using Hypertext Transfer Protocol (HTTP)
– Supports JSON, XML and CSV formats for integration into
applications
Connecting Sensor Network to Cloud (2)
• GET and POST requests is used that return JSON responses to
communicate between the base station and the Open.Sen.se server.
– JSON is easy for human beings to read and write and simpler for machines
to parse and generate messages than using XML.

• To read the current sensor value, an HTTP GET request is sent to the
resource of the sensor
• HTTP POST request is sent from the base station to the Cloud for
updating the data entry.
• For authentication, Open.Sen.se server is protected with a Sen.se key
which is specific and unique to each user.
Results and Discussions
 WSN was created to collect temperature and battery voltage
readings.
 Preliminary experiments were performed to evaluate the
system in terms of
– sensor data accessibility
– alert notification time
– battery consumption
– Senseboard>> to present the collected data to the user in
an easy and meaningful way.
Senseboard

Figure 6 shows the real-time acquisition curve on Open.sen.se Cloud services
Event Notification
• An event notification system is also implemented on
Open.Sen.se server based on measurements from sensors
and predefined If-conditions.
– allows monitoring End Devices supply voltage, temperature etc..
– send a notification alert to the user via a push email, SMS, or tweets.

Figure 7. Notification Email to alert the user on low battery voltage
Event Notification Time delay

Ten trials were conducted and it is observed that it takes about
8-13s and an average of 11s for the notification email to be
auto generated and delivered to the user on their specified
email account from the Open.Sen.se server
Battery Lifetime of the End Devices
 Replacing batteries regularly is inconvenient.

 Using cyclic sleep mechanism.
 Data Packet size.
 Carried out for End Devices since coordinator is
mains powered.
Battery Lifetime (2)
I act ( n ) 

tonoff I onoff  tlistenI listen  ttrans( n ) I trans
t active( n )

ttrans( n ) 

8  (31  n)
r

tactive( n )  tonoff  tlisten  ttrans( n )
I drain( n ) 

tactive( n )

L

T

 t active( n ) 
 I sleep
I act ( n )  1 

T 



C / ( I drain( n ) 1000)
365  24

(1)

(2)

(3)

(4)

(5)

Figure 8. Wireless Sensor Network Node
lifetime with different packet size and update
period
Conclusion
 Flexible architecture for integration of Wireless Sensor
Networks to the Cloud for sensor data collection and
sharing.
 Embedded intelligence at different architectural layers to
accommodate for the diverse requirements of possible
application scenarios with minimum redesign and recoding.
 Results illustrate that the sensor data can be accessed by
the users anywhere and on any mobile device with internet
access.
Thank you all for your attention

Integrating Wireless Sensor Network into Cloud Services for Real-time Data Collection

  • 1.
    Smog in China,July 2013
  • 2.
    Colorado's flash floods,September 17, 2013
  • 3.
    Fukushima Daiichi nucleardisaster, March 2011
  • 4.
    Yosemite National Park,August 22, 2013
  • 5.
    We don’t wantto be there……… ………..but we need information
  • 6.
    International Conference onICT Convergence 2013 Integrating Wireless Sensor Network into Cloud Services for Real-time Data Collection Presenter: Rajeev Piyare Department of Information Electronics Engineering Mokpo National University rajeev.piyare@hotmail.com
  • 7.
    Outline • • • • • • Abstract Prior Work Proposed Architecture ConnectingSensor Networks to Cloud Results and Discussion Conclusion
  • 8.
    Abstract • This paperpresents an extensible and flexible architecture for integrating Wireless Sensor Networks with the Cloud. • For proof of concept, Representational State Transfer (REST) based Web services on an IP based low power WSN test bed has been set up, which enables data accessibility from anywhere. • The alert feature has also been implemented to notify users via email or tweets for monitoring data when they exceed values and events of interest.
  • 9.
    Prior Work Problems:  Architectureof these systems has been designed in a very ad hoc fashion.  Not flexible to adapt to other applications or scenarios  Decision making process is executed at a single central point .  Coordinator is the central point of access for all applications and sensor contributors where all the sensor data is stored and analyzed.  Power consumption.
  • 10.
    Solution  Various decisionlevels can be implemented onto different architectural layers.  Flexible architecture for integrating WSN to Cloud using REST based Web services as an interoperable application layer.  To reduce energy consumption and to increase the network lifetime, sleep mechanism for battery powered sensor nodes have been utilized.  Inclusion of Alert feature
  • 11.
    Description of ProposedArchitecture The architecture of the proposed system is divided into three layers: Sensor Layer, the Coordinator Layer and the Supervision Layer. Figure 1. Proposed Architecture
  • 12.
    Sensor Layer • consistsof sensors that interact with the environment. • Mesh network and send the information gathered by the sensors to the Coordinator Layer through the sink node called the base station. • XBee ZB module has the capability to directly gather sensor data and transmit it without the use of an external microcontroller. – – – – the overall size of the nodes are reduced. minimizes weight reduces power consumption cheaper
  • 13.
    Coordination Layer • responsiblefor the management of the data received from the sensor network. • temporarily stores the gathered data into buffer and sends it to the Supervision layer at predefined intervals. • serves as a mobile mini application server between the wireless sensors and the dedicated network and has more advanced computational resources compared to the End Devices found in Sensor Layer. Base Station
  • 14.
    Supervision Layer • storesthe sensor data in a database and also offers a Web interface for the end users to manage the sensor data and generate statistics. • offers a graphical interface for real-time monitoring of systems • Automatic alert and notification to the user – Email – Twitter – SMS
  • 15.
    Connecting Sensor Networkto Cloud (1) • the access to Cloud services has to be easy, direct, open and interoperable. – to utilize Web services – Simple Object Access Protocol (SOAP) and Representational State Transfer (REST). – REST is a much more lightweight mechanism than SOAP offering functionality similar to SOAP based Web services. • Open.Sen.se is an open source “Internet of Things” application and API to store and retrieve data from things and sensors using Hypertext Transfer Protocol (HTTP) – Supports JSON, XML and CSV formats for integration into applications
  • 16.
    Connecting Sensor Networkto Cloud (2) • GET and POST requests is used that return JSON responses to communicate between the base station and the Open.Sen.se server. – JSON is easy for human beings to read and write and simpler for machines to parse and generate messages than using XML. • To read the current sensor value, an HTTP GET request is sent to the resource of the sensor • HTTP POST request is sent from the base station to the Cloud for updating the data entry. • For authentication, Open.Sen.se server is protected with a Sen.se key which is specific and unique to each user.
  • 17.
    Results and Discussions WSN was created to collect temperature and battery voltage readings.  Preliminary experiments were performed to evaluate the system in terms of – sensor data accessibility – alert notification time – battery consumption – Senseboard>> to present the collected data to the user in an easy and meaningful way.
  • 18.
    Senseboard Figure 6 showsthe real-time acquisition curve on Open.sen.se Cloud services
  • 19.
    Event Notification • Anevent notification system is also implemented on Open.Sen.se server based on measurements from sensors and predefined If-conditions. – allows monitoring End Devices supply voltage, temperature etc.. – send a notification alert to the user via a push email, SMS, or tweets. Figure 7. Notification Email to alert the user on low battery voltage
  • 20.
    Event Notification Timedelay Ten trials were conducted and it is observed that it takes about 8-13s and an average of 11s for the notification email to be auto generated and delivered to the user on their specified email account from the Open.Sen.se server
  • 21.
    Battery Lifetime ofthe End Devices  Replacing batteries regularly is inconvenient.  Using cyclic sleep mechanism.  Data Packet size.  Carried out for End Devices since coordinator is mains powered.
  • 22.
    Battery Lifetime (2) Iact ( n )  tonoff I onoff  tlistenI listen  ttrans( n ) I trans t active( n ) ttrans( n )  8  (31  n) r tactive( n )  tonoff  tlisten  ttrans( n ) I drain( n )  tactive( n ) L T  t active( n )   I sleep I act ( n )  1   T    C / ( I drain( n ) 1000) 365  24 (1) (2) (3) (4) (5) Figure 8. Wireless Sensor Network Node lifetime with different packet size and update period
  • 23.
    Conclusion  Flexible architecturefor integration of Wireless Sensor Networks to the Cloud for sensor data collection and sharing.  Embedded intelligence at different architectural layers to accommodate for the diverse requirements of possible application scenarios with minimum redesign and recoding.  Results illustrate that the sensor data can be accessed by the users anywhere and on any mobile device with internet access.
  • 24.
    Thank you allfor your attention