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

(1)

IT 11 042

Examensarbete 30 hp

June 2011

A Publish/Subscribe Platform

Supporting Mobile Brokers for

Hybrid Sensor Networks

Xiaoyu Tong

(2)

(3)

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 Mobile

Brokers for Hybrid Sensor Networks

Xiaoyu Tong

Sparse sensor networks are cost-effective when deployed over large geographical areas. 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 and functionality of participatory sensing applications could be enlarged. In this thesis, I design and implement a publish/subscribe platform which employing mobile phones connecting both stationary sensors and mobile sensors to the Internet. Through this platform, more sensor services could be utilized by participatory sensing applications and promising applications would be possible to emerge.

(4)

(5)

LIST OF TABLES

(9)

LIST OF FIGURES

Figure 2.1 A typical wireless sensor network . . . 7

Figure 2.2 A sparse sensor network connected by mobile agents . . . 8

Figure 2.3 A Tmote Sky mote . . . 9

Figure 2.4 A sample JSON representation . . . 13

Figure 2.5 A simple publish/subscribe system . . . 13

Figure 4.1 Roles in a system using our platform . . . 23

Figure 4.2 A Network Perspective of the System . . . 24

Figure 4.3 A Publish/Subscribe Perspective of the System . . . 26

Figure 4.4 Operations in the publish/subscirbe platform . . . 26

Figure 4.5 Software Architecture on Broker . . . 27

Figure 4.6 Software Architecture on Mobile Broker . . . 28

Figure 4.7 Software Architecture on SSensor . . . 29

Figure 5.1 Format of Subscription Message from Subscriber to Broker . . . 32

Figure 5.2 Format of Subscription Message to MSSPs . . . 33

Figure 5.3 Format of Subscription Message to SSSPs . . . 34

Figure 5.4 Format of Event Message . . . 34

Figure 5.5 Subscriber Registration and Association . . . 35

Figure 5.6 Random Re-registration for Mobile Broker . . . 35

Figure 5.7 Situation when MB is outside of any target area . . . 37

Figure 5.8 Communication between MB and Broker on adaptive location update 38 Figure 5.9 MB traverses through a subscription’s target area . . . 39

Figure 5.10 Subscriptions Delivery from Subscriber to Mobile Broker . . . 40

Figure 5.11 Subscriptions forwarding from MB to sensors . . . 42

Figure 5.12 Broadcast discovery message while a MB traversing in a target area 43 Figure 5.13 Event Collection from the SSensor . . . 49

Figure 6.1 Hiking Trail Application UI . . . 52

Figure 6.2 Attaching Tmote Sky to HTC Hero . . . 53

Figure 7.1 Deployment in hiking trail area . . . 56

Figure 7.2 Installation of stationary sensors . . . 57

Figure 7.3 Temperature Data . . . 58

Figure 7.4 Humidity Data . . . 59

(10)

Figure 7.6 User Speed Distribution . . . 60

Figure 7.7 User Hiking Speed at Different Positions . . . 61

Figure 7.8 User Hiking Frequency . . . 62

Figure 7.9 Data Packet Delay . . . 63

Figure 7.10 Number of Data Received at Different Speed . . . 64

Figure 7.11 Duplicate Data Received From Stationary Sensors . . . 65

Figure 7.12 Subscription Delivery Rate . . . 66

Figure 7.13 Subscription Delivery Times . . . 67

Figure 7.14 Location Update Times . . . 68

Figure B.1 Compressed Format for a subscription . . . 77

(11)

Chapter 1 Introduction

1.1 Motivation and Problem Statement

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

(12)

On the other hand, the smart phone has recently become the ubiquitous mobile device since its proliferation. As a result, participatory sensing[18] applications become applica-ble. In those applications, smart phones are used as sensing devices. Different from the low-end phones, smart phones usually contain multiple built-in sensors, e.g. GPS, light sensor and microphone. Besides, they also have higher computation and communication (e.g. 3G and Wiﬁ) abilities. Therefore, participatory sensing applications utilizing the smart 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 as mobile proxies in SSNs, the deployments of SSNs could be extended to urban wide or even to global wide. More speciﬁcally, since ordinary users carrying the smart phones could move around everywhere, the SSNs could be installed at any place where those users may visit. 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 phones have 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 of the participatory sensing applications, they are limited by the sensing abilities of mobile sensors 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 we could 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 as mobile proxies to integrate SSNs into participatory sensor networks, sensing services both from stationary sensors in the SSNs and mobile sensors on borad the smart phones could be utilized by Internet users simultaneously. As a result, constructions of large scale hybrid sensor networks become possible.

(13)

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

1.2 Challenges

When designing a platform supporting the smart phones both as mobile proxies and sensing devices, several challenges need to be tackled. In this section, different challenges are descirbed seperately.

1.2.1 Distributed System Paradigm

Since mobile phones and SSensors are used, these components in our platform actually form a distributed system. For any distributed system, the system paradigm will affect the design on system architecture, therefore it should be decided at the ﬁrst place in our design work. Actually, there are several paradigms frequently used.

Remote Procedure Call (RPC) [15] is one of the most widely used paradigms. The main advangtage of RPC is that program could invoke remote procedures or subroutines nearly 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 remote service providers. Typical middleware following RPC paradigm are SOAP [35] and JAVA RMI [65].

Publish/Subscribe [28] is another most widely used paradigm. In a typical publish/-subscribe system, there are publish/-subscribers, publishers and brokers. Instead of communicating directly, 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 received events according to the limitations specified in subscriptions. Finally, all the qualified events 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 and publishers.

1.2.2 Mobile Proxy Support

(14)

For most of the previous WSNs [11] [39], the proxy to Internet is a static device. But when 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 encounter SSensors opportunistically. Therefore, the connections between mobile proxies and SSen-sors are intermittent or even sporatic. Further more, since Internet users access SSenSSen-sors through the mobile proxies, the end-to-end connections between the Internet users and SSensors are also intermittent. Therefore, how to support the loose connectivities caused by the mobility of the mobile proxies should be considered in our platform. Speciﬁcally, the problems need to be solved for enabling the mobility of mobile proxies are listed as follows:

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

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

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

1.2.3 Uniﬁed Semantics

Not built for any specific appliction, this platform intends to provide Internet interfaces for any application or user who wants to utilize the underlying SSensors and MSensors. On the other hand, keeping scalability in mind, our platform also needs to supply interfaces for any underlying SSensor and MSensor who wants to expose their sensing services to Internet 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 abilities of different sensors may be quite distinct from each other, our platform also has to provide interfaces 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 unified encapsulation of different data is also necessary.

1.2.4 Internet Access to Stationary Sensors

(15)

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

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

Both of these two solutions have their advantages and disadvantages. For the full-IP solution, no protocol convertion is needed. But for the hybrid solution, no globally unique IPv6 address need to be assigned to each device. Since an IP packet is routed by the network infrastructures (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 Contributions

(16)

1.4 Thesis Structure

(17)

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 tiny in size, such a device usually contains a radio transceiver, a microcontroller, and one (or several) sensors. Commonly, this kind of device is refered to as a mote or sensor node. By interconnecting with each other wirelessly, the motes then form a network which is known as a wireless sensor network (WSN).

(18)

nodes perform tasks by sensing their physical and environmental conditions such as hu-midity, temperature, light intensity, pressure, and vibration. Afterwards, the sampled data is 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 a node 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 refer to the tiny embedded device. Therefore, in this thesis, these terms are also equally used if there 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 stationary sensor nodes. Since densely deployed, these nodes could communicate with their neighbors directly during most of the time. However, as the researches in this ﬁeld proceeds and develops, more and more applications require different deployments from the previous one. According to [57] and [62], the network in Figure 2.1 is classiﬁd as a static, dense, and connected WSN.

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

(19)

is to deploy enough sensor nodes in the large area to form a dense sensor network. Another is to install many base stations to collect data from sensor nodes. These base stations can only 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 and data 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 connection between each other. The connection in this network is only established when a mobile node enters radio range of any stationary node. For the mobile node, it is assumed having direct connection with data consumers or wired access points. At the same time, it should be able to communicate with stationary nodes in short-range radio. Again, according to [57] and [62], the network in Figure 2.2 is classiﬁed 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 this thesis is based on the approach in Figure 2.2, we will implicitly mean a SSN like that in Figure 2.2 when mentioning SSN in this thesis.

2.1.2 IEEE 802.15.4

IEEE 802.15.4[10] is standard which speciﬁes the physical layer and media access control for 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 facto standard of MAC layer protocols for communication in WSNs. In our implementation, the communication between SSensors and smart phones used this standard.

2.1.3 Tmote Sky

(20)

As we mentioned previously, motes or sensor nodes are the particles which form the WSNs. Until now, many different types of motes have already been available in the market or academic society. From these motes, Tmote Sky[54] which is depicted in Figure 2.3 was chosen as the stationary sensors used in our implementation. The main characteristics of this 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 outdoors

Integrated Sensors Humidity, Temperature and Light Intensity

2.1.4 Contiki

Contiki[26] is an open source, light weight, event-driven and multi-threading operating system which is especially used on resource constrained devices like sensor nodes. Upon its 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-unicast premitives. During communication, a point-number format Rime address (e.g. 10.22) is used as the sensor node identiﬁcation.

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. The Rime stack and Coffee ﬁle system were employed to provide sensor node communication and data storage management respectively.

2.2 Participatory Sensing

(21)

abilities than a low-end mobile phone. Usually, a smart phone is equiped with on-board sensors such as GPS, microphone, camera and light sensor. Because of the maturity of these devices, a new application scenario called partipatory sensing [18] [19] emerged. In participatory sensing, smart phones are seen as sensors which have ubiquitous Internet connections. As a result, a participatory sensor network is formed by connecting those sensors 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. In this thesis, since a smart phone is actually a mobile phone, these two terms will be used equally 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, the participatory sensing system may need to interact with a person in order to lead him to carry his smart phone to a target sensing area. In some other applications, users who own the smart phones may need to provide their feedbacks as the sening results. Third, for data collected in the system, it will be tagged with location and time stamps. The location stamp may be provided by GPS and the time stamp could be obtained from the network. As a result, the credibility of information on when and where the data was taken is improved.

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

2.3 Web Service

As deﬁned in [16], a web service is "a software system designed to support interoperable machine-to-machine interaction over a network". Actually, in a web service system, there are service requester and service provider respectively. The provider describes its services using a machine-processable format. On the other hand, the requester interacts with the provider in a machine independent language, e.g. XML [17] or JSON [24]. During the communication, the messages between requester and provider are conveyed by HTTP [30]. Since the Web2.0 [52] movement, the implementations of the web service system have developped into two main categories. One is called Big Web Services which especially refers to implementations following WSDL [22] and SOAP [35] standards. Another is called RESTful Web Services which represents the implementations conforming to REST [31] principles.

(22)

2.3.1 REST and RESTful Web Services

Introduced by Roy Fielding in his doctoral dissertation [31], Representational State Trans-fer (REST) is a architectural style for distributed hypermedia systems. In literature, an implementation 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 resource is identified by a resource identifier. While in the context of Web, a resource identifier is expressed by an URI [9]. Since it is an abstraction, a resource in the REST system could have different representations. For example, a document resource could be represented in HTML or XML respectively. Actually, operations in the REST system are all built around the transfer of representations of resources.

RESTful Web Services

As explained in above paragraphes, a RESTful web service is a web service system which conforms 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 other words, we do not need to bother additional protocols (e.g. WSDL) while building such web services. As a result, a RESTful web service is lighter and integrated more tightly with web than Big Web Services.

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

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

2.3.2 JSON

(23)

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 message senders do not send messages directly to message receivers. Instead, a middleware service is provided to relay messages between senders and receivers. In literature, the message sender is usually refered to as a publisher, while the message receiver is refered to as a subscriber. For the middlerware service of message relay, it is often realized by an entity called broker.

(24)

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

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

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

2.4.1 Topic-based publish/subscribe

In the early age of publish/subscribe paradigm, a lot of distributed systems (e.g. [21], [68], and [56]) were implemented in the 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 “Stock Price" 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 subscribpublish-ers are connected to each other through channels identified by specific topic keywords.

2.4.2 Content-based publish/subscribe

Although 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 expressed in topic-based scheme. Therefore, the content-based scheme emerged to solve this kind of requests.

(25)

2.5 Tools

Android Operating System

Android [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 because it could fully support Java. Actually, this is considered as a big advantage since most of the existing Java applications and libraries on Desktop platforms could later be migrated to Android platform directly. As a result, development for Android applications becomes as convenient and easy as that for desktop applications.

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

Java EE

Java Platform, Enterprise Edition (Java EE) [6] is a platform for server programming in Java 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 Java applications running on a web server.

In this thesis, the modules on the HTTP web server were implemented using the Java EE 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 and JavaServer Pages speciﬁcations deﬁned 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 the implementation for most of our modules. Therefore, Apache Tomcat was also chosen as the web server in the our implementation.

Apache CXF

(26)

Chapter 3 Related Work

For the publish/subscribe platform in this thesis, it has to deal with problems in several ﬁelds. First, in order to use the mobile phone as a mobile proxy for SSensors, previous work 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 sensing need to be reviewed. Third, for uniﬁed access of web services at SSensors and MSensors, existing web service systems in sensor networks should be referred to. At last, since our platform is a distributed system, the distributed system paradigm such as publish/subscribe need 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 by their topics.

3.1 Publish/Subscribe Systems

As 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 wireless sensor networks, mobile communication environment, and delay-tolerant networks relate closestly to this thesis.

(27)

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 WSN environment, Mires tends to provide a high-level uniﬁed API whereby different kinds of data-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 simplify application developments. For example, developpers are free to specify communication protocols, data attributes, and service extension components according to their needs. In the 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 paradigm as our platform did, they only considered their designs in pure WSN environment which is quite different from the hybrid sensor networks in this thesis. Therefore, different from their work, our platform needs to tackle problems caused by combining mobile and stationary sensors.

Fiege et al. [29] proposed solutions to support mobility in distributed publish/subscribe systems. In its solutions, two types of mobility, namely physical mobility and logical mobility, are introduced. Among them, the physical mobility refers to the situation where clients may temporarily disconnect from the pub/sub system, while logical mobility refers to 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-location-dependent filters. Then distributed algorithms on how to enable location-dependent filtering were proposed. The main idea of the algorithm is to route events based their location tags while the routing table on brokers will be adaptively updated 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 client location as the routing information. Clients register their IDs at the nearest broker when they move in, but unregister when they move out. When received register or unregistering messages, brokers will update their routing table accordingly. Afterwards, all the dedicated events and subscriptions could be directed to clients through the distributed overlay.

(28)

routing problem in a delay-tolerant mobile ad hoc network. As a precondition, it assumes mobile clients with same interest will always locate together in a physical space. This is also what they called social awareness. At the beginning, the interests or subscriptions of mobile clients are exchanged when they encounter each other. As a result, the value of a variable called “utility" is computed for each client. Then using “utility" as a metric for the message dissemination, all the published messages are routed to mobile carriers who have better “utility" values. Mobile carriers will repeat this process until messages arrive at 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] tackled the problem of supporting mobile publishers. However, in our platform, not only mobile publishers (MSensors) need to be supported, but also mobile brokers (mobile proxies) need to be enabled. On the other hand, in SocialCast, both the brokers and the publishers are mobile. Despite they used the mobile broker, their solution was based on a mobile ad hoc network 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 collaboration between mobile phones and SSensors which is actually a main problem in our platform.

3.2 Integrate WSNs with Internet

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

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

(29)

sensing ability and data centric operations for a physical sensor. As a result, the device diversity and complexity are hidden from the system. For better abstraction and manage-ment, a GSN container is further deﬁned. Thus, all the virtual nodes will reside and be managed in the respect GSN containers.

Although both SenseWeb and GSN used proxies as intermediary nodes connecting WSNs 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 a static device which is used to connect mobile clients. Since mobility of the proxies will cause new problems while integrating WSNs to the Internet, the solution in our platform is totallly different from theirs.

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

Priyantha et al. [55] tried to solve the scalability problem in WSNs by employing web services. To enable web services in WSNs, this paper ﬁrst adapt and optimize TCP/IP to sensor nodes. Then WSDL is employed to expose the web service descriptions. On top of TCP/IP, HTTP is used to convey the application layer messages. As a result, the work 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 and functionalities 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 RESTREST-ful principle is employed 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, an intermediate gateway is used to relay messages between WSNs and Internet.

(30)

3.3 Participatory Sensing

In 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 or even 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 personal impact on environment. In this system, all the mobile handsets are identiﬁed using their IMEI [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 processed through three stages before they can be ﬁninally used by the application. According to its deployment and experiments, PEIR reveals the vast usage of participatory sensing networks in urban and global scale.

Similar to PEIR, GreenGPS [32] is also a participatory sensing application which make use of location data. With the GPS-based navigation service, drivers could be dirceted to the 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 from the vehicle. Then, this data will be used to calibrate the fuel-efficiency prediction models which compute out the most fuel efficient routes.

PRISM [25] is not a speciﬁc application but a mobile platform which tends to enable different participatory sensing applications. In this platform, it allows applications to be packaged as executable binaries. Periodically, participatory mobile phones will report their current location and sensing abilities to the server. According to these metics, application binaries will be pushed to appropriate mobile phones automatically.

Different from PEIR and GreenGPS which are speciﬁc applications only supportting limited kinds of MSensors, our platform intends to provide generic interfaces through which 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 used by different participatory sensing applications, our platform could support SSensors which have not been covered in their work.

3.4 Sparse Sensor Network

A sparse sensor network refers to a sensor network where sensor nodes need to spreed over a large geographical area. In such a sensor network, how to provide connectivities between sensor nodes is the essential problem.

(31)

mo-bile agents called MULEs, this paper enables intermittent communication between access points 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 is more cost-effective and applicable than others. Second, since the stationary sensor node communicates 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 largely saved in this system. Besides the proposed architecture, this paper also build a discrete model 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 mules in a controlled manner. In this paper, the motion of data mules (e.g. speed and path) is preconﬁgured. Then the data on sensor nodes is pulled when data mules pass by. By claiming to support multiple data mules, this paper gives solutions on how to cooperate data 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 how to deliver Internet requests from users to remote SSenors. In addition, not only SSensors but also MSensors are supported in our platform. Comparing with [42], our platform are more 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 form a 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 control data delivery based on two parameters known as nodal delivery probability and message fault tolerance respectively.

(32)

Chapter 4 System Overview

In this chapter, we ﬁrst clarify the roles of our platform in a distributed system. Then an overview 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 reasons of selection on the publish/subscribe paradigm is explained while a system architecture in publish/subscribe context is given. At last, software architectures at different modules are presented.

4.1 System Roles

In this thesis, our platform aims to provide two general services. One is to forward queries from Internet users to capable sensors (e.g both SSensors and MSensors). Another is to collect sensing data from sensors back to the related consumers. Therefore, there are three roles in a system utilizing our platform. The ﬁrst one is the consumer. Consumers are the Internet 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 data and queries between consumers and underlying sensors. The last one is the sensor service provider. A sensor service provider is an organization or individual who use our platform to expose 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.

(33)

third-party modules will control the performing of speciﬁc sensing tasks based on the received queries. 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 the other hand, since MSensors are located on participating mobile phones, MSSP is just the provider of sensing binaries installed on those phones.

Further more, since our platform is envisioned to be used by different sensor service providers, scalability and generality must be principles taken into considerations. Espe-cially, for different SSSPs, as their deployments of SSensors may be diverse from each other (e.g. locations of deployments, types of SSensors, and distribution of SSensors), the design 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 the detail information of their deployments to others. Therefore, in this thesis, our platform is designed on the consideration that no detail information of deployments of SSensors should be depended on. Specifically, by detail information of a deployment of SSensors, we mean the information about the number of SSensors, location of each SSensor, sensing service types on a specific SSensor, and network ids of SSensors in that deployment.

4.2 Network Model

Our platform intends to provide the Internet access both to MSensors and SSensors. Since SSensors, MSensors, mobile proxy, and consumers are located in different networks, we ﬁrst represent the system architecture in a network perspective.

(34)

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 server through mobile networks (e.g. 3G or Wiﬁ). On the other hand, it connects to SSensors through the short-range radio (e.g. IEEE 802.15.4). Different from SSensors, MSensors are actually on board the mobile phones, so they do not need additional network connection to communicate with the mobile proxy. All the consumers connect to the platform server through high level Internet connections (e.g. HTTP in this thesis).

Selection between Full-IP and Hybrid Solutions

As 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 communicate with them directly in IP. In this case, the system utilizing our platform becomes a full-IP system. For a full-IP solution, its advantage is that no additional protocol conversion is needed 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 nodes employing IP. Therefore, if the full-IP solution is suitable for our platform, we could direct utilize the Coap protocol to simplize our design work. For example, in Coap, users could directly query a sensor by encapsulating their requests in an IP packet. Then, the request could be routed to the sensor through the Internet infrastructures.

However, IP is usually painful when it comes to handle mobility. In the above Coap example, difﬁcult problems will raise if we want to route the IP packet to a sensor through a mobile proxy. For instance, it is hard for the system to decide which mobile proxy should be selected as the next hop for that packet since the mobile proxy itself may have different IPs at different locations. Therefore, the advantages of full-IP solution will be overwhelmed by the difﬁculties on mobility handling.

(35)

handle the mobility problem.

4.3 Publish/Subscribe System

4.3.1 Selection of Pub/Sub Paradigm

Before designing the components in the platform, we should ﬁrst decide which distributed system paradigm should be used in this thesis. Since the mobility of mobile phones are uncontrolled in our system, persons who carry the mobile phones could move freely and encounter the SSensors opportunistically. Therefore, the end-to-end communication be-tween the platform server and SSensors are intermittent. Because of this characteristic, the communication between different components in this system should be as asynchronous as possible. As an illustration of the necessity for the asynchronous communications, let us consider that a consumer wants to query the temperature in an area A. When the platform server 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 temperature SSensors in area A could receive it. On the other hand, later on, when temperature data is generated on SSensors, it has to be ﬁrst cached on the SSensors before any mobile proxy could 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 distributed system. 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 to reﬂect their requests. As a result, the content-based publish/subscribe scheme will be used in this platform.

4.3.2 Publish/Subscribe System Architecture

(36)

Figure 4.3: A Publish/Subscribe Perspective of the System

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

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

(37)

4.4 Software Architecture

In our platform, three software modules will reside at different places. The server module is installed at broker. The software module of MB resides on the mobile phone. Another software module is installed on SSensors. In this section, we will introduce the components in each modules. At the same time, basic descriptions about their functionalities will be provided. For some detail information have not been covered here, the next chapter is a good place to refer to.

Software Architecture on Broker

The software architecture on broker is depicted in Figure 4.5. The subscriber

communica-tion handler manages communicacommunica-tions between the broker and subscribers in a centralized

way. 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 format before 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 underlying services. For each registered subscriber, the broker will create a profile to store its identity and latest IP. This information is used to keep the connection between the broker and the related subscriber. On the other hand, MBs who want to join the system also need to

reg-Figure 4.5: Software Architecture on Broker

(38)

caching and delivery of subscriptions. With the help of its component adaptive

sub-scription deliverer, Subsub-scription manager will deliver subsub-scriptions to MBs in an adaptive

manner. Another sub-component in this module is ECF generator. This sub-component is used to generate ECF (event collection ﬂag) informing the MBs how to collect events from SSensors. Target Area Manager manages target areas where the subscriptions should take effects. 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 for adaptive location updates. Similar as subscriber communication handler, MB

communica-tion handler provides an uniform communicacommunica-tion 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 controls how a MB should register at the broker. Since long-period location tracking on a MB will reveal its identity, register controller will employ a random re-registration mechanism to interrupt continous tracking. For each MB participating the system, they should update their newest location to the broker periodically. However, since location updates are an system overhead, the sub-component adaptive location updater in location manager will reduce the number of unneccessary updates by employing an adaptive algorithm. In a MB,

subscription manager is a component controlling caching and delivering of the received

subscription copies. In order to install subscriptions on SSensors, the sub-component

SSen-sor service discoverer is used to fetch information of available services from SSenSSen-sors. For

(39)

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 which third-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-value pair 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 binary module. 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 own computation and communication abilities. Therefore, to integrate SSensors into our plat-form, a seperate software module should be installed on each SSensor. The architecture of this module is depicted in Figure 4.7. On SSensors, the sensing execution modules provided SSSPs could be integrated with our platform by registering a key-value pair of

(serviceName, handler) at our service manager component. Accordingly, once receiving a

service 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 our platform, time manager component will be used to synchronize local time at a MSensor to global time at MBs. This is accomplished by encapsulating the latest global time at a MB 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 the global time in the message. Subscription manager manages all subscriptions received from MBs. It forwards subscriptions to sensing execution modules by refering to (serviceName,

handler) pairs in service manager. Due to intermittent connections between the MB and

(40)

(41)

Chapter 5 Publish/Subscribe Platform Design

5.1 Publish/Subscribe Semantics

In a publish/subscribe system, subscriptions and events are the only two kinds of messages traversing through all the distributed components. Therefore, the communication inter-faces in a pub/sub system are largely decided by the semantics of the subscriptions and the 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 related approaches are also explained.

5.1.1 Subscription Semantics

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

Subscription Semantics for Subscribers

(42)

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 of the 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 in

sensing events in a spatial context (e.g. temperatures in an area A) could use our platform seamlessly.

“temporalRange" in “SbSubscription" comprises two subﬁelds: “startTime" and “end-Time" . It is used to specify the valid period of a subscription. For example, by assigning values 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 ask the 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 setting the 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 task will be terminated automatically after the “endTime" expires. Combining the “targetArea" and “temporalRange" information, our platform could facilitate all the subscriptions in a spatial-temporal context (e.g. temperatures in an area A from 8:00am to 9:00pm today).

(43)

on how the events should be generated. However, since different sensing services may allow different constraint expressions, it is impossible for our platform to support all the potential 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 above 20 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 constraint in a format: (power level, MAC protocol name). Then a subscriber who wants to set the power 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 serser-vice providers who wants to use our platform, they should publish a specification of their service constraint formats (e.g. like in 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 these application-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 configuration services could be supported.

Subscription Semantics for MSSPs

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

Figure 5.2: Format of Subscription Message to MSSPs

(44)

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 the ﬁeld “targetArea". For MSensors, the “targetArea" information is used to check whether the subscription is still valid currently (e.g. whether the MSensor is still inside the target area of the subscription). However, since SSensors are static, the “targetArea" information become useless once the subscriptions have arrived at those sensors. Therefore, in order to reduce packet size (which is important for sensor communication), the “targetArea" ﬁeld is removed 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 to this event. The “appContent" field encapsulates the content of an event. However, since we assume that our platform should be used by third-party sensor service providers, the format of the event contents should be specified by these service providers. Similar as the “appConstraint" field in subscriptions, “appContent" only provides a tunnel convey-ing the application-specific events from sensors to subscribers. Therefore, when pulishconvey-ing their services, sensor service providers should also publish specifications on the formats of event contents. Then subscribers could parse the “appContent" field according to those specifications.

5.2 Registration

Subscriber Registration and Association

(45)

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 the profile of the related subscriber. During the communication, the broker will use the IP in the profile to maintain the Internet connection to the subscriber. This is important because the received events should be pushed to the subscribers as soon as possible. However, if the subscriber is temporarily disconnected when events received at the broker, all these events will be cached in its profile at first. Later on, subscribers could reconnect to the broker by sending “Associate" message containing their latest IP. This process is depicted in Figure 5.5.

Random Re-registration for Mobile Broker

(46)

Similar as the subscribers, the MBs also need to register at the broker. Through the registration 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 sent from a MB to the broker. Once received this message, the broker will assign and return a temporary id (TID) to that MB. At the same time, a profile “mProfile" will be created in the local memory of the broker for each registered MB. As it will be explained in the following sections, several status information of the registered MBs will be stored in the their “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 location information from MBs. Therefore, MBs participating the system will update their locations to the broker periodically. As pointed by [37], long-time location tracking of the MB may reveal the identity of the mobile phone user. Therefore, a random re-registration policy is employed to interrupt the long-time tracking. For the registration of a MB, a registration period is maintained, e.g. half an hour in current design. Whenever a registration period is expired, the MB’s “mProﬁle" in the broker will be removed and the “TID" of the MB will be recycled. On the other hand, the MB will wait for a random amount of time before registering again. The whole process of registration is depicted in Figure 5.6.

5.3 Adaptive Location Updates

Since the broker delivers subscriptions to suitable MBs based on the their locations, the MBs in the system need to update their latest locations to the broker periodically. In our platform, the constant time interval of location updates is conﬁgured by the parameter ΔCupdatein the MB module. In this thesis, the value ofΔCupdateis set to 30 seconds which means 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 mobile

phones. However, since GPS is energy-consuming, the location update will cause overhead on energy consumptions. On the other hand, location update messages sent to the broker will also cause the communication overhead. Therefore, we should try to reduce the system overhead by eliminating unnecessary location updates.

(47)

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 updates locations continuously. Therefore, most of the location updates in this situation are wasted and 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 necessity to reduce these unnecessary location updates.

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

ΔTupdate= max(ΔCupdate, ΔL

(48)

For clarity,ΔTupdateused in our platform is redeﬁned in Eq. 5.1. For the adaptive algorithm running in the MB module, ΔTupdate speciﬁes the time interval of location updates. For each MB, the value of ΔTupdate is initialized toΔCupdate. Afterwards, whenever received a location update, the broker will compute and return the latest ΔL value to the MB. As already mentioned, ΔL is the distance between the MB and a target area which is closest to the MB currently. In the broker, the target area information could be obtained from all the received subscriptions. The communication between the broker and the MB is depicted Figure 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 adaptive algorithm as a complete solution. As you may noticed, we have not specified the way to compute the value of Smaxfor each MB. Actually, a range-based mechanism is employed in our platform. The design of this mechanism is inspired by observing that the activities of the users who carry the MBs could be classified into several categories according to their speeds. For example, for ordinary users who are walking or running, their speeds will be most 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 to communicate with SSensors in the short-range radio, we further envision that users who move 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

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

Examensarbete 30 hp

June 2011

A Publish/Subscribe Platform

Supporting Mobile Brokers for

Hybrid Sensor Networks

Xiaoyu Tong

Abstract

A Publish/Subscribe Platform Supporting Mobile

Brokers for Hybrid Sensor Networks

TABLE OF CONTENTS

LIST OF TABLES

LIST OF FIGURES

Chapter 1

Introduction

1.1

Motivation and Problem Statement

1.2

Challenges

1.2.1

Distributed System Paradigm

1.2.2

Mobile Proxy Support

1.2.3

Uniﬁed Semantics

1.2.4

Internet Access to Stationary Sensors

1.3

Contributions

1.4

Thesis Structure

Chapter 2

Background

2.1

Wireless Sensor Networks

2.1.1

Sparse Sensor Network

2.1.2

IEEE 802.15.4

2.1.3

Tmote Sky

2.1.4

Contiki

2.2

Participatory Sensing

2.3

Web Service

2.3.1

REST and RESTful Web Services

2.3.2

JSON

2.4

Publish/Subscribe Paradigm

2.4.1

Topic-based publish/subscribe

2.4.2

Content-based publish/subscribe

2.5

Tools

Android Operating System

Java EE

Chapter 3

Related Work

3.1

Publish/Subscribe Systems

3.2

Integrate WSNs with Internet

3.3

Participatory Sensing

3.4

Sparse Sensor Network

Chapter 4

System Overview

4.1

System Roles

4.2

Network Model

Selection between Full-IP and Hybrid Solutions

4.3

Publish/Subscribe System