IT 11 042

Examensarbete 30 hpJune 2011

A Publish/Subscribe Platform Supporting Mobile Brokers for Hybrid Sensor Networks

Xiaoyu Tong

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

A Publish/Subscribe Platform Supporting MobileBrokers for Hybrid Sensor Networks

Xiaoyu Tong

Sparse sensor networks are cost-effective when deployed over large geographicalareas. However, since sensor nodes cannot communicate with each other directly,how to connect those nodes to the Internet would be a problem. On the other hand,if traditional stationary sensors could be accessed from mobile phones, usability andfunctionality of participatory sensing applications could be enlarged. In this thesis, Idesign and implement a publish/subscribe platform which employing mobile phonesconnecting both stationary sensors and mobile sensors to the Internet. Through thisplatform, more sensor services could be utilized by participatory sensing applicationsand promising applications would be possible to emerge.

Tryckt av: Reprocentralen ITCIT 11 042Examinator: Anders JanssonÄmnesgranskare: Christian RohnerHandledare: Edith Ngai

TABLE OF CONTENTS

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation and Problem Statement . . . . . . . . . . . . . . . . . . . . . . 11.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Distributed System Paradigm . . . . . . . . . . . . . . . . . . . . . 31.2.2 Mobile Proxy Support . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3 Unified Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.4 Internet Access to Stationary Sensors . . . . . . . . . . . . . . . . 4

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Sparse Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Participatory Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 REST and RESTful Web Services . . . . . . . . . . . . . . . . . . 122.3.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Publish/Subscribe Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1 Topic-based publish/subscribe . . . . . . . . . . . . . . . . . . . . 142.4.2 Content-based publish/subscribe . . . . . . . . . . . . . . . . . . . 14

2.5 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1 Publish/Subscribe Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Integrate WSNs with Internet . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Participatory Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Sparse Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

i

Chapter 4 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1 System Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Publish/Subscribe System . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.1 Selection of Pub/Sub Paradigm . . . . . . . . . . . . . . . . . . . . 254.3.2 Publish/Subscribe System Architecture . . . . . . . . . . . . . . . 25

4.4 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 5 Publish/Subscribe Platform Design . . . . . . . . . . . . . . . . . . 315.1 Publish/Subscribe Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 Subscription Semantics . . . . . . . . . . . . . . . . . . . . . . . . 315.1.2 Event Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 Adaptive Location Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4 Best-effort Policies on Subscription Caching and Delivery . . . . . . . . . . 39

5.4.1 Subscription Caching and Delivery at Broker . . . . . . . . . . . . 405.4.2 Subscription Caching and Delivery at MB . . . . . . . . . . . . . . 42

5.5 Adaptive Algorithm on Subscription Delivery at Broker . . . . . . . . . . . 465.5.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . 465.5.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.6 Event Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.6.1 Event Collection from MSensors . . . . . . . . . . . . . . . . . . . 485.6.2 Event Collection from SSensors . . . . . . . . . . . . . . . . . . . 48

Chapter 6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Mobile Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2.1 Supporting Diverse MSensors . . . . . . . . . . . . . . . . . . . . 516.3 SSensor Related Implementations . . . . . . . . . . . . . . . . . . . . . . 53

6.3.1 Communication with SSensors . . . . . . . . . . . . . . . . . . . . 536.3.2 Event caching on SSensors . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 7 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.1 Hiking Trail Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.2 Experiment Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3 Experiment Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3.1 Sensing Data from Stationary Sensors . . . . . . . . . . . . . . . . 587.3.2 Sensing Data from Mobile Sensor . . . . . . . . . . . . . . . . . . 607.3.3 User Hiking Frequency . . . . . . . . . . . . . . . . . . . . . . . . 62

ii

7.3.4 System Performance . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chapter 8 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . 708.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Appendix A Sample JSON Messages . . . . . . . . . . . . . . . . . . . . . . 74

A.1 Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74A.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Appendix B Compressed Message for Sensor Communication . . . . . . . . . 77B.1 Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.2 Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

iii

LIST OF TABLES

Table 2.1 Tmote Sky Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 10

Table 7.1 Experiment Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

iv

LIST OF FIGURES

Figure 2.1 A typical wireless sensor network . . . . . . . . . . . . . . . . . . 7Figure 2.2 A sparse sensor network connected by mobile agents . . . . . . . . 8Figure 2.3 A Tmote Sky mote . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 2.4 A sample JSON representation . . . . . . . . . . . . . . . . . . . . 13Figure 2.5 A simple publish/subscribe system . . . . . . . . . . . . . . . . . . 13

Figure 4.1 Roles in a system using our platform . . . . . . . . . . . . . . . . . 23Figure 4.2 A Network Perspective of the System . . . . . . . . . . . . . . . . 24Figure 4.3 A Publish/Subscribe Perspective of the System . . . . . . . . . . . 26Figure 4.4 Operations in the publish/subscirbe platform . . . . . . . . . . . . . 26Figure 4.5 Software Architecture on Broker . . . . . . . . . . . . . . . . . . . 27Figure 4.6 Software Architecture on Mobile Broker . . . . . . . . . . . . . . . 28Figure 4.7 Software Architecture on SSensor . . . . . . . . . . . . . . . . . . 29

Figure 5.1 Format of Subscription Message from Subscriber to Broker . . . . . 32Figure 5.2 Format of Subscription Message to MSSPs . . . . . . . . . . . . . 33Figure 5.3 Format of Subscription Message to SSSPs . . . . . . . . . . . . . . 34Figure 5.4 Format of Event Message . . . . . . . . . . . . . . . . . . . . . . . 34Figure 5.5 Subscriber Registration and Association . . . . . . . . . . . . . . . 35Figure 5.6 Random Re-registration for Mobile Broker . . . . . . . . . . . . . . 35Figure 5.7 Situation when MB is outside of any target area . . . . . . . . . . . 37Figure 5.8 Communication between MB and Broker on adaptive location update 38Figure 5.9 MB traverses through a subscription’s target area . . . . . . . . . . 39Figure 5.10 Subscriptions Delivery from Subscriber to Mobile Broker . . . . . . 40Figure 5.11 Subscriptions forwarding from MB to sensors . . . . . . . . . . . . 42Figure 5.12 Broadcast discovery message while a MB traversing in a target area 43Figure 5.13 Event Collection from the SSensor . . . . . . . . . . . . . . . . . . 49

Figure 6.1 Hiking Trail Application UI . . . . . . . . . . . . . . . . . . . . . . 52Figure 6.2 Attaching Tmote Sky to HTC Hero . . . . . . . . . . . . . . . . . . 53

Figure 7.1 Deployment in hiking trail area . . . . . . . . . . . . . . . . . . . . 56Figure 7.2 Installation of stationary sensors . . . . . . . . . . . . . . . . . . . 57Figure 7.3 Temperature Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figure 7.4 Humidity Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figure 7.5 Light Intensity Data . . . . . . . . . . . . . . . . . . . . . . . . . . 59

v

Figure 7.6 User Speed Distribution . . . . . . . . . . . . . . . . . . . . . . . . 60Figure 7.7 User Hiking Speed at Different Positions . . . . . . . . . . . . . . . 61Figure 7.8 User Hiking Frequency . . . . . . . . . . . . . . . . . . . . . . . . 62Figure 7.9 Data Packet Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 7.10 Number of Data Received at Different Speed . . . . . . . . . . . . 64Figure 7.11 Duplicate Data Received From Stationary Sensors . . . . . . . . . . 65Figure 7.12 Subscription Delivery Rate . . . . . . . . . . . . . . . . . . . . . . 66Figure 7.13 Subscription Delivery Times . . . . . . . . . . . . . . . . . . . . . 67Figure 7.14 Location Update Times . . . . . . . . . . . . . . . . . . . . . . . . 68

Figure B.1 Compressed Format for a subscription . . . . . . . . . . . . . . . . 77Figure B.2 Compressed Format for an Event . . . . . . . . . . . . . . . . . . . 77

vi

Chapter 1

Introduction

1.1 Motivation and Problem StatementDuring the last decade, wireless sensor networks (WSNs)[13] are intensively researched bythe community. These networks are usually formed by a large number of interconnectedsensor nodes which have low power, tiny dimension, and short range radio. A typicalexample of such nodes is Tmote Sky[1]. Previous results in the research community re-veal vast usage of WSNs in different fields such as health care[48][67], environmentalmonitoring[63][46], habitat monitoring[47], and industrial monitoring[44]. As shown inthese applications, a WSN could autonomously sense the physical proximity for continu-ous periods.

Traditionally, nodes in WSNs are densely deployed because of their short range radio.In addition, data consumers from other networks (e.g. Internet) have to access WSNsthrough pre-installed sinks or proxies. However, this kind of deployments will be cost-prohibitive if the sensor nodes are required to spread over a large geographical area. Forexample, temporature sensors may need to be deployed in a forest park. In this case, toomany nodes will be needed in order to form a dense sensor network accrossing this park.As described in [58], a sparse sensor network (SSN) which uses the data mule would be abetter choice in these scenarios. In order to connect sparsely deployed sensors, a mobiledevice called data mule is employed as a mobile proxy between those stationary sensorsand data consumers. Since no static infrastructure depended on and only a few number ofsparsely deployed sensors needed, SSNs are cost-effective and easy to deploy. However,since the deployment of a SSN relies on the mobile proxies, the selection of devices used asmobile proxies will largely affect the cost and usage of a SSN. Further more, if we want toextend the advantages of SSNs to a very large scale (e.g. urban wide), the cadidate devicesfor the mobile proxies should be as ubiquitous as possible.

1

On the other hand, the smart phone has recently become the ubiquitous mobile devicesince its proliferation. As a result, participatory sensing[18] applications become applica-ble. In those applications, smart phones are used as sensing devices. Different from thelow-end phones, smart phones usually contain multiple built-in sensors, e.g. GPS, lightsensor and microphone. Besides, they also have higher computation and communication(e.g. 3G and Wifi) abilities. Therefore, participatory sensing applications utilizing thesmart phones could even be deployed in a global scale. Applications like [50], [53] and[49] demonstrated how participatory sensing applications could work.

Since smart phones are ubiquitous mobile devices nowadays, if we use smart phones asmobile proxies in SSNs, the deployments of SSNs could be extended to urban wide or evento global wide. More specifically, since ordinary users carrying the smart phones couldmove around everywhere, the SSNs could be installed at any place where those users mayvisit. Therefore, the deployments of such SSNs will not be restrictred by any infrastruc-ture and their sensing scopes could be dramatically enlarged. Besides, since smart phoneshave Internet connections, SSNs employing these mobile devices could expose their sens-ing services to all the Internet users around the world. On the other hand, for most ofthe participatory sensing applications, they are limited by the sensing abilities of mobilesensors on board the smart phones. For example, a typical smart phone only has GPS,digital compass, camera, microphone, light sensor and proximity sensor. Therefore, if wecould integrate sensor nodes in SSNs into the participatory sensor networks, the function-ality and sensing ability of participatory sensing applications will be largely extended (e.g.temperature and humidity sensors in SSNs could be used). By employing smart phones asmobile proxies to integrate SSNs into participatory sensor networks, sensing services bothfrom stationary sensors in the SSNs and mobile sensors on borad the smart phones couldbe utilized by Internet users simultaneously. As a result, constructions of large scale hybridsensor networks become possible.

Therefore, if we could enable smart phones as mobile proxies and sensing devices atthe same time, the advantages descirbed above could be obtained. In this thesis, we focuson design and implementation of a publish/subscribe platform through which smart phonescould be enabled as both mobile proxies in SSNs and mobile sensing devices. In the restpart of this thesis, the sensor in the SSN will be referred to as stationary sensor (SSensor).On the other hand, the sensor on board the smart phone will be referred to as mobile sensor(MSensor). With this platform, users (or applications) could assign sensing tasks both toMSensors and SSensors directly from the Internet. Afterwards, the generated data bothfrom MSensors and SSensors could be automatically returned back to remote users. Sincemobile sensors and stationary sensors usually have distinct sensing abilities, users who useour platform could utilize more diverse data than they could before. Further more, sincemore sensing services could be combined in one application, new applications which are

2

impossible before would also emerge. As a sample, such an application was implementedin our experiment part. In addition, since the terms of smart phone and mobile phone areusually used in turn, we will also use them equally in this thesis.

1.2 ChallengesWhen designing a platform supporting the smart phones both as mobile proxies and sensingdevices, several challenges need to be tackled. In this section, different challenges aredescirbed seperately.

1.2.1 Distributed System ParadigmSince mobile phones and SSensors are used, these components in our platform actuallyform a distributed system. For any distributed system, the system paradigm will affect thedesign on system architecture, therefore it should be decided at the first place in our designwork. Actually, there are several paradigms frequently used.

Remote Procedure Call (RPC) [15] is one of the most widely used paradigms. Themain advangtage of RPC is that program could invoke remote procedures or subroutinesnearly the same way as local ones. Thus, it makes distributed programming very easy.For example, in a data collection application, the data collection operation could be im-plemented as a remote procedure call which is called by the client but executed at remoteservice providers. Typical middleware following RPC paradigm are SOAP [35] and JAVARMI [65].

Publish/Subscribe [28] is another most widely used paradigm. In a typical publish/-subscribe system, there are subscribers, publishers and brokers. Instead of communicatingdirectly, subscribers and publishers exchange messages through the intermediary brokers.In the system, subscribers express their interests on data by sending subscriptions to bro-kers. Afterwards, once events generated at the publishers, broker will filter the receivedevents according to the limitations specified in subscriptions. Finally, all the qualifiedevents will be notified to the related subscribers. Since the intermediary brokers are em-ployed, publish/subscribe system has a nature on the decoupling between subscribers andpublishers.

1.2.2 Mobile Proxy SupportIn our platform, since the mobile phone is used as the proxy between stationary sensors andInternet users, how to support its mobility during the end-to-end communication betweenthese components is a main problem need to be solved.

3

For most of the previous WSNs [11] [39], the proxy to Internet is a static device. Butwhen it becomes mobile, multiple new problems will occur. For example, since the mo-bility of mobile phones is uncontrolled in our platform, mobile proxies can only encounterSSensors opportunistically. Therefore, the connections between mobile proxies and SSen-sors are intermittent or even sporatic. Further more, since Internet users access SSensorsthrough the mobile proxies, the end-to-end connections between the Internet users andSSensors are also intermittent. Therefore, how to support the loose connectivities causedby the mobility of the mobile proxies should be considered in our platform. Specifically,the problems need to be solved for enabling the mobility of mobile proxies are listed asfollows:

– How could mobile proxy and SSensors discovery each other and establish connectionswhile the mobile proxy is moving uncontrolledly?

– How could the queries or subscriptions be transmitted from Internet users to SSensors insuch intermittent or sporatic connections?

– How could data or events be sent back from SSensors to Internet users in such looseconnectivities?

1.2.3 Unified SemanticsNot built for any specific appliction, this platform intends to provide Internet interfaces forany application or user who wants to utilize the underlying SSensors and MSensors. Onthe other hand, keeping scalability in mind, our platform also needs to supply interfacesfor any underlying SSensor and MSensor who wants to expose their sensing services toInternet users. Therefore, our platform has to provide generic interfaces in two directions.First, since users or applications could have diverse interests on different kinds of sensors(both SSensors and MSensors), our platform should support interfaces having enough ex-pressiveness to reflect and satisfy the users’ interests. Second, since the sensing abilitiesof different sensors may be quite distinct from each other, our platform also has to provideinterfaces through which diverse sensors could expose their services to the users. In ad-dition, since the data generated at different sensors may have different formats, an unifiedencapsulation of different data is also necessary.

1.2.4 Internet Access to Stationary SensorsIn our platform, SSensors could reach the Internet through the Internet connections on themobile proxies. However, before reaching the Internet, SSensors should be connected tothe mobile proxies at first. Since there is no standard for the connections between the

4

mobile phones and SSensors, the selection of connection protocols between them has tobe decided in our platform. Further more, since the network layer protocol will affect thedesign on the application layers, it is quite important to choose the right approach based onthe system requirements.

Currently, there are two popular approaches for integrating SSensors to Internet. One isto install IPv6 stack on sensor nodes [38], then they can communicate with proxies directlyin IP. Since in this approach, all the devices communicate in IP, it is refered to as full-IPsolution in this thesis. On the other hand, another approach uses customized and optimizednetwork-layer protocols on sensor nodes, e.g. Rime [27]. Then before sending the receivedpackets to the Internet, the proxy needs to convert them to the IP format. Since in the laterapproach, both IP and customized network-layer protocol are employed, it will be referedto as hybrid solution in this thesis.

Both of these two solutions have their advantages and disadvantages. For the full-IPsolution, no protocol convertion is needed. But for the hybrid solution, no globally uniqueIPv6 address need to be assigned to each device. Since an IP packet is routed by the networkinfrastructures (e.g. routers), an IP address of a device usually implies its physical location.Therefore, for the hybrid solution, it is easier to support the mobilities of devices.

1.3 ContributionsIn this thesis, my work contributes from three points. First, a publish/subscribe platformis designed to enable mobile phones both as the mobile proxies for SSensors and mobilesensing devices. In this platform, since connections between mobile phones and SSensorsare intermittent or sporadic, mechanisms handling communication between different com-ponents are proposed. Additionally, two adaptive algorithms reduing system overheads inthe platform are designed. Second, in order to prove our design is feasible under currenttechnologies, we also implemented this platform on real devices. In the implementation,different components of the platform were realized in the Internet server, Android mobilephone and Tmote sky sensor node respectively. Third, in order to evaluate the performanceof our implementation, real experiments were carried out. According to the experiments,it is proved that our platform could receive 100% of all the subscribed data from remotesensors although in the condition of intermittent connections. At the same time, the end-to-end data packet delays were also acceptable. In addition, the experiment also showed ouradaptive algorithms could improve the platform performance effectively.

5

1.4 Thesis StructureThe structure of this thesis is as follows. Chapter 2 describes the background knowledgeswhich are neccessory to understand this report. In the chapter 3, the state of the art inrelevant fields is reviewed. After that, chapter 4 will show the system perspective of theplatform. In chapter 5, the detail information on the design of different components isexplained. Chapter 6 depicts how the platform was implemented on real devices. Followingthat, chaper 7 is about the experiment and its results. At the end of this report, chapter 8gives the conclusion and the future possible work.

6

Chapter 2

Background

2.1 Wireless Sensor Networks

Figure 2.1: A typical wireless sensor network

Advances in the electronic and the wireless communication have enabled small embed-ded devices which integrate sensing and wireless communication abilities. Although tinyin size, such a device usually contains a radio transceiver, a microcontroller, and one (orseveral) sensors. Commonly, this kind of device is refered to as a mote or sensor node. Byinterconnecting with each other wirelessly, the motes then form a network which is knownas a wireless sensor network (WSN).

Usually, WSNs are utilized in applications like environmental monitoring, structuralmonitoring, home automation, and industrial monitoring. In such applications, sensor

7

nodes perform tasks by sensing their physical and environmental conditions such as hu-midity, temperature, light intensity, pressure, and vibration. Afterwards, the sampled datais transmitted hop by hop then through the whole network to a proxy or sink node. A typ-ical deployment of a WSN is presented in Figure 2.1. The sink in Figure 2.1 is usually anode or base station which could relay messages between the WSN and other networks.

In WSNs, the terminologies of senor node, mote, and sensor are mutually used to referto the tiny embedded device. Therefore, in this thesis, these terms are also equally used ifthere is no explicit explanation.

2.1.1 Sparse Sensor Network

Figure 2.2: A sparse sensor network connected by mobile agents

As depicted in Figure 2.1, the traditional deployment of a WSN includes only stationarysensor nodes. Since densely deployed, these nodes could communicate with their neighborsdirectly during most of the time. However, as the researches in this field proceeds anddevelops, more and more applications require different deployments from the previous one.According to [57] and [62], the network in Figure 2.1 is classifid as a static, dense, andconnected WSN.

For the non-traditional applications, some of them especially require the sensor nodesto be spreaded over a large geographical area. As a result, these sensor nodes will forma network which is usually refered to as sparse sensor network (SSN) [41]. Because theradio ranges of sensor nodes are very short, how to enable connectivities is a main problemin a SSN.

As mentioned in [58], there could be two simple but cost-prohibitive approaches. One

8

is to deploy enough sensor nodes in the large area to form a dense sensor network. Anotheris to install many base stations to collect data from sensor nodes. These base stations canonly communicate with sensor nodes which are in their radio ranges.

However, because the above two approaches are not cost-effective, [41] and [58] pro-posed a solution which employs mobile devices to relay data between sensor nodes anddata consumers. Figure 2.2 depicts a scenario of this solution.

Different from Figure 2.1, there are both stationary nodes and mobile nodes in Fig-ure 2.2. Because they are sparsely deployed, stationary nodes have no direct connectionbetween each other. The connection in this network is only established when a mobile nodeenters radio range of any stationary node. For the mobile node, it is assumed having directconnection with data consumers or wired access points. At the same time, it should be ableto communicate with stationary nodes in short-range radio. Again, according to [57] and[62], the network in Figure 2.2 is classified as a dynamic, sparse and sporadic WSN.

If related to this thesis, the stationary node and the mobile node in Figure 2.2 are actu-ally the SSensor and the smart phone respectively. Since the problem and solution in thisthesis is based on the approach in Figure 2.2, we will implicitly mean a SSN like that inFigure 2.2 when mentioning SSN in this thesis.

2.1.2 IEEE 802.15.4IEEE 802.15.4[10] is standard which specifies the physical layer and media access controlfor low-rate wireless personal area networks (LR-WPANs). It intends to be used on low-cost, low-speed pervasive communication between embedded devices. It is also the de factostandard of MAC layer protocols for communication in WSNs. In our implementation, thecommunication between SSensors and smart phones used this standard.

2.1.3 Tmote Sky

Figure 2.3: A Tmote Sky mote

9

As we mentioned previously, motes or sensor nodes are the particles which form theWSNs. Until now, many different types of motes have already been available in the marketor academic society. From these motes, Tmote Sky[54] which is depicted in Figure 2.3 waschosen as the stationary sensors used in our implementation. The main characteristics ofthis mote are listed in Table 2.1.

Table 2.1: Tmote Sky Parameters

Microcontroller 8MHz Texas Instruments MSP430 microcon-troller (10k RAM, 48k Internal Flash, 1MB Ex-ternal Flash)

Radio Chip 250kbps 2.4GHz IEEE 802.15.4 Chipcon Wire-less Transceiver

Communication Range 50m range indoors / 125m range outdoorsIntegrated Sensors Humidity, Temperature and Light Intensity

2.1.4 ContikiContiki[26] is an open source, light weight, event-driven and multi-threading operatingsystem which is especially used on resource constrained devices like sensor nodes. Uponits 2.5 version, Contiki has been ported to a lot of hardware platforms including Tmote Sky.

In Contiki, there is a stack Rime[27] which could be used for the low-power communi-cation between sensor nodes. Rime stack contains broadcast, unicast and reliable-unicastpremitives. During communication, a point-number format Rime address (e.g. 10.22) isused as the sensor node identification.

Beside this, Contiki also enables large-scale storage by a file system called Coffee[64].With the help of Coffee, data could be stored as files on flash-based memories.

In our implementation, Contiki was used as the sensor programming platform. TheRime stack and Coffee file system were employed to provide sensor node communicationand data storage management respectively.

2.2 Participatory SensingRecently, the proliferation of smart phones make them ubiquitous devices in our daily lifes.A smart phone is a mobile phone which has more advanced computing and communication

10

abilities than a low-end mobile phone. Usually, a smart phone is equiped with on-boardsensors such as GPS, microphone, camera and light sensor. Because of the maturity ofthese devices, a new application scenario called partipatory sensing [18] [19] emerged.In participatory sensing, smart phones are seen as sensors which have ubiquitous Internetconnections. As a result, a participatory sensor network is formed by connecting thosesensors together. Because smart phones are carried by users moving around everywhere,the participatory sensor network could be extended to the urban or even globle scale. Inthis thesis, since a smart phone is actually a mobile phone, these two terms will be usedequally and alternatively.

Different from the traditional WSNs, participatory sensing has several unique features.First, sensors are mobile, so they may enter the target areas opportunistically. Second,human is not only a data consumer, but also involve in the sensing task. For example, theparticipatory sensing system may need to interact with a person in order to lead him tocarry his smart phone to a target sensing area. In some other applications, users who ownthe smart phones may need to provide their feedbacks as the sening results. Third, for datacollected in the system, it will be tagged with location and time stamps. The location stampmay be provided by GPS and the time stamp could be obtained from the network. As aresult, the credibility of information on when and where the data was taken is improved.

The above features make participatory sensing system suitable for applications whichrequire large coverage, high data quantity and quality.

2.3 Web ServiceAs defined in [16], a web service is "a software system designed to support interoperablemachine-to-machine interaction over a network". Actually, in a web service system, thereare service requester and service provider respectively. The provider describes its servicesusing a machine-processable format. On the other hand, the requester interacts with theprovider in a machine independent language, e.g. XML [17] or JSON [24]. During thecommunication, the messages between requester and provider are conveyed by HTTP [30].

Since the Web2.0 [52] movement, the implementations of the web service system havedevelopped into two main categories. One is called Big Web Services which especiallyrefers to implementations following WSDL [22] and SOAP [35] standards. Another iscalled RESTful Web Services which represents the implementations conforming to REST[31] principles.

Because the implementation in this thesis follows REST constrains, I will only explainREST and RESTful web services in this section. The information about SOAP and WSDLcould be found in [35] and [22].

11

2.3.1 REST and RESTful Web ServicesIntroduced by Roy Fielding in his doctoral dissertation [31], Representational State Trans-fer (REST) is a architectural style for distributed hypermedia systems. In literature, animplementation is usually refered to as being RESTful if it conforms to the REST princi-ples. Currently, the largest RESTful implemenation is World Wide Web [40].

A key abstraction in REST is the resource. Between components in REST, a resourceis identified by a resource identifier. While in the context of Web, a resource identifier isexpressed by an URI [9]. Since it is an abstraction, a resource in the REST system couldhave different representations. For example, a document resource could be represented inHTML or XML respectively. Actually, operations in the REST system are all built aroundthe transfer of representations of resources.

RESTful Web Services

As explained in above paragraphes, a RESTful web service is a web service system whichconforms to REST constrains. Because the architecture of web itself follows REST prin-ciples, a RESTful web service could be implemented directly on top of HTTP. In otherwords, we do not need to bother additional protocols (e.g. WSDL) while building suchweb services. As a result, a RESTful web service is lighter and integrated more tightlywith web than Big Web Services.

On the other hand, a resource in a RESTful web service could be represented in anyvalid Internet media type such as JSON and XML. Additionally, this makes it more flexibleand scalable than Big Web Services.

In this thesis, my aim is to enable Internet users to access both SSensors and MSensorsthrough mobile phones. During the design and implementation, the sensing abilities ofSSensors and MSensors could be expressed as web services. Therefore, a lightweight andflexible web service architecture is preferred. As a result, RESTful architecture is used inour platform.

2.3.2 JSONJavaScript Object Notation [24] is a human-readable, lightweight and text-based format

for data interchange between machines. Similar as XML, it intends to serialize structureddata over a network connection. Since encoding data directly using key-value format, JSONhas lower overhead than XML. In this thesis, JSON was used as the representation formatof resources. A sample JSON representation is depicted in Figure 2.4.

12

Figure 2.4: A sample JSON representation

2.4 Publish/Subscribe Paradigm

Figure 2.5: A simple publish/subscribe system

First mentioned in [14], publish/subscribe [28] is a messaging paradigm where messagesenders do not send messages directly to message receivers. Instead, a middleware serviceis provided to relay messages between senders and receivers. In literature, the messagesender is usually refered to as a publisher, while the message receiver is refered to as asubscriber. For the middlerware service of message relay, it is often realized by an entitycalled broker.

In a publish/subscribe system, subscribers could express their interests on an event, ora class of events by registering a subscription at broker. When receiving any event frompublishers, broker will filter them according to the registered subscriptions. Afterwards,the subscribers could be notified by matched events. On the other hand, publishers alsohave the abilities to register their services at the broker. Therefore, when receiving any

13

subscription, the broker may forward it to suitable publishers according to their serviceregistration. A simple publish/subscribe system is depicted in Figure 2.5.

As researched in [28], the main advantage of publish/subscribe paradigm is its fulldecoupling in time, space, and synchronization between publishers and subscribers. Sinceusing an event-based interaction style, publishers and subscribers do not need to wait foreach other during a communication. At the same time, neither publishers nor subscriberswould be aware of the existance of the counterparts.

As summarized in [28], the different ways of expressing subscribers’ interests on eventshave led to two main subscription schemes. Based on the subscription schemes, publish/-subscribe systems are seperated into two categories. they will be explained respectively inthe following subsections.

2.4.1 Topic-based publish/subscribeIn the early age of publish/subscribe paradigm, a lot of distributed systems (e.g. [21], [68],and [56]) were implemented in the topic-based scheme. As implied by its name, a topic-based publish/subscribe system enable subscribers to subscribe events according to topics.Usually, the topics are identified by keywords. For example, by wrapping keyword “StockPrice" in its subscription, a subscriber could subscribe to all events related to “Stock Price".In abstraction, topic-based system could be thought as a distributed system where publish-ers and subscribers are connected to each other through channels identified by specific topickeywords.

2.4.2 Content-based publish/subscribeAlthough very simple to use, topic-based scheme is static, so its expressiveness is very lim-ited. For example, a subscription interested in “Stock prices >= 120" can not be expressedin topic-based scheme. Therefore, the content-based scheme emerged to solve this kind ofrequests.

In a content-based scheme, subscribers could express their interests directly on the con-tent of events. For this purposes, filters could be specified as constrains in a subscription.Normally, the constrains are defined by predicates (e.g. =, �, �, <, >) with name-valuepairs. Further more, basic constrains could be combined into more complex patterns. Withhelp of fine-grained constrains, subscribers could subscribe to events which match theirrequests exactly. Therefore, if compared to topic-based system, a content-based publish/-subscribe system could filter more unwanted events. Because of its rich expressiveness,content-based publish/subscribe scheme is widely used in many applications, e.g. [34] and[61] .

14

2.5 Tools

Android Operating SystemAndroid [2] is an operating system for mobile devices. Built on top of the Linux [7] kernel,it is composed by a software stack which enables communication and multi-media funci-tionalities. Compared to other mobile operating systems, Android is outstanding becauseit could fully support Java. Actually, this is considered as a big advantage since most ofthe existing Java applications and libraries on Desktop platforms could later be migrated toAndroid platform directly. As a result, development for Android applications becomes asconvenient and easy as that for desktop applications.

In this thesis, the modules on mobile phones were implemented on Android platform.

Java EEJava Platform, Enterprise Edition (Java EE) [6] is a platform for server programming inJava lanuage. Different from the Java Standard Edition Platform (Java SE), Java EE con-tains additional libraries which enable the development of distributed and web-based Javaapplications running on a web server.

In this thesis, the modules on the HTTP web server were implemented using the JavaEE compliant tools. These tools are introduced in the following sections.

Apache Tomcat

Apache Tomcat [4] is an open source HTTP web server which implements Java Servlet andJavaServer Pages specifications defined in Java EE. Different from some other web servers,Apache Tomcat could provide a complete java environment for application development.Since Java is machine independent, Java was chosen as the programming language in theimplementation for most of our modules. Therefore, Apache Tomcat was also chosen asthe web server in the our implementation.

Apache CXF

Apache CXF [3] is an open source framework helping build web service applications inJava EE platform. It provides convenient interfaces for developers to create web serviceapplications easily. Besides SOAP and CORBA, Apache CXF also facilitates RESTful webservices through its RESTful HTTP interfaces. Because of these features, all the RESTfulweb service modules in this thesis are realized on the Apache CXF library inside a ApacheTomcat server.

15

Chapter 3

Related Work

For the publish/subscribe platform in this thesis, it has to deal with problems in severalfields. First, in order to use the mobile phone as a mobile proxy for SSensors, previouswork in sparse sensor networks and integration of WSNs and Internet need to be studied.Second, if we use mobile phone as a sensing device, related work in participatory sensingneed to be reviewed. Third, for unified access of web services at SSensors and MSensors,existing web service systems in sensor networks should be referred to. At last, since ourplatform is a distributed system, the distributed system paradigm such as publish/subscribeneed to be researched, especially, when this paradigm is applied to sensor networks.

In the following part of this chapter, all the related work will be listed and discussed bytheir topics.

3.1 Publish/Subscribe SystemsAs a fully decoupled messaging pattern, publish/subscribe paradigm has already been uti-lized in many systems. Among the previous work, the topics on its adoption in wirelesssensor networks, mobile communication environment, and delay-tolerant networks relateclosestly to this thesis.

MQTT-S [39] is a publish/subscribe protocol designed for WSNs. Extended fromMQTT [8], it employs topic-based scheme for the subscriptions. Similar as this thesis,one of its goals is to enable queries to sensor nodes directly from Internet. Inside a MQTT-S system, there are two componets: MQTT-S clients and MQTT-S gateways. The MQTT-Sclients reside in WSNs and they are installed on sensor nodes. On the other hand, MQTT-Sgateways are infrastructures which act as proxies between Internet and WSNs. By usingone hop broadcast, MQTT-S clients could discovery the nearest MQTT-S gateways. Afterthat, connections between them could be established and messages could be transmitted

16

between MQTT-S clients and the Internet server through MQTT-S gateways.Different from our platform, MQTT-S only employed static proxies in their design,

therefore they did not consider problems on supporting mobilility of the proxies.Mires [60] is a publish/subscribe middleware for sensor networks. Different from

MQTT-S, it uses content-based scheme. By incorporating characteristics of message-oriented middleware, Mires allows applications to communicate in a publish/subscribe way.Inside Mires, the middleware itself is composed by modules which have distinct responsi-bilities. At the same time, interfaces are left for furture extention. Focused on pure WSNenvironment, Mires tends to provide a high-level unified API whereby different kinds ofdata-centric applications could be developed.

Hauer et al. [36] designs a framework for content-based publish/subscribe in sensor net-works. Applying the componnent-based architecture, this framework claimed to simplifyapplication developments. For example, developpers are free to specify communicationprotocols, data attributes, and service extension components according to their needs. Inthe end, they also implemented a system called TinyCOPS on TinyOS 2.0 [45] platform.

Although both Mires and [36] applied the content-based publish/subscribe paradigmas our platform did, they only considered their designs in pure WSN environment which isquite different from the hybrid sensor networks in this thesis. Therefore, different from theirwork, our platform needs to tackle problems caused by combining mobile and stationarysensors.

Fiege et al. [29] proposed solutions to support mobility in distributed publish/subscribesystems. In its solutions, two types of mobility, namely physical mobility and logicalmobility, are introduced. Among them, the physical mobility refers to the situation whereclients may temporarily disconnect from the pub/sub system, while logical mobility refersto the situation where clients remains attached to their brokers when they are moving.In order to support logical mobility, the author defined new concepts known as location-dependent subscriptions and location-dependent filters. Then distributed algorithms on howto enable location-dependent filtering were proposed. The main idea of the algorithm is toroute events based their location tags while the routing table on brokers will be adaptivelyupdated by clients’ new locations.

Mauro et al. [20] also focused on the problem of supporting mobility in distributed pub-lish/subscribe systems. But different from [29], this paper use client ID instead of the clientlocation as the routing information. Clients register their IDs at the nearest broker whenthey move in, but unregister when they move out. When received register or unregisteringmessages, brokers will update their routing table accordingly. Afterwards, all the dedicatedevents and subscriptions could be directed to clients through the distributed overlay.

SocialCast [23] is a routing protocol devised to support publish/subscribe in intermi-tently connected human networks. Different from the above two papers, this paper tackles

17

routing problem in a delay-tolerant mobile ad hoc network. As a precondition, it assumesmobile clients with same interest will always locate together in a physical space. This isalso what they called social awareness. At the beginning, the interests or subscriptions ofmobile clients are exchanged when they encounter each other. As a result, the value of avariable called “utility" is computed for each client. Then using “utility" as a metric forthe message dissemination, all the published messages are routed to mobile carriers whohave better “utility" values. Mobile carriers will repeat this process until messages arriveat subscribers.

Although there are mobile entities in the the previous three solutions, they are still dif-ferent from our platform in the type of the mobile entities. Especially, [29] and [20] tackledthe problem of supporting mobile publishers. However, in our platform, not only mobilepublishers (MSensors) need to be supported, but also mobile brokers (mobile proxies) needto be enabled. On the other hand, in SocialCast, both the brokers and the publishers aremobile. Despite they used the mobile broker, their solution was based on a mobile ad hocnetwork which is composed purely by mobile phones. In other words, no stationary sen-sor exists in their system. Therefore, they did not consider the problem on collaborationbetween mobile phones and SSensors which is actually a main problem in our platform.

3.2 Integrate WSNs with InternetWSNs comprise tiny sensor devices which could monitor their physical vicinity. By ex-tending WSN services to Internet, diverse sensing data could be accessed from ubiquitousplaces. As a result, the data of WSNs could be combined with other web services and newapplications is promising to emerge.

SenseWeb [43] is a system aiming at facilitating data access from all the shared sensorsacross the entire Internet. With a tasking module in the coordinator component, this systemcould optimize the sensor selction for each application based on their requirements. At thesame time, sensing data is aggregated and managed using the SenseDB and Transformerutilities. A feature of this system is that shared sensors are not directly connected to thecentrol system. Instead, sense gateway and mobile proxy are employed to provide portinginterface for stationary sensors and mobile sensors respectively. However, sense gatewayand mobile proxy must be installed as static infrastructures in this system.

Including but not specific for Internet, Aberer et al. [11] proposed a middleware calledGlobal Sensor Networks (GSN). The aim of this paper is to provide a high level abstrac-tion which could easy the inter-connection between the underlying, heterogenous sensornetworks. To bridge sensor networks to the global network, it assumes, for each sensornetwork, a sink node is connected to the base computer. Then a concept called virtualsensor is proposed. Actually, the virtual sensor is a profile which specifies properties like

18

sensing ability and data centric operations for a physical sensor. As a result, the devicediversity and complexity are hidden from the system. For better abstraction and manage-ment, a GSN container is further defined. Thus, all the virtual nodes will reside and bemanaged in the respect GSN containers.

Although both SenseWeb and GSN used proxies as intermediary nodes connectingWSNs to the Internet, their proxies are all static, which is quite different from our plat-form. Especially in SenseWeb, although a “mobile proxy" is proposed, it is actually astatic device which is used to connect mobile clients. Since mobility of the proxies willcause new problems while integrating WSNs to the Internet, the solution in our platform istotallly different from theirs.

In [38], they designed and implemented an IPv6-based network architecture for wirelesssensor networks. By applying IP on tiny embedded devices, WSNs could communicatewith Internet directly at smallest overhead of protocol transformation. Besides porting thebasic IPv6 protocol to TinyOS 2.x devices, this paper also proposed additionaly serviceslike multihop routing and forwarding which are tailored for WSNs.

Priyantha et al. [55] tried to solve the scalability problem in WSNs by employing webservices. To enable web services in WSNs, this paper first adapt and optimize TCP/IPto sensor nodes. Then WSDL is employed to expose the web service descriptions. Ontop of TCP/IP, HTTP is used to convey the application layer messages. As a result, thework in this paper make web services at sensor nodes accessible directly from Internet.Further more, new sensor nodes could be added at any time by reporting their services andfunctionalities through XML messages.

In [33], they proposed a platform which enable direct access from Internet to the REST-ful web services in WSNs. Different from the above approach, the RESTful principle isemployed in this paper. In order to integrate WSNs into Internet, they described two so-lutions. One is to install a web server on each sensor node, then they could directly com-municate with Internet using HTTP. But for sensor nodes which do not support TCP/IP, anintermediate gateway is used to relay messages between WSNs and Internet.

The previous three work all proposed full-IP solutions to bridge WSNs to Internet.However, [38] focused on network layer support for IP but not the application platformdesigns as this thesis did. [55] and [33] proposed solutions to enable IP-based web ser-vices in WSNs. However, both of their designs assume the connections between users andservice providers (sensor nodes providing sensing services) are constant. Differently, inour platform, since the intermittent connections will be caused by the mobility of mobileproxies, different approachs need to be proposed to enable communication between usersand service providers.

19

3.3 Participatory SensingIn participatory sensing, mobile handsets are seen as sensor nodes because it usually con-tains on-board sensors such as camera, microphone, light sensor and GPS. By intercon-necting them into a participatory sensor network, applications which are urban-wide oreven globle-wide become possible.

PEIR [50], the Personal Environmental Impact Report, is a participatory sensing ap-plication which employs GPS location data from mobile phones to analyze the personalimpact on environment. In this system, all the mobile handsets are identified using theirIMEI [5]. During the task, handsets will update their location-time information periodi-cally. On the server side, the location-time traces from mobile clients will be processedthrough three stages before they can be fininally used by the application. According to itsdeployment and experiments, PEIR reveals the vast usage of participatory sensing networksin urban and global scale.

Similar to PEIR, GreenGPS [32] is also a participatory sensing application which makeuse of location data. With the GPS-based navigation service, drivers could be dirceted tothe most fuel efficient route. But different from PEIR, GreenGPS utilize a vehicle’s OBD-II system to get data such as fuel consumption, engine RPM, and coolant temperature fromthe vehicle. Then, this data will be used to calibrate the fuel-efficiency prediction modelswhich compute out the most fuel efficient routes.

PRISM [25] is not a specific application but a mobile platform which tends to enabledifferent participatory sensing applications. In this platform, it allows applications to bepackaged as executable binaries. Periodically, participatory mobile phones will report theircurrent location and sensing abilities to the server. According to these metics, applicationbinaries will be pushed to appropriate mobile phones automatically.

Different from PEIR and GreenGPS which are specific applications only supporttinglimited kinds of MSensors, our platform intends to provide generic interfaces throughwhich different kinds of MSensors and SSensors could expose their services to the In-ternet users. On the other hand, although PRISM is also a platform which can be usedby different participatory sensing applications, our platform could support SSensors whichhave not been covered in their work.

3.4 Sparse Sensor NetworkA sparse sensor network refers to a sensor network where sensor nodes need to spreed overa large geographical area. In such a sensor network, how to provide connectivities betweensensor nodes is the essential problem.

Data MULEs [41] is a three-tier architecture for sparse sensor networks. Through mo-

20

bile agents called MULEs, this paper enables intermittent communication between accesspoints and stationary sensor nodes. There are several advantages for this approch. First,because only a few stationary sensors are needed to cover a large area, this approach ismore cost-effective and applicable than others. Second, since the stationary sensor nodecommunicates with the mobile agent directly, the routing process is simplized. Third, be-cause all sensor nodes could use the short range radio for communication, power is largelysaved in this system. Besides the proposed architecture, this paper also build a discretemodel which is used to analyze the performance of such a network.

Different from MULEs, the approach in Jea et al. [42] focused on using data mulesin a controlled manner. In this paper, the motion of data mules (e.g. speed and path)is preconfigured. Then the data on sensor nodes is pulled when data mules pass by. Byclaiming to support multiple data mules, this paper gives solutions on how to cooperatedata collection between concurrent mules.

In Data MULEs, they only consider how to use mobile devices as data carriers in SSNs.Therefore, the mobile devices in their system are only responsible for pulling data from SS-esnors. However, different from Data MULEs, our platform also propose solutions on howto deliver Internet requests from users to remote SSenors. In addition, not only SSensorsbut also MSensors are supported in our platform. Comparing with [42], our platform aremore different because the mobility of the mobile devices in our platform is uncontrolled.

Wang et al. [66] developped a data delivery scheme especially for the delay fault toler-ant mobile sensor network. Because sensor nodes in such a network are mobile, they forma sparse sensor network where sensors are connected occasionally. To enable data trans-mission in this kind of network, this paper proposed an adaptive approach which controldata delivery based on two parameters known as nodal delivery probability and messagefault tolerance respectively.

Different from [66] where all sensors are mobile, our platform is built on a hybirdsensor networks including both mobile sensors and stationary sensors.

21

Chapter 4

System Overview

In this chapter, we first clarify the roles of our platform in a distributed system. Then anoverview of the network architecture of the system is presented and discussion about selec-tion between Full-IP and hybrid approaches is also included. Following that, the reasonsof selection on the publish/subscribe paradigm is explained while a system architecture inpublish/subscribe context is given. At last, software architectures at different modules arepresented.

4.1 System RolesIn this thesis, our platform aims to provide two general services. One is to forward queriesfrom Internet users to capable sensors (e.g both SSensors and MSensors). Another is tocollect sensing data from sensors back to the related consumers. Therefore, there are threeroles in a system utilizing our platform. The first one is the consumer. Consumers are theInternet users or applications who use our platform to query data from underlying sensors.The second one is our platform itself. In the system, it provides services on relaying dataand queries between consumers and underlying sensors. The last one is the sensor serviceprovider. A sensor service provider is an organization or individual who use our platform toexpose their services to consumers. Since there are providers for SSensors and MSensors,we call them stationary sensor service provider (SSSP) and mobile sensor service provider(MSSP) respectively.

Since our platform acts as a middleware between consumers and sensor serviceproviders, the execution module of a sensing task itself should be provided by relatedSSSPs and MSSPs. In other words, whenever a query or subscription is received at asensor node, our platform module on that node will be only responsible for delivering thequery or subscription to the dedicated sensing execution modules. Afterwards, these third-

22

party modules will control the performing of specific sensing tasks based on the receivedqueries. The relationship between different roles is depicted in Figure 4.1.

Figure 4.1: Roles in a system using our platform

In addition, since SSensors are hardware devices deployed by organizations or indi-viduals, we consider that the SSSP is always the owner (deployer) of the related SSensors(e.g a SSSP is the owner of all SSensors running its sensing execution modules). On theother hand, since MSensors are located on participating mobile phones, MSSP is just theprovider of sensing binaries installed on those phones.

Further more, since our platform is envisioned to be used by different sensor serviceproviders, scalability and generality must be principles taken into considerations. Espe-cially, for different SSSPs, as their deployments of SSensors may be diverse from eachother (e.g. locations of deployments, types of SSensors, and distribution of SSensors), thedesign of our platform should not rely on any static information of any specific deployment.On the other hand, from the SSSPs’ point of view, they may also not want to expose thedetail information of their deployments to others. Therefore, in this thesis, our platform isdesigned on the consideration that no detail information of deployments of SSensors shouldbe depended on. Specifically, by detail information of a deployment of SSensors, we meanthe information about the number of SSensors, location of each SSensor, sensing servicetypes on a specific SSensor, and network ids of SSensors in that deployment.

4.2 Network ModelOur platform intends to provide the Internet access both to MSensors and SSensors. SinceSSensors, MSensors, mobile proxy, and consumers are located in different networks, wefirst represent the system architecture in a network perspective.

As depicted in Figure 4.2, a system utilizing our platform may comprise platformserver, mobile proxy, mobile sensor (MSensor), stationary sensor (SSensor), and con-sumers. Platform server is an Internet server which is responsible for relaying messages(e.g. queries and sensing data) between consumers and mobile proxies. Similar as theplatform server but in a lower level, mobile proxies relay messages between the platformserver and the connected sensors. In this thesis, the mobile phone is used as the mobileproxy. Since it has to communicate with components both in the Internet and the sparse

23

Figure 4.2: A Network Perspective of the System

sensor network (SSN), the mobile proxy is located on the border between different net-works. As we can see from Figure 4.2, the mobile proxy connects to platform serverthrough mobile networks (e.g. 3G or Wifi). On the other hand, it connects to SSensorsthrough the short-range radio (e.g. IEEE 802.15.4). Different from SSensors, MSensorsare actually on board the mobile phones, so they do not need additional network connectionto communicate with the mobile proxy. All the consumers connect to the platform serverthrough high level Internet connections (e.g. HTTP in this thesis).

Selection between Full-IP and Hybrid SolutionsAs we mentioned in the previous chapter, some sensor nodes are IPv6 enabled right now.Therefore, if such sensor nodes are used as SSensors, the mobile proxy could communicatewith them directly in IP. In this case, the system utilizing our platform becomes a full-IPsystem. For a full-IP solution, its advantage is that no additional protocol conversion isneeded on the proxy. In addition, any sensor node could be directly reached in the Internet.As a recent approach, the Coap [59] protocol even enables web services at sensor nodesemploying IP. Therefore, if the full-IP solution is suitable for our platform, we could directutilize the Coap protocol to simplize our design work. For example, in Coap, users coulddirectly query a sensor by encapsulating their requests in an IP packet. Then, the requestcould be routed to the sensor through the Internet infrastructures.

However, IP is usually painful when it comes to handle mobility. In the above Coapexample, difficult problems will raise if we want to route the IP packet to a sensor througha mobile proxy. For instance, it is hard for the system to decide which mobile proxy shouldbe selected as the next hop for that packet since the mobile proxy itself may have differentIPs at different locations. Therefore, the advantages of full-IP solution will be overwhelmedby the difficulties on mobility handling.

Instead, we take a hybrid approach where IP and sensor customized protocol (e.g Rime)coexist in the system. Since no IP packet need to be routed to sensors, it is much easier to

24

handle the mobility problem.

4.3 Publish/Subscribe System

4.3.1 Selection of Pub/Sub ParadigmBefore designing the components in the platform, we should first decide which distributedsystem paradigm should be used in this thesis. Since the mobility of mobile phones areuncontrolled in our system, persons who carry the mobile phones could move freely andencounter the SSensors opportunistically. Therefore, the end-to-end communication be-tween the platform server and SSensors are intermittent. Because of this characteristic, thecommunication between different components in this system should be as asynchronous aspossible. As an illustration of the necessity for the asynchronous communications, let usconsider that a consumer wants to query the temperature in an area A. When the platformserver receives this request, there may be no mobile proxy available in that area currently.Therefore, the query has to be stored in the server for unexpected time before temperatureSSensors in area A could receive it. On the other hand, later on, when temperature data isgenerated on SSensors, it has to be first cached on the SSensors before any mobile proxycould occasionally pull it to the related consumers.

As we introduced in the background chapter, publish/subscribe paradigm is full de-coupling in time, space and synchronization between different components in a distributedsystem. Especially, this is formally analyzed in [28]. Therefore, publish/subscribe is cho-son as the system paradigm in this thesis.

On the otherhand, since users may have diverse interests on the content of sensor data(e.g. temperatures above 20 degrees), our platform should have enough expressiveness toreflect their requests. As a result, the content-based publish/subscribe scheme will be usedin this platform.

4.3.2 Publish/Subscribe System ArchitectureAs the first step, we rename the components in Figure 4.2 with the publish/subscribe ter-minologies. Accordingly, the query from consumers will be refered to as subscription inthe rest part of this thesis. Sensing data generated at sensors will be called as events. Inthe publish/subscribe context, consumers in our platform will be refered to as subscribers.Since SSensors and MSensors expose services and events to subscribers, we also call thempublishers sometimes. The platform server in Figure 4.2 relays messages between sub-scribers and mobile proxies, so it is called broker in our pub/sub system. On the otherhand, the mobile proxy also act as a message relay. But in order to differentiate it from the

25

Figure 4.3: A Publish/Subscribe Perspective of the System

platform server, we call it mobile broker (MB) in our system. The relationships betweendifferent components in the pub/sub context are depicted in Figure 4.3. Publishers insidethe dot-border box are MSensors.

In the next chapter, the detail information on how our platform is designed will bedescribed. Before introducing designs of each module, we first give a summary on alloperations used in the platform. This is depicted in Figure 4.4. Since random re-registrationwill be employed by the MBs, the operations between the MB and the broker in this figureare happened during one registration period of a MB.

Figure 4.4: Operations in the publish/subscirbe platform

26

4.4 Software ArchitectureIn our platform, three software modules will reside at different places. The server moduleis installed at broker. The software module of MB resides on the mobile phone. Anothersoftware module is installed on SSensors. In this section, we will introduce the componentsin each modules. At the same time, basic descriptions about their functionalities will beprovided. For some detail information have not been covered here, the next chapter is agood place to refer to.

Software Architecture on BrokerThe software architecture on broker is depicted in Figure 4.5. The subscriber communica-tion handler manages communications between the broker and subscribers in a centralizedway. Through this handler, all the incoming messages are dispatched to related compo-nents. On the other hand, all the outgoing messages are wrapped in a suitable formatbefore sent out. Subscriber profile manager manages the profiles of registered subscribers.In our platform, subscribers need to register at the broker before they can use the underlyingservices. For each registered subscriber, the broker will create a profile to store its identityand latest IP. This information is used to keep the connection between the broker and therelated subscriber. On the other hand, MBs who want to join the system also need to reg-

Figure 4.5: Software Architecture on Broker

ister themselves at the broker. Similar as it is for subscribers, a profile will also be createdfor each registered MB. In Figure 4.5, MB profile manager is the component managing theprofiles of MBs. As you can imply from its name, event manager is the entity controllingall the received events. Whenever an event is received, the broker will try to notify thededicated subscribers immediately. Subscription manager is a component managing the

27

caching and delivery of subscriptions. With the help of its sub-component adaptive sub-scription deliverer, Subscription manager will deliver subscriptions to MBs in an adaptivemanner. Another sub-component in this module is ECF generator. This sub-component isused to generate ECF (event collection flag) informing the MBs how to collect events fromSSensors. Target Area Manager manages target areas where the subscriptions should takeeffects. In this thesis, the destination areas of subscriptions are refered to as target areas.The sub-component Shortest Distance Calculator is used to provide distance metrics foradaptive location updates. Similar as subscriber communication handler, MB communica-tion handler provides an uniform communication interface between the broker and MBs.

Software Architecture on MB

Figure 4.6: Software Architecture on Mobile Broker

The software architecture on MB is depicted in Figure 4.6. Register controller controlshow a MB should register at the broker. Since long-period location tracking on a MB willreveal its identity, register controller will employ a random re-registration mechanism tointerrupt continous tracking. For each MB participating the system, they should updatetheir newest location to the broker periodically. However, since location updates are ansystem overhead, the sub-component adaptive location updater in location manager willreduce the number of unneccessary updates by employing an adaptive algorithm. In a MB,subscription manager is a component controlling caching and delivering of the receivedsubscription copies. In order to install subscriptions on SSensors, the sub-component SSen-sor service discoverer is used to fetch information of available services from SSensors. Forcached subscriptions, status manager in a MB will maintain and update their installationstatuses. Different from event manager in the broker, event manager in the MB needs topull data from SSensors proactively. This is accomplished by its sub-component SSensor

28

event collecter. Since MSensors reside on the same device as the MB, the communica-tions between the MB and MSensors are enabled by a software handler through whichthird-party sensing execution modules could be invoked. Actually, all the third-party ex-ecution modules could attach themselives to our MB module by registering a key-valuepair of (serviceName, handler) where the “serviceName" is the name of the MSensor ser-vices they could provide and “handler" could be an invoking address of the related binarymodule. This is represented by the MSensor Handlers in Figure 4.6.

Software Architecture on SSensor

Figure 4.7: Software Architecture on SSensor

Different from MSensors, SSensors are individual sensor devices which have their owncomputation and communication abilities. Therefore, to integrate SSensors into our plat-form, a seperate software module should be installed on each SSensor. The architectureof this module is depicted in Figure 4.7. On SSensors, the sensing execution modulesprovided SSSPs could be integrated with our platform by registering a key-value pair of(serviceName, handler) at our service manager component. Accordingly, once receiving aservice discovery message from a MB, the service manager component will reply the reg-istered services to the MB. Since time-sensitive subscriptions need to be supported in ourplatform, time manager component will be used to synchronize local time at a MSensorto global time at MBs. This is accomplished by encapsulating the latest global time at aMB in a “TimeSync" message and then sending this message from the MB to SSensors.Therefore, once received a “TimeSync" message, a SSensor will update its local time to theglobal time in the message. Subscription manager manages all subscriptions received fromMBs. It forwards subscriptions to sensing execution modules by refering to (serviceName,handler) pairs in service manager. Due to intermittent connections between the MB andthe SSensor, most of the events generated at a SSensor need to be cached in its local mem-ory at first. Therefore, the main responsibility of event manager is to manage the storagy

29

of events. As depicted in Figure 4.7, this is taken over by sub-component storage manager.

30

Chapter 5

Publish/Subscribe Platform Design

5.1 Publish/Subscribe SemanticsIn a publish/subscribe system, subscriptions and events are the only two kinds of messagestraversing through all the distributed components. Therefore, the communication inter-faces in a pub/sub system are largely decided by the semantics of the subscriptions andthe events. Besides, since subscriptions express the interests of subscribers, their seman-tics will directly affect the design and functionalities of a publish/subscribe system (e.g.supported service types, id or location based routing). In this section, the designs of sub-scription and event semantics are presented. Reasons regarding the selection of relatedapproaches are also explained.

5.1.1 Subscription SemanticsIn our platform, subscriptions are received from subscribers and finally delivered to third-party sensing execution modules provided by SSSPs and MSSPs. In other words, bothsubscribers and sensing service providers are the potential users of our platform, thereforedifferent semantics need to be supplied to both of them. In this section, the designs ofsubscription semantics for different users will be presented and explained.

Subscription Semantics for Subscribers

For subscribers who want to use our platform, the format of subscriptions is depicted inFigure 5.1. Each subscription is presented by a “SbSubscription" message. In this mes-sage, there are three fields “targetArea", “temporalRange" and “Constraints" respectively.Among them, “targetArea" is used to describe the geographical area where this subscrip-tion should be performed. This area is expressed by a geographical circle in the format

31

Figure 5.1: Format of Subscription Message from Subscriber to Broker

of targetArea = {point, radius} where “point" is the geo-coordinate of the center point ofthe area and “radius" is the area’s radius. The format of “point" is point = {latitude, lon-gitude}. Since area-based subscriptions are supported, subscribers who are interested insensing events in a spatial context (e.g. temperatures in an area A) could use our platformseamlessly.

“temporalRange" in “SbSubscription" comprises two subfields: “startTime" and “end-Time" . It is used to specify the valid period of a subscription. For example, by assigningvalues to “startTime" and “endTime" respectively, subscriber could express when the sens-ing task should begin and when it should end. Through the “startTime", we can even askthe sensing task to be performed in the future. For example, a subscriber may want to sub-scribe the humidity starting from the next week. Then this is achieched by simply settingthe value of “startTime" to the beginning time of the next week. By specifying “endTime",we can also avoid sending explicit unsubscribe messages to stop a sensing task. The taskwill be terminated automatically after the “endTime" expires. Combining the “targetArea"and “temporalRange" information, our platform could facilitate all the subscriptions in aspatial-temporal context (e.g. temperatures in an area A from 8:00am to 9:00pm today).

Besides the spatial and temporal range, the most important thing for a subscription is toexpress the subscriber’s interests on the content of the sensing data. For example, such aninterest could be “temperatures above 20 degrees.". In "SbSubscription", the field “Con-straint" is used for this purpose. As we can see from Figure 5.1, one field of “Constraint"is “serviceName" and another is “appConstraint". The “serviceName" specifies the typeof the sensing services. For richer expressiveness, it is expressed in an URI similar for-mat. For instance, “serviceName" in the former example could be “ssensor/temperature".The advantage of this format is that all the services could be organized in a containmentrelationship, so that subscriptions could be further routed in a hierarchical way. For ex-ample, in this platform, all the subscriptions to SSensors begin their “serviceName" fieldswith prefix “ssensor/". One the other hand, the subscriptions to MSensors start their “ser-viceName" fields with “msensor/". Then when arriving at the MB, these subscriptions arefurther dispatched to SSensors and MSensors according to their prefixes in the “service-Name" field. Field “appConstraint" specifies the constraints on sensing data or conditions

32

on how the events should be generated. However, since different sensing services mayallow different constraint expressions, it is impossible for our platform to support all thepotential constraint semantics in a limited format. For example, a sensing service called“Temperature Monitor" may allow subscribers to specify the constraint in a format: (predi-cate, value, sample rate). Then a subscriber who wants to subscribe the temperatures above20 degrees and at the rate of 1 sample/second may write his/her constraint like: (>, 20,1). However, another service called “radio configeration" may only allow the constraintin a format: (power level, MAC protocol name). Then a subscriber who wants to set thepower to -10dBm and use the XMAC protocol may create a constraint like: (-10, XMAC).Therefore, for the scalability, the format of service constraints should be specified by ser-vice providers but not by our platform. For sensor service providers who wants to use ourplatform, they should publish a specification of their service constraint formats (e.g. likein the above examples). Then the subscribers who prefers to use these services could com-pose their constraints following that format and encapsulate them in the “appConstraint"field. In our platform, the “appConstraint" field will be used as a tunnel conveying theseapplication-specific constraints from subscribers to sensing execution modules on sensors.By employing this strategy, our platform could support any third-party sensing services.Especially, as depicted in the above examples, not only data services but also configurationservices could be supported.

Subscription Semantics for MSSPs

Since our platform adds management information to all the received subscriptions, theformat of subscriptions arriving at sensors are a little bit different from that of the originalsubscriptions received from subscribers.

Figure 5.2: Format of Subscription Message to MSSPs

For subscriptions arriving at the MSensors, their format “MnSubscription" is depictedin Figure 5.2. As we can see, there are two additional fields comparing with the previous“SbSubscription". “SbID" is the unique id of the subscriber who sends this subscription.This id will be used to relate events to subscribers. “SpID" is the unique id for each sub-scription in the system. This information could be used by third-party sensing executionsto distinguish between different subscriptions.

33

Figure 5.3: Format of Subscription Message to SSSPs

Subscription Semantics for SSSPs

For subscriptions received at the SSensors, their format “SnSubscription" is depicted at Fig-ure 5.3. Comparing with the above “MnSubscription", “SnSubscription" does not have thefield “targetArea". For MSensors, the “targetArea" information is used to check whetherthe subscription is still valid currently (e.g. whether the MSensor is still inside the targetarea of the subscription). However, since SSensors are static, the “targetArea" informationbecome useless once the subscriptions have arrived at those sensors. Therefore, in order toreduce packet size (which is important for sensor communication), the “targetArea" field isremoved from subscriptions received at SSensors.

5.1.2 Event Semantics

Figure 5.4: Format of Event Message

The format of events in our platform is depicted in Figure 5.4. Generated by per-forming the related subscriptions, “SbID" is the id of the subscriber who subscribes tothis event. The “appContent" field encapsulates the content of an event. However, sincewe assume that our platform should be used by third-party sensor service providers, theformat of the event contents should be specified by these service providers. Similar asthe “appConstraint" field in subscriptions, “appContent" only provides a tunnel convey-ing the application-specific events from sensors to subscribers. Therefore, when pulishingtheir services, sensor service providers should also publish specifications on the formatsof event contents. Then subscribers could parse the “appContent" field according to thosespecifications.

5.2 Registration

Subscriber Registration and AssociationBefore starting to use the platform, each subscriber needs to register itself at the broker.This is performed by sending an “SbRegister" message to the broker. Once received thismessage, the broker will allocate an unified id “SbID" for the subscriber. At the same time,

34

Figure 5.5: Subscriber Registration and Association

a blank profile will be created for the subscriber. Afterwards, once received the “SbID"from the broker, the subscriber will associate itself to the broker by sending an “Associate"message Associate[SbID, IP]. At the broker, values of “SbID" and IP will be stored in theprofile of the related subscriber. During the communication, the broker will use the IP inthe profile to maintain the Internet connection to the subscriber. This is important becausethe received events should be pushed to the subscribers as soon as possible. However, ifthe subscriber is temporarily disconnected when events received at the broker, all theseevents will be cached in its profile at first. Later on, subscribers could reconnect to thebroker by sending “Associate" message containing their latest IP. This process is depictedin Figure 5.5.

Random Re-registration for Mobile Broker

Figure 5.6: Random Re-registration for Mobile Broker

35

Similar as the subscribers, the MBs also need to register at the broker. Through theregistration process, they could inform the broker that they are willing to join this publish/-subscribe system. At the beginning of this process, an “MbRegister" message will be sentfrom a MB to the broker. Once received this message, the broker will assign and returna temporary id (TID) to that MB. At the same time, a profile “mProfile" will be createdin the local memory of the broker for each registered MB. As it will be explained in thefollowing sections, several status information of the registered MBs will be stored in thetheir “mProfile"s.

However, since the MB module resides in the mobile phones owned by individual users,the protection of user privacy should also be taken into considerations. In our platform,in order to deliver subscriptions to their desired target areas, the broker needs locationinformation from MBs. Therefore, MBs participating the system will update their locationsto the broker periodically. As pointed by [37], long-time location tracking of the MB mayreveal the identity of the mobile phone user. Therefore, a random re-registration policy isemployed to interrupt the long-time tracking. For the registration of a MB, a registrationperiod is maintained, e.g. half an hour in current design. Whenever a registration periodis expired, the MB’s “mProfile" in the broker will be removed and the “TID" of the MBwill be recycled. On the other hand, the MB will wait for a random amount of time beforeregistering again. The whole process of registration is depicted in Figure 5.6.

5.3 Adaptive Location UpdatesSince the broker delivers subscriptions to suitable MBs based on the their locations, theMBs in the system need to update their latest locations to the broker periodically. In ourplatform, the constant time interval of location updates is configured by the parameterΔCupdate in the MB module. In this thesis, the value of ΔCupdate is set to 30 seconds whichmeans that defaultly a MB will update its latest location to the broker every 30 seconds.The location update message “LUpdate" has the format of LUpdate[TID, Location] where“TID" is the temporary id of the MB and “Location" has its format as Location[latitude,longitude]. In our platform, all the locations are sampled by the GPS on board the mobilephones. However, since GPS is energy-consuming, the location update will cause overheadon energy consumptions. On the other hand, location update messages sent to the brokerwill also cause the communication overhead. Therefore, we should try to reduce the systemoverhead by eliminating unnecessary location updates.

In this thesis, our improvement was inspired by analyzing the relationship betweenthe locations of the MBs and the target areas of the subscriptions. As we can observe inFigure 5.7, a MB may be outside of any target area during some periods of its movement.Since a subscription is delivered to a MB only when this MB is currently in the related

36

Figure 5.7: Situation when MB is outside of any target area

target area, no subscription will be routed to the MB in Figure 5.7 although it updateslocations continuously. Therefore, most of the location updates in this situation are wastedand unnecessary. This kind of waste will last even longer if the MB moves from a very far(e.g. tens of kilometers) place outside of any target area. Therefore, we saw the necessityto reduce these unnecessary location updates.

If we obtain the distance ΔL between a MB and the closest target area (e.g. the ΔLbetween the MB and target area 1 in Figure 5.7), then an estimation ΔTupdate for the nextlocation update at the MB could be computed by ΔTupdate = ΔL ÷ Smax, where Smax isthe estimated value of the MB’s maximum speed. With such an estimation, it is easyto conclude that the MB will take at least ΔTupdate time before it could enter any targetarea. In other words, the MB could suspend its location updates for at least ΔTupdate time.Therefore, if the value of ΔTupdate is bigger than that of ΔCupdate, the time interval for thenext location update could actually be set to ΔTupdate to avoid unnecessary location updateswhen using the ΔCupdate. For example, if the computed value of a ΔTupdate is 300 seconds,9 (9 = ΔTupdate÷ΔCupdate - 1) unneccessary location updates could be eliminated by settingtime interval to ΔTupdate instead of ΔCupdate. Intuitively, more unnecessary location updatescould be saved if the MB moves from farther places to any target area.

ΔTupdate = max(ΔCupdate,ΔL

Smax) (5.1)

37

For clarity, ΔTupdate used in our platform is redefined in Eq. 5.1. For the adaptive algorithmrunning in the MB module, ΔTupdate specifies the time interval of location updates. Foreach MB, the value of ΔTupdate is initialized to ΔCupdate. Afterwards, whenever receiveda location update, the broker will compute and return the latest ΔL value to the MB. Asalready mentioned, ΔL is the distance between the MB and a target area which is closestto the MB currently. In the broker, the target area information could be obtained from allthe received subscriptions. The communication between the broker and the MB is depictedFigure 5.8.

Figure 5.8: Communication between MB and Broker on adaptive location update

However, there is still one problem need to be considered in order to make the adaptivealgorithm as a complete solution. As you may noticed, we have not specified the way tocompute the value of Smax for each MB. Actually, a range-based mechanism is employedin our platform. The design of this mechanism is inspired by observing that the activities ofthe users who carry the MBs could be classified into several categories according to theirspeeds. For example, for ordinary users who are walking or running, their speeds will bemost likely located in the range [0 m/s, 8 m/s] [51]. For ordinary users who are biking,their speed will less likely exceed 15 m/s [12]. On the other hand, since the MB needs tocommunicate with SSensors in the short-range radio, we further envision that users whomove very fast, e.g. drivers who are driving very fast, are not suitable to carry a MB.Therefore, the speeds of MBs in our system could be classified into two ranges. The range[0 m/s, 8 m/s] is called the low-speed range, and the range (8 m/s, 15 m/s] is called the high-speed range. Whenever the ΔTupdate needs to be computed, the current speed of the MBwill be checked against different ranges. If the current speed is located in the low-speedrange, the Smax will be 8 m/s. Otherwise, the maximum value in the high-speed range willbe assigned to the Smax.

38

5.4 Best-effort Policies on Subscription Caching and De-livery

In order to deliver subscriptions from subscribers to dedicated sensors, our platform needsto solve two problems. The first, since MBs are employed to relay messages between thebroker and underlying sensors, the communications between different components in ourplatform are opportunistic. Therefore, our platform should be able to deliver subscriptionsin such intermittent connections.

The second, since subscriptions in our platform subscribe services from target areas butnot from specific sensor nodes, the implicit meaning of these subscriptions is subscribingservices from all the available sensors in desired target areas. To fully satisfy these requestsof subscribers, our platform should try its best effort to install received subscriptions on allthe dedicated sensors. To better illustrate this problem, we first give a concept called fullinstallation of a subscription. In this thesis, a subscription is said fully installed when it hasbeen installed on all the sensors of interest. For example, for a subscription to the targetarea in Figure 5.9, if all the SSensors in the area provide common services desired by thissubscription, it is said fully installed when the subscription has been installed on node A,B and C. However, since the SSenors are sparsely deployed over a target area, the MB maynot have the luck to encounter all the available SSensors during one trip in the target area.In the worst case, it is even possible that the MB encounters none of the SSensors. Asdepicted in Figure 5.9, the MB in the figure only encounters SSensor A during its currenttrip in a subscription’s target area. Therefore, special approaches should be proposed tomaximize the possibility of full installation for subscriptions in our platform.

Figure 5.9: MB traverses through a subscription’s target area

In order to solve the aforementioned two problems, two levels of best-effort policiesare used on the broker and MB respectively. In the following part of this section, we will

39

desicribe how these approaches are designed.

5.4.1 Subscription Caching and Delivery at BrokerAs depicted in Figure 5.10, the subscriber could subscribe services from our platform bysending an “SbSUB" message SbSUB[SbSubscriptions, SbID] to the broker. The field“SbSubscriptions" contains a list of subscriptions where at least one subscription shouldbe included. As we mentioned in the previous section about the subscription formats, eachsubscription from the subscribers has the format “SbSubscription".

Once received an “SbSUB" message, the broker will first store the subscriptions intoits local memory. In order to distinguish between different subscriptions, an unique id“SpID" will be assigned to each received subscription. Later on, whenever a location up-date message recevied from a MB, the broker will deliver subscriptions based on theirtarget areas. Only subscriptions whose target area covering the MB’s current locationwill be disseminated. Actually, this is an one hop location-based routing process. Thebroker sends subscriptions to the MB using a message “BrSUB" with the format of Br-SUB[MbSubscriptions]. Each subscription contained in “MbSubscriptions" has the sameformat as “MnSubscription". This process is depicted in Figure 5.10.

Figure 5.10: Subscriptions Delivery from Subscriber to Mobile Broker

40

However, in order to maximize the possibility of full installation for subscriptions, thebroker will cache all the received subscriptions in its local memory until these subscrip-tions are expired (“endTime" reached). Therefore, in the previous described subscriptiondelivery process, whenever a location update message is received from a MB, the brokeractually sends one copy of each qualified subscription to that MB. This is called best-effortapproach since the broker will try its best effort to send copies of a subscription to everyMB entering the subscription’s target area. As depicted in Figure 5.10, whenever a “LUp-date" message is received, the broker will encapsulate copies of qualified subscriptions andsend them to the MB.

For the subscriptions to MSensors, the best-effort policy is necessary because the num-ber of MSensors in a target area is actually dynamic and unlimited. As you can imagine,since MSensors are on board the mobile phones participating the system, they could entera target area at any time. Therefore, the best-effort approach should be employed to installthose subscriptions on as many as possible MSensors of interest. As a result, possibility of“full installation" for subscriptions to MSensors is maximized.

On the other hand, for the subscriptions to SSensors, as shown in Figure 5.9, it isnearly impossible to fully install a subscription overnight or during one trip of only oneMB. Therefore, by employing the best-effort policy on the broker, every MB entering asubscription’s target area could contributes to relay that subscription to SSensors in thetarget area. Intuitively, since a subscription is more likely to be fully installed if thereare more MBs helping to relay it, the possibility of full installation for subscriptions toSSensors could also be maximized by the best-effort approach.

However, for the subscriptions to SSensors, instead of storing them until their expira-tion, a better solution may be removing a subscription from the broker as soon as it hasbeen fully installed. The consideration behind is that a subscription in the broker no longerneeds to be delivered once it has been installed on all the available SSensors. Although thisis a reasonable approach, it is actually impossible for the broker in our platform to certainlyjudge whether a subscription has been fully installed because the broker has no knowledgeof the detail deployment information of the SSensors (e.g. ids and service types of eachSSensor) in a target area. The consideration on the anonymity of underlying SSensors hasbeen discussed in the previous chapter. Although it is impossible for the broker to certainlyjudge the full installation of a subscription to SSensors, an adaptive algorithm is proposedin this thesis to enable the judgement heuristicly. The design of this algorithm will bepresented in later sections.

In addition, for the better management in the best-effort approach, the broker maintainsa property “SpStatus" for each cached subscription. This property specifies the currentstatus of a subscription. “WaitForDelivery", “Delivered", and “Expired" are three possiblevalues for this property. For each subscription just received from the subscriber, the “Sp-

41

Status" will be initialized to “WaitForDelivery". This status indicates the subscription hasnot been installed on any sensor yet. Since then, if the subscription has once been success-fully installed on any sensor of interest, the “SpStatus" will be updated to “Delivered". Aswe will introduce in later section, statuses “WaitForDelivery" and “Delivered" will be usedto compute a flag for the data collection from SSensors. At last, whenever a subscriptionreaches its “endTime", the “SpStatus" will be changed to “Expired". Once the “SpStatus"of a subscription becomes “Expired", the broker will not deliver copies of that subscriptionto MBs again. Afterwards, the recycling module in the broker will periodically delete allthe subscriptions whose “SpStatus" are “Expired". The recycling of expired subscriptionsis also depicted in Figure 5.10.

5.4.2 Subscription Caching and Delivery at MB

Figure 5.11: Subscriptions forwarding from MB to sensors

When the subscriptions are received from the broker, a MB will also first cache themin its local memory. Afterwards, the MB will check whether a subscription should be

42

sent to a MSensor or a SSensor. This is decided by checking the “serviceName" field in asubscription. If the string of “serviceName" begins with “ssensor/", this subscription shouldbe sent to SSensors. Otherwise, if the string begins with “msensor/", the subscription willbe sent to MSensors.

For subscriptions to MSensors, since the MSensors are on borad the mobile phone andthey are directly connected to our MB module through the handlers of third-party sens-ing modules, the delivery and installation process is very simple. For a subscription to aMSensor, the MB will first compare the subscription’s “serviceName" field with (service-Name, handler) pairs registered at the MB module currently. If there is a matching entry(e.g. “serviceName" strings are the same), the subscription will be sent to and installedon a third-party sensing module through the handler in the related (serviceName, handler)pair. This process is depicted in Figure 5.11 as the communication between the MB andthe MSensor.

On the other hand, for subscriptions to SSensors, since a MB can only encounter SSen-sors opportunistically in a target area, indirect delivery approach will be used. In order to setup connections with SSensors, a MB has to broadcast “Discovery" messages periodicallywhile it traverses in a target area. This is depicted in Figure 5.12. Once a SSensor receives

Figure 5.12: Broadcast discovery message while a MB traversing in a target area

the “Discovery" message, a message “Services" encapsulating available services on thatSSensor will be replied to the MB. For instance, for a SSensor supporting both temperatureand humidity monitoring services, the content of a “Services" message could be a stringlike “ssensor/temperature;ssensor/humidity". In our platform, different services in a “Ser-vices" message are seperated by semicolons. Once received “Services" message, the MBwill check if the SSensor provides any service desired by the cached subscriptions. Thisis performed by checking whether the received “Services" message contains any substringequals to the content of the subscription’s “serviceName" field. If the SSensor provides the

43

required service, the MB will deliver copies of the filtered subscriptions to that SSensorwith a message “MbSub". The format of a “MbSub" message is MbSUB[SnSubscriptions]where each subscription in this message has the format of “SnSubscription". This com-munication process is depicted in Figure 5.11 as the communication between the MB andthe SSensor. In this thesis, we call this process the discovery-based subscription deliveryprocess.

However, in order to maximize the possibility of full installation for subscriptions toSSensors, a MB will also cache the received subscriptions in its local memory as long asit is still in those subscriptions’ target areas. Therefore, during the previous discovery-based delivery process, whenever a “Services" message is received from a SSensor, theMB actually sends replications of the filtered subscriptions to that SSensor. Then, as a MBproceeds in a target area, replications of related subscriptions will be installed on all theencountered SSensors. Since the MB tries its best effort to send one copy of each cachedsubscription to every encountered SSensor in the subscription’s target area, we call theaforementioned approach the best-effort policy on the MB. In Figure 5.11, the discovery-based delivery process is surrounded by a dot-border box to indicate that it will be repeatedfor every encountered SSensor.

Installation status management

Since the broker needs to know whether a subscription has ever been successfully installedon at least one SSensor in its target area, a property “FinalInstallStatus" will be attachedto each subscription cached in a MB. The “FinalInstallStatus" will record the installationstatus of each subscription during the hosting MB’s trip in the subscription’s target area.“Installed", “Duplicated" and “None" are three possible values of this property. “Installed"indicates the subscription is successfully installed on a sensor of interest for the first time.“Duplicated" means a previous copy of the subscription has already been installed on asensor. “None" manifests no desired sensor is available right now. For each subscription,the “FinalInstallStatus" will be initialized to “None".

Therefore, for the subscriptions to MSensors, if a subscription is installed on the third-party module for the first time, an “Installed" status will be returned to the MB throughan “InstallStatus" message. As a result, the MB will change “FinalInstallStatus" of thesubscription to “Installed". Otherwise, if an “Duplicated" message is returned, the MB willchange “FinalInstallStatus" of the subscription to “Duplicated". This reply of installationstatus is also depicted in Figure 5.11 as a part of the communication between the MB andthe MSensor.

On the other hand, for the subscriptions to SSensors, a SSensor will also return “In-stalled" or “Duplicated" message to the MB based on the installation status of the subscrip-tion. However, since replications of a subscription may be sent to multiple SSensors, more

44

than one installation status messages could be received for the same subscription while theMB is traversing through a target area. Therefore, the update policy for the “FinalInstall-Status" of subscriptions to SSensors is different from those to MSensors. For subscriptionsto SSensors, if current value of the “FinalInstallStatus" of a subscription is “Installed", thisvalue will not be changed again no matter what status message is received to this subscrip-tion later. Otherwise, the value of the “FinalInstallStatus" will be updated according to thereceived status message. Actually, this implies that, when the MB traverses in a subscrip-tion’s target area, “FinalInstallStataus" of the subscription will be set to “Installed" as longas it has been installed on at least one SSensor for the first time. The reply of installationstatus from SSensors is depicted in Figure 5.11 as a part of the discovery-based deliveryprocess.

Expiration Management

As we mentioned in the best-effort approach, a MB will cache the received subscriptionsas long as it is still in the subscriptions’ target areas. Actually, this information is notenough if we want to correctly decide whether a subscription should be still cached in a MB.To manage the caching period of subscriptions on a MB, we first redefine the expirationconditions for them. For the subscriptions cached in the MB, they will expire if any one ofthe aftermentioned conditions matchs. First, if the current location of the hosting MB is outof a subscription’s target area, the subscription is claimed expired. Second, a subscriptionwill expire when its “endTime" is reached in the MB. Third, all the cached subscriptionswill be made expired when the current registration period of the MB has finished. For thethird condition, since the random re-registration policy is employed, a MB needs to clean itsstates before it could register at the broker again. Therefore, previous cached subscriptionsneed to be made expired and cleaned.

For the subscriptions installed on MSensors, the MB needs inform the third-party mod-ules to stop the sensing tasks when the installed subscriptions have expired. For example,if the MB is currently out of a subscription’s target area, the sensing task activated by thissubscription should be stopped. In the MB module, the expiration notification to the third-party modules is sent by a message “UnSub" with the format of UnSub[MnSubscriptions].The currently expired subscriptions are encapsulated in this message and informed to thethird-party modules. Therefore, when installing a subscription on a MSensor, a copy of thesubscription is actually passed to the related third-party module. The original subscriptionis still cached in the MB for the expiration monitoring.

In the MB, whenever a cached subscription is expired, a message “SpExpiration" willbe sent to the broker. The format of this message is SpExpiration[SpID, FinalInstallStatus]where “SpID" is the unque id of the subscription and “FinalInstallStatus" is the value of the“FinalInstallStatus" property of this subscription. This is depicted in Figure 5.11 as a part

45

of the communication between the broker and the MB. Whenever received a “SpExpira-tion" message, the broker will update the “SpStatus" of the related subscription accordingto the value of “FinalInstallStatus". If current value of “SpStatus" is “WaitForDelivery" fora subscription, it will be updated to “Delivered" when the received value of “FinalInstall-Status" is “Installed". Therefore, for any subscription whose “SpStatus" is “Delivered",the broker could judge that this subscription has been successfully installed on at least oneSSensor in its target area.

Duplication Avoidance

However, since subscriptions will be cached in the MB, it is possible for the MB to receiveduplicate copies of cached subscriptions from the broker. For example, for a subscriptionA which has already been received and cached in the MB, the broker will deliver anothercopy of A when receving next location update from the MB as long as the MB is still insideA’s target area. To avoid the delivery of duplicated copies of a subscription from the brokerto a MB, the broker in our platform will store the “SpID" in the MB’s “mProfile" for eachsubscription delivered to the MB. Therefore, before delivering a subscription to a MB, thebroker will check if this subscription has already been cached in the MB by examining the“SpID" list stored in the MB’s “mProfile". If “SpID" of the subscription is found there,this subscription will not be delivered this time. Then, whenever a “SpExpiration" messageis received from the MB, the broker will remove the related “SpID" from the “mProfile".Intuitively, this indicates this subscription is no longer cached in the MB.

5.5 Adaptive Algorithm on Subscription Delivery at Bro-ker

5.5.1 Problem DescriptionIn order to relay subscriptions to SSensors by the MBs, the broker will keep deliveringcopies of subscriptions to MBs based on their location updates. However, if a subscriptionhas already been fully installed, no copy of the subscription needs to be delivered to theMBs any longer. Therefore, subscription copies delivered in such a situation is meaninglessand totally wasted. In our platform, since the broker can not decide whether a subscrip-tion has been fully installed for sure, how to avoid or reduce deliveries of full-installedsubscriptions becomes a problem.

46

5.5.2 SolutionAs we mentioned previously, for each copy of a subscription delivered to MBs, its finalinstallation status will be reported to the broker within a “SpExpiration" message. Sincea final installation status “Duplicated" indicates the subscription is “Duplicated" on all theencountered SSensors of interest while the hosting MB traverses through the target area,high receiving rate of this status at the broker will imply the high possibility of the fullinstallation of a subscription. Further more, this possibility is even higher for a subscriptionif the “Duplicated" statuses are received at the broker in a continuous manner for a longperiod.

Algorithm 1 Adaptive Algorithm on Subscription Deliverywhile Final installation status M is received do

if M is “Installed” thenNd = 0Frq = 1

elseif M is “Duplicated” then

Nd = Nd +1Frq = 1

Ndend if

end ifend while

In the broker, we create a variable “Nd" for each subscription. “Nd" is the numberof “Duplicated" statuses continuously received for a subscription. Therefore, if “Nd" fora subscription is bigger, the subscription is more likely to be fully installed. Based onthis statistic number, an adaptive algorithm trying to reduce the meaningless deliveriesof full-installed subscriptions is depicted in Algorithm 1. Frq is the delivery frequency(probability) for a subscription at the broker. Whenever a location update is recevied froma MB, the broker then delivers each qualified subscription with their related probabilitiesFrq. The intuition behind this algorithm is that a subscription should be delivered lessfrequently (in lower probability) if it is more likely to be fully installed.

However, if an “Installed" status received again after a serial of “Duplicated" statusesfor a subscription, it indicates this subscription is successfully installed on at least oneSSensor which the MBs have not encountered before. Actually, a MB could discover “new"SSensors in two conditions. For the first, a MB may encounter “new" SSensors becauseit traverses along a path which has not been visited by the previous MBs. In this case,the “new" SSensors are initially existed in the target area. For the second, a MB may

47

encounter new SSensors because SSSP dynamically deploys additional SSensors at theprevious visited pathes. However, no matter which reason causes the discovery of “new"SSensors, the reception of a “Installed" status implies the subscription is not fully installedright now. Therefore, this will cause the Frq to be recovered to 1 immediately in ouralgorithm. At the same time, Nd will be reset to 0 since the continuous receptions of“Duplicated" statuses is interrupted.

For each new subscription received from subscribers, the broker will initialized the Frqto 1 and Nd to 0.

5.6 Event CollectionOnce subscriptions are successfully installed on sensors, sensing events will be generatedaccordingly. Since SSensors and MSensors have different connections with MBs, the eventcollection mechanisms will be different for them. Therefore, event collection mechansimsfor SSensors and MSensors will be explained seperately in this section.

5.6.1 Event Collection from MSensorsData collection from MSensors employs a push-based approach. Whenever an event gener-ated at a MSensor, it will be pushed to the connected MB module in a message “MnEvents".The MB then encapsulates the received events in a message “Events" and sends this mes-sage to the broker immediately. Once received events from a MB, the broker will furtherpush events to subscribers according to their “SbID"s.

5.6.2 Event Collection from SSensorsHowever, different from the MSensors, event collection from SSensors employs a pull-based approach. Since connections between a MB and a SSensor are established oppor-tunistically, the events generated on a SSensor have to be cached in the SSensor’s localmemory before pulled by a MB. Therefore, in order to collect events from SSensors, a MBneeds to proactively keep broadcasting polling messages “eventCollection" to SSensors.Once received an “eventCollection" message, our platform module on the SSensor will de-liver all the cached events to the MB in a message “SnEvents". When received events fromSSensors, the MB will upload them to the broker in the same way as that for the eventsfrom MSensors. The process of event collection from SSensors is depicted in Figure 5.13.

Given that “eventCollection" messages are an overhead caused by the intermittend con-nections between MBs and SSensors, we should avoid sending them when there is no sucha necessity, especially if there is no event needs to be collected in a target area. Therefore,

48

Figure 5.13: Event Collection from the SSensor

an event collection flag (ECF) is used in our platform to inform the MBs whether they needto perform pull-based event collection in a target area. Whenever received a location updatefrom a MB, the broker will check the “SpStatus" of subscriptions. As we mentioned previ-ously, value “Delivered" of the “SpStatus" indicates the subscription has been installed inits target area, so there are events need to be collected. On contrary, value “WaitForDeliv-ery" implies a subscription has never been sucessfully installed before, therefore no eventneeds to be gathered in the subscription’s target area. Accordingly, if the “SpStatus" valueis “Delivered" for at least one of the subscriptions belonging to the same target area, a ECFwith value “Yes" will be sent to the MB currently in the target area. Otherwise, a ECFwith value “No" will be sent to the MB. When a ECF with value “Yes" is received fromthe broker, a MB will keep broadcasting “eventCollection" messages periodically. On theother hand, a MB will stop broadcasting “eventCollection" messages if the value of ECF is“No".

Further more, since a newly generated ECF value may be the same as that generated lasttime for a MB , the broker should only send ECF to the MB if a different value is generatedcurrently. Therefore, in our platform, the broker will cache the latest ECF value in a MB’s“mProfile" before sending it to the MB. Later on, when a location update is received froma MB and a new ECF value is generated, the broker will first compare the new value withthe cached ECF value in the MB’s “mProfile". If these two values are different, the brokerwill update the cached value with the new ECF value and then send the latest ECF valueto the related MB. Through this process, the broker could avoid sending a lot of duplicatedECF values to MBs.

49

Chapter 6

Implementation

In order to verify the design is applicable, we implement our platform on real devices. Inour implementation, RESTful princinples are followed to provide publish/subscribe inter-faces. For the mobile phones, they are enabled to communicate with SSensors by a sensornode attached through USB cable. Since communication between SSensors and MBs arebased on low-rate and low-power radio, adaptations on message encoding have been em-ployed. Further more, Intent messaging mechanism of Android system is used to facilitatediverse third-party sensing modules on the MBs.

6.1 BrokerOur broker is implemented on a Ubuntu 10.10 PC and the software modules of the brokerreside in an Apache Tomcat 7.0 server. All the programs in the broker is written in Javalanguage. Since the REST principles are applied in our design, the broker communicateswith other modules in our platform using HTTP messages. In addition, Apache CXF libraryis used to facilitate RESTful HTTP interfaces.

For the users or applications who want to use our platform, there are two main inter-faces exposed by the broker. One is the “SbSub" with which the users could send theirsubscriptions to the broker. Another is “Events" through which the broker could push thereceived events to the designated users. Actually, interface “SbSub" is exposed by a HTTPURI. An user could subscribe services from our platform by a HTTP POST message:

���� ������ �����

���� �����������

������������� ����������������

������� ���� �������

50

The payload of this message should include the subscriptions and user id in a JSON format.An sample JSON payload in such a request is depicted in Appendix A.1. On the other hand,“Events" will be encapsulated in a HTTP response message to the users. A sample JSONmessage of “Events" is shown in Appendix A.2. Since "appContraint" and "appContent"are application specific fields, our platform will not parse them and only treat them asstrings of characters.

In order to manage subscriptions and events, MySQL Database is also employed in ourimplementation as the storagy manager.

6.2 Mobile BrokerAndroid 1.5 is used as the OS platform for our MB implementation. Same as the broker,all programs in the MB module is written in Java language. In our implementation, HTCHero smart phones are employed as the testing devices. These phones include camera,microphone, accelerometer and GPS sensors. Besides, they also support Wifi, Bluetooth,GPRS/EDGE/3G radios. For simplicity, only 3G connection is used in our current imple-mentation. The MB module communicates with the broker using HTTP. All the messages(e.g. LUpdate, MRegister, BrSUB) between the MB and the broker are wrapped in JSONformats. In the experiment, a hiking trail application is built on our platform. The userinterfaces of this application on the mobile phone are depicted in Figure 6.1. In this appli-cation, our MB module ran as a background service. Users of this application could gathertheir speed information while hiking. At the same time, information on detected SSensorsand collected events from those SSensors was shown to the users. Detail information aboutthe experiment could be found in next chapter.

6.2.1 Supporting Diverse MSensorsAs we mentioned in the design part, any sensor service provider should be able to useour platform to expose their services. In other words, our platform should not be affectedwhen new sensing modules are added. For the mobile sensor service provider (MSSP), thisis achieved through the Intent messaging mechanism in Android. For any application orbackground service module in Android system, they could communicate with other appli-cations or modules by sending Intent messages. The Intent message is routed by Androidsystem accroding to its action name. Therefore, only an application which registers thesame action name in its XML manifest could receive the related Intent messages. In ourimplementation, the MB module registers its action name as:

�������������

����� � ��� ���������������� ������������� �

51

(a) (b)

Figure 6.1: Hiking Trail Application UI

��������������

Therefore, for sensing execution modules provided by MSSPs, they could send information(e.g. generated events) to our MB module using an Intent message with an action name“uu.it.tong.mb.INCOME". On the other hand, since sensing execution modules need toreceive subscriptions from our MB module, they should register their action names too.However, in order to integrate with our platform, their action names should follow thenaming schema in our platform. All the third-party sensing modules should compose theiraction names by concatenating a prefix “uu.it.tong.mb.OUTPUT.msensor" and their servicenames. For example, for a sensing execution module providing speed service, an actionname could be registered as:

�������������

�� ���� ����������������������������������������������� ��

��������������

Therefore, whenever receiving a subscription whose “serviceName" field is “msen-sor/speed", the MB module will deliver this subscription to the speed service module by anIntent message with an action name “uu.it.tong.mb.OUTPUT.msensor.speed".

With the help of Intent messaging mechanism, both our MB module and third-partysensing modules could be installed as stand-alone binaries in Android. Therefore, theyare completely separate from each other. Further more, since only their own action namesneed to be registered in Android system, new sensing modules could be added on Androidphones without affecting anything in our platform.

52

6.3 SSensor Related Implementations

6.3.1 Communication with SSensorsFor the MBs in our platform, they need to communicate with SSensors. Since most of thesensor nodes using IEEE 802.15.4 radio for their wireless communication, smart phones bydefault could not talk with these sensors. Therefore, in our implementation, a workaroundsolution is used as depicted in Figure 6.2.

Figure 6.2: Attaching Tmote Sky to HTC Hero

In this solution, one sensor node equiped with IEEE 802.15.4 radio is attached to themobile phone by an USB cable. Since USB cable needs 5V power supply to enable the datatransmission, a lithium battery is also connected as an external power source. Employingthis solution, the MB in our platform could communicate with SSensors indirectly throughthe attached sensor node.

In our implementation, all the senor nodes are Tmote Sky powered by Contiki operatingsystem. Since Contiki is a C based OS platform, all the programs running on sensor nodesare written in C language.

For the communication between MBs and SSensors, one big problem is the limitedbandwidth. Since IEEE 802.15.4 is a low-rate and low-power radio standard, its theoriticalmaximum bandwidth is only 250kbps and its largest packet size is only 127 bytes [10].On the other hand, since JSON encoding all the messages in text format (e.g. ASCII orUTF-8), if we encapsulate JSON message (e.g. received subscriptions) directly in a packetto a SSensor, the packet size may be too large or even unacceptable. For example, only an“endTime" field with value “1399002489" in an ASCII encoded subscription will take 10bytes (e.g. one byte for each character), not to mention that a subscription message as thatin Appendix A.1 could easily exceed 127 bytes. Therefore, in order to transmit messages

53

from MBs to SSensors, a message compression module is proposed on the attached sensornode.

The principle of our compression is to change the text encoding of the messages tobinary encoding. For example, the character string of “1399002489" will be re-encoded asa 4 bytes integer. Therefore, only for the previous “endTime" field “1399002489", 6 bytescould be saved. Formats of the compressed messages could be found in Appendix B.

For the network layer communication between attached sensor node and the SSensors,Rime stack in Contiki system is used. In current implementation, “Discovery" and “event-Collection" messages are transmitted using broadcast primitive in Rime. “Services", “Mb-SUB", and “InstallStatus" are implemented with unicast primitive. For the “SnEvents",since events may be cached on SSensors for quite a long time, the cached events may betrasmitted in a burst when a MB is encountered. Therefore, as the wireless channel willbe heavily interfered by too frequent transmission of packets, it is very possible that thepackets of events would be lost during the transmission. As a result, we employ a serial-izing mechanism in the event deliveries. During the event transmission from SSensors tothe MBs, a next event packet will only be trasmitted when the previous event packet hasbeen acknowledged. On the other hand, if a SSensor is transmitting event packets to a MB,it will not reply event collection requests from other MBs. By employing this serializingapproach, our platform could receive 100% of the generated events, which is testified inour experiment.

6.3.2 Event caching on SSensorsSince MBs could only encounter SSensors opportunistically, events generated on SSensorsneed to be cached in their local memories at first. In our implementation, the event cachingis realized based on the Coffee file system of Contiki. Currently, in our platform module onSSensors, a 2 megabytes file is allocated as the cache for events. Since the caching spaceon a SSensor is very limited, our module will recycle the space once events have beentransmitted to MBs. As a result, the recycled space could be re-used for the new generatedevents in the future.

54

Chapter 7

Experiments

In the experiments, we prototyped a hiking trail application on our publish/subscribe plat-form. According to them, we would like to demonstrate that our platform is useful inreal applications. More important, the performance of the platform will be evaluated andanalyzed.

7.1 Hiking Trail ApplicationHiking trails could be found almost everywhere and they are usually free to be used. Be-cause of this, a lot of people choose hike as their daily exercises. In reality, a lot of hikingtrails go through forests, groves, or wild roads where the environmental data or statisticsmay be interesting or important for hikers, scientists or engineers. According to the pre-vious researches, these environmental monitoring tasks could be accomplished by WSNs.But as we argued in the previous chapters, sparsely deployed wireless sensors will be moresuitable than traditional WSNs for applications like hiking trail. Thus, we proposed an ideato build a hiking trail application on our publish/subscribe platform. In this application,environmental monitoring sensors are sparsely deployed along those hiking trails. At thesame time, hikers who are equiped with mobile brokers (MBs) could collect environmentaldata while hiking. In addition, since we use smart phone as mobile broker, the activity dataof hikers, e.g. speed, could also be gathered.

According to our publish/subscribe platform, all the interests for different kinds of datacould be expressed as subscriptions for various services. Thus, in the hiking trail applica-tion, users could subscribe different services provided in the hiking trail area. For example,hikers could subscribe their interested environmental data (e.g. temperature and humidity)from their home computers. Then based on the received data, they can decide whetherthey will go to hike or not. Besides, hikers may also want to know the statistics of their

55

activities. For example, in order to better schedule his/her own exercises, a hiker usuallywould like to know how many hikers in average are in the trail during different periods, orwhat are their speed during hiking.

In this application, besides the SSensors (e.g. temperature and humidity sensors), wealso use built-in sensors (e.g. GPS for location and speed) on the smart phone. In summary,both SSensors and MSensors will be used to provide services in our hiking trail application.This is also a proof of the generality and flexibility of our publish/subscribe platform.

7.2 Experiment Set-Up

Figure 7.1: Deployment in hiking trail area

We chose two sidewalks behind our laboratory building as the deployment site of thehiking trail testbed. As depicted in Figure 7.1, we called them Trail 1 and Trail 2 respec-tively. Length of each trail was 200 meters, so the total length of our hiking trail was 400meters. There were four sensor nodes deployed along the trail. Node 1 and Node 2 wereplaced along Trail 1, while Node 3 and Node 4 were placed along Trail 2. The intersectionpoint of Trail 1 and Trail 2 was the central point of the hiking trail area. This area wasactually a circle whose radius was 200 meters. In our publish/subscribe platform, we callthis area the target area of hiking trail services. Then, anyone could subscribe services fromthis area by specifying the central point, radius and service types.

As we can see from Figure 7.2, the SSensors were fixed on the road poles or tree trunks

56

(a) (b) (c)

Figure 7.2: Installation of stationary sensors

along the sidewalks. This was because we would like to improve the quality of wirelesssignals. As we tested, most of the wireless signals would be reflected or absored by theground if we put SSensors too low. In order to proof them against water, temperature andhumidity sensor nodes were put in black plastic boxes. However, light intensity sensornodes were put in transperant plastic bags because they need to be exposed in the sunshine.

Table 7.1: Experiment Setting

Length of hiking trail 400mNumber of SSensors 4Data generation rate at each SSensor 5 samples/hourDistance between SSensors 100mCommunication power level of SSensors -5dBmNumber of temperature Sensor 1Number of light intensity sensor 2Number of humidity sensor 1Number of hikers 4Number of initial subscriptions 4Experiment period 9 days

All the hikers would carry an HTC Hero phone while hiking. The same as we explained

57

in the implementation chapter, these mobile phones were installed with our publish/sub-scribe platform and they were enabled to communicate with SSensors directly.

Initially, we installed four different subscriptions in the broker. These subscriptionsbooked temperature, humidity, light intensity and speed services respectively. All of thesesubscriptions set their target area to the hiking trail area. The beginning time of these foursubscriptions was 11 Apr 2011 7pm, while the end time was 19 Apr 2011 10pm.

As a summary, the experiment parameters are listed in Table 7.1.

7.3 Experiment Result

7.3.1 Sensing Data from Stationary Sensors

−10

0

10

20

30

Date

Deg

rees

Cel

sius

Temperature Data

12/04 12PM

13/04 12PM

14/04 12PM

15/04 12PM

16/04 12PM

17/04 12PM

18/04 12PM

19/04 12PM

Figure 7.3: Temperature Data

Initially, the user subscribed temperature, humidity and light intensity services in thehiking trail area. Therefore, we could obtain envrionmental data at the end of our experi-ment. As we can see from Figure 7.3, temperatures in the hiking trail area were changedobviously during the experimental period. In the first two days, the hightest temperatureswere 9 to 10 degrees, while the lowest temperatures were around 2 to 3 degrees. Then, thetemperature increased continuously up to 22 degrees during the following four days. But atthe end of experiment, it started to decrease again. In this figure, we can also find that thelowest temperature occurred in the early moring of everyday, and the highest temperaturealways appearred around the middle of the afternoon.

As depicted in Figure 7.4, humidities during the experimental period also fluctuatedsignificantly. In the hiking trail area, humidity would achieve its top value in the early

58

20

40

60

80

Date

Rel

ativ

e H

umid

ity (

%)

Humidity Data

12/04 12PM

13/04 12PM

14/04 12PM

15/04 12PM

16/04 12PM

17/04 12PM

18/04 12PM

19/04 12PM

Figure 7.4: Humidity Data

moring, then decreased to the lowest value in the middle of the afternoon. If comparedwith Figure 7.3, the curve of humidity data was opposite to that of the temperature data.The reason for this is very intuitive: in an open space area, the air will be drier as thetemperature goes higher.

0

100

200

300

400

500

Date

TS

R (

lux)

Total Sun Radiation Data

12/04 12PM

13/04 12PM

14/04 12PM

15/04 12PM

16/04 12PM

17/04 12PM

18/04 12PM

19/04 12PM

Node2 Node4 Node5

Figure 7.5: Light Intensity Data

Different from temperature and humidity, we thought the sample values of light inten-sity sensor would be heavily affected by its location. For example, two nodes at distinctlocations may receive the strongest sunlight at different clocks during one day. Thus, in

59

order to increase the data diversity, we deployed two light intensity sensors in our hikingtrail area. As depicted in Figure 7.1, they were Node 2 and Node 4 which were located onTrail 1 and Trail 2 respectively. But unfortunatedly, node 4 was stolen during the third dayof our experiment. As a result, we had to deploy a new light intensity sensor node (node 5)at a nearby place.

As you can see in Figure 7.5, there are data from three different nodes. Because node 4was stolen, its data only last for two days. Node 5 was installed in the third day, so its datalast for six days. During the daytime, the differences between sample values from differentnodes are obvious. In Figure 7.5, the maximum value of light intensity from node 5 ishigher than that of node 2, but node 2 will achieve its maximum value earlier than node 5.The lowest values of all three nodes are nearly the same from each other. This is becausethe whole hiking trail area has very little light during night.

7.3.2 Sensing Data from Mobile SensorBesides subscriptions for the environmental data, there was another subscription for hiker’sspeed. According to this subscription, speed of all hikers would be collected once theyentered hiking trail area. Because this subscription subscribed services from the mobilesensor (e.g GPS in this experiment), it verified that our platform could enable not onlySSensor services to the Internet, but also the services provided by mobile sensors.

0 1 2 3 4 50

0.2

0.4

0.6

0.8

1

Hiking Speed (meter/second)

CD

F

Cumulative Distribution of User Speed

user1user2user3user4

Figure 7.6: User Speed Distribution

The speed data we collected during the experiment is presented in Figure 7.6 and Fig-

60

ure 7.7. In the hiking trail application, the calculation period of speed was set to twoseconds. In other words, the average speed of the hiker was sampled every two seconds.Figure 7.6 depicts the cumulative distributions of speed values. Because 80 percent of thespeed values are below 1.5 m/s, we could imply that all hikers preferred to walk duringmost of the time. For hiker 3, his fastest speed is only around 2.3 m/s. As a comparison,hiker 4 ever reached 4 m/s which was the fastest speed among all hikers.

0501001502000.5

1

1.5

2

2.5

3

3.5

4

Distance to Central Point (meter)

Hik

ing

Spe

ed (

met

er/s

econ

d)

Hiking Speed at Different Positions

run walk

Figure 7.7: User Hiking Speed at Different Positions

To better understand hiker’s motion, we also evaluated the relationship between thespeed, locations and activity types. In the experiment, the GPS accuracy is around 4 to 6meters. We selected data from hiker 1 who visited the hiking trail area most often. Becausehikers could walk or run during the experiment, we further seperate speed data by thesetwo types. In Figure 7.7, the x-axis depicts the locations along trail 1. The entrance of trail1 is 200 meters away from the central point of the hiking trail area. The exit of trail 1 isoverlapping with the central point. In this figure, only speed collected along trail 1 is used.From Figure 7.7, it is obvious that hiker’s speed was between 0.5 m/s and 1.5 m/s whenhe was walking, but the speed stayed between 2 m/s and 4 m/s if he was running. Anotherdifference is that the speed fluctuated more dramatically while the hiker was running.

In the figure, an interesting phenomenon is that the curve for running and the curvefor walking have nearly the same trend along the x-axis. It implies that road conditionswill affect the motion of a hiker. Another common point for these two curves is that speedvalues will fall rapidly before the hiker arrived the exit (central point of the hiking trailarea). According to Figure 7.1, we find that a hiker had to turn left at the central point if

61

he hiked from trail 1 to trail 2. Therefore, we can figure out why hiker lowered his speedbefore arriving the central point.

7.3.3 User Hiking Frequency

8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 24:00

11/04

12/04

13/04

14/04

15/04

16/04

17/04

18/04

19/04

Time

Dat

e

User Hiking Frequency

Figure 7.8: User Hiking Frequency

We also evaluated how often hikers visited the hiking trail area during the experimentalperiod. To make the statistics more meaningful, we recorded the visits by their occuringtime and dates. This information is depicted in Figure 7.8. Each star mark in the figurestands for one visit.

7.3.4 System PerformanceData Packet Delay

In our publish/subscribe platform, there are two latencies for data genereted on SSensors.One is the latency on SSensors before the data could be picked up by a MB. Another is thelatency on a MB before the data could be uploaded to the broker. We call the first latencySLatency, and the second MLatency. Because MSensors and MB are in the same device(e.g. the mobile phone), data from MSensors only have MLatency.

62

12/04 13/04 14/04 15/04 16/04 17/04 18/04 19/0410

1

102

103

104

105

Date

Ave

rage

Dat

a P

acke

t Del

ay (

seco

nd)

Data Packet Delay

Mobile phoneNode1Node2Node3Node4Node5

Figure 7.9: Data Packet Delay

In any communication system, packet delay is an important estimation of the systemperformance, so we first evaluated end-to-end delay of data packets in our experiment. Wedefine this delay as the difference between the time when data is generated and the timeit is received at broker. For concision, we call it data packet delay and refer it to DPD. Inthe experiment, since we used 3G for communication beween MB and broker, the DPD ofdata from MSensors is the sum of 3G communication latency and MLatency. On the otherhand, besides the previous two latencies, DPD of data from SSensors includes wirelesssensor communication latency and SLatency.

In Figure 7.9, the curve of mobile phone represents DPD of speed data, and the curvesof node 1 to node 5 show DPDs of data from different SSensors. As we can see from thefigure, the DPD of speed data is only 22 to 23 seconds. However, for data from SSensors,even the shortest DPD is still above 3000 seconds. This also shows how largely a SLatencywould affect the DPD.

Because SLatency depends on how often hikers or MBs will enter the SSensors’ vicin-ity, we relate Figure 7.8 with Figure 7.9 when analyzing the fluctuation of DPD values.For data from SSensors, the DPDs in 12th April and 17th April are obviously higher thanother days (except 16th April). If looking back at Figure 7.8, we can find that the numberof hikes in 12th April and 17 April are obviously smaller than other days. It shows that themore frequently hikers visit the hiking trail area, the shorter the SLatency will be. However,although the numbers of hikes in 13th April, 16th April and 19th April all equal to 8, the

63

delay in 16th April is much higher than the other two days. In Figure 7.8, it is easy to findthat the eight hikes in 16th April were centered to four groups while hikes in the other twodays were more uniformly distributed along the time line. This illustrates that not only thenumber of hikes but also their distribution will affect the SLatency.

Number of received data

1 2 3 40

5

10

15

20

25

30

35

40

Sensor Node ID

Num

ber

of R

ecei

ved

Dat

a

Number of Data Received at Different Speed

WalkRun

Figure 7.10: Number of Data Received at Different Speed

Because MB will only be able to fetch data whenever it is in the vicinity of a SSensor,its moving speed and the communication chip’s power level of the SSensor will affect thevolumn of received data. For better understanding, I need to explain that power level ofcommunication chip would affect the strength of wireless signal, thus it will affect thesuccess rate on packet transmission at different distances.

For Tmote Sky nodes, the wireless communication is provided by CC2420 chip. In ourexperiment, the transmission power level of CC2420 is set to -5dBm. Then we first testedthe communication quality between two static sensor nodes. When their distance is 50meters, they could only occasionally receive packets from each other. But if their distancewas smaller than 30 meters, almost every packets could be received. I believe this couldgive us a hint on the quality of wireless channels when two static nodes communicate atdifferent distances. In order to see how the hiker’s moving speed will affect the number ofreceived data, we repeated trials when the hiker ran or walked respectively. During running,the average speed of hiker is between 2.75 m/s to 3.1 m/s, and it is between 1 m/s to 1.5

64

m/s while walking.As depicted in Figure 7.10, mobile broker could receive at most 37 pieces of data while

hiker was walking. Differently, it could only receive at most 8 packets while hiker wasrunning. Generally speaking, MB could receive more data while hiker was walking. As wecan image, if the hiker moves slower, the MB could stay longer in the vicinity of a SSensor.As a result, it could receive more data while moving.

You may also notice that the numbers at distinct sensor nodes are different when theywere collected at nearly the same hiking speed. We argue that this difference is reasonableand it is caused by the unstable wireless signal. For example, data packets may be lost dueto fluctuating conditions of communication channels at each sensor node.

Duplication of Data Packets

1 2 3 4 50

200

400

600

800

1000

1200

Node ID

Num

ber

of D

ata

Duplicate Data Received

Data generated by sensorsData received at broker

Figure 7.11: Duplicate Data Received From Stationary Sensors

As we mentioned in the implementation part, we use reliable unicast for the transmis-sion of data packets. A data packet will only be transmitted when the previous one has beenacknowledged. If current data packet has not been acknowledged until timing out, it willbe restored into the caching file for retransmission in the future. This policy will make surethat any data packet is either received by a mobile broker or stored at the stationary sensor.As we proved in the experiment, 100 percent of the generated data were finally receivedat broker. However, when counting the number of data received at broker, we surprisinglyfound that this number was bigger than what it should be. In other word, we received du-plicate packets for some data. An extreme example was that one of the data packets was

65

even received for five times!After rethinking our policy, we found that this was because a data packet may still

time out although the mobile broker has received it. More clearly speaking, all of theacknowledgements for that packet may be lost, then the stationary sensor will believe thepacket has not been received by MB. Afterwards, this packet will be re-sent wheneverpossible. As a result, duplicate data packets will be received at broker. In Figure 7.11, itshows the numbers of data which broker should received in comparison with the numberswhich broker finally received. During the experiment, data generation rate of all sensorswere set to 5 samples per hour. Data generated at node 2 is less than that at node 1 andnode 3. This is because that node 2 was installed nearly one day later (the light sensorswas not fully prepared in the first day). But node 4 and node 5 generated far less datathan other nodes. If reminding that node 4 was stolen two days after its installation, youcan understand why it generated less data. On the other hand, since node 5 was installedafter node 4 was stolen, it lasted fewer days and also generated less data than other normalnodes. For the data from node 3, there are nearly three hundred duplicate data packets.

Adaptive Algorithm on Subscription Delivery

12/04 13/04 14/04 15/04 16/04 17/04 18/04 19/040

0.2

0.4

0.6

0.8

1

Date

Sub

scrip

tion

deliv

ery

rate

Subscription Delivery Rate

subscription1 subscription4 subscription6 subscription7

Figure 7.12: Subscription Delivery Rate

In the design part, we explained the adaptive algorithm on subscription delivery. Sub-scription delivery is for delivering the subscriptions in broker to stationary sensors throughthe mobile broker. To evaluate its performance, we compared the numbers of subscriptiondeliveries for speed service and SSensor’s services respectively. For the speed service, be-

66

1 2 3 4 5 60

10

20

30

40

50

60

70

80

90

Subscription ID

Num

ber

of S

ubsc

riptio

n D

eliv

erie

s

Subscription Delivery Times

Figure 7.13: Subscription Delivery Times

cause an ‘installed’ message will be received whenever the subscription is installed on themobile sensor, the delivery rate of such subscription will always be 1. Hence, it will behavethe same as the constant algorithm, so we treated its data as generated under the constantalgorithm. In Figure 7.12, subscription 4 subscribed speed service, and subscription 1,subscription 6, and subscription 7 all subscribed TSR service.

As we can expect, the delivery rate of subscription 4 kept one constantly. Subscription1 was added to broker at the beginning of the experiment. Initially, its delivery rate wasnearly 0.8, but it quickly decreased below 0.4 two days later. However, in the evening of14th April, one of our light intensity sensor was stolen, so we had to deploy a new onein the second day. This caused the average delivery rate of subscription 1 increased againin 15th April. For a deployed subscription, the broker may receive an ‘installed’ messageagain if there is a new sensor node added in the target area. Thus, the delivery rate of thatsubscription will be restored to 1 immediately. Naturally, this will increase the averagedelivery rate of that subscription. On the other hand, this also present that our algorithmcould effectively handle the dynamic deployment of stationary sensor nodes.

In the following days of the experiment, we added new light intensity subscriptions in15th April and 19th April respectively. Obviously, their delivery rates decreased quicklyover time. In addition, Figure 7.13 shows how many subscription deliveries the broker to-tally issued for different subscriptions. During the experimental perioid, constant algorithmdelivered subscription 4 for around 90 times, but the largest value while using adaptive al-gorithm was only 38 times. It testifies that the adaptive algorithm can largely reduce the

67

number of unnecessary subscription deliveries.

Adaptive Algorithm on Location Update

(2250, 1800] (1800, 1350] (1350, 900] (900, 450] (450, 0]0

1

2

3

4

5

Distance to Target Area (meters)

Num

ber

of L

ocat

ion

Upd

ates

Location Update Times

Adaptive UpdatePeriodic Update

Figure 7.14: Location Update Times

Another improvement in our platform is the adaptive algorithm on location update. Thepurpose of location update is to check if the user arrives the sensing field of interest. In theexperiment, we composed two versions of the mobile broker software. In one version,we enabled adaptive algorithm on location update, while in the other version, we usedperiodical algorithm. Then they were installed into two mobile phones respectively. Afterthat, a hiker holded these two phones was required biking towards the hiking trail area froma place 2250 meters away. During the trials, we recorded the number of location updates.

In the experiment, location update interval was set to 30 seconds. For the adaptiveversion, the maximum speed of biking was set to 15 m/s. As depicted in Figure 7.14,we counted the number of location updates while the hiker proceeded in differnt distanceranges. The target area in the figure is our hiking trail area. Obviously, for the adaptiveversion, the number of udpates increased when the hiker went closer to the hiking trail area.This is because the update interval was decreased during this procedure. In other words, thelocation will be updated more and more frequently while the hiker approching the hikingtrail area.

Before the distance to target area was less than 450 meters, the number of updates inadaptive version was always less than that in periodical version. But once the hiker entered

68

range (450,0], two versions issued same number of location updates. Actually, this is notcoincident. Reminder that the maximum speed of biking was 15 m/s and the constantinterval is 30 seconds, we would realize that the computed interval in adaptive versionwould be smaller than the constant interval when hiker was less than 450 meters far awayfrom target area. As a result, both versions used the same update interval at last.

69

Chapter 8

Conclusions and Future Work

In this thesis, we have presented a publish/subscribe platform enabling mobile phones asboth mobile proxies and MSensors. With our platform, SSenors in sparse sensor networkscould be connected to the Internet without depending on any additional infrastructure.Therefore, the extension of sparse sensor networks to the urban wide or global wide be-comes possible. On the other hand, since our platform connects SSensors and MSensorsforming hybrid sensor networks, participatory sensing applications could be augmentedwith sensing abilities of SSensors. A key challenge of our publish/subscribe platform isto support the intermittent connections between the broker and SSenors caused by the un-controlled mobilities of MBs. To solve this challenge, policies on subscription caching anddelivery at the broker and MBs are designed respectively in the thesis. Pull-based eventcollection strategy is also employed. In addition, to improve the performance of the sys-tem, adaptive algorithms on location update and subscription delivery are also proposed.Another focus of our platform is on the flexibility and scalability in terms of supportingdiverse sensing applications and sensing service providers using both MSensors and SSen-sors, easing the development and installation of these sensing applications and sensingservice modules. In the thesis, unified publish/subscribe semantics are designed to enablediverse sensing applications utilizing the underlying sensing services through our platform.On the other hand, programming interfaces are also proposed to facilitate the easy integra-tion of third-party sensing modules to our platform.

To demonstrate the design is applicable, we implemented our publish/subscribe plat-form on real devices. During the implementation, the mobile phone is enabled to commu-nicate with SSensors through an attached sensor node. Further more, special adaptationon low-rate and low-power sensor communication is also performed. In order to supportdiverse third-party sensing modules, Intent messaging mechanism of Android system isutilized on our MB module. Afterwards, based on our implementation, a hiking trail ap-plication was further deployed to carry out the performance evaluation of our system. Ac-

70

cording to the experiment, it is verified that our platform could facilitate new participatoryapplications accessing MSensors and SSensors at the same time. More importantly, theevaluation testified that the performance of our platform in the condition of intermittendconnections is acceptable.

8.1 Future workAlthough the main problems of utilizing mobile phones to build hybrid sensor networkshas been solved in this thesis, there are still other problems need to be further researchedto improve the performance of such systems.

One possible improvement on our current work would be a more energy-effecientmechanism on event collection. In this thesis, although we have avoided sending a lotof unnecessary event collection messages by using the event collection flag (ECF), batterypower of the mobile phones are still highly consumed since the MBs will broadcast eventcollection messages (ECMs) at a very high rate (e.g every 10 seconds in current imple-mentation) once an ECF received. The basic consideration behind the high-rate deliveryof ECMs is based on the nature of opportunistic communication between mobile phonesand SSensors. Given that mobile phones and SSensors communicate in short-range radioand they can only encounter each other opportunistically in a short time range, if we set thedelivery rate of ECMs lower (e.g. every 10 minutes), it is very possible that a mobile phonewould lose the chance to pull events from SSenors since it may pass by those sensors whilewaiting for sending the next ECM. For the future work, the quality of event collection andthe efficiency of power consumption could be better balanced if the event collection mes-sages could be sent adaptively according to the mobility prediction and energy consumptionestimation of the mobile phones.

Similarly, another possible improvement would be a more energy-effecient mechanismon service discovery issued by the MBs. In our current design, in order to deliver subscrip-tions to SSensors, the MBs will broadcast service discovery messages at a very high rate(e.g. every 10 seconds). This is also driven by the opportunistic communication nature be-tween MBs and SSenors. Actually, the consideration behind this design is the same as thatfor the event collection. Therefore, a more energy-effecient approach could be proposedbased on sophisticate algorithms of mobility prediction and energy consumption estimationfor moblie phones.

71

8.2 DiscussionIn this thesis, the publish/subscribe platform is designed with the consideration that as littleas possible deployment information of the underlying SSensors should be relied. Actually,this is motivated by our aim to achieve generality in the platform and high degree decou-pling between our platform and the underlying sensor deployments. Since no informationof the SSensor deployments is depended on, our platform could be used by any sensorservice provider without any additional configuration. More specifically, as long as ourplatform module is installed on the sensor nodes, the deployments could be integrated intothe publish/subscribe system immediately. Further more, the sensor service providers couldalso change their deployments dynamicly without affecting the publish/subscribe system.

However, one price paid by this decoupling design is that a MB has to rediscover theSSensors whenever it enters a target area again. Although this is worthwhile for dynamicdeployments of SSensors, it is not necessary for other deployments which may not changeso frequently. For example, deployments of temperature sensors in a forest may not changeover a whole year. On the other hand, if this platform is only used for specific applications,the previous consideration on generality will be also unnecessary. Therefore, in these sce-narios, it is a better choice if the MBs could register the information of the discoveredSSensors on the broker. Based on this information, the broker could request the MBs torediscover SSesnors in a target area only when it is necessary (e.g. when new sensor nodesare added in a target area). As a result, since discovery processes will be performed lessfrequently, the energy consumption both on MBs and SSensors could be reduced.

72

APPENDICES

73

Appendix A

Sample JSON Messages

A.1 SubscriptionsTwo subscriptions are encapsulated in this message. As an example, application constraintsin this message has the format of (predicate, threshold, sampleRate). In the example sub-scription interested in temperature, the “appConstraint" means: sample the temperatureevery 720 seconds (12 minutes), and only return the values higher than 20 degrees. Forthe subscription interested in humidity, it specifies that only the humidities smaller than 80percent should be returned. "startTime" and "endTime" in our current implementation isthe number of seconds since 1st Jan 1970 00:00:00. The unit of "radius" is meter.

����������

������� ����

������ �������� �� �

������ ���������� �

������������� �

�������� �

����������� ����� !"��

������������ ������ !"�

#�

������ �� �""�

#�

���$�����%������ �

� ����&�$��� ��!!""' !��

����&�$��� ��!!"' !�

#�

�(�� �������� �

� ��)���*�$��� � �� ��+��$����������

74

�������������� �

�� ���� �� ����

��� ������� �����

������ ��� �� �����

�

�

��

�������������� �

���� �� ��� �

������� �

������� �� ��� !"�#$����

�������� �� ��� !"�#$���

��

������� �����

��

�� ��������� �� �

�����%� �� ��&$$���'#$��

� ��%� �� ��&$$���'#$�

��

����������� �

�� (� )�� �� ��� ���*�����+��

�������������� �

�� ���� �� �,��

��� ������� �#���

������ ��� �� �����

�

�

�

-

�

�

A.2 EventsThree events are encapsulated in this message. Among them, two events contain temper-ature data and the other contains humidity data. As an example, the “appContent" in thismessage has the format of (type, value).

��.( ����� /

�.( ���� �

75

������� ����

���� �������� �

������� �������������

�������� ���

�

�

�������� �

������� ����

���� �������� �

������� �������������

�������� ����

�

�

�������� �

������� ����

���� �������� �

������� ����������

�������� �� �

�

�

!

�

76

Appendix B

Compressed Message for SensorCommunication

The compressed messages are used during the communication between MBs and SSensors.

B.1 Subscription

Figure B.1: Compressed Format for a subscription

In the compressed message, “spID" and “sbID" are encoded as 2 byte integers. “start-Time" and “endTime" are encoded as 4 bytes Integers. Since “appConstraint" and “ser-viceName" are application specific, they will still be transmitted in text format in order toachieve generality in our platform. However, in order to distinguish the “serviceName" and“appConstraint" in a text string, a semicolon is inserted as a separator.

B.2 Event

Figure B.2: Compressed Format for an Event

77

In a compressed event message, “sbID" is encapsulated as a 2 byte integer. Since“appContent" is application specific, it should be encoded as text string to keep our platformgeneric.

78

REFERENCES

[1] ������������������ ������� ���������� .

[2] Android operating system. ������������������ ��.

[3] Apache cxf. ������� ������ �������.

[4] Apache tomcat. ��������� ������ �������.

[5] Imei. ���������������� �������������� ������������� � ���� .

[6] Java platform, enterprise edition. �������������� �� ���� �������������

����������������������� .

[7] Linux operating system. ��������������� �����.

[8] Mqtt v3.1 protocol specification. ���������� � �������� ��������������

�������� �����!"���"��!�#�$��� .

[9] Uris, urls, and urns clarifications and recommendations 1.0. Reportfrom the joint w3c/ietf uri planning interest group, W3C, Sept. 2001.http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/.

[10] Ieee, wireless medium access control (mac) and physical layer (phy) specificationsfor low rate wireless personal area networks (wpans). IEEE Sandard 802.15.4-2006,2006.

[11] K. Aberer, M. Hauswirth, and A. Salehi. Infrastructure for data processing in large-scale interconnected sensor networks. In Mobile Data Management, 2007 Interna-tional Conference on, pages 198 –205, may 2007.

[12] E.-G. Ahmed, J. K. Kevin, and I. Michael. Predicting bicycle travel speeds along dif-ferent facilities using gps data: A proof of concept model. In Transportation ResearchBoard 86th Annual Meeting, 2007.

[13] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. Wireless sensor net-works: a survey. Computer Networks, 38(4):393 – 422, 2002.

[14] K. Birman and T. Joseph. Exploiting virtual synchrony in distributed systems. InProceedings of the eleventh ACM Symposium on Operating systems principles, SOSP’87, pages 123–138, New York, NY, USA, 1987. ACM.

79

[15] A. D. Birrell and B. J. Nelson. Implementing remote procedure calls. ACM Trans.Comput. Syst., 2:39–59, February 1984.

[16] D. Booth, H. Haas, F. Mccabe, E. Newcomer, M. Champion, C. Ferris, and D. Or-chard. Web Services Architecture, Oct. 2004.

[17] T. Bray, J. Paoli, S. C. M. Mcqueen, E. Maler, and F. Yergeau. Extensible MarkupLanguage (XML) 1.0 (Third Edition), 2004.

[18] J. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, and M. B.Srivastava. Participatory sensing. In Workshop on World-Sensor-Web (WSWâAZ06):Mobile Device Centric Sensor Networks and Applications, pages 117–134, 2006.

[19] A. T. Campbell, S. B. Eisenman, N. D. Lane, E. Miluzzo, and R. A. Peterson. People-centric urban sensing. In Proceedings of the 2nd annual international workshop onWireless internet, WICON ’06, New York, NY, USA, 2006. ACM.

[20] M. Caporuscio, A. Carzaniga, and A. L. Wolf. Design and evaluation of a supportservice for mobile, wireless publish/subscribe applications. IEEE Transactions onSoftware Engineering, 29:1059–1071, 2003.

[21] M. Castro, P. Druschel, A.-M. Kermarrec, and A. Rowstron. Scribe: a large-scale anddecentralized application-level multicast infrastructure. Selected Areas in Communi-cations, IEEE Journal on, 20(8):1489 – 1499, oct 2002.

[22] R. Chinnici, S. Weerawarana, J.-J. Moreau, and A. Ryman. Web services descriptionlanguage (WSDL) version 2.0 part 1: Core language. W3C recommendation, W3C,June 2007. http://www.w3.org/TR/2007/REC-wsdl20-20070626.

[23] P. Costa, C. Mascolo, M. Musolesi, and G. Picco. Socially-aware routing for publish-subscribe in delay-tolerant mobile ad hoc networks. Selected Areas in Communica-tions, IEEE Journal on, 26(5):748 –760, june 2008.

[24] D. Crockford. The application/json media type for javascript object notation (json),July 2006.

[25] T. Das, P. Mohan, V. N. Padmanabhan, R. Ramjee, and A. Sharma. Prism: platformfor remote sensing using smartphones. In Proceedings of the 8th international confer-ence on Mobile systems, applications, and services, MobiSys ’10, pages 63–76, NewYork, NY, USA, 2010. ACM.

80

[26] A. Dunkels, B. Gr?nvall, and T. Voigt. Contiki - a lightweight and flexible operatingsystem for tiny networked sensors. Local Computer Networks, Annual IEEE Confer-ence on, 0:455–462, 2004.

[27] A. Dunkels, F. Österlind, and Z. He. An adaptive communication architecture forwireless sensor networks. In Proceedings of the 5th international conference on Em-bedded networked sensor systems, SenSys ’07, pages 335–349, New York, NY, USA,2007. ACM.

[28] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces ofpublish/subscribe. ACM Comput. Surv., 35:114–131, June 2003.

[29] L. Fiege, F. Gartner, O. Kasten, and A. Zeidler. Supporting mobility in content-basedpublish/subscribe middleware. In M. Endler and D. Schmidt, editors, Middleware2003, volume 2672 of Lecture Notes in Computer Science, pages 998–998. SpringerBerlin / Heidelberg, 2003. 10.1007/3-540-44892-6-6.

[30] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Standard), 1999.

[31] R. T. Fielding. Architectural styles and the design of network-based software archi-tectures. PhD thesis, 2000. AAI9980887.

[32] R. K. Ganti, N. Pham, H. Ahmadi, S. Nangia, and T. F. Abdelzaher. Greengps: aparticipatory sensing fuel-efficient maps application. In Proceedings of the 8th in-ternational conference on Mobile systems, applications, and services, MobiSys ’10,pages 151–164, New York, NY, USA, 2010. ACM.

[33] D. Guinard. Towards the web of things: Web mashups for embedded devices. In InMEM 2009 in Proceedings of WWW 2009. ACM, 2009.

[34] A. Gupta, O. D. Sahin, D. Agrawal, and A. E. Abbadi. Meghdoot: content-basedpublish/subscribe over p2p networks. In Proceedings of the 5th ACM/IFIP/USENIXinternational conference on Middleware, Middleware ’04, pages 254–273, New York,NY, USA, 2004. Springer-Verlag New York, Inc.

[35] M. Hadley, H. F. Nielsen, N. Mendelsohn, M. Gudgin, and J.-J. Moreau. SOAPversion 1.2 part 1: Messaging framework. first edition of a recommendation, W3C,June 2003. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.

[36] J.-H. Hauer, V. Handziski, A. KÃupke, A. Willig, and A. Wolisz. A componentframework for content-based publish/subscribe in sensor networks. In R. Verdone,

81

editor, Wireless Sensor Networks, volume 4913 of Lecture Notes in Computer Science,pages 369–385. Springer Berlin / Heidelberg, 2008. 10.1007/978-3-540-77690-1-23.

[37] B. Hoh and M. Gruteser. Preserving privacy in gps traces via uncertainty-aware pathcloaking. In In Proceedings of ACM CCS 2007, 2007.

[38] J. W. Hui and D. E. Culler. Ip is dead, long live ip for wireless sensor networks.In Proceedings of the 6th ACM conference on Embedded network sensor systems,SenSys ’08, pages 15–28, New York, NY, USA, 2008. ACM.

[39] U. Hunkeler, H. L. Truong, and A. Stanford-Clark. Mqtt-s - a publish/subscribe pro-tocol for wireless sensor networks. In Communication Systems Software and Mid-dleware and Workshops, 2008. COMSWARE 2008. 3rd International Conference on,pages 791 –798, jan. 2008.

[40] I. Jacobs and N. Walsh. Architecture of the world wide web, volume one. W3Crecommendation, W3C, Dec. 2004. http://www.w3.org/TR/2004/REC-webarch-20041215/.

[41] S. Jain, R. Shah, W. Brunette, G. Borriello, and S. Roy. Exploiting mobility forenergy efficient data collection in wireless sensor networks. Mobile Networks andApplications, 11:327–339, 2006. 10.1007/s11036-006-5186-9.

[42] D. Jea, A. Somasundara, and M. Srivastava. Multiple controlled mobile elements(data mules) for data collection in sensor networks. In V. Prasanna, S. Iyengar, P. Spi-rakis, and M. Welsh, editors, Distributed Computing in Sensor Systems, volume 3560of Lecture Notes in Computer Science, pages 466–466. Springer Berlin / Heidelberg,2005. 10.1007/11502593-20.

[43] A. Kansal, S. Nath, J. Liu, and F. Zhao. Senseweb: An infrastructure for sharedsensing. IEEE MultiMedia, 14:8–13, October 2007.

[44] L. Krishnamurthy, R. Adler, P. Buonadonna, J. Chhabra, M. Flanigan, N. Kushalna-gar, L. Nachman, and M. Yarvis. Design and deployment of industrial sensor net-works: experiences from a semiconductor plant and the north sea. In Proceedingsof the 3rd international conference on Embedded networked sensor systems, SenSys’05, pages 64–75, New York, NY, USA, 2005. ACM.

[45] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay,J. Hill, M. Welsh, E. Brewer, and D. Culler. Tinyos: An operating system for sensornetworks. In W. Weber, J. M. Rabaey, and E. Aarts, editors, Ambient Intelligence,pages 115–148. Springer Berlin Heidelberg, 2005. 10.1007/3-540-27139-2-7.

82

[46] M. Li and Y. Liu. Underground structure monitoring with wireless sensor networks. InProceedings of the 6th international conference on Information processing in sensornetworks, IPSN ’07, pages 69–78, New York, NY, USA, 2007. ACM.

[47] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J. Anderson. Wireless sensornetworks for habitat monitoring. In Proceedings of the 1st ACM international work-shop on Wireless sensor networks and applications, WSNA ’02, pages 88–97, NewYork, NY, USA, 2002. ACM.

[48] D. Malan, T. Fulford-jones, M. Welsh, and S. Moulton. Codeblue: An ad hoc sensornetwork infrastructure for emergency medical care. In In International Workshop onWearable and Implantable Body Sensor Networks, 2004.

[49] E. Miluzzo, C. T. Cornelius, A. Ramaswamy, T. Choudhury, Z. Liu, and A. T. Camp-bell. Darwin phones: the evolution of sensing and inference on mobile phones. InProceedings of the 8th international conference on Mobile systems, applications, andservices, MobiSys ’10, pages 5–20, New York, NY, USA, 2010. ACM.

[50] M. Mun, S. Reddy, K. Shilton, N. Yau, J. Burke, D. Estrin, M. Hansen, E. Howard,R. West, and P. Boda. Peir, the personal environmental impact report, as a platformfor participatory sensing systems research. In Proceedings of the 7th internationalconference on Mobile systems, applications, and services, MobiSys ’09, pages 55–68, New York, NY, USA, 2009. ACM.

[51] A. Nummela, T. KerÃd’nen, and L. O. Mikkelsson. Factors Related to Top RunningSpeed and Economy. Int J Sports Med, 28:655–661, 2007.

[52] T. O’Reilly. What is web 2.0: Design patterns and business models for the nextgeneration of software. MPRA Paper 4578, University Library of Munich, Germany,Mar. 2007.

[53] J. Paek, J. Kim, and R. Govindan. Energy-efficient rate-adaptive gps-based position-ing for smartphones. In Proceedings of the 8th international conference on Mobilesystems, applications, and services, MobiSys ’10, pages 299–314, New York, NY,USA, 2010. ACM.

[54] J. Polastre, R. Szewczyk, and D. Culler. Telos: enabling ultra-low power wirelessresearch. In Information Processing in Sensor Networks, 2005. IPSN 2005. FourthInternational Symposium on, pages 364 – 369, april 2005.

[55] N. B. Priyantha, A. Kansal, M. Goraczko, and F. Zhao. Tiny web services: designand implementation of interoperable and evolvable sensor networks. In Proceedings

83

of the 6th ACM conference on Embedded network sensor systems, SenSys ’08, pages253–266, New York, NY, USA, 2008. ACM.

[56] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker. Application-level multicast usingcontent-addressable networks. In J. Crowcroft and M. Hofmann, editors, NetworkedGroup Communication, volume 2233 of Lecture Notes in Computer Science, pages14–29. Springer Berlin / Heidelberg, 2001. 10.1007/3-540-45546-9-2.

[57] K. Romer and F. Mattern. The design space of wireless sensor networks. WirelessCommunications, IEEE, 11(6):54 – 61, dec. 2004.

[58] R. C. Shah, S. Roy, S. Jain, and W. Brunette. Data mules: modeling and analysis ofa three-tier architecture for sparse sensor networks. Ad Hoc Networks, 1(2-3):215 –233, 2003. Sensor Network Protocols and Applications.

[59] Z. Shelby. Constrained Application Protocol (CoAP), May 2011.

[60] E. Souto, G. GuimarÃces, G. Vasconcelos, M. Vieira, N. Rosa, C. Ferraz, and J. Kel-ner. Mires: a publish/subscribe middleware for sensor networks. Personal and Ubiq-uitous Computing, 10:37–44, 2006. 10.1007/s00779-005-0038-3.

[61] D. Tam, R. Azimi, and H.-A. Jacobsen. Building content-based publish/subscribesystems with distributed hash tables. In K. Aberer, M. Koubarakis, and V. Kalogeraki,editors, Databases, Information Systems, and Peer-to-Peer Computing, volume 2944of Lecture Notes in Computer Science, pages 138–152. Springer Berlin / Heidelberg,2004. 10.1007/978-3-540-24629-9-11.

[62] S. Tilak, N. B. Abu-Ghazaleh, and W. Heinzelman. A taxonomy of wireless micro-sensor network models. SIGMOBILE Mob. Comput. Commun. Rev., 6:28–36, April2002.

[63] G. Tolle, J. Polastre, R. Szewczyk, D. Culler, N. Turner, K. Tu, S. Burgess, T. Dawson,P. Buonadonna, D. Gay, and W. Hong. A macroscope in the redwoods. In Proceedingsof the 3rd international conference on Embedded networked sensor systems, SenSys’05, pages 51–63, New York, NY, USA, 2005. ACM.

[64] N. Tsiftes, A. Dunkels, Z. He, and T. Voigt. Enabling large-scale storage in sensornetworks with the coffee file system. In Proceedings of the 2009 International Con-ference on Information Processing in Sensor Networks, IPSN ’09, pages 349–360,Washington, DC, USA, 2009. IEEE Computer Society.

84

[65] J. Waldo. Remote procedure calls and java remote method invocation. Concurrency,IEEE, 6(3):5 –7, jul-sep 1998.

[66] Y. Wang and H. Wu. Dft-msn: The delay/fault-tolerant mobile sensor network forpervasive information gathering. In In Proceedings of INFOCOMâAZ06, pages 1021–1034, 2006.

[67] A. Wood, G. Virone, T. Doan, Q. Cao, L. Selavo, Y. Wu, L. Fang, Z. He, S. Lin, andJ. Stankovic. Alarm-net: Wireless sensor networks for assisted-living and residentialmonitoring. Technical report, 2006.

[68] S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. H. Katz, and J. D. Kubiatowicz. Bayeux:an architecture for scalable and fault-tolerant wide-area data dissemination. In Pro-ceedings of the 11th international workshop on Network and operating systems sup-port for digital audio and video, NOSSDAV ’01, pages 11–20, New York, NY, USA,2001. ACM.

85