REAL TIME DATA ANALYSIS IN SENSORCLOUD PLATFORM

A Dissertation Submitted in partial fulfillment of the requirementsfor the degree of

Master of Technologyin

Computer Science and Engineering

Submitted by

Sanjit Kumar Dash.Registration No :0951012011

Under the guidance of

Prof. Sarada Prasanna Pati.Prof. Subasish Mohapatra.

Department of Computer Science and EngineeringInstitute of Technical Education and Research

Siksha ’O’ Anusandhan UniversityBhubaneswar, Odisha

2012

Dissertation Approval Certificate

This is to certify that the dissertation entitled ”Real Time Data Analysis inSensor-Cloud Platform” submitted by Sanjit Kumar Dash (Redg. No.0951012011) is approved for the degree of Master of Technology in ComputerScience and Engineering from Institute of Technical Education and Research,Siksha ’O’ Anusandhan University, Odisha.

Mr. Subasish Mohapatra(Co-guide)

Mr. Sarada Prasanna Pati(Guide)

Prof. (Dr.) B.K. Patanaik(Head of the Department)

(External Examiner)

Date: 19th July 2012Place: ITER, Bhubaneswar

Declaration

I declare that this written submission represents my ideas in my own words andwhere others ideas or words have been included, I have adequately cited and ref-erenced the original sources. I also declare that I have adhered to all principlesof academic honesty and integrity and have not misrepresented or fabricated orfalsified any idea/data/fact/source in my submission. I understand that any vio-lation of the above will cause for disciplinary action by the Institute and can alsoevoke penal action from the sources which have thus not been properly cited orfrom whom proper permission has not been taken when needed.

Sanjit Kumar DashRedg No. 0951012011

Acknowledgment

At first, I would like to thank Prof. (Dr.) B.K.Patnaik, HOD, Computer Scienceand Engineering, ITER and Mr. Chinmay Swain, Course Coordinator, ComputerScience and Engineering for their enthusiasm towards achieving excellence. At thenib but not neap tide, I would like to thank my friends who are my constant sourceof learning; and my family for providing me mental strength while I am away fromhome. I would also like to thank all those who have become the part of this thesiswork.

Secondly, I would like to thank Mr. Sarada Prasanna Pati, Asst. Professor,Dept of CSE,ITER and Mr. Subasish Mohapatra, Asst. Professor, Dept of CSE,ITER and Mr. Jyoti Prakash Sahoo, Dept of IT, ITER for their support duringthe preparation of this seminar. It is a great pleasure to study and work for thisseminar at S’O’A University.

Finally, I would like to express my thanks to my parents for all their support,advice and assistance.

Sanjit Kumar DashRedg No. 0951012011

Abstract

Cloud Computing is an Internet-based computing, whereby shared resources, soft-ware, and information are provided to computers and other devices on demand.NIST sees cloud as having essential characteristics of self-service, on-demand,location-independent, measured access to shared, and elastic resources over thenetwork. That is: ubiquitous, metered access to scalable network services.

A Wireless Sensor Network (WSN) consists of spatially distributed autonomoussensors to cooperatively monitor physical or environmental conditions, such astemperature, sound, vibration,pressure, motion or pollutants.

The communication among sensor nodes using Internet is often a challengingissue. It makes a lot of sense to integrate sensor networks with Internet. At thesame time the data of sensor network should be available at any time, at anyplace. It is possibly a difficult issue to assign address to the sensor nodes of largenumbers; so sensor node may not establish connection with internet exclusively.Cloud computing strategy can help business organizations to conduct their corebusiness activities with less hassle and greater efficiency. Companies can maximizethe use of their existing hardware to plan for and serve specific peaks in usage.Thousands of virtual machines and applications can be managed more easily usinga cloud-like environment.Businesses can also save on power costs as they reducethe number of servers required.

Table of Contents

1 Cloud Computing 91.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 On demand self-service . . . . . . . . . . . . . . . . . . . . . 111.3.2 Ubiquitous Network Access . . . . . . . . . . . . . . . . . . 111.3.3 Location Independent Resource Pooling . . . . . . . . . . . . 111.3.4 Rapid Elasticity . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.5 Pay per Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4 Cloud Delivery Models . . . . . . . . . . . . . . . . . . . . . . . . . 111.4.1 Public Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.2 Private Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.3 Hybrid Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.4 Community Cloud . . . . . . . . . . . . . . . . . . . . . . . 13

1.5 Cloud Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.5.1 Software-as-a-Service (SaaS) . . . . . . . . . . . . . . . . . . 131.5.2 Platform-as-a-Service (PaaS) . . . . . . . . . . . . . . . . . . 131.5.3 Infrastructure-as-a-Service (IaaS) . . . . . . . . . . . . . . . 14

1.6 Storage Architecture in the Cloud . . . . . . . . . . . . . . . . . . . 14

2 Wireless Sensor Network 162.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Sensor Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.2 Transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.3 External Memory . . . . . . . . . . . . . . . . . . . . . . . . 202.4.4 Power source . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.5 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Sensor Network Topologies . . . . . . . . . . . . . . . . . . . . . . . 21

5

2.5.1 Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.2 Star . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.3 Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.4 Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Routing Protocols in WSN . . . . . . . . . . . . . . . . . . . . . . . 242.7 Applications of Sensor Network . . . . . . . . . . . . . . . . . . . . 25

2.7.1 Military Applications . . . . . . . . . . . . . . . . . . . . . . 252.7.2 Environmental Applications . . . . . . . . . . . . . . . . . . 262.7.3 Health Applications . . . . . . . . . . . . . . . . . . . . . . . 272.7.4 Home Applications . . . . . . . . . . . . . . . . . . . . . . . 27

3 Literature Survey 28

4 Sensor-Cloud: Assimilation of Wireless Sensor Network and Cloud 314.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Sensor-Cloud System Model . . . . . . . . . . . . . . . . . . . . . . 324.3 Sensor-Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.1 Virtualization Manager . . . . . . . . . . . . . . . . . . . . . 334.3.2 Publish/Subscribe Broker . . . . . . . . . . . . . . . . . . . 344.3.3 Monitoring and Metering(MaM) . . . . . . . . . . . . . . . . 354.3.4 System Manager . . . . . . . . . . . . . . . . . . . . . . . . 354.3.5 Service Registry . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.6 Stream Monitoring and Processing (SMP) . . . . . . . . . . 354.3.7 Application Specific Interface . . . . . . . . . . . . . . . . . 36

4.4 Sensor-Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . 364.5 Sensor-Cloud Design Issues and Challenges . . . . . . . . . . . . . 37

4.5.1 Sensor Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5.2 Cloud Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Sensor-Cloud Application in Patient Monitoring 405.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Design Consideration for Patient Monitoring System . . . . . . . . 415.3 Sensor Cloud Architecture for Patient Monitoring . . . . . . . . . . 435.4 Event Matching Algorithm for Patient Monitoring . . . . . . . . . . 46

6 Environmental Setup and Implementation 496.1 Epileptic Seizure: A Case Study . . . . . . . . . . . . . . . . . . . . 496.2 Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 506.3 Environmental Components . . . . . . . . . . . . . . . . . . . . . . 50

6.3.1 Mercury Wearable Sensor Network Platform . . . . . . . . . 506.3.2 Medical server . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6

6.3.3 Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . 536.4 Observation and Result . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 Conclusion 57

7

List of Figures

1.1 Conceptual Diagram of Cloud Computing . . . . . . . . . . . . . . 101.2 Cloud Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 131.3 Cloud Service Architecture . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Multi-hop Wireless Sensor Network . . . . . . . . . . . . . . . . . . 172.2 Sensor Node Architecture . . . . . . . . . . . . . . . . . . . . . . . 192.3 Example of Sensor Node . . . . . . . . . . . . . . . . . . . . . . . . 212.4 Peer-to-Peer Network . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5 Star Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.6 Tree Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7 Mesh Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Sensor-Cloud System Model . . . . . . . . . . . . . . . . . . . . . . 334.2 Sensor-Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Sensor-Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 WSN Application Scenario for Health Care . . . . . . . . . . . . . . 435.2 Sensor-Cloud Architecture for Monitoring Patients at Hospital . . . 445.3 High Level Architecture of Sensor-Cloud with Medical Server and

Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Event Grouping Algorithm . . . . . . . . . . . . . . . . . . . . . . . 475.5 Event Matching Algorithm . . . . . . . . . . . . . . . . . . . . . . . 48

6.1 Mercury Wearable Sensor Network Platform . . . . . . . . . . . . . 516.2 Shimmer Wearable Sensor Node . . . . . . . . . . . . . . . . . . . . 526.3 miTag with Pulse Oximeter . . . . . . . . . . . . . . . . . . . . . . 526.4 An Elliptic Seizure Patient under observation in an ICU . . . . . . 546.5 Medical Server output for Monitoring Patients . . . . . . . . . . . . 556.6 Snapshot of Emergency Alert Window when Anomaly Detected . . 566.7 Web Page Showing Patient Details . . . . . . . . . . . . . . . . . . 56

8

Chapter 1

Cloud Computing

1.1 Introduction

Cloud Computing means ”Internet-based” development, where ’Cloud’ is a metaphorfor ’Internet’ and ’Computing’ is the use of ”Computer Technology”. It is a styleof computing in which IT-related capabilities are provided ”as a service”, allow-ing users to access technology-enabled services from the Internet (”in the cloud”)without knowledge of, expertise with, or control over the technology infrastructurethat supports them.

Cloud computing is clearly one of today’s most enticing technology areas due,at least in part, to its cost-efficiency and flexibility. However, despite the surge inactivity and interest, there are significant, persistent concerns about cloud com-puting that are impeding momentum and will eventually compromise the visionof cloud computing as a new IT procurement model.

Today, the 14th largest software company by market capitalization (Sales-force.com) operates almost entirely in the cloud; the top five software companies bysales revenue all have major cloud offerings. Yet, despite the trumpeted businessand technical advantages of cloud computing, many potential cloud users have yetto join the cloud, and those major corporations that are cloud users are for themost part putting only their less sensitive data in the cloud. Lack of control inthe cloud is the major worry. One aspect of control is transparency in the cloudimplementation - somewhat contrary to the original promise of cloud computingin which the cloud implementation is not relevant. Transparency is needed forregulatory reasons and to ease concern over the potential for data breaches[1].

9

Figure 1.1: Conceptual Diagram of Cloud Computing

1.2 Characteristics

The capabilities that must be adhered to an offering to be considered a cloud.These include:

1. Pay as you go - payment is variable based on the actual consumption by thecustomer.

2. Highly abstracted - server hardware and related network infrastructure ishighly abstracted from the users.

3. Multi-tenant - multi-tenant architectures allow numerous customer enter-prizes to subscribe to the cloud computing capabilities while retaining pri-vacy and security over their information.

4. Immediately scalable - usage, capacity, and therefore cost, can be scaled upor down with no additional contract or penalties.

1.3 Attributes

There are differing views on the number and description of the cloud’s key at-tributes. For this Information Security Briefing, the cloud is defined by a minimumof three attributes:

1. Hardware management is highly abstracted;

2. Infrastructure costs are incurred as variable (operating) expense;

3. Infrastructure capacity is elastic (i.e. it can be scaled up or down).

The US National Institute of Standards and Technology (NIST) define cloud com-puting with five attributes [2][3]:

10

1.3.1 On demand self-service

A consumer can unilaterally have the provision of getting computing capabili-ties such as server time and network storage, as needed without requiring humaninteraction with each service’s provider.

1.3.2 Ubiquitous Network Access

Capabilities are available over the network and accessed through standard mech-anisms that promote use by heterogeneous thin or thick client platforms such asmobile phones, laptops, and PDAs.

1.3.3 Location Independent Resource Pooling

The provider’s computing resources are pooled to serve all consumers using a multi-tenant model, with different physical and virtual resources dynamically assignedand reassigned according to consumer demand. The customer generally has nocontrol or knowledge over the exact location of the provided resources. Examplesof resources include storage, processing, memory, network bandwidth, and virtualmachines.

1.3.4 Rapid Elasticity

Capabilities can be rapidly and elastically provisioned to quickly scale up, andrapidly released to quickly scale down. To the consumer, the capabilities availablefor rent often appear to be infinite and can be purchased in any quantity at anytime.

1.3.5 Pay per Use

Capabilities are charged using a metered, fee-for-service, or advertising basedbilling model to promote optimisation of resource use. Examples are: measur-ing the storage, bandwidth, and computing resources consumed, and charging forthe number of active user accounts per month.

1.4 Cloud Delivery Models

Cloud computing services are normally delivered in one of the four ways, dependingon the level of ownership and the technical architecture. Cloud services can beprovided by public, private, hybrid or community clouds

11

1.4.1 Public Cloud

Public clouds are run by third parties, and applications from different customersare likely to be mixed together on the cloud’s servers, storage systems, and net-works. Public clouds are most often hosted away from customer premises, andthey provide a way to reduce customer risk and cost by providing a flexible, eventemporary extension to enterprize infrastructure. If a public cloud is implementedwith performance, security, and data locality in mind, the existence of other ap-plications running in the cloud should be transparent to both cloud architects andend users. Indeed, one of the benefits of public clouds is that they can be muchlarger than a company’s private cloud might be, offering the ability to scale up anddown on demand, and shifting infrastructure risks from the enterprize to the cloudprovider, if even just temporarily. Private clouds are built for the exclusive useof one client, providing the utmost control over data, security, and quality of ser-vice (Figure 1.2). The company owns the infrastructure and has control over howapplications are deployed on it. Private clouds may be deployed in an enterprizedata center.

1.4.2 Private Cloud

Private clouds can be built and managed by a company’s own IT organization orby a cloud provider. In this ”hosted private” model, a company such as Sun caninstall, configure, and operate the infrastructure to support a private cloud withina company’s enterprize data center. This model gives companies a high level ofcontrol over the use of cloud resources while bringing in the expertise needed toestablish and operate the environment.

1.4.3 Hybrid Cloud

A mix of public cloud services, internal cloud computing architectures forms ahybrid clouds combine both public and private cloud models. They can help toprovide on-demand, externally provisioned scale. The ability to augment a privatecloud with the resources of a public cloud can be used to maintain service levelsin the face of rapid workload fluctuations. This is most often seen with the useof storage clouds to support Web 2.0 applications. A hybrid cloud also can beused to handle planned workload spikes. Sometimes called ”surge computing,” apublic cloud can be used to perform periodic tasks that can be deployed easilyon a public cloud. Hybrid clouds introduce the complexity of determining how todistribute applications across both a public and private cloud.

12

1.4.4 Community Cloud

Community clouds are used across organisations that have similar objectives andconcerns, allowing for shared infrastructure and services. Community clouds canbe deployed using any of the three methods outlined above, simplifying cross-functional IT governance.

Figure 1.2: Cloud Deployment Model

1.5 Cloud Services

Clouds are commonly described in terms of the functionality offered. The threemain types of cloud computing services are:

1.5.1 Software-as-a-Service (SaaS)

In this model, a complete application is offered to the customer, as a service ondemand. A single instance of the service runs on the cloud and multiple end usersare serviced. On the customer’s side, there is no need for upfront investment inservers or software licenses, while for the provider, the costs are lowered, since onlya single application needs to be hosted and maintained. Today SaaS is offered bycompanies such as Google, Salesforce, Microsoft, Zoho, etc.

1.5.2 Platform-as-a-Service (PaaS)

In this model, a layer of software, or development environment is encapsulatedand offered as a service, upon which other higher levels of service can be built.The customer has the freedom to build his own applications, which run on the

13

provider’s infrastructure. To meet manageability and scalability requirements ofthe applications, PaaS providers offer a predefined combination of OS and applica-tion servers, such as LAMP platform (Linux, Apache, MySql and PHP), restrictedJ2EE, Ruby etc. Google’s App Engine, Force.com, etc are some of the popularPaaS examples.

1.5.3 Infrastructure-as-a-Service (IaaS)

This model provides basic storage and computing capabilities as standardized ser-vices over the network. Servers, storage systems, networking equipment, data cen-ter space etc. are pooled and made available to handle workloads. The customerwould typically deploy his own software on the infrastructure. Some commonexamples are Amazon, GoGrid, 3 Tera, etc.

Figure 1.3: Cloud Service Architecture

1.6 Storage Architecture in the Cloud

The storage architecture of the cloud includes the capabilities of the Google filesystem along with the benefits of a storage area network (SAN). Either techniquecan be used by itself, or both can be used together as needed. Computing withoutdata is as rare as data without computing. The combination of data and computerpower is important. Computer power often is measured in the cycle speed of aprocessor. Computer speed also needs to account for the number of processors.The number of processors within an SMP and the number within a cluster mayboth be important. When looking at disk storage, the amount of space is oftenthe primary measure. The number of gigabytes or terabytes of data needed is

14

important. But access rates are often more important. Being able to only readsixty megabytes per second may limit your processing capabilities below yourcomputer capabilities. Individual disks have limits on the rate at which theycan process data. A single computer may have multiple disks, or with SAN filesystem be able to access data over the network. So data placement can be animportant factor in achieving high data access rates. Spreading the data overmultiple computer nodes may be desired, or having all the data reside on a singlenode may be required for optimal performance.

The Google file structure can be used in the cloud environment. When used, ituses the disks inside the machines, along with the network to provide a shared filesystem that is redundant.This can increase the total data processing speed whenthe data and processing power is spread out efficiently.The Google file system isa part of storage architecture but it is not considered to be a SAN architecture.A SAN architecture relies on an adapter other than an Ethernet in the computernodes, and has a network similar to an Ethernet network that can then hostvarious SAN devices.Typically a single machine has both computer power anddisks. The ratio of disk capability to computer capability is fairly static. Withthe Google file system, the single node’s computer power can be used against verylarge data by accessing the data through the network and staging it on the localdisk. Alternatively, if the problem lends itself to distribution, then many computernodes can be used allowing their disks to also be involved. With the SAN we canfundamentally alter the ratio between computer power and disk capability. Asingle SAN client can be connected to, and access at high speeds, an enormousamount of data. When more computer power is needed, more machines can beadded. When more I/O capability is needed, more SAN devices can be added.Either capability is independent of the other. Fast write is a capability availableon many SAN devices. Normal disk writes do not complete until the data hasbeen written to disk, which involves spinning the disk, and potentially moving theheads. With fast write, the write completes when the data reaches memory in theSAN device, long before it gets written to disk.

15

Chapter 2

Wireless Sensor Network

2.1 Introduction

A wireless sensor network (WSN) consists of spatially distributed autonomous sen-sors to cooperatively monitor physical or environmental conditions, such as tem-perature, sound, vibration,pressure, motion or pollutants[4,5]. The development ofwireless sensor networks was motivated by military applications such as battlefieldsurveillance. They are now used in many industrial and civilian application areas,including industrial process monitoring and control, machine health monitoring[6], environment and habitat monitoring, health-care applications, home automa-tion, and traffic control [4,7]. Each node in a sensor network is typically equippedwith a radio transceiver or other wireless communications device, a small micro-controller, and an energy source, usually a battery. The size of sensor node mayvary from shoebox down to a grain of dust. The cost of sensor nodes is also variesfrom hundreds of dollars to a few pennies, depending on the size of the sensornetwork and the complexity required of individual sensor nodes [4]. Size and costconstraints on sensor nodes result in corresponding constraints on resources suchas energy, memory, computational speed and bandwidth [4]. A sensor network isa computer network Composed of a large number of sensor nodes [8]. The sen-sor nodes are densely deployed inside the phenomenon, they deploy random andhave cooperative capabilities. Usually these devices are small and inexpensive, sothat they can be produced and deployed in large numbers, and so their resourcesin terms of energy, memory, computational speed and bandwidth are severelyconstrained. There are different Sensors such as pressure, accelerometer,camera,thermal, microphone, etc. They monitor conditions at different locations, suchas temperature, humidity, vehicular movement, lightning condition, pressure, soilmakeup, noise levels,the presence or absence of certain kinds of objects, mechanicalstress levels on attached objects,the current characteristics such as speed, direc-

16

tion and size of an object. Normally these Sensor nodes consist there components:sensing, processing and communicating [9]. The development of sensor networksrequires technologies from three different research areas: sensing, communication,and computing (including hardware, software, and algorithms). Thus, combinedand separate advancements in each of these areas have driven research in sensornetworks. Examples of early sensor networks include the radar networks used inair traffic control. The national power grid, with its many sensors, can be viewedas one large sensor network.

Figure 2.1: Multi-hop Wireless Sensor Network

2.2 Terminologies

Following are the important terms which are used widely in sensor network:

1. Sensor: A transducer that converts a physical phenomenon such as heat,light, sound or motion into electrical or other signal that may be furthermanipulated by other apparatus.

2. Sensor node: A basic unit in a sensor network, with processor, memory,wireless modem and power supply.

3. Network Topology: A connectivity graph where nodes are sensor nodes andedges are communication links.

4. Routing: The process of determining a network path from a source node toits destination.

5. Resource: Resource includes sensors, communication links, processors andmemory and node energy.

17

6. Data Storage: The run-time system support for sensor network application.Storage may be local to the node where the data is generated, load balancedacross a network, or anchored at a few points.

2.3 Characteristics

The main characteristics of a WSN include

1. Power consumption constrains for nodes using batteries or energy harvesting

2. Ability to cope with node failures

3. Mobility of nodes

4. Dynamic network topology

5. Communication failures

6. Heterogeneity of nodes

7. Scalability to large scale of deployment

8. Ability to withstand harsh environmental conditions

9. Ease of use

10. Unattended operation

11. Power consumption

2.4 Sensor Node

A sensor node, also known as a mote is a node in a wireless sensor network thatis capable of performing some processing, gathering sensory information and com-municating with other connected nodes in the network. A mote is a node but anode cannot always be a mote.Sensor nodes can be imagined as small computers,extremely basic in terms of their interfaces and their components. They usuallyconsist of a processing unit with limited computational power and limited mem-ory, sensors or MEMS, and a power source usually in the form of a battery. Otherpossible inclusions are energy harvesting modules, secondary ASICs, and possiblysecondary communication devices (e.g. RS-232 or USB). The base stations areone or more components of the WSN with much more computational, energy andcommunication resources. They act as a gateway between sensor nodes and the

18

end user as they typically forward data from the WSN on to a server. Other specialcomponents in routing based networks are routers, designed to compute, calculateand distribute the routing tables. Many techniques are used to connect to theoutside world including mobile phone networks, satellite phones, radio modems,long-range Wi-Fi links etc. Many base stations are ARM-based running a form ofEmbedded Linux.

The main components of a sensor node are a micro-controller, transceiver,external memory, power source and one or more sensors.

Figure 2.2: Sensor Node Architecture

2.4.1 Controller

The controller performs tasks, processes data and controls the functionality ofother components in the sensor node. While the most common controller is amicro-controller, other alternatives that can be used as a controller are: a generalpurpose desktop microprocessor, digital signal processors, FPGAs and ASICs. Amicro-controller is often used in many embedded systems such as sensor nodesbecause of its low cost, flexibility to connect to other devices, ease of program-ming, and low power consumption. A general purpose microprocessor generallyhas a higher power consumption than a micro-controller, therefore it is often notconsidered a suitable choice for a sensor node.

2.4.2 Transceiver

Sensor nodes often make use of ISM band which gives free radio, spectrum allo-cation and global availability. The possible choices of wireless transmission mediaare Radio frequency (RF), Optical communication (Laser) and Infrared. Lasersrequire less energy , but need line-of-sight for communication and are sensitive toatmospheric conditions. Infrared, like lasers, needs no antenna but it is limitedin its broadcasting capacity. Radio frequency based communication is the mostrelevant that fits most of the WSN applications. WSNs tend to use license-freecommunication frequencies: 173, 433, 868, and 915 MHz; and 2.4 GHz. The func-tionality of both transmitter and receiver are combined into a single device known

19

as transceivers. Transceivers often lack unique identifiers. The operational statesare transmit, receive, idle, and sleep. Current generation transceivers have built-in state machines that perform some operations automatically.Most transceiversoperating in idle mode have a power consumption almost equal to the power con-sumed in receive mode. Thus, it is better to completely shutdown the transceiverrather than leave it in the idle mode when it is not transmitting or receiving.A significant amount of power is consumed when switching from sleep mode totransmit mode in order to transmit a packet.

2.4.3 External Memory

From an energy perspective, the most relevant kinds of memory are the on-chipmemory of a micro-controller and Flash memory off-chip RAM is rarely, if ever,used. Flash memories are used due to their cost and storage capacity. Memoryrequirements are very much application dependent. Two categories of memorybased on the purpose of storage are: user memory used for storing applicationrelated or personal data, and program memory used for programming the device.Program memory also contains identification data of the device if present.

2.4.4 Power source

The sensor node consumes power for sensing, communicating and data processing.More energy is required for data communication than any other process. The en-ergy cost of transmitting 1 Kb a distance of 100 metres (330 ft) is approximatelythe same as that used for the execution of 3 million instructions by a 100 millioninstructions per second/W processor. Power is stored either in batteries or ca-pacitors. Batteries, both rechargeable and non-rechargeable, are the main sourceof power supply for sensor nodes. They are also classified according to electro-chemical material used for the electrodes such as NiCd (nickel-cadmium), NiZn(nickel-zinc), NiMH (nickel-metal hydride), and lithium-ion. Current sensors areable to renew their energy from solar sources, temperature differences, or vibra-tion. Two power saving policies used are Dynamic Power Management (DPM) andDynamic Voltage Scaling (DVS).DPM conserves power by shutting down parts ofthe sensor node which are not currently used or active. A DVS scheme varies thepower levels within the sensor node depending on the non-deterministic workload.By varying the voltage along with the frequency, it is possible to obtain quadraticreduction in power consumption.

20

2.4.5 Sensors

Sensors are hardware devices that produce a measurable response to a change in aphysical condition like temperature or pressure. Sensors measure physical data ofthe parameter to be monitored. The continual analog signal produced by the sen-sors is digitized by an analog-to-digital converter and sent to controllers for furtherprocessing. A sensor node should be small in size, consume extremely low energy,operate in high volumetric densities, be autonomous and operate unattended, andbe adaptive to the environment. As wireless sensor nodes are typically very smallelectronic devices, they can only be equipped with a limited power source of lessthan 0.5-2 ampere-hour and 1.2-3.7 volts.

Sensors are classified into three categories: passive, omni-directional sensors;passive, narrow-beam sensors; and active sensors. Passive sensors sense the datawithout actually manipulating the environment by active probing. They are selfpowered; that is, energy is needed only to amplify their analog signal. Activesensors actively probe the environment, for example, a sonar or radar sensor, andthey require continuous energy from a power source. Narrow-beam sensors havea well-defined notion of direction of measurement, similar to a camera. Omni-directional sensors have no notion of direction involved in their measurements.

Figure 2.3: Example of Sensor Node

2.5 Sensor Network Topologies

The development and deployment of wireless sensor networks (WSN) have takentraditional network topologies in new directions. Many of today’s sensor applica-tions require networking alternatives that reduce the cost and complexity whileimproving the overall reliability. There are basically four types of wireless sensornetwork topologies.

21

Figure 2.4: Peer-to-Peer Network

2.5.1 Peer-to-Peer

Peer-to-Peer networks allow each node to communicate directly with another nodewithout needing to go through a centralized communications hub. Each Peerdevice is able to function as both a client and a server to the other nodes on thenetwork.

Figure 2.5: Star Network

22

2.5.2 Star

Star networks are connected to a centralized communications hub. Each nodecannot communicate directly with one another; all communications must be routedthrough the centralized hub. Each node is then a client while the central hub isthe server. Every node in this topology communicated its data directly to thecentral hub. The limitation of this topology is its poor scalability and robustnessproperties.

Figure 2.6: Tree Network

2.5.3 Tree

Tree networks use a central hub called a Root node as the main communicationsrouter. One level down from the Root node in the hierarchy is a Central hub.This lower level then forms a Star network. The Tree network can be considereda hybrid of both the Star and Peer to Peer networking topologies.

2.5.4 Mesh

Mesh networks allow data to hop from node to node. Each node is then able tocommunicate with each other as data is routed from node to node until it reachesthe desired location. Mesh network allows any node in the network to transmit toany other node in the network that is with in its radio transmission range.

23

Figure 2.7: Mesh Network

2.6 Routing Protocols in WSN

Routing protocols in WSNs are broadly divided into two categories: NetworkStructure based and Protocol Operation based. Network Structure based routingprotocols are again divided into flat based routing, hierarchical-based routing, andlocation-based routing. Protocol Operation based are again divided into Multi-path based, Query based, QoS based, Coherent based and Negotiation based.

In flat based routing, all nodes are typically assigned equal roles or functionalitysensor nodes collaborate together to perform the sensing task. Due to the largenumber of such nodes,it is not feasible to assign a global identifier to each node.The examples of flat based routing protocols are -SPIN [10,11], Directed Diffusion[12], Rumor Routing [13], MCFA [14], GBR[15],IDSQ and CADR [16], COUGAR[17], ACQUIRE [18], Energy Aware Routing [19] etc.

In hierarchical-based or cluster based routing, nodes will play different roles inthe network. In a hierarchical architecture, higher energy nodes can be used toprocess and send the information while low energy nodes can be used to performthe sensing in the proximity of the target. This means that creation of clusters andassigning special tasks to cluster heads can greatly contribute to overall systemscalability, lifetime, and energy efficiency. Hierarchical routing is an efficient wayto lower energy consumption within a cluster and by performing data aggregationand fusion in order to decrease the number of transmitted messages to the BS.Hierarchical routing is mainly two-layer routing where one layer is used to selectcluster heads and the other layer is used for routing. The examples of hierarchical-

24

based routing protocols are - LEACH [20],PEGASIS [21], TEEN[22], APTEEN[23], MECN [24], SMECN [25], SOP[26], Sensor Aggregate routing [27], VGA[28],HPAR [29], TTDD [30] etc.

In location-based routing, sensor nodes’positions are exploited to route datain the network. In this kind of routing, sensor nodes are addressed by meansof their locations. The distance between neighboring nodes can be estimated onthe basis of incoming signal strengths. Relative coordinates of neighboring nodescan be obtained by exchanging such information between neighbors [37, 38, 39].Alternatively,the location of nodes may be available directly by communicatingwith a satellite, using GPS (Global Positioning System), if nodes are equippedwith a small low power GPS receiver [40].The examples of location-based routingprotocols are - GAF [31], GEAR [32], GPSR [33], MFR,DIR, GEDIR [34], GOAFR[35], SPAN [36] etc.

In multi-path routing, communication among nodes uses multiple paths to en-hance the network performance instead of single path. In Query based routing, thedestination nodes propagate a query for data from a node through the network anda node having this data sends the data which matches the query back to the node,which initiates the query. Usually these queries are described in natural language,or in high-level query languages. In QoS-based routing protocols, the network hasto balance between energy consumption and data quality. The network has to sat-isfy certain QoS metrics, e.g., delay, energy, bandwidth, etc for delivering data tothe BS. In coherent routing, the data is forwarded to aggregators after minimumprocessing. The minimum processing typically includes tasks like time stamping,duplicate suppression, etc. In Negotiation based routing, protocols use high leveldata descriptors in order to eliminate redundant data transmissions through ne-gotiation.Communication decisions are also taken based on the resources that areavailable to them.

2.7 Applications of Sensor Network

2.7.1 Military Applications

Because most of the elemental knowledge of sensor networks is basic on the defenseapplication at the beginning, especially two important programs the DistributedSensor Networks (DSN) and the Sensor Information Technology (SenIT) form theDefense Advanced Research Project Agency (DARPA), sensor networks are ap-plied very successfully in the military sensing[37]. Now wireless sensor networkscan be an integral part of military command, control, communications, computing,intelligence, surveillance, reconnaissance and targeting systems. In the battlefieldcontext, rapid deployment, self-organization, fault tolerance security of the net-

25

work should be required. The sensor devices or nodes should provide followingservices[37]:

1. Monitoring friendly forces, equipment and ammunition

2. Battlefield surveillance

3. Reconnaissance of opposing forces

4. Targeting

5. Battle damage assessment

6. Nuclear, biological and chemical attack detection reconnaissance

2.7.2 Environmental Applications

Nowadays sensor networks are also widely applied in habitat monitoring, agricul-ture research,fire detection and traffic control. Because there is no interruptionto the environment, sensor networks in environmental area is not that strict asin battlefield. Bush Fire Response: A low cost distributed sensor network forenvironmental monitor and disaster response. An integrated network of sensorscombining on the ground sensors monitoring local moisture levels, humidity, windspeed and direction, together with satellite imagery and longer term meteorologi-cal forecasting will enable the determination of fire risk levels in targeted regionsas well as valuable information on probable fire direction. Such a network willprovide valuable understanding of bushfire development and most importantly as-sist authorities in organizing a coordinated disaster response that will save livesand property by providing early warning for high risk areas[38]. Fancy CalifornianWinemaking: A project from Intel (the wireless vineyard) [39]. ”Imagine smartfarmlands where literally every...vine plant will have its own sensor, making surethat it gets exactly the right nutrients, exactly the right watering. Imagine theimpact it could have on difficult areas of the world for agricultural purposes.” IntelChief Technology Officer Pat Gelsinger said[39]. In this project Berkeley motes areinstalled in the test site - an Oregon, USA vineyard located in a region famous forworld-class pinot noir wine. They monitor temperature throughout the vineyard.Each mote in the vineyard currently takes one temperature reading per minuteand stores the results. The mote records the highest and lowest temperature read-ings for each hour of the day. In the future these sensors may also act upon theenvironment. Imagine sensors that could monitor soil moisture to irrigate only thesections that needed it, or monitor crops to keep them free from pests and diseases.Information gathered by sensor networks could guide irrigation or harvesting toimprove quality, providing vineyard owners and managers a better return on their

26

investment. This potential extends to other crops where growers could use motesto maximize yields. The further aim of this project with the help of sensor net-works the owner of vineyard can manage the vineyard works more efficiently andautomatically[40].

2.7.3 Health Applications

Sensor networks are also widely used in health care area. In some modern hospitalsensor networks are constructed to monitor patient physiological data, to controlthe drug administration track and monitor patients and doctors and inside a hos-pital. In spring 2004 some hospital in Taiwan even use RFID basic of above namedapplications to get the situation at first hand. Long-term nursing home [41]: thisapplication is focus on nursing of old people. In the town farm cameras, pressuresensors, orientation sensors and sensors for detection of muscle activity constructa complex network. They support fall detection, unconsciousness detection, vi-tal sign monitoring and dietary/exercise monitoring. These applications reducepersonnel cost and rapid the reaction of emergence situation.

2.7.4 Home Applications

Along with developing commercial application of sensor network it is no so hardto image that Home application will step into our normal life in the future. Manyconcepts are already designed by researcher and architects, like ”Smart Environ-ment: Residential Laboratory” [42] and ”Smart Kindergarten” [43] Some are evenrealized.

27

Chapter 3

Literature Survey

The issue of integrating sensor network to Cloud computing model is not yetaddressed in the literature. Sensor-Grid [45] architecture is already there but aswe mentioned earlier it is not suitable in the current application scenarios. In [46],it is also discussed that current Grid computing applications are different fromthe Cloud applications. Grid is generally focus on HPC related application whileCloud focuses on general purpose applications. Users are now moving from HPCworkloads to more generic workloads for which Cloud is more appropriate solution.

To integrate sensor networks to Cloud, we propose a content based pub-submodel. A Pub/Sub system [47] encapsulates sensor data into events and providesthe services of event publications and subscriptions for asynchronous data exchangeamong the system entities. Several Pub/Sub systems have been developed in recentyears in the context of WSNs most notably in [48]-[51].

Mires [48] is a publish/subscribe architecture for WSNs. Basically sensors onlypublish readings if the user has subscribed to the specific sensor reading. Messagescan be aggregated in cluster heads. Subscriptions are issued from the sink node(typically directly connected to a PC), which then receives all publications.

TinySIP [49] supports session semantics, publish/subscribe, and instant mes-saging. It offers support for multiple gateways. Most communication is done byaddressing individual devices. As device addresses are related to the gateway beingused, changing the gateway on the fly is difficult.

DV/DRP [50] is another publish/subscribe architecture for WSNs. DV/DRPstands for Distance Vector/Dynamic Receiver Partitioning. Subscriptions aremade based on the content of the desired messages. Subscriptions are floodedin the network. Intermediate nodes aggregate subscriptions. They forward publi-cations only if there is an interest for this publication.

MQTT-S [51] is an open topic-based pub-sub protocol that hides the topologyof the sensor network and allows data to be delivered based on interests ratherthan individual device addresses. It allows a transparent data exchange between

28

WSNs and traditional networks and even between different WSNs.In our framework, like MQTT-S, all of the system complexities reside on the

broker’s side but it differs from MQTT-S in that it uses content-based pub-subbroker rather than topic-based which is suitable for our application scenarios.When an event is published, it is transmitted from a publisher to one or moresubscribers without the publisher having to address the message to any specificsubscriber. Matching is done by the pub-sub broker outside of the WSN envi-ronment. In content-based pub/sub system, sensor data has to be augmentedwith meta-data to identify the different data fields. For example, a meta-data ofa sensor value (also event) can be body temperature, blood pressure etc.To de-liver published sensor data or events to subscribers, an efficient and scalable eventmatching algorithm is required by the pub-sub broker.

In [52], authors proposed two event matching algorithms - sequential and sub-order. In sequential algorithm, according to each predicate in event, searchingspace is gradually reduced by deleting subscriptions which are not satisfied. Theadvantage is that no pre-processing for subscriptions and no additional index is re-quired. When the number of attribute increases, the cost approaches to a constantnumber. But the drawback is that at least we need to check every predicate oncein the subscriptions. That means the cost is no less than the total no. predicates.The second algorithm, sub-order, reduces the expected number of predicate evalu-ations by analyzing the expected cost differences when subscriptions are evaluatedin different orders. In case of suborder, connect the same predicates together byusing an index called ”linked chain” that can help to find same predicates quickly,and then it is possible to quickly reserve or delete predicates. The advantage isthat by pre-processing, it can avoid great amount of comparison during the search-ing and also it can further reduce the searching cost when there are many samepredicates in the subscriptions. But the disadvantage is that it is hard or evenimpossible to make chain sometimes, for instance in range predicate case. Anotherproblem is that here every two predicates, if they are same, share a chain. Thusit needs to maintain a complete graph and bring so much overload when insertingand deleting subscriptions.

Forwarding algorithm in [53] matches event data to subscriptions that includea single predicate. It groups predicates using attributes and operators, and indexesthe values of predicates. The advantage is that searching is very fast. But whenpredicates are in range or highly overlapped, this algorithm results in separategroups of predicates by matching operators and finds correct subscriptions bycombining the results of different groups.

In VCR Indexing described in [54], range of each subscription are transferredinto many overlapping rectangles and when event data comes, rectangles whichcontain this event point can be found and then subscriptions are found which

29

contain those rectangles. The advantage is that it performs better when the sub-scriptions are highly-overlapping. But its disadvantage is that it is not scalable. Ifthe number of attribute increases the overhead of rectangle construction and stor-age increases dramatically. Our event matching algorithm targets range predicatecase suitable to our application scenario and it is also efficient and scalable whenthe number of predicates increases.

In [44], authors presented a vision for the creation of global Cloud exchangefor trading services. But authors did not mention about dynamic collaborationbetween cloud providers. In [56], authors proposed a VO based CDN peeringframework.

In [55] the author provides the solution of integrating the industrial sensornetworks with Internet through SOA paradigm, and with cloud technology. Intheir work, an integrated solution with application server (providers), integrationcontroller (through which consumers contacts), and a register agent (registry), isdesigned. The Integration controller is responsible for storing sensed data andprovides recovery system. The main job of IC is uploading sensed data to internetthrough cloud technology, so the authorized user can access sensed data from anywhere in the world.

A number of recent research efforts focus on wearable systems for health mon-itoring. Researchers at the MIT Media Lab have developed MIThril, a wearablecomputing platform compatible with both custom and off-the-shelf sensors. Code-Blue, a Harvard University research project, is also focused on developing WSNsfor medical applications. The sensors, when outfitted on patients in hospitals ordisaster environments, use ad hoc networks to transmit vital signs to health-caregivers, facilitating automatic vital sign collection and real-time triage [57].

Recently, research efforts are beginning to study the integration of WSNs andgrid computing. Researchers in the UK are studying how sensors can be integratedinto e-Science grid computing applications. The Discovery Net project is building agrid-based framework for developing and deploying knowledge discovery services toanalyze data collected from distributed high-throughput sensors. The applicationsinclude life sciences, environmental monitoring, geo-hazard modeling and remotepatient monitoring.

The current trend towards Telemedicine and Telecare evident in the UK [58] hasseen an explosion in the range of locations where advanced medical care needs to bedelivered. E-medicine initiatives such as NHS Direct have illustrated the need tomaximize the flexibility of delivery of health care. Existing trials in Telemedicineand Telecare such as those carried out by the Oxford center for e-health [58],the Biomedical Informatics group at Nottingham University [59] and the GlasgowRoyal Infirmary and Glasgow University [60] have demonstrated the feasibility ofremotely monitoring patients as part of an overall care programme.

30

Chapter 4

Sensor-Cloud: Assimilation ofWireless Sensor Network andCloud

4.1 Introduction

A sensor network is a computer network Composed of a large number of sensornodes. The sensor nodes are densely deployed inside the phenomenon, they deployrandom and have cooperative capabilities. Usually these devices are small and in-expensive, so that they can be produced and deployed in large numbers, and sotheir resources in terms of energy, memory, computational speed and bandwidthare severely constrained. There are different Sensors such as pressure, accelerom-eter, camera, thermal, microphone, etc. They monitor conditions at differentlocations, such as temperature, humidity, vehicular movement, lightning condi-tion, pressure, soil makeup, noise levels, the presence or absence of certain kindsof objects, mechanical stress levels on attached objects, the current characteristicssuch as speed, direction and size of an object.Normally these Sensor nodes con-sist there components: sensing, processing and communicating. WSN have beenevolved in the past few years to enable solutions in the areas such as industrial au-tomation, asset management, environmental monitoring, transportation business,health care, etc. Bringing various WSNs deployed for different applications underone roof and looking it as a single virtual WSN entity through cloud computinginfrastructure is novel. Data generated from a vast sea of sensor applications suchas environmental monitoring, transportation business, health care, etc., is enor-mous. If we add this collection of sensor-derived data to various web based virtualcommunities, we can have a remarkable transformation in the way we see ourselvesand our planet. Some of the examples are - a virtual community of doctors mon-

31

itoring patient health care for virus infection, portal for sharing real-time trafficinformation, real-time environmental data monitoring and analyzing, etc. To en-able this exploration, sensor data of all types will drive a need for an increasingcapability to do analysis and mining on-the-fly. However, the computational toolsneeded to launch this exploration can be more appropriately built from the cloudcomputing model rather than traditional distributed or grid approaches. Cloudcomputing models are designed to provide on-demand capacity for the applicationproviders that involves three parties - the data center, the application providerand the application user vis–vis traditional approaches that operate on two partycontracts. To summarize, integrating WSNs with cloud makes it easy to shareand analyze real time sensor data on-the-fly. It also gives an added advantage ofproviding sensor data or sensor event as a service over the internet. The termsSensing as a Service (SaaS) and Sensor Event as a Service (SEaaS) are coined todescribe the process of making the sensor data and event of interests available tothe consumers respectively over the cloud infrastructure. We propose, a content-based publish/ subscribe platform to utilize the ever expanding sensor data forvarious next generation community-centric sensing applications.

4.2 Sensor-Cloud System Model

A Sensor-Cloud consists of wireless sensor networks (WSNs) and cloud resourceslike computers,servers and disk arrays for the processing and storage of sensor data.The resources in the Sensor-Cloud are shared by several Organizations and certainresources might also belong to more than one organization. Users from various or-ganizations may access the resources in the Sensor Cloud, even if the resources arenot owned by their organization. Figure 4.1 consists of WSNs (i.e. WSN1, WSN2,and WSN3), cloud infrastructure and the clients. Clients seek services from thesystem. WSN consists of physical wireless sensor nodes to sense different appli-cations like Transport Monitoring, Weather Forecasting, and Military Applicationetc. Each sensor node is programmed with the required application. Sensor nodealso consists of operating system components and network management compo-nents. On each sensor node, application program senses the application and sendsback to gateway in the cloud directly through base station or in multi-hop throughother nodes. Routing protocol plays a vital role in managing the network topologyand to accommodate the network dynamics. Cloud provides on-demand serviceand storage resources to the clients. It provides access to these resources throughinternet and comes in handy when there is a sudden requirement of resources.Combining WSNs with cloud makes it easy to share and analyze real time sen-sor data on-the-fly. It also gives an advantage of providing sensor data or sensorevent as a service over the internet. Merging of two technologies makes sense for

32

Figure 4.1: Sensor-Cloud System Model

large number of application such as Transport monitoring, Weather Forecastingand Military Application etc [10].

4.3 Sensor-Cloud Platform

The proposed platform consists of Virtualization Manager, Pub/Sub Broker, Mon-itoring and metering, System Manager, Service Registry, Stream Monitoring andProcessing Component and Application Specific Interface . Figure 4.2 gives anoverview of the components that constitute the sensor-cloud platform.

4.3.1 Virtualization Manager

This component is divided into three subcomponents. They are: Common Inter-face, Data processor and Command Interpreter.

1. Common Interface: Sensor networks are connected with the gateway throughcommon interface in different ways (serial, USB and Ethernet). Gateway

33

Figure 4.2: Sensor-Cloud Platform

receives the raw data from the communication ports and convert it to apacket. The packet is further kept in a buffer for further processing.

2. Data Processor: This component retrieves the packet from the buffer andprocesses according to its type. The packet type depends on the applicationbeing run on the platform.

3. Command Interpreter: This component is responsible for providing reversecommunication channel from the gateway to the WSN and for processingand interpreting various commands issued from different applications andgenerates the code that is understood by the sensor nodes.

4.3.2 Publish/Subscribe Broker

This module is responsible for monitoring, processing and delivering events toregistered users through SaaS applications.

34

4.3.3 Monitoring and Metering(MaM)

This module tracks the usage of the primary cloud resources. Consumer usessigned web service requests to access the data. Role of MaM deals with handlingthe request of consumers, checking of registry manager, keeps track of web servicesetc.

4.3.4 System Manager

This module is responsible for processing and archiving the sensor data and alsomanages the system resources. Computation cycles are utilized internally to pro-cess the data that emanates from the sensors. Storing the sensor data will help toanalyze the patterns in the data collected over a period of time.

4.3.5 Service Registry

It maintains the credentials of different consumers applications register to pub-lisher/subscriber system for various sensor data required. For each application,registry component stores user subscriptions, sensor data and sensor event typesthe application is interested in. Each application is associated with a unique ap-plication ID along with the service level agreement (SLA). SLA provides basis formetering and accounting of services to be used, by covering all the attributes ofthe service customs.

4.3.6 Stream Monitoring and Processing (SMP)

SMP monitors the sensor streams comes in many different forms from differentsources and invokes correct analysis method. This module is divided into threesub components: registry component, analyzer component and disseminator com-ponent.

1. Registry Component (RC): Registry component stores user subscriptions ofdifferent applications and user specific sensor data types of those users whoregister to Pub/Sub Agent.It also sends all user subscriptions along withapplication id to the disseminator component for event delivery.

2. Analyzer Component (AC): AC analyzes the incoming sensor data or eventto match with user subscriptions in the Service registry. If the sensor datamatches with the interest of the subscriber, the same is handed over to thedisseminator component to deliver to the appropriate users.

35

3. Disseminator Component (DC): DC receives the data or event of interestfrom the analyzer component and delivers the data through SaaS interfaceto the subscribed applications.

4.3.7 Application Specific Interface

The interfaces give access to the WSN cloud platform web services. Consumers canconsume the services through web services that are often referred to as internetapplication programming interface (IAPI). This allows the users to access theremotely hosted services over network, such as internet. Consumers can buildtheir customer applications by weaving the required services from the WSN cloudplatform.

4.4 Sensor-Cloud Architecture

Figure 4.3: Sensor-Cloud Architecture

This framework aims at bringing sensor data to a pub/sub Agent throughgateways. Pub/sub agent delivers information to the consumers of applications

36

interfaces. The WSN cloud platform web services are granted access through theinterfaces built with Web 2.0 technologies. The masking of the lower level detailsof each WSN cloud in terms of different platforms, sensors being used, data beinggenerated is done by the Virtualization Manager. The various SaaS applicationstransfer the information and subscriptions of the registered users to pub/sub Agentregistry. Sensor data, on reaching the system from gateways, are then determinedthrough stream monitoring and processing component (SMPC) in the pub/subAgent as to whether they need processing or just have to be stored for periodicsend or for immediate delivery. If in case sensor data need periodic/ emergencydelivery, the analyzer determines which SaaS applications the events belong toand then pass the events to the disseminator. The disseminator then delivers theevents for use by finding appropriate subscribers for each application with thehelp of event matching algorithm. Computational cycles are provided internallyby SM as required to process the data emanated from the sensors. SRM managesthe users’ subscriptions and credentials. MaM calculates the price for the offeredservices.

4.5 Sensor-Cloud Design Issues and Challenges

In this section, we discuss the important issues and challenges in the design of Sen-sor Clouds. Most of these design issues and challenges arise due to the inherentlimitations of sensor devices such as limited processor performance, small storagecapacity, limited battery power, and unreliable low-bandwidth wireless communi-cation and some issue arise due issue de-facto standard of cloud such as reliability,back up, privacy, security ownership etc.

4.5.1 Sensor Issues

1. Power Management: Power management is a major concern as sensor nodesdo not have fixed power sources and rely on limited battery power. Sensorapplications executing on these devices have to make tradeoffs between sen-sor operation and conserving battery life. The sensor nodes should provideadaptive power management facilities that can be accessed by the applica-tions. From the Sensor-Cloud perspective, the availability of sensor nodesis not only dependent on their load, but also on their power consumption.Thus, the Sensor Cloud resource management component has to account forpower consumption.

2. Scalability: Scalability is the ability to add sensor resources to a Sensor-Cloud to increase the capacity of sensor data collection, without substantial

37

changes to its software architecture. The Sensor-Cloud architecture shouldallow multiple wireless sensor networks, possibly owned by different virtualorganizations, to be easily integrated with compute and data cloud resources.

3. Network Connectivity and Protocols: The network connections are usuallyfast and reasonably reliable in cloud. On the other hand, the sensor nodesin Sensor Clouds are connected via wireless ad hoc networks which are low-bandwidth, high-latency, and unreliable. The network connectivity of sensornodes is dynamic in nature, and it might be irregular and vulnerable to faultsdue to noise and signal degradation caused by environmental factors. TheSensor-Cloud has to gracefully handle unexpected network disconnections orprolonged periods of disconnection. Thus, efficient techniques to interfacesensor network protocols with cloud networking protocols are necessary.

4. Scheduling: In wireless sensor networks, scheduling of sensor nodes is oftenperformed to facilitate power management and sensor resource management.Researchers have developed algorithms to schedule the radio communicationof active sensor nodes, and to turn off the radio links of idle nodes to conservepower. Similarly, for applications like target tracking, sensor managementalgorithms selectively turn off sensor nodes that are located far away fromthe target, while maximizing the coverage area of the sensors.

5. Availability: Due to the power issue and the unpredictable wireless networkcharacteristics, it is possible that applications running on the sensor nodesmight fail. Thus, techniques to improve the availability of sensor nodes arenecessary. Sensor Clouds should support job and service migration, so thata job can be migrated from a sensor node that is running out of power orhas failing hardware to another node.

4.5.2 Cloud Issues

1. Reliability: Stability of the data storage system is of important considerationin clouds. Generally, people worry about whether a cloud service provideris financially stable and whether their data storage system is trustworthy.Most cloud providers attempt to mollify this concern by using redundantstorage techniques, but it is still possible that a service could crash or go outof business, leaving users with limited or no access to their data.

2. Data Backup: Cloud providers employ redundant servers and routine databackup processes, but some customers worry about being able to controltheir own backups. Many providers are now offering data dumps onto mediaor allowing users to back up their data through regular downloads.

38

3. Privacy: The Cloud model has been criticized by privacy advocates for thegreater ease in which the companies hosting the Cloud services control andmonitor communication and data stored between the user and the host com-pany lawfully or unlawfully. There have been efforts to ”harmonize” thelegal environment by deploying local infrastructure and allowing customersto select ”availability zones.

4. Security: Cloud service providers employ data storage and transmission en-cryption, user authentication, and authorization. Many clients worry aboutthe vulnerability of remote data to criminals and hackers. Cloud providersare enormously sensitive to this issue and apply substantial resources to mit-igate this problem.

5. Ownership: Once data has been relegated to the cloud, some worry aboutlosing their rights or being unable to protect the rights of their customers.Many cloud providers address this issue with well-skilled user-sided agree-ments. According to the agreement, users would be wise to seek advice fromtheir favorite legal representative.

6. Availability and Performance: Business organizations are worried about ac-ceptable levels of availability and performance of applications hosted in thecloud.

7. Legal: There are certain points of concern for a cloud provider and a clientreceiving the service like location of the cloud provider, location of infrastruc-ture, physical location of the data and out sourcing of the cloud providersservices etc.

Sensor networks is a relatively recent field and there are many research issuespertaining to sensor networks such as energy management, coverage, localization,medium access control, routing and transport, security etc. Research in cloud com-puting is also in fantasy stage. It also has a number of research challenges suchas efficient resource allocation, high resource utilization and security etc. Apartfrom the afore-mentioned research issues in sensor networks and cloud computing,sensor-cloud computing gives rise to additional research challenges, especially whenit is used in mission-critical situations. These research challenges are: web servicesand service discovery which work across both sensor networks and the cloud, in-terconnection and networking, coordinated quality of service (QoS) mechanismsetc.

39

Chapter 5

Sensor-Cloud Application inPatient Monitoring

5.1 Introduction

Wireless sensor network technologies are considered as one of the key research areasin computer science and health-care application industries. The pervasive health-care systems provide rich contextual information and alerting mechanisms againstodd conditions with continuous monitoring. This minimizes the need for caretak-ers and helps the chronically ill and elderly to survive an independent life. Sensornetworking devices in WSNs are resource constrained since they have limited pro-cessing power and communication bandwidth. However, with a large number ofsuch devices being deployed and aggregated over a wide area, WSNs have sub-stantial data acquisition and processing capability. Thus, WSNs are importantdistributed computing resources that can be shared by different groups of patientsin different environments. The emerging domain of WSNs with the cloud ex-tends the cloud computing paradigm to the sharing of sensor resources in WSNs.In this paper, we propose wireless sensor cloud architecture for monitoring thehealth status of different groups of patients to provide a platform for physiciansand researchers to share information with distributed database and computationalresources to facilitate analysis, diagnosis, and prognosis and drug delivery.

One of the major challenges of the world for the last decades has been the con-tinuous elderly population increase in the developed countries. Hence the need ofdelivering quality care to a rapidly growing population of elderly while reducing thehealth-care costs is an important issue. One promising application in that areais the integration of sensing and consumer electronics technologies which wouldallow people to be constantly monitored [61]. In-home pervasive networks mayassist residents and their caretakers by providing continuous medical monitoring,

40

memory enhancement, control of home appliances, medical data access, and emer-gency communication [62, 63]. Constant monitoring will increase early detection ofemergency conditions and diseases for at risk patients and also provide wide rangeof health-care services for people with various degrees of cognitive and physicaldisabilities [64].

A link between Wireless Sensor Networks (WSNs) and cloud computing wouldbe an exciting avenue to explore. By integrating the two systems, the WSN wouldcollect large quantities of data which could be processed intensively and storedeffectively within the cloud system. The combination of the two systems, that is,the wireless sensor cloud, would provide a powerful platform for a range of researchstudies, large-scale military operations, medical applications and commercial or-ganizations. This paper proposes a technique for monitoring different groups ofpatients using a wireless sensor cloud. The need to make cloud facilities available”in the field” is particularly critical in the case of medical services where muchof the day to day work of medicine centers on the patient requiring a number ofmedical professionals to correlate medical data with patient examination and ob-servation. The ultimate goal is to increase the availability of medical care in orderboth to reduce the demands on hospital services and to improve the long-termcare and recovery of patients. This system also reduces the time of routine check-ups and its real- time monitoring also allows emergency situations to be handledimmediately. The data are published via web servers. Health-care professionals,researchers and patients can access the long-term physiological data via the In-ternet. A secure web server allows authenticated users to access real-time patientinformation to consult with medical specialists located at distant places.

5.2 Design Consideration for Patient Monitor-

ing System

The medical applications of wireless sensor networks aim to improve the existinghealth-care and monitoring services especially for the elderly, children and chron-ically ill. There are several benefits achieved with these systems. To begin with,remote monitoring capability is the main benefit of pervasive health-care systems.With remote monitoring, the identification of emergency conditions for at riskpatients will become easy and the people with different degrees of cognitive andphysical disabilities will be enabled to have a more independent and easy life. Thelittle children and babies will also be cared for in a more secure way while theirparents are away. Identifying emergency situations like heart attacks or suddenfalls in a few seconds or even minutes will suffice for saving lives considering that,without them these conditions will not be identified at all. Therefore, provid-

41

ing real-time identification and action taking in pervasive health-care systems areamong the main benefits. The technology advancements in consumer electronicshave reduced the production costs and have made it possible to afford inexpensivesensor devices for ordinary users as well. Together with the mature and also in-expensive RFID technology, the costs for pervasive health-care systems are withinthe affordable range for many people. In caretaker’s Assistant [68], inexpensiveRFID tags are placed on household object and the systems precision can be in-creased at very low costs, by tagging more objects with these RFID tags. Beingable to identify the context is another benefit achieved with pervasive health-caresystems. Context awareness enables us to understand the conditions of the peopleto be monitored constantly and environments in which these people are. Thiscontext information is achieved mostly by sensing systems that incorporate morethan one type of sensing capabilities. By fusing the information gathered by sev-eral sensors, we may have a more clear understanding of the context. The contextinformation helps better in identifying the unusual patterns and making more pre-cise inferences about the situation. For instance, if we can identify the location ofthe person to be tracked and the activity he/she is busy with together with his/hervital signs; we can deduce useful information out of these. During night-time, be-ing in the sleeping room in a lying position may not indicate something seriouswhereas lying down in the sleeping room in the middle of the day may indicate analarm situation. Context-awareness provides this useful information to us. Thereare several prototypes as well as commercially available products. When severalapplications are investigated, it is observed that these applications have commonproperties. Most of the existing solutions include one or more types of sensorscarried by the patient, forming a Body Area Network (BAN), and one or moretypes of sensors deployed in the environment forming a Personal Area Network(PAN). These two are connected to a backbone network via a gateway node. Atthe application level, the health care professionals or other caretakers can mon-itor the vital health information of the patient in real-time via a graphical userinterface (GUI). The emergency situations produce alerts by the application andthese alerts and other health status information can be reached via mobile deviceslike laptop computers, Personal Digital Assistants (PDAs) and smart phones. Theoverview of a simple wireless sensor network for health care scenario is depictedin fig 5.1. Based on this observation, in a typical scenario, there are four differentcategories of actors other than the power users of the systems such as adminis-trators and developers. Recent advances in electronic circuit miniaturization andmicro-electromechanical systems (MEMS) have led to the creation of small wire-less sensor nodes which integrate several kinds of sensor, a central processing unit(CPU), memory and a wireless transceiver. These nodes are capable of sensing andcommunicating one or more vital physiological signals from the patients and inte-

42

Figure 5.1: WSN Application Scenario for Health Care

grating them into wireless personal or body networks for health monitoring [65].These networks promise to revolutionize health care by allowing inexpensive, non-invasive, continuous health monitoring of post-operative patients at hospital andelderly patients in home environments with almost real-time updates of medicalrecords. Physiological sensors are attached in the human body to monitor disor-ders in the heart and brain during normal activities and to help patients maintaintheir health even after surgery. The integration of sensing and communicationtechnologies has allowed monitoring of elderly patients in home environments andpost-operative patients in hospitals for early detection of adverse conditions anddiseases, definitely saving more lives [66]. Patients recovering from surgery are atrisk of complications due to reduced mobility as a result of post-operative pain.The ability to pervasively monitor the recovery of this group of patients and iden-tify those at risk of developing complications is therefore clinically desirable; itmay result in an early intervention to prevent adverse outcomes [67].

5.3 Sensor Cloud Architecture for Patient Mon-

itoring

The architecture of a wireless sensor cloud comprises a number of different sitesthat are geographically distributed and belong to different divisions of organiza-tions, connected through a sensor cloud. In particular, the post-operative patients’sites are equipped with wireless sensor nodes for retrieval of data from sensors,which transfer the collected data to the central database.The proposed architec-ture consists of the following components: a graphical user interface, a central

43

medical server, a cloud server a WSN deployed near the patient’s site. Our archi-tecture framework is a hybrid architecture that combines WSNs and cloud- enabledsoftware tools that support the storage, processing and information-sharing tasks.The data are acquired from patients at all the sites mentioned and the data repli-cas are transferred to databases. The transfer comprises the actual sensor data,denoted as data, and the information which is provided by physicians during theannotation phase [69]. These two units of information (data and metadata) must

Figure 5.2: Sensor-Cloud Architecture for Monitoring Patients at Hospital

be transferred to a database that can be accessed by all the authorized and au-thenticated parties. Thus, the services must include certain security properties,something that is already inherent in the cloud. The security and privacy will beprovided by Cloud environment. A cloud user authenticates him by presentingan X.509 proxy certificate, and as a result, security properties like authentica-tion, authorization, integrity and non-repudiation are provided. Proxy certificatesuse the format described for X.509 public key certificates. They serve to bind aunique public key to a subject name, as a public key certificate does. The useof the same format as X.509 public key certificates allows proxy certificates tobe used in protocols and libraries in many places as if they were normal X.509public key certificates, which significantly eases implementation. However, unlikea public key certificate, the issuer (and signer) of a proxy certificate is identifiedby a public key certificate or another proxy certificate rather than a certificationauthority (CA) certificate. Proxy certificates can also be created so as to delegateprivileges from an issuer to another party over a network connection without theexchange of private keys. Our proposed architecture provides a platform for clini-cians and researchers within the sensor cloud consortium to share information in

44

Figure 5.3: High Level Architecture of Sensor-Cloud with Medical Server andCloud Server

distributed databases and computational resources to facilitate the analysis, diag-nosis and care for patients within the cloud. The proposed architecture comprisesof following components:

1. A front end composed of the different sensors for the recording of the vitalsignals that are demanded by the application (ECG, respiration and activitylevel).

2. A patient station, which consists of a mote device that receives informationfrom the sensors and is responsible for the first stage of data processing inthe data communication. The received signal is sent to a central server foranalysis.

3. A central medical server, which is the core processing element, receives thepatient’s data from the patient station for analysis. It also performs complexon-line and off-line analysis, data mining, and prediction with the informa-tion databases. The analysis is done using moteView software and generatesalerts to the medical professionals, caretakers and emergency medical de-partment personnel.

4. A cloud server is used for authentication and for identifying abnormal dataand alerting the physicians, emergency departments and caretakers for fur-ther follow-up of the patients.

45

5.4 Event Matching Algorithm for Patient Mon-

itoring

To deliver publish events to appropriate consumers who subscribed an efficientevent matching algorithm is required for our Sensor-Cloud framework. We aretargeting the Cloud-based health-care monitoring system where doctors and re-searchers express their interests into a range. Normally, in our system, a subscrip-tion S is expressed by a pair (Sid,P) where Sid is the subscriber’s ID (subscriber IDfor short) and P is a set of predicates specifying subscriber’s interest. P consistsof five elements as given below:

P = [event-type, N, op, mPV , MPV]where event-type = detail event name (i.e. body temperature, blood pressure)mPV = minimum threshold value of predicateMPV = maximum threshold value of predicateN = count of predicatesop = represents operators like greater than lesser than etc.Here is one example of a subscription and an event in the system Subscription

S : [body temperature, 1,><, 29, 32] which contains two predicates that are joinedtogether to specify a range value or range predicate [ i.e. p1=body temperature>29and p2=body temperature < 32]. An event satisfies a subscription only if itsatisfies all predicates in the subscription. Here, the event e = [body temperature=30] satisfies the subscription S since body temperature is within the range. Sothe matching problem is: Given an event e and a set of predicates in subscriptionset S. We need to find all subscriptions in set S that are satisfied by e.

Let S is a set of subscriptions, S=[s1, s2, s3....sn] where n is the total no. ofsubscriptions and P is a set of predicates in S, P=[p1, p2, p3,...pm] where m is thetoal no of predicates in a subscription. In our system we have two predicates in asubscription [i.e. data > mPV and dat< MPV ] and these two predicates is usedto group the subscriptions. We define a set S’ that contains all the subscriptionsof S sorted by mPV value in ascending order. Then we define a grouping sequence(mG1, mG2,...mGg) such that g = [1+log (n)] and S’ is the summation of all mGrwhere n is the total no of subscriptions in S’.The grouping space, denoted by SP(S’,g) is defined as the set containing all such group sequences over S’ and g. Noweach mGi contains k= [n/g] no of subscriptions, so group index, gI=[min(mPV)-max(mPV)] is created for each gI.

After grouping of subscriptions, first predicate of an event is composed withgroup index gI and if any match found then second predicate is compared withgroup indexes hI within MG and so on. Finally sequential matching is done in theselected groups to find the subscriptions that are satisfied by all predicates in theevent. The pseudo code of grouping and event method is shown in fig 5.4 and 5.5.

46

Figure 5.4: Event Grouping Algorithm

47

Figure 5.5: Event Matching Algorithm

48

Chapter 6

Environmental Setup andImplementation

6.1 Epileptic Seizure: A Case Study

Epilepsy is a brain disorder in which clusters of nerve cells, or neurons, in the brainsometimes signal abnormally. Neurons normally generate electrochemical impulsesthat act on other neurons, glands, and muscles to produce human thoughts, feel-ings, and actions. In epilepsy, the normal pattern of neuronal activity becomesdisturbed, causing strange sensations, emotions, and behavior, or sometimes con-vulsions, muscle spasms, and loss of consciousness. During a seizure, neurons mayfire as many as 500 times a second, much faster than normal. In some people, thishappens only occasionally; for others, it may happen up to hundreds of times aday.An epileptic seizure, occasionally referred to as a fit, is defined as a transientsymptom of ”abnormal excessive or synchronous neuronal activity in the brain”.The outward effect can be as dramatic as a wild thrashing movement (tonic-clonicseizure) or as mild as a brief loss of awareness (absence seizure). It can manifest asan alteration in mental state, tonic or clonic movements, convulsions, and variousother psychic symptoms. Sometimes it is not accompanied by convulsions but afull body ”slump”, where the person simply will lose body control and slump tothe ground. The medical syndrome of recurrent, unprovoked seizures is termedepilepsy, but seizures can occur in people who do not have epilepsy.

About 25 percentage of people will have an unprovoked seizure by the ageof 80 and the chance of experiencing a second seizure is between 30 percentageand 50percentage. Treatment may reduce the chance of a second one by as muchas half. Most single episode seizures are managed by primary care physicians(emergency or general practitioners), whereas investigation and management ofongoing epilepsy is usually done by neurologists.

49

The signs and symptoms of seizures vary depending on the type. Seizures maycause involuntary changes in body movement or function, sensation, awareness, orbehavior. Seizures are often associated with a sudden and involuntary contractionof a group of muscles and loss of consciousness. However, a seizure can also beas subtle as a fleeting numbness of a part of the body, a brief or long term lossof memory, visual changes, sensing/discharging of an unpleasant odor, a strangeepigastric sensation, or a sensation of fear and total state of confusion. A seizurecan last from a few seconds to status epilepticus, a continuous group of seizuresthat is often life-threatening without immediate intervention. Therefore seizuresare typically classified as motor, sensory, autonomic, emotional or cognitive.

Causes of epileptic seizures include: Dehydration, sleep deprivation, head in-jury intoxication with drugs, infection, fever and metabolic disturbances etc.

6.2 Application Scenario

1. A patient wears up to 8 sensors equipped with MEMS accelerometers andgyroscopes

2. A base station, such as a laptop in the patient’s home, collects data fromthe network.

3. The data is then delivered via an Internet connection to the clinic where itis visualized and further processed by physicians.

4. The patient will put on the sensors in the morning and take them off torecharge each night.

5. This application involves detection of the onset of epileptic seizures

6. The patient is observed for several days (in a hospital) while withholdinganticonvulsant medications, thereby permitting seizures to occur.

6.3 Environmental Components

6.3.1 Mercury Wearable Sensor Network Platform

Mercury is a wearable, wireless sensor platform. It is designed to overcome thecore challenges of long battery lifetime and high data fidelity for long-term studies.It supports data collection on patients in hospital and home settings. It provideflexible programming interface allowing a range of policies to be implemented ontop of the core functionality of the sensor network.

50

Figure 6.1: Mercury Wearable Sensor Network Platform

A. SHIMMER Wearable Sensor Node

The SHIMMER comprises of:

1. An embedded micro-controller (TI MSP430; 8-MHz clock speed; 10-KBRAM; 48-KB ROM)

2. A low power radio (Chipcon CC2420; IEEE 802.15.4; 2.4 GHz; 250-Kb/sPHY data rate).

3. A MicroSD slot supporting up to 2 GB of flash storage.

4. A 250 mAh Li-polymer rechargeable battery.

Fig.6.2 shows a typical wearable sensor node for medical applications, the SHIM-MER platform [70].

B. miTag with Pulse Oximeter

The miTag is a wearable 2-way communication device. It displays text and graph-ics to allow a patient to communicate with his/her medical providers. miTags usea robust wireless mesh network that is self-organizing and self-healing. Thousandsof miTags can be quickly deployed simultaneously because they require no pre-existing network infrastructure. The miTag is a replacement for the conventionalpaper triage tag. A triage priority level is set on the tag and this is wirelessly re-layed to a central command station. As each patient wears the miTag, the medicalresponse teams now have a way to keep accurate and up-to-date records of their

51

Figure 6.2: Shimmer Wearable Sensor Node

patients. miTags monitor patient heart rate and pulse oxygenation level using apulse oximeter sensor. These disposable and reusable sensors are available for thefinger and forehead and open to pediatric adults.

Figure 6.3: miTag with Pulse Oximeter

6.3.2 Medical server

The medical server is used to store the data simultaneously and to do the on-line and off-line analysis and prediction from the gathered information. The largeamount of collected physiological data will allow a quantitative analysis of variousconditions and patterns. Data mining is a complex process that allows discover-ing unsuspected meaningful knowledge in large databases. The process could beclassification, clustering, association rule mining, attributes, etc. The algorithmdeveloped for analyzing ECG signals is capable of detecting similar sequential pat-terns in a set of time series. The algorithm will be useful for finding significantsubsequences that are likely to characterize a set of non-uniform time series. The

52

3 min ECG data have been used for testing this algorithm. One of the most com-mon tasks involved before testing is to take a reference template for comparingreal time data that come from the patients.

6.3.3 Cloud Server

Data from WSNs are stored in a cloud server to facilitate analysis, diagnosis andalerting when a life-threatening event occurs. The criterion of our architectureframework design was to make the use of the cloud infrastructure completelytransparent to the physicians, caretakers, and researchers. Using the cloud toprovide seamless access to geographically distributed data and high computa-tional resources for complex analysis, more accurate and efficient diagnosis canbe achieved.

6.4 Observation and Result

A 72 year old woman was referred to a neurologist for evaluation after gettingunconscious due to statistical epileptic seizure. The neurologist kept the patientunder observation in the ICU. After getting admitted in the ICU; the patient’s dis-ease symptoms were recorded with help mercury wearable sensor platform. near-est to the patient body. Then the captured data were sent to the medical serverthrough the base station.

Figure 6.4 shows an epileptic seizure patient kept under observation with thehelp of mercury wearable platform.Eight numbers of shimmer nodes were attachedat the various places of the patient of the body to capture symptoms like bloodpressure and temperature. One miTag with Pulse oximeter was attached in thehand to capture the heartbeat rate and respiration level. The real-time datacaptured by the sensors were displayed in the monitor attached

Fig. 6.5 represents the output of the medical server which displays the moni-toring of patient data. The results show that our system is capable of continuouslymonitoring/logging the patient’s daily activities.The medical server is used to storethe data simultaneously and to do the on-line and off-line analysis and predictionfrom the gathered information. Data from WSNs are stored in a cloud server tofacilitate analysis, diagnosis and alerting when a life-threatening event occurs.

Fig. 6.6 shows the alert window in the cloud server when an anomaly event isdetected. When an anomaly is detected in the patient’s vital sign, the applicationsoftware generates an alert for the physicians, caretakers and emergency depart-ment personnel through SMS. In our implementation, the cloud portal serves asan interface between an end user (e.g. a clinician or a researcher) and the cloud.At the client side, a doctor staying far away from the patient’s clinic could log into

53

Figure 6.4: An Elliptic Seizure Patient under observation in an ICU

the cloud portal via a web browser. After user authentication (login/password),the doctor can make use of the services provided by the cloud and could suggestnecessary drugs which much be given to the patient to recover him/her from liferisk. When doctor submits its suggestion in the portal, an SMS alert will be sentto the patient’s caretaker reminding him to give recently prescribed drugs to thedesired patent as soon as possible. The cloud portal sits in a web server withrelevant components (e.g. databases and classes) and establishes connections be-tween an end-user and the lower layer cloud services. A nurse/physician logs ontothe system to collect the data about a patient’s health status. The doctor placesthe request to view the heart beat rate and the blood pressure value of a patientwho is recovering from cardiac surgery. The server now sends the request to theparticular WSN monitoring the patient concerned, to collect the data.

Fig. 6.7 is the snapshot of a webpage showing the patients’ details such as name,age, address, the current heart rate and temperature. Our web-based informationportal allows different types of user to access the patient information in real time.

1. Caretakers may log onto a web site under a patient account to review vitalstatistics and the location of the elderly patients who had been tagged withsensors.

54

2. Medical specialists, located at a distance, may view their respective patients’real-time health status and alert the caretakers near the patients through thedoctor’s login.

3. Emergency personnel have full access to all data in the system. They canadd new patients, health professionals, and administrators. They can accessand change the information of all the participants.

Figure 6.5: Medical Server output for Monitoring Patients

The sensor cloud architecture also provides various medical organizations andphysicians across the world with access to the medical records of patients in orderto refer and/or consult some critical case with some other doctor or physician whois far away from the patient site, and also enables them to come together to shareresources and collaborate with each other in order to achieve efficient medicalcare. Therefore we developed a collection of user friendly interfaces which allowphysicians to get access to the resources without any prior knowledge of cloudtechnologies.

55

Figure 6.6: Snapshot of Emergency Alert Window when Anomaly Detected

Figure 6.7: Web Page Showing Patient Details

56

Chapter 7

Conclusion

Cloud computing promises to change the economics of the data center, but beforesensitive and regulated data move into the public cloud, issues of security standardsand compatibility must be addressed including strong authentication, delegatedauthorization, and key management for encrypted data, data loss protections,and regulatory reporting. All are elements of a secure identity, information andinfrastructure model, and are applicable to private and public clouds as well as toIAAS, PAAS and SAAS services.

In the development of public and private clouds, enterprizes and service providerswill need to use these guiding principles to selectively adopt and extend securitytools and secure products to build and offer end-to-end trustworthy cloud comput-ing and services. Fortunately, many of these security solutions are largely availabletoday and are being developed further to undertake increasingly seamless cloudfunctionalities.

Cloud computing is the most popular notion in IT today; even an academicreport from UC Berkeley says ”Cloud Computing is likely to have the same impacton software that foundries have had on the hardware industry.” They go on torecommend that ”developers would be wise to design their next generation ofsystems to be deployed into Cloud Computing”. While many of the predictionsmay be cloud hype, we believe the new IT procurement model offered by cloudcomputing is here to stay. Whether adoption becomes as prevalent and deep assome forecast will depend largely on overcoming fears of the cloud. Cloud fearslargely stem from the perceived loss of control of sensitive data. Current controlmeasures do not adequately address cloud computing third-party data storageand processing needs. Extending control measures from the enterprize into thecloud through the use of Trusted Computing and applied cryptographic techniquesshould alleviate much of today’s fear of cloud computing.

Combination of the two talented technologies, wireless sensor networks andcloud computing which further results in sensor clouds significantly enhances the

57

prospective of these technologies for new and powerful applications. This furtherexplains the reason of the widespread adoption of this technique in industries.Thus, we believe that sensor clouds will attract growing attention from the researchcommunity and the industry.

In this thesis, we propose a framework of Sensor-Cloud connection to utilize theever-expanding sensor data for various next generation community-centric sensingapplications on the Cloud. It can be seen that the computational tools neededto launch this exploration is more appropriately built from the data center cloudcomputing model than the traditional HPC approaches or cloud approaches. Wepropose a content-based pub-sub model to enable this framework. Also to deliverpublished sensor data or events to appropriate users of Cloud applications, wepropose an efficient and scalable event matching algorithm which targets rangepredicate case.

Our proposed architecture aims to provide a cloud-enabled network that fa-cilitates secure and seamless sharing of different groups of patients’ physiologicalinformation and to support the acquisition and analysis of patients to combat ma-jor diseases on an individual basis. The data are distributed into databases locatedin all the individual systems. Information from the distributed databases is madeavailable, securely, over the Internet to provide access to patients and cliniciansto combat major health diseases. This powerful combination would enable us togive effective early alerts to the specialists, researchers and caretakers about theirpatients’ health status. This enables the doctors to share the databases of differ-ent groups of patients’ physiological status from which high-value computationslike decision-making, data mining and prediction of diseases can take place. Thedata are published via web servers. Health-care professionals, researchers and pa-tients can access the long-term physiological data via the Internet. A secure webserver allows authenticated users to access real-time patient information to consultmedical specialists located at distant places.

58

Bibliography

[1] C. Ulmer, L. Alkalai and S. Yalamanchili, Wireless distributed sensor networksfor in-situ exploration of mars, Work in progress for NASA Technical Report.http://users.ece.gatech.edu/

[2] P. Mell and T. Grance, ”Draft nist working definition of cloud computing -v15,” 21. Aug 2005, 2009.

[3] M. Armbrust, A. Fox, R. Grinth, A. Joseph, R. Katz, A. Konwinski, G. Lee,D. Patterson,A. Rabkin, and I. Stoica, ”Above the clouds-A Berkeley viewof cloud computing,” EECS Department, University of California, Berkeley,Tech. Rep. UCB/EECS-2009-28, 2009.

[4] Rmer, Kay, Friedemann Mattern (December 2004), ”The De-sign Space of Wireless Sensor Networks”, IEEE Wireless Com-munications 11 (6): 54-61, doi:10.1109/MWC.2004.1368897,http://www.vs.inf.ethz.ch/publ/papers/wsn designspace.pdf

[5] Thomas Haenselmann (2006-04-05). Sensornetworks. GFDL Wireless Sen-sor Network text book. http://pi4.informatik.uni/mannheim.de/haensel/snbook. Retrieved 2006-08-29.

[6] vTiwari, Ankit et. al, Energy-efficient wireless sensor network design and im-plementation for condition-based maintenance, ACM Transactions on SensorNetworks (TOSN), http://portal.acm.org/citation.cfm?id=1210670

[7] Hadim, Salem, Nader Mohamed (2006), ”Middleware Chal-lenges and Approaches for Wireless Sensor Networks”, IEEE Dis-tributed Systems Online 7 (3): 1,doi:10.1109/MDSO.2006.19,http://doi.ieeecomputersociety.org/10.1109/MDSO.2006.19art. no. 0603-o3001.

[8] http://en.wikipedia.org/wiki/Sensor Networks

59

[9] Akyildiz, I.F., W. Su, Y. Sankarasubramaniam, E. Cayirci, ”A Survey onSensor Networks”, IEEE Communications Magazine, August, 102-114(2002).

[10] W. Heinzelman, J. Kulik, and H. Balakrishnan, ”Adaptive Protocols for Infor-mation Dissemination in Wireless Sensor Networks,” Proc. 5th ACM/IEEEMobicom Conference (MobiCom ’99), Seattle, WA, August, 1999. pp.174-85.

[11] J. Kulik, W. R. Heinzelman, and H. Balakrishnan, ”Negotiation-based pro-tocols for disseminating information in wireless sensor networks,” WirelessNetworks, Volume: 8, pp.169-185, 2002.

[12] C. Intanagonwiwat, R. Govindan, and D. Estrin, ”Directed diffusion: a scal-able and robust communication paradigm for sensor networks,” Proceedingsof ACM MobiCom ’00, Boston,MA, 2000, pp. 56-67.

[13] D. Braginsky and D. Estrin, Rumor Routing Algorithm for Sensor Net-works,In the Proceedings of the First Workshop on Sensor Networks andApplications (WSNA), Atlanta, GA, October 2002.

[14] F. Ye, A. Chen, S. Liu, L. Zhang, A scalable solution to minimum cost for-warding in large sensor networks”, Proceedings of the tenth InternationalConference on Computer Communications and Networks (ICCCN), pp. 304-309, 2001.

[15] C. Schurgers and M.B. Srivastava, Energy efficient routing in wireless sensornetworks”, in the MILCOM Proceedings on Communications for Network-Centric Operations: Creating the Information Force, McLean, VA, 2001.

[16] M. Chu, H. Haussecker, and F. Zhao,Scalable Information-Driven SensorQuerying and Routing for ad hoc Heterogeneous Sensor Networks,” The In-ternational Journal of High Performance Computing Applications, Vol. 16,No. 3, August 2002.

[17] Y. Yao and J. Gehrke, The cougar approach to in-network query processingin sensor networks”, in SIGMOD Record, September 2002.

[18] N. Sadagopan et al., The ACQUIRE mechanism for efficient querying in sensornetworks, in the Proceedings of the First International Workshop on SensorNetwork Protocol and Applications, Anchorage, Alaska, May 2003.

[19] R. C. Shah and J. Rabaey, Energy Aware Routing for Low Energy Ad HocSensor Networks”, IEEE Wireless Communications and Networking Confer-ence (WCNC), March 17-21, 2002, Orlando, FL.

60

[20] W. Heinzelman, A. Chandrakasan and H. Balakrishnan, ”Energy-EfficientCommunication Protocol for Wireless Microsensor Networks,” Proceedings ofthe 33rd Hawaii International Conference on System Sciences (HICSS ’00),January 2000.

[21] S. Lindsey, C. Raghavendra, PEGASIS: Power-Efficient Gathering in SensorInformation Systems”,IEEE Aerospace Conference Proceedings, 2002, Vol. 3,9-16 pp. 1125-1130.

[22] A. Manjeshwar and D. P. Agarwal, ”TEEN: a routing protocol for enhancedefficiency in wireless sensor networks,” In 1st International Workshop on Par-allel and Distributed Computing Issues in Wireless Networks and MobileComputing, April 2001.

[23] A. Manjeshwar and D. P. Agarwal, ”APTEEN: A hybrid protocol for efficientrouting and comprehensive information retrieval in wireless sensor networks,”Parallel and Distributed Processing Symposium., Proceedings International,IPDPS 2002, pp. 195-202.

[24] V. Rodoplu and T. H. MengMinimum Energy Mobile Wireless Networks”,IEEE Journal Selected Areas in Communications, vol. 17, no. 8, Aug. 1999,pp. 133344.

[25] L. Li, and J. Y. Halpern,Minimum-Energy Mobile Wireless Networks Revis-ited,” IEEE International Conference on Communications (ICC) 2001. Vol.1, pp. 278-283.

[26] L. Subramanian and R. H. Katz, An Architecture for Building Self Con

gurable Systems”, in the Proceedings of IEEE/ACMWorkshop on Mobile AdHoc Networking and Computing,Boston, MA, August 2000.

[27] Q. Fang, F. Zhao, and L. Guibas, Lightweight Sensing and CommunicationProtocols for Target Enumeration and Aggregation”, Proceedings of the 4thACM international symposium on Mobile ad hoc networking and computing(MOBIHOC),2003, pp. 165-176.

[28] Jamal N. Al-Karaki, Raza Ul-Mustafa, Ahmed E. Kamal, ”Data Aggregationin Wireless Sensor Networks - Exact and Approximate Algorithms’”, Proceed-ings of IEEE Workshop on High Performance Switching and Routing (HPSR)2004, April 18-21, 2004, Phoenix,Arizona, USA.

[29] Q. Li and J. Aslam and D. RusHierarchical Power-aware Routing in SensorNetworks”, In Proceedings of the DIMACS Workshop on Pervasive Network-ing, May, 2001.

61

[30] F. Ye, H. Luo, J. Cheng, S. Lu, L. Zhang, A Two-tier data disseminationmodel for large- scale wireless sensor networks”, proceedings of ACM/IEEEMOBICOM, 2002.

[31] Y. Xu, J. Heidemann, D. Estrin,Geography-informed Energy Conservation forAd-hoc Routing,” In Proceedings of the Seventh Annual ACM/IEEE Inter-national Conference on Mobile Computing and Networking 2001, pp. 70-84.

[32] Y. Yu, D. Estrin, and R. Govindan, Geographical and Energy-Aware Rout-ing: A Recursive Data Dissemination Protocol for Wireless Sensor Networks”,UCLA Computer Science Department Technical Report, UCLA-CSD TR-01-0023, May 2001.

[33] B. Karp and H. T. Kung, GPSR: Greedy perimeter stateless routing for wire-less sensor networks”, in the Proceedings of the 6th Annual ACM/IEEE Inter-national Conference on Mobile Computing and Networking (MobiCom ’00),Boston, MA, August 2000.

[34] I. Stojmenovic and X. Lin. GEDIR: Loop-Free Location Based Routing inWireless Networks”, In International Conference on Parallel and DistributedComputing and Systems,Boston, MA, USA, Nov. 3-6, 1999.

[35] F. Kuhn, R. Wattenhofer, A. Zollinger,Worst-Case optimal and average-caseefficient geometric ad-hoc routing”, Proceedings of the 4th ACM InternationalConference on Mobile Computing and Networking, Pages: 267-278, 2003.

[36] B. Chen, K. Jamieson, H. Balakrishnan, R. Morris, SPAN: an energy-efficientcoordination algorithm for topology maintenance in ad hoc wireless net-works”, Wireless Networks, Vol.8, No. 5, Page(s): 481-494, September 2002.

[37] Container and Truck Trailer Security Project, Cambridge Systematics, Inc.Parsons Brinckerhoff Quade and Douglas, Inc.

[38] http://www.sensornetworks.net.au/applic health.html.

[39] Intel wireless vineyard, www.intel.com/technology/techresearch/research/rs01031.htm

[40] J. Burrel, T. Brooke and R. Beckwith, ”Vineyard Computing: Sensor Net-works in Agriculture Production”, Pervasive Computing, IEEE Volume 3,Issue 1, Jan.-March 2004 Page(s):38 - 45.

[41] Polly Huang, ”Sensor Networks Solutions to Real Life Problems”http://cc.ee.ntu.edu.tw/phuang

62

[42] I.A. Essa, Ubiquitous sensing for smart and aware environments, IEEE Per-sonal Communications (Oct. 2000) 47-49.

[43] M. Srivastava, R. Muntz, M. Potkonjak, ”Smart kindergarten: sensor-basedwireless networks for smart developmental problem-solving enviroments”,Proceedings of the 7th annual international conference on Mobile comput-ing and networking.

[44] Buyya R. Yeo C. S. et al. 2008. Market Oriented Cloud Computing: Vision,Hype and Reality for Delivering IT Services as Computing Utilities. In Proc.of 10th IEEE Conference on HPCC’08, 25-27 September.

[45] Lim H. B., Teo Y.M., Mukherjee P., Lam V.T. et al. 2005. Sensor Grid:Integration of Wireless Sensor Networks and the Grid, In Proc. of the IEEEConf. on Local Computer Networks.

[46] Harris D. 2008. Managing Editor, On-Demand Enterprise. ”TheGrid Cloud Connection-Compare and Contrast.” http://www.on-demandenterprise.com/features/The Grid-cloud Connection 30634819.html

[47] Eugster P. Th., et al. 2003. The many faces of Publish/Subscribe. In ACMComputing Surveys Vol. 35(2): 114 - 131.

[48] Souto E., et al. 2005. Mires: A publish/subscribe middleware for sensor net-works. In ACM Personal and Ubiquitous Computing, 10(1): 37-44.

[49] Krishnamurthy S. 2006. TinySIP: Providing Seamless Access to SensorbasedServices. In Proceedings of the 1st International Workshop on Advances inSensor Networks (IWASN).

[50] Hall C. P., Carzaniga A., Rose J. and Wolf A. L. 2004. A content-basednetworking protocol for sensor networks. Department of Computer Science,University of Colorado, Technical Report.

[51] Hunkeler U., Truong H. L. and Stanford-Clark A. 2008. MQTT-S - A Pub-lish/Subscribe Protocol For Wireless Sensor Networks. In IEEE Conferenceon COMSWARE.

[52] Liu Z. et al. 2007. Scalable Event Matching for Overlapping Subscriptions inPub/Sub Systems. In Proc. of DEBS’07, ACM Press, Toronto, Canada

[53] Carzaniga A., Wolf A. L. et.al. 2003. Forwarding in a Content-Based Network,In Proceedings of ACM SIGCOMM 2003. p. 163-174. Karlsruhe, Germany.

63

[54] Wu K., Chen S. and Yu P. S. 2004. VCR Indexing for Fast Event Match-ing for Highly-Overlapping Range Predicates. ACM Symposium on AppliedComputing, Nicosia, Cyprus.

[55] V.Rajesh, J.M.Gnanasekar, R.S.Ponmagal, P.Anbalagan.2010. Integration ofWireless Sensor Network with Cloud. In Proc. of International Conferenceon Recent Trends in Information, Telecommunication and Computing. DOI10.1109/ITC.2010.88

[56] Pathan A. K., Broberg J., et al. 2007. An Architecture for Virtual Organiza-tion (VO)-Based Effective Peering of Content Delivery Networks. In Proc. ofUPGRADE-CN’07. ACM Press, California, USA.

[57] Y-T. Zhang, X.Y. Xiang, C.C.Y. Poon, The evaluation of nodes of body sensornetworks: Wearable blood pressure measuring devices, in: Proceedings of theInternational Workshop on Wearable and Implantable Body Sensor Networks,2006.

[58] The oxford centre for e-health. http://www.medicine.ox.ac.uk/ndog/tmr/

[59] The biomedical informatics group at Nottigham University. http://www.eee.nott.ac.uk/medical/.

[60] Computer assisted reporting of electrocardiograms, Glasgow University.http://www.gla.ac.uk/departments/medicalcardiology/research/care.html.

[61] A. Schmidt, K.V. Laerhoven, How to build smart appliances?, IEEE PersonalCommunications 8 (4) (2001) 66-71.

[62] V. Stanford, Using pervasive computing to deliver elder care, IEEE PervasiveComputing 1 (1) (2002) 10-13.

[63] T. Mcfadden, J. Indulska, Context-aware environments for independent living,in: 3rd National Conference of Emerging Researchers in Ageing, 2004, pp. 1-6.

[64] J.A. Stankovic, Q. Cao, T. Doan, L. Fang, Z. He, R. Kiran, S. Lin, S. Son, R.Stoleru, A. Wood, Wireless sensor networks for in-home healthcare: potentialand challenges, in: High Confidence Medical Device Software and Systems(HCMDSS) Workshop, 2005.

[65] A. Lymberis, Smart wearables for remote health monitoring, from preventionto rehabilitation: In the Proceedings of 4th International IEEE EMBS SpecialTopic Conference on Information Technology Applications in Biomedicine,2003, pp. 272-275.

64

[66] M. Pallikonda Rajasekaran, S. Radhakrishnan, P. Subbaraj, Remote patientmonitoring system using wireless sensor networks, International Journal ofHealthcare Technology and Management 9 (3) (2008) 247-257.

[67] N. Oliver, F.F. Mangas, HealthGear: A real-time wearable system for moni-toring and analyzing physiological signals, In the Proceedings of the Interna-tional Workshop on Wearable and Implantable Body Sensor Networks, 2006.

[68] M. Philipose, S. Consolvo, I. Smith, D. Fox, H. Kautz, D. Patterson, Fast,detailed inference of diverse daily human activities, in: Sixth InternationalConference on Ubiquitous Computing, 2004.

[69] M. Gaynor, et al., Integrating wireless sensor networks with the grid, IEEEInternet Computing (Jul/Aug) (2004) 32-39.

[70] Intel Corporation. (2006). The SHIMMER sensor node platform. [Online].http://www.eecs.harvard.edu/mdw/proj/codeblue.

65