REAL TIME DATA ANALYSIS IN SENSOR CLOUD PLATFORM

A Dissertation Submitted in partial fulllment of the requirements for the degree of Master of Technology in 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 Engineering Institute of Technical Education and Research Siksha O Anusandhan University Bhubaneswar, Odisha 2012

Dissertation Approval Certicate

This is to certify that the dissertation entitled Real Time Data Analysis in Sensor-Cloud Platform submitted by Sanjit Kumar Dash (Redg. No. 0951012011) is approved for the degree of Master of Technology in Computer Science 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 2012 Place: ITER, Bhubaneswar

Declaration

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

Sanjit Kumar Dash Redg No. 0951012011

Acknowledgment

At rst, I would like to thank Prof. (Dr.) B.K.Patnaik, HOD, Computer Science and Engineering, ITER and Mr. Chinmay Swain, Course Coordinator, Computer Science and Engineering for their enthusiasm towards achieving excellence. At the nib but not neap tide, I would like to thank my friends who are my constant source of learning; and my family for providing me mental strength while I am away from home. I would also like to thank all those who have become the part of this thesis work. 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 during the preparation of this seminar. It is a great pleasure to study and work for this seminar at SOA University. Finally, I would like to express my thanks to my parents for all their support, advice and assistance.

Sanjit Kumar Dash Redg No. 0951012011

Abstract

Cloud Computing is an Internet-based computing, whereby shared resources, software, 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 the network. That is: ubiquitous, metered access to scalable network services. A Wireless Sensor Network (WSN) consists of spatially distributed autonomous sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration,pressure, motion or pollutants. The communication among sensor nodes using Internet is often a challenging issue. It makes a lot of sense to integrate sensor networks with Internet. At the same time the data of sensor network should be available at any time, at any place. It is possibly a dicult issue to assign address to the sensor nodes of large numbers; so sensor node may not establish connection with internet exclusively. Cloud computing strategy can help business organizations to conduct their core business activities with less hassle and greater eciency. Companies can maximize the use of their existing hardware to plan for and serve specic peaks in usage. Thousands of virtual machines and applications can be managed more easily using a cloud-like environment.Businesses can also save on power costs as they reduce the number of servers required.

Table of Contents
1 Cloud Computing 1.1 Introduction . . . . . . . . . . . . . . . . . . . . 1.2 Characteristics . . . . . . . . . . . . . . . . . . 1.3 Attributes . . . . . . . . . . . . . . . . . . . . . 1.3.1 On demand self-service . . . . . . . . . . 1.3.2 Ubiquitous Network Access . . . . . . . 1.3.3 Location Independent Resource Pooling . 1.3.4 Rapid Elasticity . . . . . . . . . . . . . . 1.3.5 Pay per Use . . . . . . . . . . . . . . . . 1.4 Cloud Delivery Models . . . . . . . . . . . . . . 1.4.1 Public Cloud . . . . . . . . . . . . . . . 1.4.2 Private Cloud . . . . . . . . . . . . . . . 1.4.3 Hybrid Cloud . . . . . . . . . . . . . . . 1.4.4 Community Cloud . . . . . . . . . . . . 1.5 Cloud Services . . . . . . . . . . . . . . . . . . . 1.5.1 Software-as-a-Service (SaaS) . . . . . . . 1.5.2 Platform-as-a-Service (PaaS) . . . . . . . 1.5.3 Infrastructure-as-a-Service (IaaS) . . . . 1.6 Storage Architecture in the Cloud . . . . . . . . 2 Wireless Sensor Network 2.1 Introduction . . . . . . . . 2.2 Terminologies . . . . . . . 2.3 Characteristics . . . . . . 2.4 Sensor Node . . . . . . . . 2.4.1 Controller . . . . . 2.4.2 Transceiver . . . . 2.4.3 External Memory . 2.4.4 Power source . . . 2.4.5 Sensors . . . . . . . 2.5 Sensor Network Topologies 9 9 10 10 11 11 11 11 11 11 12 12 12 13 13 13 13 14 14 16 16 17 18 18 19 19 20 20 21 21

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . 5

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

2.6 2.7

2.5.1 Peer-to-Peer . . . . . . . . 2.5.2 Star . . . . . . . . . . . . . 2.5.3 Tree . . . . . . . . . . . . . 2.5.4 Mesh . . . . . . . . . . . . . Routing Protocols in WSN . . . . . Applications of Sensor Network . . 2.7.1 Military Applications . . . . 2.7.2 Environmental Applications 2.7.3 Health Applications . . . . . 2.7.4 Home Applications . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

22 23 23 23 24 25 25 26 27 27 28

3 Literature Survey

4 Sensor-Cloud: Assimilation of Wireless Sensor Network and Cloud 31 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Sensor-Cloud System Model . . . . . . . . . . . . . . . . . . . . . . 32 4.3 Sensor-Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1 Virtualization Manager . . . . . . . . . . . . . . . . . . . . . 33 4.3.2 Publish/Subscribe Broker . . . . . . . . . . . . . . . . . . . 34 4.3.3 Monitoring and Metering(MaM) . . . . . . . . . . . . . . . . 35 4.3.4 System Manager . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.5 Service Registry . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.6 Stream Monitoring and Processing (SMP) . . . . . . . . . . 35 4.3.7 Application Specic Interface . . . . . . . . . . . . . . . . . 36 4.4 Sensor-Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . 36 4.5 Sensor-Cloud Design Issues and Challenges . . . . . . . . . . . . . 37 4.5.1 Sensor Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.5.2 Cloud Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5 Sensor-Cloud Application in Patient Monitoring 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 5.2 Design Consideration for Patient Monitoring System 5.3 Sensor Cloud Architecture for Patient Monitoring . . 5.4 Event Matching Algorithm for Patient Monitoring . . 6 Environmental Setup and Implementation 6.1 Epileptic Seizure: A Case Study . . . . . . . . . . . 6.2 Application Scenario . . . . . . . . . . . . . . . . . 6.3 Environmental Components . . . . . . . . . . . . . 6.3.1 Mercury Wearable Sensor Network Platform 6.3.2 Medical server . . . . . . . . . . . . . . . . . 6 40 40 41 43 46 49 49 50 50 50 52

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6.4

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

7 Conclusion

List of Figures
1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 2.6 2.7 4.1 4.2 4.3 5.1 5.2 5.3 5.4 5.5 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Conceptual Diagram of Cloud Computing . . . . . . . . . . . . . . 10 Cloud Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 13 Cloud Service Architecture . . . . . . . . . . . . . . . . . . . . . . . 14 Multi-hop Wireless Sensor Network Sensor Node Architecture . . . . . Example of Sensor Node . . . . . . Peer-to-Peer Network . . . . . . . . Star Network . . . . . . . . . . . . Tree Network . . . . . . . . . . . . Mesh Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 19 21 22 22 23 24

Sensor-Cloud System Model . . . . . . . . . . . . . . . . . . . . . . 33 Sensor-Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . . . 34 Sensor-Cloud Architecture . . . . . . . . . . . . . . . . . . . . . . . 36 WSN Application Scenario for Health Care . . . . . . . . . . . . . Sensor-Cloud Architecture for Monitoring Patients at Hospital . . High Level Architecture of Sensor-Cloud with Medical Server and Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Grouping Algorithm . . . . . . . . . . . . . . . . . . . . . . Event Matching Algorithm . . . . . . . . . . . . . . . . . . . . . . Mercury Wearable Sensor Network Platform . . . . . . . . . . . Shimmer Wearable Sensor Node . . . . . . . . . . . . . . . . . . miTag with Pulse Oximeter . . . . . . . . . . . . . . . . . . . . An Elliptic Seizure Patient under observation in an ICU . . . . Medical Server output for Monitoring Patients . . . . . . . . . . Snapshot of Emergency Alert Window when Anomaly Detected Web Page Showing Patient Details . . . . . . . . . . . . . . . . . . . . . . . . 43 . 44 . 45 . 47 . 48 . . . . . . . 51 52 52 54 55 56 56

Chapter 1 Cloud Computing

1.1 Introduction

Cloud Computing means Internet-based development, where Cloud is a metaphor for Internet and Computing is the use of Computer Technology. It is a style of computing in which IT-related capabilities are provided as a service, allowing users to access technology-enabled services from the Internet (in the cloud) without knowledge of, expertise with, or control over the technology infrastructure that supports them. Cloud computing is clearly one of todays most enticing technology areas due, at least in part, to its cost-eciency and exibility. However, despite the surge in activity and interest, there are signicant, persistent concerns about cloud computing that are impeding momentum and will eventually compromise the vision of cloud computing as a new IT procurement model. Today, the 14th largest software company by market capitalization (Salesforce.com) operates almost entirely in the cloud; the top ve software companies by sales revenue all have major cloud oerings. Yet, despite the trumpeted business and technical advantages of cloud computing, many potential cloud users have yet to join the cloud, and those major corporations that are cloud users are for the most part putting only their less sensitive data in the cloud. Lack of control in the cloud is the major worry. One aspect of control is transparency in the cloud implementation - somewhat contrary to the original promise of cloud computing in which the cloud implementation is not relevant. Transparency is needed for regulatory reasons and to ease concern over the potential for data breaches[1].

Figure 1.1: Conceptual Diagram of Cloud Computing

1.2

Characteristics

The capabilities that must be adhered to an oering to be considered a cloud. These include: 1. Pay as you go - payment is variable based on the actual consumption by the customer. 2. Highly abstracted - server hardware and related network infrastructure is highly abstracted from the users. 3. Multi-tenant - multi-tenant architectures allow numerous customer enterprizes to subscribe to the cloud computing capabilities while retaining privacy and security over their information. 4. Immediately scalable - usage, capacity, and therefore cost, can be scaled up or down with no additional contract or penalties.

1.3

Attributes

There are diering views on the number and description of the clouds key attributes. For this Information Security Brieng, the cloud is dened by a minimum of 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) dene cloud computing with ve attributes [2][3]: 10

1.3.1

On demand self-service

A consumer can unilaterally have the provision of getting computing capabilities such as server time and network storage, as needed without requiring human interaction with each services provider.

1.3.2

Ubiquitous Network Access

Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms such as mobile phones, laptops, and PDAs.

1.3.3

Location Independent Resource Pooling

The providers computing resources are pooled to serve all consumers using a multitenant model, with dierent physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact location of the provided resources. Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

1.3.4

Rapid Elasticity

Capabilities can be rapidly and elastically provisioned to quickly scale up, and rapidly released to quickly scale down. To the consumer, the capabilities available for rent often appear to be innite and can be purchased in any quantity at any time.

1.3.5

Pay per Use

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

1.4

Cloud Delivery Models

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

11

1.4.1

Public Cloud

Public clouds are run by third parties, and applications from dierent customers are likely to be mixed together on the clouds servers, storage systems, and networks. Public clouds are most often hosted away from customer premises, and they provide a way to reduce customer risk and cost by providing a exible, even temporary extension to enterprize infrastructure. If a public cloud is implemented with performance, security, and data locality in mind, the existence of other applications running in the cloud should be transparent to both cloud architects and end users. Indeed, one of the benets of public clouds is that they can be much larger than a companys private cloud might be, oering the ability to scale up and down on demand, and shifting infrastructure risks from the enterprize to the cloud provider, if even just temporarily. Private clouds are built for the exclusive use of one client, providing the utmost control over data, security, and quality of service (Figure 1.2). The company owns the infrastructure and has control over how applications are deployed on it. Private clouds may be deployed in an enterprize data center.

1.4.2

Private Cloud

Private clouds can be built and managed by a companys own IT organization or by a cloud provider. In this hosted private model, a company such as Sun can install, congure, and operate the infrastructure to support a private cloud within a companys enterprize data center. This model gives companies a high level of control over the use of cloud resources while bringing in the expertise needed to establish and operate the environment.

1.4.3

Hybrid Cloud

A mix of public cloud services, internal cloud computing architectures forms a hybrid clouds combine both public and private cloud models. They can help to provide on-demand, externally provisioned scale. The ability to augment a private cloud with the resources of a public cloud can be used to maintain service levels in the face of rapid workload uctuations. This is most often seen with the use of storage clouds to support Web 2.0 applications. A hybrid cloud also can be used to handle planned workload spikes. Sometimes called surge computing, a public cloud can be used to perform periodic tasks that can be deployed easily on a public cloud. Hybrid clouds introduce the complexity of determining how to distribute applications across both a public and private cloud.

12

1.4.4

Community Cloud

Community clouds are used across organisations that have similar objectives and concerns, allowing for shared infrastructure and services. Community clouds can be deployed using any of the three methods outlined above, simplifying crossfunctional IT governance.

Figure 1.2: Cloud Deployment Model

1.5

Cloud Services

Clouds are commonly described in terms of the functionality oered. The three main types of cloud computing services are:

1.5.1

Software-as-a-Service (SaaS)

In this model, a complete application is oered to the customer, as a service on demand. A single instance of the service runs on the cloud and multiple end users are serviced. On the customers side, there is no need for upfront investment in servers or software licenses, while for the provider, the costs are lowered, since only a single application needs to be hosted and maintained. Today SaaS is oered by companies 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 encapsulated and oered 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

providers infrastructure. To meet manageability and scalability requirements of the applications, PaaS providers oer a predened combination of OS and application servers, such as LAMP platform (Linux, Apache, MySql and PHP), restricted J2EE, Ruby etc. Googles App Engine, Force.com, etc are some of the popular PaaS examples.

1.5.3

Infrastructure-as-a-Service (IaaS)

This model provides basic storage and computing capabilities as standardized services over the network. Servers, storage systems, networking equipment, data center space etc. are pooled and made available to handle workloads. The customer would typically deploy his own software on the infrastructure. Some common examples 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 le system along with the benets of a storage area network (SAN). Either technique can be used by itself, or both can be used together as needed. Computing without data is as rare as data without computing. The combination of data and computer power is important. Computer power often is measured in the cycle speed of a processor. Computer speed also needs to account for the number of processors. The number of processors within an SMP and the number within a cluster may both be important. When looking at disk storage, the amount of space is often the 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 read sixty megabytes per second may limit your processing capabilities below your computer capabilities. Individual disks have limits on the rate at which they can process data. A single computer may have multiple disks, or with SAN le system be able to access data over the network. So data placement can be an important factor in achieving high data access rates. Spreading the data over multiple computer nodes may be desired, or having all the data reside on a single node may be required for optimal performance. The Google le structure can be used in the cloud environment. When used, it uses the disks inside the machines, along with the network to provide a shared le system that is redundant.This can increase the total data processing speed when the data and processing power is spread out eciently.The Google le system is a 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 computer nodes, and has a network similar to an Ethernet network that can then host various SAN devices.Typically a single machine has both computer power and disks. The ratio of disk capability to computer capability is fairly static. With the Google le system, the single nodes computer power can be used against very large data by accessing the data through the network and staging it on the local disk. Alternatively, if the problem lends itself to distribution, then many computer nodes can be used allowing their disks to also be involved. With the SAN we can fundamentally alter the ratio between computer power and disk capability. A single SAN client can be connected to, and access at high speeds, an enormous amount of data. When more computer power is needed, more machines can be added. 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 available on many SAN devices. Normal disk writes do not complete until the data has been written to disk, which involves spinning the disk, and potentially moving the heads. With fast write, the write completes when the data reaches memory in the SAN 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 sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration,pressure, motion or pollutants[4,5]. The development of wireless sensor networks was motivated by military applications such as battleeld surveillance. 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 automation, and trac control [4,7]. Each node in a sensor network is typically equipped with a radio transceiver or other wireless communications device, a small microcontroller, and an energy source, usually a battery. The size of sensor node may vary from shoebox down to a grain of dust. The cost of sensor nodes is also varies from hundreds of dollars to a few pennies, depending on the size of the sensor network and the complexity required of individual sensor nodes [4]. Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and bandwidth [4]. A sensor network is a computer network Composed of a large number of sensor nodes [8]. The sensor nodes are densely deployed inside the phenomenon, they deploy random and have cooperative capabilities. Usually these devices are small and inexpensive, so that they can be produced and deployed in large numbers, and so their resources in terms of energy, memory, computational speed and bandwidth are severely constrained. There are dierent Sensors such as pressure, accelerometer,camera, thermal, microphone, etc. They monitor conditions at dierent locations, such as temperature, humidity, vehicular movement, lightning condition, pressure, soil makeup, noise levels,the presence or absence of certain kinds of objects, mechanical stress 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 networks requires technologies from three dierent research areas: sensing, communication, and computing (including hardware, software, and algorithms). Thus, combined and separate advancements in each of these areas have driven research in sensor networks. Examples of early sensor networks include the radar networks used in air trac control. The national power grid, with its many sensors, can be viewed as 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 further manipulated 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 and edges are communication links. 4. Routing: The process of determining a network path from a source node to its destination. 5. Resource: Resource includes sensors, communication links, processors and memory 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 balanced across 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 that is capable of performing some processing, gathering sensory information and communicating with other connected nodes in the network. A mote is a node but a node cannot always be a mote.Sensor nodes can be imagined as small computers, extremely basic in terms of their interfaces and their components. They usually consist of a processing unit with limited computational power and limited memory, sensors or MEMS, and a power source usually in the form of a battery. Other possible inclusions are energy harvesting modules, secondary ASICs, and possibly secondary communication devices (e.g. RS-232 or USB). The base stations are one or more components of the WSN with much more computational, energy and communication 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 special components in routing based networks are routers, designed to compute, calculate and distribute the routing tables. Many techniques are used to connect to the outside world including mobile phone networks, satellite phones, radio modems, long-range Wi-Fi links etc. Many base stations are ARM-based running a form of Embedded 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 of other components in the sensor node. While the most common controller is a micro-controller, other alternatives that can be used as a controller are: a general purpose desktop microprocessor, digital signal processors, FPGAs and ASICs. A micro-controller is often used in many embedded systems such as sensor nodes because of its low cost, exibility to connect to other devices, ease of programming, and low power consumption. A general purpose microprocessor generally has a higher power consumption than a micro-controller, therefore it is often not considered a suitable choice for a sensor node.

2.4.2

Transceiver

Sensor nodes often make use of ISM band which gives free radio, spectrum allocation and global availability. The possible choices of wireless transmission media are Radio frequency (RF), Optical communication (Laser) and Infrared. Lasers require less energy , but need line-of-sight for communication and are sensitive to atmospheric conditions. Infrared, like lasers, needs no antenna but it is limited in its broadcasting capacity. Radio frequency based communication is the most relevant that ts most of the WSN applications. WSNs tend to use license-free communication frequencies: 173, 433, 868, and 915 MHz; and 2.4 GHz. The functionality of both transmitter and receiver are combined into a single device known 19

as transceivers. Transceivers often lack unique identiers. The operational states are transmit, receive, idle, and sleep. Current generation transceivers have builtin state machines that perform some operations automatically.Most transceivers operating in idle mode have a power consumption almost equal to the power consumed in receive mode. Thus, it is better to completely shutdown the transceiver rather than leave it in the idle mode when it is not transmitting or receiving. A signicant amount of power is consumed when switching from sleep mode to transmit 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-chip memory of a micro-controller and Flash memory o-chip RAM is rarely, if ever, used. Flash memories are used due to their cost and storage capacity. Memory requirements are very much application dependent. Two categories of memory based on the purpose of storage are: user memory used for storing application related or personal data, and program memory used for programming the device. Program memory also contains identication 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 energy cost of transmitting 1 Kb a distance of 100 metres (330 ft) is approximately the same as that used for the execution of 3 million instructions by a 100 million instructions per second/W processor. Power is stored either in batteries or capacitors. Batteries, both rechargeable and non-rechargeable, are the main source of power supply for sensor nodes. They are also classied according to electrochemical material used for the electrodes such as NiCd (nickel-cadmium), NiZn (nickel-zinc), NiMH (nickel-metal hydride), and lithium-ion. Current sensors are able to renew their energy from solar sources, temperature dierences, or vibration. Two power saving policies used are Dynamic Power Management (DPM) and Dynamic Voltage Scaling (DVS).DPM conserves power by shutting down parts of the sensor node which are not currently used or active. A DVS scheme varies the power levels within the sensor node depending on the non-deterministic workload. By varying the voltage along with the frequency, it is possible to obtain quadratic reduction in power consumption.

20

2.4.5

Sensors

Sensors are hardware devices that produce a measurable response to a change in a physical condition like temperature or pressure. Sensors measure physical data of the parameter to be monitored. The continual analog signal produced by the sensors is digitized by an analog-to-digital converter and sent to controllers for further processing. A sensor node should be small in size, consume extremely low energy, operate in high volumetric densities, be autonomous and operate unattended, and be adaptive to the environment. As wireless sensor nodes are typically very small electronic devices, they can only be equipped with a limited power source of less than 0.5-2 ampere-hour and 1.2-3.7 volts. Sensors are classied into three categories: passive, omni-directional sensors; passive, narrow-beam sensors; and active sensors. Passive sensors sense the data without actually manipulating the environment by active probing. They are self powered; that is, energy is needed only to amplify their analog signal. Active sensors actively probe the environment, for example, a sonar or radar sensor, and they require continuous energy from a power source. Narrow-beam sensors have a well-dened notion of direction of measurement, similar to a camera. Omnidirectional 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 taken traditional network topologies in new directions. Many of todays sensor applications require networking alternatives that reduce the cost and complexity while improving the overall reliability. There are basically four types of wireless sensor network 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 node without needing to go through a centralized communications hub. Each Peer device is able to function as both a client and a server to the other nodes on the network.

Figure 2.5: Star Network

22

2.5.2

Star

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

Figure 2.6: Tree Network

2.5.3

Tree

Tree networks use a central hub called a Root node as the main communications router. 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 considered a 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 to communicate with each other as data is routed from node to node until it reaches the desired location. Mesh network allows any node in the network to transmit to any 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: Network Structure based and Protocol Operation based. Network Structure based routing protocols are again divided into at based routing, hierarchical-based routing, and location-based routing. Protocol Operation based are again divided into Multipath based, Query based, QoS based, Coherent based and Negotiation based. In at based routing, all nodes are typically assigned equal roles or functionality sensor nodes collaborate together to perform the sensing task. Due to the large number of such nodes,it is not feasible to assign a global identier to each node. The examples of at based routing protocols are -SPIN [10,11], Directed Diusion [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 dierent roles in the network. In a hierarchical architecture, higher energy nodes can be used to process and send the information while low energy nodes can be used to perform the sensing in the proximity of the target. This means that creation of clusters and assigning special tasks to cluster heads can greatly contribute to overall system scalability, lifetime, and energy eciency. Hierarchical routing is an ecient way to lower energy consumption within a cluster and by performing data aggregation and 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 select cluster heads and the other layer is used for routing. The examples of hierarchical24

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 nodespositions are exploited to route data in the network. In this kind of routing, sensor nodes are addressed by means of their locations. The distance between neighboring nodes can be estimated on the basis of incoming signal strengths. Relative coordinates of neighboring nodes can be obtained by exchanging such information between neighbors [37, 38, 39]. Alternatively,the location of nodes may be available directly by communicating with a satellite, using GPS (Global Positioning System), if nodes are equipped with a small low power GPS receiver [40].The examples of location-based routing protocols 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 enhance the network performance instead of single path. In Query based routing, the destination nodes propagate a query for data from a node through the network and a 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 has to balance between energy consumption and data quality. The network has to satisfy certain QoS metrics, e.g., delay, energy, bandwidth, etc for delivering data to the BS. In coherent routing, the data is forwarded to aggregators after minimum processing. The minimum processing typically includes tasks like time stamping, duplicate suppression, etc. In Negotiation based routing, protocols use high level data descriptors in order to eliminate redundant data transmissions through negotiation.Communication decisions are also taken based on the resources that are available to them.

2.7
2.7.1

Applications of Sensor Network

Military Applications

Because most of the elemental knowledge of sensor networks is basic on the defense application at the beginning, especially two important programs the Distributed Sensor Networks (DSN) and the Sensor Information Technology (SenIT) form the Defense Advanced Research Project Agency (DARPA), sensor networks are applied very successfully in the military sensing[37]. Now wireless sensor networks can be an integral part of military command, control, communications, computing, intelligence, surveillance, reconnaissance and targeting systems. In the battleeld context, rapid deployment, self-organization, fault tolerance security of the net25

work should be required. The sensor devices or nodes should provide following services[37]: 1. Monitoring friendly forces, equipment and ammunition 2. Battleeld 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, agriculture research,re detection and trac control. Because there is no interruption to the environment, sensor networks in environmental area is not that strict as in battleeld. Bush Fire Response: A low cost distributed sensor network for environmental monitor and disaster response. An integrated network of sensors combining on the ground sensors monitoring local moisture levels, humidity, wind speed and direction, together with satellite imagery and longer term meteorological forecasting will enable the determination of re risk levels in targeted regions as well as valuable information on probable re direction. Such a network will provide valuable understanding of bushre development and most importantly assist authorities in organizing a coordinated disaster response that will save lives and property by providing early warning for high risk areas[38]. Fancy Californian Winemaking: A project from Intel (the wireless vineyard) [39]. Imagine smart farmlands where literally every...vine plant will have its own sensor, making sure that it gets exactly the right nutrients, exactly the right watering. Imagine the impact it could have on dicult areas of the world for agricultural purposes. Intel Chief Technology Ocer Pat Gelsinger said[39]. In this project Berkeley motes are installed in the test site - an Oregon, USA vineyard located in a region famous for world-class pinot noir wine. They monitor temperature throughout the vineyard. Each mote in the vineyard currently takes one temperature reading per minute and stores the results. The mote records the highest and lowest temperature readings for each hour of the day. In the future these sensors may also act upon the environment. Imagine sensors that could monitor soil moisture to irrigate only the sections that needed it, or monitor crops to keep them free from pests and diseases. Information gathered by sensor networks could guide irrigation or harvesting to improve quality, providing vineyard owners and managers a better return on their 26

investment. This potential extends to other crops where growers could use motes to maximize yields. The further aim of this project with the help of sensor networks the owner of vineyard can manage the vineyard works more eciently and automatically[40].

2.7.3

Health Applications

Sensor networks are also widely used in health care area. In some modern hospital sensor networks are constructed to monitor patient physiological data, to control the drug administration track and monitor patients and doctors and inside a hospital. In spring 2004 some hospital in Taiwan even use RFID basic of above named applications to get the situation at rst hand. Long-term nursing home [41]: this application is focus on nursing of old people. In the town farm cameras, pressure sensors, orientation sensors and sensors for detection of muscle activity construct a complex network. They support fall detection, unconsciousness detection, vital sign monitoring and dietary/exercise monitoring. These applications reduce personnel 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 hard to image that Home application will step into our normal life in the future. Many concepts are already designed by researcher and architects, like Smart Environment: Residential Laboratory [42] and Smart Kindergarten [43] Some are even realized.

27

Chapter 3 Literature Survey

The issue of integrating sensor network to Cloud computing model is not yet addressed in the literature. Sensor-Grid [45] architecture is already there but as we mentioned earlier it is not suitable in the current application scenarios. In [46], it is also discussed that current Grid computing applications are dierent from the Cloud applications. Grid is generally focus on HPC related application while Cloud focuses on general purpose applications. Users are now moving from HPC workloads to more generic workloads for which Cloud is more appropriate solution. To integrate sensor networks to Cloud, we propose a content based pub-sub model. A Pub/Sub system [47] encapsulates sensor data into events and provides the services of event publications and subscriptions for asynchronous data exchange among the system entities. Several Pub/Sub systems have been developed in recent years in the context of WSNs most notably in [48]-[51]. Mires [48] is a publish/subscribe architecture for WSNs. Basically sensors only publish readings if the user has subscribed to the specic sensor reading. Messages can 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 messaging. It oers support for multiple gateways. Most communication is done by addressing individual devices. As device addresses are related to the gateway being used, changing the gateway on the y is dicult. DV/DRP [50] is another publish/subscribe architecture for WSNs. DV/DRP stands for Distance Vector/Dynamic Receiver Partitioning. Subscriptions are made based on the content of the desired messages. Subscriptions are ooded in the network. Intermediate nodes aggregate subscriptions. They forward publications only if there is an interest for this publication. MQTT-S [51] is an open topic-based pub-sub protocol that hides the topology of the sensor network and allows data to be delivered based on interests rather than individual device addresses. It allows a transparent data exchange between 28

WSNs and traditional networks and even between dierent WSNs. In our framework, like MQTT-S, all of the system complexities reside on the brokers side but it diers from MQTT-S in that it uses content-based pub-sub broker 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 more subscribers without the publisher having to address the message to any specic subscriber. Matching is done by the pub-sub broker outside of the WSN environment. In content-based pub/sub system, sensor data has to be augmented with meta-data to identify the dierent data elds. For example, a meta-data of a sensor value (also event) can be body temperature, blood pressure etc.To deliver published sensor data or events to subscribers, an ecient and scalable event matching algorithm is required by the pub-sub broker. In [52], authors proposed two event matching algorithms - sequential and suborder. In sequential algorithm, according to each predicate in event, searching space is gradually reduced by deleting subscriptions which are not satised. The advantage is that no pre-processing for subscriptions and no additional index is required. When the number of attribute increases, the cost approaches to a constant number. But the drawback is that at least we need to check every predicate once in 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 evaluations by analyzing the expected cost dierences when subscriptions are evaluated in dierent orders. In case of suborder, connect the same predicates together by using an index called linked chain that can help to nd same predicates quickly, and then it is possible to quickly reserve or delete predicates. The advantage is that by pre-processing, it can avoid great amount of comparison during the searching and also it can further reduce the searching cost when there are many same predicates in the subscriptions. But the disadvantage is that it is hard or even impossible to make chain sometimes, for instance in range predicate case. Another problem is that here every two predicates, if they are same, share a chain. Thus it needs to maintain a complete graph and bring so much overload when inserting and deleting subscriptions. Forwarding algorithm in [53] matches event data to subscriptions that include a single predicate. It groups predicates using attributes and operators, and indexes the values of predicates. The advantage is that searching is very fast. But when predicates are in range or highly overlapped, this algorithm results in separate groups of predicates by matching operators and nds correct subscriptions by combining the results of dierent groups. In VCR Indexing described in [54], range of each subscription are transferred into many overlapping rectangles and when event data comes, rectangles which contain 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 subscriptions are highly-overlapping. But its disadvantage is that it is not scalable. If the number of attribute increases the overhead of rectangle construction and storage increases dramatically. Our event matching algorithm targets range predicate case suitable to our application scenario and it is also ecient and scalable when the number of predicates increases. In [44], authors presented a vision for the creation of global Cloud exchange for trading services. But authors did not mention about dynamic collaboration between cloud providers. In [56], authors proposed a VO based CDN peering framework. In [55] the author provides the solution of integrating the industrial sensor networks with Internet through SOA paradigm, and with cloud technology. In their work, an integrated solution with application server (providers), integration controller (through which consumers contacts), and a register agent (registry), is designed. The Integration controller is responsible for storing sensed data and provides recovery system. The main job of IC is uploading sensed data to internet through cloud technology, so the authorized user can access sensed data from any where in the world. A number of recent research eorts focus on wearable systems for health monitoring. Researchers at the MIT Media Lab have developed MIThril, a wearable computing platform compatible with both custom and o-the-shelf sensors. CodeBlue, a Harvard University research project, is also focused on developing WSNs for medical applications. The sensors, when outtted on patients in hospitals or disaster environments, use ad hoc networks to transmit vital signs to health-care givers, facilitating automatic vital sign collection and real-time triage [57]. Recently, research eorts are beginning to study the integration of WSNs and grid computing. Researchers in the UK are studying how sensors can be integrated into e-Science grid computing applications. The Discovery Net project is building a grid-based framework for developing and deploying knowledge discovery services to analyze data collected from distributed high-throughput sensors. The applications include life sciences, environmental monitoring, geo-hazard modeling and remote patient monitoring. The current trend towards Telemedicine and Telecare evident in the UK [58] has seen an explosion in the range of locations where advanced medical care needs to be delivered. E-medicine initiatives such as NHS Direct have illustrated the need to maximize the exibility of delivery of health care. Existing trials in Telemedicine and Telecare such as those carried out by the Oxford center for e-health [58], the Biomedical Informatics group at Nottingham University [59] and the Glasgow Royal Inrmary and Glasgow University [60] have demonstrated the feasibility of remotely monitoring patients as part of an overall care programme.

30

Chapter 4 Sensor-Cloud: Assimilation of Wireless Sensor Network and Cloud

4.1 Introduction

A sensor network is a computer network Composed of a large number of sensor nodes. The sensor nodes are densely deployed inside the phenomenon, they deploy random and have cooperative capabilities. Usually these devices are small and inexpensive, so that they can be produced and deployed in large numbers, and so their resources in terms of energy, memory, computational speed and bandwidth are severely constrained. There are dierent Sensors such as pressure, accelerometer, camera, thermal, microphone, etc. They monitor conditions at dierent locations, such as temperature, humidity, vehicular movement, lightning condition, pressure, soil makeup, noise levels, the presence or absence of certain kinds of objects, mechanical stress levels on attached objects, the current characteristics such as speed, direction and size of an object.Normally these Sensor nodes consist there components: sensing, processing and communicating. WSN have been evolved in the past few years to enable solutions in the areas such as industrial automation, asset management, environmental monitoring, transportation business, health care, etc. Bringing various WSNs deployed for dierent applications under one roof and looking it as a single virtual WSN entity through cloud computing infrastructure is novel. Data generated from a vast sea of sensor applications such as environmental monitoring, transportation business, health care, etc., is enormous. If we add this collection of sensor-derived data to various web based virtual communities, we can have a remarkable transformation in the way we see ourselves and 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 trac information, real-time environmental data monitoring and analyzing, etc. To enable this exploration, sensor data of all types will drive a need for an increasing capability to do analysis and mining on-the-y. However, the computational tools needed to launch this exploration can be more appropriately built from the cloud computing model rather than traditional distributed or grid approaches. Cloud computing models are designed to provide on-demand capacity for the application providers that involves three parties - the data center, the application provider and the application user visvis traditional approaches that operate on two party contracts. To summarize, integrating WSNs with cloud makes it easy to share and analyze real time sensor data on-the-y. It also gives an added advantage of providing sensor data or sensor event as a service over the internet. The terms Sensing as a Service (SaaS) and Sensor Event as a Service (SEaaS) are coined to describe the process of making the sensor data and event of interests available to the consumers respectively over the cloud infrastructure. We propose, a contentbased publish/ subscribe platform to utilize the ever expanding sensor data for various next generation community-centric sensing applications.

4.2

Sensor-Cloud System Model

A Sensor-Cloud consists of wireless sensor networks (WSNs) and cloud resources like 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 certain resources might also belong to more than one organization. Users from various organizations may access the resources in the Sensor Cloud, even if the resources are not 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 the system. WSN consists of physical wireless sensor nodes to sense dierent applications like Transport Monitoring, Weather Forecasting, and Military Application etc. Each sensor node is programmed with the required application. Sensor node also consists of operating system components and network management components. On each sensor node, application program senses the application and sends back to gateway in the cloud directly through base station or in multi-hop through other nodes. Routing protocol plays a vital role in managing the network topology and to accommodate the network dynamics. Cloud provides on-demand service and storage resources to the clients. It provides access to these resources through internet 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 sensor data on-the-y. It also gives an advantage of providing sensor data or sensor event 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 Forecasting and Military Application etc [10].

4.3

Sensor-Cloud Platform

The proposed platform consists of Virtualization Manager, Pub/Sub Broker, Monitoring and metering, System Manager, Service Registry, Stream Monitoring and Processing Component and Application Specic Interface . Figure 4.2 gives an overview of the components that constitute the sensor-cloud platform.

4.3.1

Virtualization Manager

This component is divided into three subcomponents. They are: Common Interface, Data processor and Command Interpreter. 1. Common Interface: Sensor networks are connected with the gateway through common interface in dierent 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 a packet. The packet is further kept in a buer for further processing. 2. Data Processor: This component retrieves the packet from the buer and processes according to its type. The packet type depends on the application being run on the platform. 3. Command Interpreter: This component is responsible for providing reverse communication channel from the gateway to the WSN and for processing and interpreting various commands issued from dierent applications and generates 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 to registered users through SaaS applications.

34

4.3.3

Monitoring and Metering(MaM)

This module tracks the usage of the primary cloud resources. Consumer uses signed web service requests to access the data. Role of MaM deals with handling the request of consumers, checking of registry manager, keeps track of web services etc.

4.3.4

System Manager

This module is responsible for processing and archiving the sensor data and also manages the system resources. Computation cycles are utilized internally to process the data that emanates from the sensors. Storing the sensor data will help to analyze the patterns in the data collected over a period of time.

4.3.5

Service Registry

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

4.3.6

Stream Monitoring and Processing (SMP)

SMP monitors the sensor streams comes in many dierent forms from dierent sources and invokes correct analysis method. This module is divided into three sub components: registry component, analyzer component and disseminator component. 1. Registry Component (RC): Registry component stores user subscriptions of dierent applications and user specic sensor data types of those users who register to Pub/Sub Agent.It also sends all user subscriptions along with application id to the disseminator component for event delivery. 2. Analyzer Component (AC): AC analyzes the incoming sensor data or event to match with user subscriptions in the Service registry. If the sensor data matches with the interest of the subscriber, the same is handed over to the disseminator component to deliver to the appropriate users.

35

3. Disseminator Component (DC): DC receives the data or event of interest from the analyzer component and delivers the data through SaaS interface to the subscribed applications.

4.3.7

Application Specic Interface

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

4.4

Sensor-Cloud Architecture

Figure 4.3: Sensor-Cloud Architecture This framework aims at bringing sensor data to a pub/sub Agent through gateways. Pub/sub agent delivers information to the consumers of applications 36

interfaces. The WSN cloud platform web services are granted access through the interfaces built with Web 2.0 technologies. The masking of the lower level details of each WSN cloud in terms of dierent platforms, sensors being used, data being generated is done by the Virtualization Manager. The various SaaS applications transfer the information and subscriptions of the registered users to pub/sub Agent registry. Sensor data, on reaching the system from gateways, are then determined through stream monitoring and processing component (SMPC) in the pub/sub Agent as to whether they need processing or just have to be stored for periodic send or for immediate delivery. If in case sensor data need periodic/ emergency delivery, the analyzer determines which SaaS applications the events belong to and then pass the events to the disseminator. The disseminator then delivers the events for use by nding appropriate subscribers for each application with the help of event matching algorithm. Computational cycles are provided internally by SM as required to process the data emanated from the sensors. SRM manages the users subscriptions and credentials. MaM calculates the price for the oered services.

4.5

Sensor-Cloud Design Issues and Challenges

In this section, we discuss the important issues and challenges in the design of Sensor Clouds. Most of these design issues and challenges arise due to the inherent limitations of sensor devices such as limited processor performance, small storage capacity, limited battery power, and unreliable low-bandwidth wireless communication 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 nodes do not have xed power sources and rely on limited battery power. Sensor applications executing on these devices have to make tradeos between sensor operation and conserving battery life. The sensor nodes should provide adaptive power management facilities that can be accessed by the applications. From the Sensor-Cloud perspective, the availability of sensor nodes is not only dependent on their load, but also on their power consumption. Thus, the Sensor Cloud resource management component has to account for power consumption. 2. Scalability: Scalability is the ability to add sensor resources to a SensorCloud to increase the capacity of sensor data collection, without substantial

37

changes to its software architecture. The Sensor-Cloud architecture should allow multiple wireless sensor networks, possibly owned by dierent virtual organizations, to be easily integrated with compute and data cloud resources. 3. Network Connectivity and Protocols: The network connections are usually fast and reasonably reliable in cloud. On the other hand, the sensor nodes in Sensor Clouds are connected via wireless ad hoc networks which are lowbandwidth, high-latency, and unreliable. The network connectivity of sensor nodes is dynamic in nature, and it might be irregular and vulnerable to faults due to noise and signal degradation caused by environmental factors. The Sensor-Cloud has to gracefully handle unexpected network disconnections or prolonged periods of disconnection. Thus, ecient techniques to interface sensor network protocols with cloud networking protocols are necessary. 4. Scheduling: In wireless sensor networks, scheduling of sensor nodes is often performed to facilitate power management and sensor resource management. Researchers have developed algorithms to schedule the radio communication of active sensor nodes, and to turn o the radio links of idle nodes to conserve power. Similarly, for applications like target tracking, sensor management algorithms selectively turn o sensor nodes that are located far away from the target, while maximizing the coverage area of the sensors. 5. Availability: Due to the power issue and the unpredictable wireless network characteristics, it is possible that applications running on the sensor nodes might fail. Thus, techniques to improve the availability of sensor nodes are necessary. Sensor Clouds should support job and service migration, so that a job can be migrated from a sensor node that is running out of power or has failing hardware to another node.

4.5.2

Cloud Issues

1. Reliability: Stability of the data storage system is of important consideration in clouds. Generally, people worry about whether a cloud service provider is nancially stable and whether their data storage system is trustworthy. Most cloud providers attempt to mollify this concern by using redundant storage techniques, but it is still possible that a service could crash or go out of business, leaving users with limited or no access to their data. 2. Data Backup: Cloud providers employ redundant servers and routine data backup processes, but some customers worry about being able to control their own backups. Many providers are now oering data dumps onto media or allowing users to back up their data through regular downloads. 38

3. Privacy: The Cloud model has been criticized by privacy advocates for the greater ease in which the companies hosting the Cloud services control and monitor communication and data stored between the user and the host company lawfully or unlawfully. There have been eorts to harmonize the legal environment by deploying local infrastructure and allowing customers to select availability zones. 4. Security: Cloud service providers employ data storage and transmission encryption, user authentication, and authorization. Many clients worry about the vulnerability of remote data to criminals and hackers. Cloud providers are enormously sensitive to this issue and apply substantial resources to mitigate this problem. 5. Ownership: Once data has been relegated to the cloud, some worry about losing their rights or being unable to protect the rights of their customers. Many cloud providers address this issue with well-skilled user-sided agreements. According to the agreement, users would be wise to seek advice from their favorite legal representative. 6. Availability and Performance: Business organizations are worried about acceptable levels of availability and performance of applications hosted in the cloud. 7. Legal: There are certain points of concern for a cloud provider and a client receiving the service like location of the cloud provider, location of infrastructure, physical location of the data and out sourcing of the cloud providers services etc. Sensor networks is a relatively recent eld and there are many research issues pertaining to sensor networks such as energy management, coverage, localization, medium access control, routing and transport, security etc. Research in cloud computing is also in fantasy stage. It also has a number of research challenges such as ecient resource allocation, high resource utilization and security etc. Apart from the afore-mentioned research issues in sensor networks and cloud computing, sensor-cloud computing gives rise to additional research challenges, especially when it is used in mission-critical situations. These research challenges are: web services and service discovery which work across both sensor networks and the cloud, interconnection and networking, coordinated quality of service (QoS) mechanisms etc.

39

Chapter 5 Sensor-Cloud Application in Patient Monitoring

5.1 Introduction

Wireless sensor network technologies are considered as one of the key research areas in computer science and health-care application industries. The pervasive healthcare systems provide rich contextual information and alerting mechanisms against odd conditions with continuous monitoring. This minimizes the need for caretakers and helps the chronically ill and elderly to survive an independent life. Sensor networking devices in WSNs are resource constrained since they have limited processing power and communication bandwidth. However, with a large number of such devices being deployed and aggregated over a wide area, WSNs have substantial data acquisition and processing capability. Thus, WSNs are important distributed computing resources that can be shared by dierent groups of patients in dierent environments. The emerging domain of WSNs with the cloud extends the cloud computing paradigm to the sharing of sensor resources in WSNs. In this paper, we propose wireless sensor cloud architecture for monitoring the health status of dierent groups of patients to provide a platform for physicians and researchers to share information with distributed database and computational resources to facilitate analysis, diagnosis, and prognosis and drug delivery. One of the major challenges of the world for the last decades has been the continuous elderly population increase in the developed countries. Hence the need of delivering quality care to a rapidly growing population of elderly while reducing the health-care costs is an important issue. One promising application in that area is the integration of sensing and consumer electronics technologies which would allow people to be constantly monitored [61]. In-home pervasive networks may assist residents and their caretakers by providing continuous medical monitoring,

40

memory enhancement, control of home appliances, medical data access, and emergency communication [62, 63]. Constant monitoring will increase early detection of emergency conditions and diseases for at risk patients and also provide wide range of health-care services for people with various degrees of cognitive and physical disabilities [64]. A link between Wireless Sensor Networks (WSNs) and cloud computing would be an exciting avenue to explore. By integrating the two systems, the WSN would collect large quantities of data which could be processed intensively and stored eectively 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 research studies, large-scale military operations, medical applications and commercial organizations. This paper proposes a technique for monitoring dierent groups of patients using a wireless sensor cloud. The need to make cloud facilities available in the eld is particularly critical in the case of medical services where much of the day to day work of medicine centers on the patient requiring a number of medical professionals to correlate medical data with patient examination and observation. The ultimate goal is to increase the availability of medical care in order both to reduce the demands on hospital services and to improve the long-term care and recovery of patients. This system also reduces the time of routine checkups and its real- time monitoring also allows emergency situations to be handled immediately. The data are published via web servers. Health-care professionals, researchers and patients can access the long-term physiological data via the Internet. A secure web server allows authenticated users to access real-time patient information to consult with medical specialists located at distant places.

5.2

Design Consideration for Patient Monitoring System

The medical applications of wireless sensor networks aim to improve the existing health-care and monitoring services especially for the elderly, children and chronically ill. There are several benets achieved with these systems. To begin with, remote monitoring capability is the main benet of pervasive health-care systems. With remote monitoring, the identication of emergency conditions for at risk patients will become easy and the people with dierent degrees of cognitive and physical disabilities will be enabled to have a more independent and easy life. The little children and babies will also be cared for in a more secure way while their parents are away. Identifying emergency situations like heart attacks or sudden falls in a few seconds or even minutes will suce for saving lives considering that, without them these conditions will not be identied at all. Therefore, provid-

41

ing real-time identication and action taking in pervasive health-care systems are among the main benets. The technology advancements in consumer electronics have reduced the production costs and have made it possible to aord inexpensive sensor devices for ordinary users as well. Together with the mature and also inexpensive RFID technology, the costs for pervasive health-care systems are within the aordable range for many people. In caretakers Assistant [68], inexpensive RFID tags are placed on household object and the systems precision can be increased at very low costs, by tagging more objects with these RFID tags. Being able to identify the context is another benet achieved with pervasive health-care systems. Context awareness enables us to understand the conditions of the people to be monitored constantly and environments in which these people are. This context information is achieved mostly by sensing systems that incorporate more than one type of sensing capabilities. By fusing the information gathered by several sensors, we may have a more clear understanding of the context. The context information helps better in identifying the unusual patterns and making more precise inferences about the situation. For instance, if we can identify the location of the person to be tracked and the activity he/she is busy with together with his/her vital signs; we can deduce useful information out of these. During night-time, being in the sleeping room in a lying position may not indicate something serious whereas lying down in the sleeping room in the middle of the day may indicate an alarm situation. Context-awareness provides this useful information to us. There are several prototypes as well as commercially available products. When several applications are investigated, it is observed that these applications have common properties. Most of the existing solutions include one or more types of sensors carried by the patient, forming a Body Area Network (BAN), and one or more types of sensors deployed in the environment forming a Personal Area Network (PAN). These two are connected to a backbone network via a gateway node. At the application level, the health care professionals or other caretakers can monitor the vital health information of the patient in real-time via a graphical user interface (GUI). The emergency situations produce alerts by the application and these alerts and other health status information can be reached via mobile devices like laptop computers, Personal Digital Assistants (PDAs) and smart phones. The overview of a simple wireless sensor network for health care scenario is depicted in g 5.1. Based on this observation, in a typical scenario, there are four dierent categories of actors other than the power users of the systems such as administrators and developers. Recent advances in electronic circuit miniaturization and micro-electromechanical systems (MEMS) have led to the creation of small wireless sensor nodes which integrate several kinds of sensor, a central processing unit (CPU), memory and a wireless transceiver. These nodes are capable of sensing and communicating 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, noninvasive, continuous health monitoring of post-operative patients at hospital and elderly patients in home environments with almost real-time updates of medical records. Physiological sensors are attached in the human body to monitor disorders in the heart and brain during normal activities and to help patients maintain their health even after surgery. The integration of sensing and communication technologies has allowed monitoring of elderly patients in home environments and post-operative patients in hospitals for early detection of adverse conditions and diseases, denitely saving more lives [66]. Patients recovering from surgery are at risk 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 identify those at risk of developing complications is therefore clinically desirable; it may result in an early intervention to prevent adverse outcomes [67].

5.3

Sensor Cloud Architecture for Patient Monitoring

The architecture of a wireless sensor cloud comprises a number of dierent sites that are geographically distributed and belong to dierent divisions of organizations, 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 architecture consists of the following components: a graphical user interface, a central 43

medical server, a cloud server a WSN deployed near the patients site. Our architecture framework is a hybrid architecture that combines WSNs and cloud- enabled software tools that support the storage, processing and information-sharing tasks. The data are acquired from patients at all the sites mentioned and the data replicas are transferred to databases. The transfer comprises the actual sensor data, denoted as data, and the information which is provided by physicians during the annotation 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 authenticated parties. Thus, the services must include certain security properties, something that is already inherent in the cloud. The security and privacy will be provided by Cloud environment. A cloud user authenticates him by presenting an X.509 proxy certicate, and as a result, security properties like authentication, authorization, integrity and non-repudiation are provided. Proxy certicates use the format described for X.509 public key certicates. They serve to bind a unique public key to a subject name, as a public key certicate does. The use of the same format as X.509 public key certicates allows proxy certicates to be used in protocols and libraries in many places as if they were normal X.509 public key certicates, which signicantly eases implementation. However, unlike a public key certicate, the issuer (and signer) of a proxy certicate is identied by a public key certicate or another proxy certicate rather than a certication authority (CA) certicate. Proxy certicates can also be created so as to delegate privileges from an issuer to another party over a network connection without the exchange of private keys. Our proposed architecture provides a platform for clinicians and researchers within the sensor cloud consortium to share information in 44

Figure 5.3: High Level Architecture of Sensor-Cloud with Medical Server and Cloud Server distributed databases and computational resources to facilitate the analysis, diagnosis and care for patients within the cloud. The proposed architecture comprises of following components: 1. A front end composed of the dierent sensors for the recording of the vital signals that are demanded by the application (ECG, respiration and activity level). 2. A patient station, which consists of a mote device that receives information from the sensors and is responsible for the rst stage of data processing in the data communication. The received signal is sent to a central server for analysis. 3. A central medical server, which is the core processing element, receives the patients data from the patient station for analysis. It also performs complex on-line and o-line analysis, data mining, and prediction with the information databases. The analysis is done using moteView software and generates alerts to the medical professionals, caretakers and emergency medical department personnel. 4. A cloud server is used for authentication and for identifying abnormal data and alerting the physicians, emergency departments and caretakers for further follow-up of the patients.

45

5.4

Event Matching Algorithm for Patient Monitoring

To deliver publish events to appropriate consumers who subscribed an ecient event matching algorithm is required for our Sensor-Cloud framework. We are targeting the Cloud-based health-care monitoring system where doctors and researchers express their interests into a range. Normally, in our system, a subscription S is expressed by a pair (Sid,P) where Sid is the subscribers ID (subscriber ID for short) and P is a set of predicates specifying subscribers interest. P consists of ve 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 predicate MPV = maximum threshold value of predicate N = count of predicates op = 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 joined together to specify a range value or range predicate [ i.e. p1=body temperature>29 and p2=body temperature < 32]. An event satises a subscription only if it satises all predicates in the subscription. Here, the event e = [body temperature =30] satises the subscription S since body temperature is within the range. So the matching problem is: Given an event e and a set of predicates in subscription set S. We need to nd all subscriptions in set S that are satised by e. Let S is a set of subscriptions, S=[s1, s2, s3....sn] where n is the total no. of subscriptions and P is a set of predicates in S, P=[p1, p2, p3,...pm] where m is the toal no of predicates in a subscription. In our system we have two predicates in a subscription [i.e. data > mPV and dat< MPV ] and these two predicates is used to group the subscriptions. We dene a set S that contains all the subscriptions of S sorted by mPV value in ascending order. Then we dene a grouping sequence (mG1, mG2,...mGg) such that g = [1+log (n)] and S is the summation of all mGr where n is the total no of subscriptions in S.The grouping space, denoted by SP(S, g) is dened as the set containing all such group sequences over S and g. Now each 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, rst predicate of an event is composed with group index gI and if any match found then second predicate is compared with group indexes hI within MG and so on. Finally sequential matching is done in the selected groups to nd the subscriptions that are satised by all predicates in the event. The pseudo code of grouping and event method is shown in g 5.4 and 5.5. 46

Figure 5.4: Event Grouping Algorithm

47

Figure 5.5: Event Matching Algorithm 48

Chapter 6 Environmental Setup and Implementation

6.1 Epileptic Seizure: A Case Study

Epilepsy is a brain disorder in which clusters of nerve cells, or neurons, in the brain sometimes signal abnormally. Neurons normally generate electrochemical impulses that act on other neurons, glands, and muscles to produce human thoughts, feelings, and actions. In epilepsy, the normal pattern of neuronal activity becomes disturbed, causing strange sensations, emotions, and behavior, or sometimes convulsions, muscle spasms, and loss of consciousness. During a seizure, neurons may re as many as 500 times a second, much faster than normal. In some people, this happens only occasionally; for others, it may happen up to hundreds of times a day.An epileptic seizure, occasionally referred to as a t, is dened as a transient symptom of abnormal excessive or synchronous neuronal activity in the brain. The outward eect can be as dramatic as a wild thrashing movement (tonic-clonic seizure) or as mild as a brief loss of awareness (absence seizure). It can manifest as an alteration in mental state, tonic or clonic movements, convulsions, and various other psychic symptoms. Sometimes it is not accompanied by convulsions but a full body slump, where the person simply will lose body control and slump to the ground. The medical syndrome of recurrent, unprovoked seizures is termed epilepsy, but seizures can occur in people who do not have epilepsy. About 25 percentage of people will have an unprovoked seizure by the age of 80 and the chance of experiencing a second seizure is between 30 percentage and 50percentage. Treatment may reduce the chance of a second one by as much as half. Most single episode seizures are managed by primary care physicians (emergency or general practitioners), whereas investigation and management of ongoing epilepsy is usually done by neurologists.

49

The signs and symptoms of seizures vary depending on the type. Seizures may cause involuntary changes in body movement or function, sensation, awareness, or behavior. Seizures are often associated with a sudden and involuntary contraction of a group of muscles and loss of consciousness. However, a seizure can also be as subtle as a eeting numbness of a part of the body, a brief or long term loss of memory, visual changes, sensing/discharging of an unpleasant odor, a strange epigastric sensation, or a sensation of fear and total state of confusion. A seizure can last from a few seconds to status epilepticus, a continuous group of seizures that is often life-threatening without immediate intervention. Therefore seizures are typically classied as motor, sensory, autonomic, emotional or cognitive. Causes of epileptic seizures include: Dehydration, sleep deprivation, head injury 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 and gyroscopes 2. A base station, such as a laptop in the patients home, collects data from the network. 3. The data is then delivered via an Internet connection to the clinic where it is visualized and further processed by physicians. 4. The patient will put on the sensors in the morning and take them o to recharge 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 withholding anticonvulsant medications, thereby permitting seizures to occur.

6.3
6.3.1

Environmental Components
Mercury Wearable Sensor Network Platform

Mercury is a wearable, wireless sensor platform. It is designed to overcome the core challenges of long battery lifetime and high data delity for long-term studies. It supports data collection on patients in hospital and home settings. It provide exible programming interface allowing a range of policies to be implemented on top 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-KB RAM; 48-KB ROM) 2. A low power radio (Chipcon CC2420; IEEE 802.15.4; 2.4 GHz; 250-Kb/s PHY data rate). 3. A MicroSD slot supporting up to 2 GB of ash storage. 4. A 250 mAh Li-polymer rechargeable battery. Fig.6.2 shows a typical wearable sensor node for medical applications, the SHIMMER platform [70]. B. miTag with Pulse Oximeter The miTag is a wearable 2-way communication device. It displays text and graphics to allow a patient to communicate with his/her medical providers. miTags use a robust wireless mesh network that is self-organizing and self-healing. Thousands of miTags can be quickly deployed simultaneously because they require no preexisting network infrastructure. The miTag is a replacement for the conventional paper triage tag. A triage priority level is set on the tag and this is wirelessly relayed to a central command station. As each patient wears the miTag, the medical response 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 a pulse oximeter sensor. These disposable and reusable sensors are available for the nger 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 online and o-line analysis and prediction from the gathered information. The large amount of collected physiological data will allow a quantitative analysis of various conditions and patterns. Data mining is a complex process that allows discovering unsuspected meaningful knowledge in large databases. The process could be classication, clustering, association rule mining, attributes, etc. The algorithm developed for analyzing ECG signals is capable of detecting similar sequential patterns in a set of time series. The algorithm will be useful for nding signicant subsequences 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 common tasks involved before testing is to take a reference template for comparing real 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 and alerting when a life-threatening event occurs. The criterion of our architecture framework design was to make the use of the cloud infrastructure completely transparent to the physicians, caretakers, and researchers. Using the cloud to provide seamless access to geographically distributed data and high computational resources for complex analysis, more accurate and ecient diagnosis can be achieved.

6.4

Observation and Result

A 72 year old woman was referred to a neurologist for evaluation after getting unconscious due to statistical epileptic seizure. The neurologist kept the patient under observation in the ICU. After getting admitted in the ICU; the patients disease symptoms were recorded with help mercury wearable sensor platform. nearest to the patient body. Then the captured data were sent to the medical server through the base station. Figure 6.4 shows an epileptic seizure patient kept under observation with the help of mercury wearable platform.Eight numbers of shimmer nodes were attached at the various places of the patient of the body to capture symptoms like blood pressure and temperature. One miTag with Pulse oximeter was attached in the hand to capture the heartbeat rate and respiration level. The real-time data captured by the sensors were displayed in the monitor attached Fig. 6.5 represents the output of the medical server which displays the monitoring of patient data. The results show that our system is capable of continuously monitoring/logging the patients daily activities.The medical server is used to store the data simultaneously and to do the on-line and o-line analysis and prediction from the gathered information. Data from WSNs are stored in a cloud server to facilitate 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 is detected. When an anomaly is detected in the patients vital sign, the application software generates an alert for the physicians, caretakers and emergency department personnel through SMS. In our implementation, the cloud portal serves as an 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 patients 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 suggest necessary drugs which much be given to the patient to recover him/her from life risk. When doctor submits its suggestion in the portal, an SMS alert will be sent to the patients caretaker reminding him to give recently prescribed drugs to the desired patent as soon as possible. The cloud portal sits in a web server with relevant components (e.g. databases and classes) and establishes connections between an end-user and the lower layer cloud services. A nurse/physician logs onto the system to collect the data about a patients health status. The doctor places the request to view the heart beat rate and the blood pressure value of a patient who is recovering from cardiac surgery. The server now sends the request to the particular 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 information portal allows dierent 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 vital statistics and the location of the elderly patients who had been tagged with sensors. 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 the doctors login. 3. Emergency personnel have full access to all data in the system. They can add new patients, health professionals, and administrators. They can access and 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 and physicians across the world with access to the medical records of patients in order to refer and/or consult some critical case with some other doctor or physician who is far away from the patient site, and also enables them to come together to share resources and collaborate with each other in order to achieve ecient medical care. Therefore we developed a collection of user friendly interfaces which allow physicians to get access to the resources without any prior knowledge of cloud technologies.

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 before sensitive and regulated data move into the public cloud, issues of security standards and compatibility must be addressed including strong authentication, delegated authorization, and key management for encrypted data, data loss protections, and regulatory reporting. All are elements of a secure identity, information and infrastructure model, and are applicable to private and public clouds as well as to IAAS, PAAS and SAAS services. In the development of public and private clouds, enterprizes and service providers will need to use these guiding principles to selectively adopt and extend security tools and secure products to build and oer end-to-end trustworthy cloud computing and services. Fortunately, many of these security solutions are largely available today and are being developed further to undertake increasingly seamless cloud functionalities. Cloud computing is the most popular notion in IT today; even an academic report from UC Berkeley says Cloud Computing is likely to have the same impact on software that foundries have had on the hardware industry. They go on to recommend that developers would be wise to design their next generation of systems to be deployed into Cloud Computing. While many of the predictions may be cloud hype, we believe the new IT procurement model oered by cloud computing is here to stay. Whether adoption becomes as prevalent and deep as some forecast will depend largely on overcoming fears of the cloud. Cloud fears largely stem from the perceived loss of control of sensitive data. Current control measures do not adequately address cloud computing third-party data storage and processing needs. Extending control measures from the enterprize into the cloud through the use of Trusted Computing and applied cryptographic techniques should alleviate much of todays fear of cloud computing. Combination of the two talented technologies, wireless sensor networks and cloud computing which further results in sensor clouds signicantly enhances the 57

prospective of these technologies for new and powerful applications. This further explains the reason of the widespread adoption of this technique in industries. Thus, we believe that sensor clouds will attract growing attention from the research community and the industry. In this thesis, we propose a framework of Sensor-Cloud connection to utilize the ever-expanding sensor data for various next generation community-centric sensing applications on the Cloud. It can be seen that the computational tools needed to launch this exploration is more appropriately built from the data center cloud computing model than the traditional HPC approaches or cloud approaches. We propose a content-based pub-sub model to enable this framework. Also to deliver published sensor data or events to appropriate users of Cloud applications, we propose an ecient and scalable event matching algorithm which targets range predicate case. Our proposed architecture aims to provide a cloud-enabled network that facilitates secure and seamless sharing of dierent groups of patients physiological information and to support the acquisition and analysis of patients to combat major diseases on an individual basis. The data are distributed into databases located in all the individual systems. Information from the distributed databases is made available, securely, over the Internet to provide access to patients and clinicians to combat major health diseases. This powerful combination would enable us to give eective early alerts to the specialists, researchers and caretakers about their patients health status. This enables the doctors to share the databases of dierent groups of patients physiological status from which high-value computations like decision-making, data mining and prediction of diseases can take place. The data are published via web servers. Health-care professionals, researchers and patients can access the long-term physiological data via the Internet. A secure web server allows authenticated users to access real-time patient information to consult medical specialists located at distant places.

58

Bibliography
[1] C. Ulmer, L. Alkalai and S. Yalamanchili, Wireless distributed sensor networks for 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 denition 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 view of cloud computing, EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2009-28, 2009. [4] Rmer, Kay, Friedemann Mattern (December 2004), The Design Space of Wireless Sensor Networks, IEEE Wireless Communications 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 Sensor Network text book. http://pi4.informatik.uni/mannheim.de/haensel/sn book. Retrieved 2006-08-29. [6] vTiwari, Ankit et. al, Energy-ecient wireless sensor network design and implementation for condition-based maintenance, ACM Transactions on Sensor Networks (TOSN), http://portal.acm.org/citation.cfm?id=1210670 [7] Hadim, Salem, Nader Mohamed (2006), Middleware Challenges and Approaches for Wireless Sensor Networks, IEEE Distributed Systems Online 7 (3): 1,doi:10.1109/MDSO.2006.19, http://doi.ieeecomputersociety.org/10.1109/MDSO.2006.19art. no. 0603o3001. [8] http://en.wikipedia.org/wiki/Sensor Networks

59

[9] Akyildiz, I.F., W. Su, Y. Sankarasubramaniam, E. Cayirci, A Survey on Sensor Networks, IEEE Communications Magazine, August, 102-114(2002). [10] W. Heinzelman, J. Kulik, and H. Balakrishnan, Adaptive Protocols for Information Dissemination in Wireless Sensor Networks, Proc. 5th ACM/IEEE Mobicom Conference (MobiCom 99), Seattle, WA, August, 1999. pp.174-85. [11] J. Kulik, W. R. Heinzelman, and H. Balakrishnan, Negotiation-based protocols for disseminating information in wireless sensor networks, Wireless Networks, Volume: 8, pp.169-185, 2002. [12] C. Intanagonwiwat, R. Govindan, and D. Estrin, Directed diusion: a scalable and robust communication paradigm for sensor networks, Proceedings of ACM MobiCom 00, Boston,MA, 2000, pp. 56-67. [13] D. Braginsky and D. Estrin, Rumor Routing Algorithm for Sensor Networks,In the Proceedings of the First Workshop on Sensor Networks and Applications (WSNA), Atlanta, GA, October 2002. [14] F. Ye, A. Chen, S. Liu, L. Zhang, A scalable solution to minimum cost forwarding in large sensor networks, Proceedings of the tenth International Conference on Computer Communications and Networks (ICCCN), pp. 304309, 2001. [15] C. Schurgers and M.B. Srivastava, Energy ecient routing in wireless sensor networks, in the MILCOM Proceedings on Communications for NetworkCentric Operations: Creating the Information Force, McLean, VA, 2001. [16] M. Chu, H. Haussecker, and F. Zhao,Scalable Information-Driven Sensor Querying and Routing for ad hoc Heterogeneous Sensor Networks, The International 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 processing in sensor networks, in SIGMOD Record, September 2002. [18] N. Sadagopan et al., The ACQUIRE mechanism for ecient querying in sensor networks, in the Proceedings of the First International Workshop on Sensor Network Protocol and Applications, Anchorage, Alaska, May 2003. [19] R. C. Shah and J. Rabaey, Energy Aware Routing for Low Energy Ad Hoc Sensor Networks, IEEE Wireless Communications and Networking Conference (WCNC), March 17-21, 2002, Orlando, FL.

60

[20] W. Heinzelman, A. Chandrakasan and H. Balakrishnan, Energy-Ecient Communication Protocol for Wireless Microsensor Networks, Proceedings of the 33rd Hawaii International Conference on System Sciences (HICSS 00), January 2000. [21] S. Lindsey, C. Raghavendra, PEGASIS: Power-Ecient Gathering in Sensor Information 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 enhanced eciency in wireless sensor networks, In 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing, April 2001. [23] A. Manjeshwar and D. P. Agarwal, APTEEN: A hybrid protocol for ecient routing 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 Revisited, 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 Ad Hoc Networking and Computing,Boston, MA, August 2000. [27] Q. Fang, F. Zhao, and L. Guibas, Lightweight Sensing and Communication Protocols for Target Enumeration and Aggregation, Proceedings of the 4th ACM 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 Aggregation in Wireless Sensor Networks - Exact and Approximate Algorithms, Proceedings 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 Sensor Networks, In Proceedings of the DIMACS Workshop on Pervasive Networking, May, 2001. 61

[30] F. Ye, H. Luo, J. Cheng, S. Lu, L. Zhang, A Two-tier data dissemination model for large- scale wireless sensor networks, proceedings of ACM/IEEE MOBICOM, 2002. [31] Y. Xu, J. Heidemann, D. Estrin,Geography-informed Energy Conservation for Ad-hoc Routing, In Proceedings of the Seventh Annual ACM/IEEE International Conference on Mobile Computing and Networking 2001, pp. 70-84. [32] Y. Yu, D. Estrin, and R. Govindan, Geographical and Energy-Aware Routing: A Recursive Data Dissemination Protocol for Wireless Sensor Networks, UCLA Computer Science Department Technical Report, UCLA-CSD TR-010023, May 2001. [33] B. Karp and H. T. Kung, GPSR: Greedy perimeter stateless routing for wireless sensor networks, in the Proceedings of the 6th Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom 00), Boston, MA, August 2000. [34] I. Stojmenovic and X. Lin. GEDIR: Loop-Free Location Based Routing in Wireless Networks, In International Conference on Parallel and Distributed Computing and Systems,Boston, MA, USA, Nov. 3-6, 1999. [35] F. Kuhn, R. Wattenhofer, A. Zollinger,Worst-Case optimal and average-case ecient geometric ad-hoc routing, Proceedings of the 4th ACM International Conference on Mobile Computing and Networking, Pages: 267-278, 2003. [36] B. Chen, K. Jamieson, H. Balakrishnan, R. Morris, SPAN: an energy-ecient coordination algorithm for topology maintenance in ad hoc wireless networks, Wireless Networks, Vol.8, No. 5, Page(s): 481-494, September 2002. [37] Container and Truck Trailer Security Project, Cambridge Systematics, Inc. Parsons Brinckerho 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 Networks 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 Personal Communications (Oct. 2000) 47-49. [43] M. Srivastava, R. Muntz, M. Potkonjak, Smart kindergarten: sensor-based wireless networks for smart developmental problem-solving enviroments, Proceedings of the 7th annual international conference on Mobile computing 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 HPCC08, 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 IEEE Conf. on Local Computer Networks. [46] Harris D. 2008. Managing Editor, On-Demand Enterprise. The Grid Cloud Connection-Compare and Contrast. http://www.ondemandenterprise.com/features/The Grid-cloud Connection 30634819 .html [47] Eugster P. Th., et al. 2003. The many faces of Publish/Subscribe. In ACM Computing Surveys Vol. 35(2): 114 - 131. [48] Souto E., et al. 2005. Mires: A publish/subscribe middleware for sensor networks. In ACM Personal and Ubiquitous Computing, 10(1): 37-44. [49] Krishnamurthy S. 2006. TinySIP: Providing Seamless Access to Sensorbased Services. In Proceedings of the 1st International Workshop on Advances in Sensor Networks (IWASN). [50] Hall C. P., Carzaniga A., Rose J. and Wolf A. L. 2004. A content-based networking 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 Publish/Subscribe Protocol For Wireless Sensor Networks. In IEEE Conference on COMSWARE. [52] Liu Z. et al. 2007. Scalable Event Matching for Overlapping Subscriptions in Pub/Sub Systems. In Proc. of DEBS07, 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 Matching for Highly-Overlapping Range Predicates. ACM Symposium on Applied Computing, Nicosia, Cyprus. [55] V.Rajesh, J.M.Gnanasekar, R.S.Ponmagal, P.Anbalagan.2010. Integration of Wireless Sensor Network with Cloud. In Proc. of International Conference on Recent Trends in Information, Telecommunication and Computing. DOI 10.1109/ITC.2010.88 [56] Pathan A. K., Broberg J., et al. 2007. An Architecture for Virtual Organization (VO)-Based Eective Peering of Content Delivery Networks. In Proc. of UPGRADE-CN07. ACM Press, California, USA. [57] Y-T. Zhang, X.Y. Xiang, C.C.Y. Poon, The evaluation of nodes of body sensor networks: Wearable blood pressure measuring devices, in: Proceedings of the International 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 Personal Communications 8 (4) (2001) 66-71. [62] V. Stanford, Using pervasive computing to deliver elder care, IEEE Pervasive Computing 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: potential and challenges, in: High Condence Medical Device Software and Systems (HCMDSS) Workshop, 2005. [65] A. Lymberis, Smart wearables for remote health monitoring, from prevention to rehabilitation: In the Proceedings of 4th International IEEE EMBS Special Topic Conference on Information Technology Applications in Biomedicine, 2003, pp. 272-275. 64

[66] M. Pallikonda Rajasekaran, S. Radhakrishnan, P. Subbaraj, Remote patient monitoring system using wireless sensor networks, International Journal of Healthcare Technology and Management 9 (3) (2008) 247-257. [67] N. Oliver, F.F. Mangas, HealthGear: A real-time wearable system for monitoring and analyzing physiological signals, In the Proceedings of the International 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 International Conference on Ubiquitous Computing, 2004. [69] M. Gaynor, et al., Integrating wireless sensor networks with the grid, IEEE Internet 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