8/2/2019 Bartel En

1/4

A Middleware Pattern to Support Complex Sensor NetworkApplications

Bart Elen, Sam Michiels, Wouter Joosen, Pierre VerbaetenIBBT-DistriNet, Department of Computer Science, K.U.LeuvenCelestijnenlaan 200A

B-3001 Leuven, Belgium

bart.elen@cs.kuleuven.be

ABSTRACTMost current sensor middleware solutions focus on deliveringa particular subset of typical middleware services. Becauseof this, they only meet the requirements of a, rather lim-ited, set of applications. It is reasonable to expect that awide variety of applications will be deployed in an indus-trial WSN (Wireless Sensor Network) environment (e.g. ina harbor that handles container transport). To support suchheterogeneous applications, general purpose middleware so-lutions are needed. We propose a hierarchical layered mid-dleware pattern to handle this heterogeneity. This middle-ware pattern combines three recurring themes: applicationmanagement, data management and network service man-agement. These themes were identified by studying state-of-the-art middleware solutions and generalizing common as-pects. Combining these three themes allows constructing amiddleware which is more general purpose. This makes ituseful for a wide variety of heterogeneous applications thatwill be used in complex WSN environments.

Categories and Subject Descriptors

D.2.11 [Software Engineering]: Software Architectures;C.2.4 [Computer-Communication Networks]: DistributedSystems

KeywordsWireless sensor networks, middleware, architectures, pat-terns

1. INTRODUCTIONWSNs are currently used for monitoring active volcanos[11], remote health care [1], structural health monitoring[2], and other applications. Due to the considerable chal-lenges WSNs are facing (highly limited resources, hardwareand network heterogeneity, need for self-repairing, etc.) [4]

application developers need middleware support to facilitatesensor programming. A wide variety of middleware solutions[8, 3, 5, 6, 10, 9, 7] have been proposed to fulfill this need.

In our opinion, sensor programming will evolve from fixed,single purpose (single application) WSNs, to more complexWSN environments. We are participating in the MultiTr@nsproject1, in which WSNs are used in a multimodal trans-portation context. Sensor nodes installed inside containers,will here become part of heterogeneous WSNs at differentlocations (ports, trains, boats, trucks, depots, etc.). A widevariety of applications will run on the WSNs to meet theneeds of customers, harbor management, security person-nel, customs authorities, etc.

This context does impose new requirements on the used mid-dleware. First of all, it will no longer be feasible to use aspecific middleware for each WSN application. A more gen-eral purpose middleware solution is needed which offers allneeded services to the applications that will be running onthese WSNs. This evolution is schematically illustrated inFigure 1. Multiple applications make use of the same servicecomponents, making it possible to save resources on the sen-sor nodes. Secondly, sensor middleware must deal with theevolution and heterogeneity of used technologies on differentWSNs. Both the network protocols and the application on

the WSNs continuously evolve. In addition, they may differfrom one WSN to another because of differences in networkproperties (size, available infrastructure, node mobility, etc.)as well as local user requirements. A static middleware cannot deal with this evolution and heterogeneity. Dynamicmiddleware is needed, which is able to adapt its services tothe network and application environment.

Based on a survey on sensor middleware, we will show thatmost current WSN middlewares focus on a subset of thefollowing three themes: application management, data man-agement and network service management. By consequence,these middlewares only deliver a limited set of services andare unable to support a wide variety of applications.

We argue that complete middleware solutions are neededwhich combine the application management, data manage-ment and network service management themes. The maincontributions of this paper are (1) identification of three re-curring themes in the existing middleware solutions, and (2)the proposal of a new middleware pattern that is able to sup-port a wide variety of WSN applications by combining thesethree themes in one hierarchical middleware architecture.

1https://projects.ibbt.be/multitrans

8/2/2019 Bartel En

2/4

Figure 1: Middleware offering services

The remainder of this paper is structured as follows. In sec-tion 2, we give an overview of the services offered by thestate-of-the-art sensor middlewares. With the help of a sur-vey we will demonstrate that most middlewares focus on asubset of the three proposed middleware themes, and iden-tify their main shortcomings. In section 3, we propose a newhierarchical middleware pattern which is able to support ap-plications in complex sensor network environments. Section4 presents conclusions and sketches future work.

2. EXISTING MIDDLEWARESSoftware developers for WSNs have to deal with challengessuch as managing the limited amount of resources, the needfor self-repairing, and environment heterogeneity [4]. Mid-dleware support is needed to help application developers tohandle these challenges. A wide variety of middlewares for

WSNs have been constructed to meet this need for support.

Based on an extensive study on sensor middleware, we claimthat sensor middleware services can be partitioned accord-ing to three themes: application management, data manage-ment, and network service management. We evaluate exist-ing sensor middlewares on the presence of following mainservices for each theme:

Application management theme:

Program global behavior: It should be possi-ble to program the global behavior of WSNs in-stead of individual nodes. The middleware has to

transform the WSN application into distributedtasks which can be executed on individual sensornodes.

Application scheduling: Assign resources tothe application. To make this possible the mid-dleware first has to determine the application re-source requirements and the availability of resourceson the WSN.

Application deployment: Dynamically deploythe application over the air on the WSN.

Data management theme:

Local data storage: Local data storage is neededfor information that needs to migrate with thesensor node (e.g. a sensor node in a containertraveling from one sensor network to another).

Sensor support: The middleware should sam-ple the best fitted sensors to deliver the applica-tion his needed data. If QoS requirements of theapplication allow it, the middleware must save

energy by lowering the sample rate and by select-ing less precise, but also less energy consumingsensors.

Remote data service: The middleware shouldoffer data on the WSN. This allows remote nodesto request data from the sensor node.

Network service management theme:

Offer network services: The middleware shouldoffer the applications an extensible set of networkservices.

Customize network services: The middlewareshould be able to customize the network service

implementations on the node to both, service re-quirements of the applications and the changinglocal network properties.

Support sensor migration: The middlewareshould make it possible for sensor nodes to mi-grate from one sensor network to another. Theneeded middleware support includes detecting thepresence of reachable WSNs, selecting the best fit-ted WSN to join, authentication of WSNs, join-ing WSNs, participating in the local sensor net-work applications and detecting the sensor net-work border. Further should the middleware alsobe able to authenticate sensor nodes that want to

join the WSN, accept or reject them and to detect

when a node or group of nodes is leaving a sensornetwork.

Figure 2 summarizes our survey and gives an overview ofthe main services offered by the current sensor middlewares.In this figure, a + identifies a supported service, while a -means that the service is partially supported. For each mid-dleware have we identified the theme of focus and markedit gray. We identify three reasons why current sensor mid-dlewares are not suited for complex sensor network environ-ments:

1. None of the current middlewares is offering the com-plete set of required services. This involves that foreach application the appropriate middleware must beselected. When multiple applications are executed onthe same sensor node, this may require the usage ofmultiple middlewares to offer support to all applica-tions. The usage of multiple middlewares implies aconsiderable increase of used resources.

2. Only TinyCubus [9] and Impala [7] are able to adaptthe used network service implementations towards thecurrent network and application environment of thesensor node.

8/2/2019 Bartel En

3/4

Figure 2: Overview of sensor middlewares and of-

fered services

Figure 3: Hierarchical middleware pattern

3. There are still missing parts in the sensor middlewareresearch. An example is the lack of middleware sup-port for the migration of sensor nodes to other sensornetworks.

3. NEW MIDDLEWARE PATTERNIn this section we propose a new middleware pattern whichprovides application developers the necessary support forcomplex application contexts. As already mentioned in theprevious section, this middleware pattern distinguishes itselffrom the current middlewares by (1) offering a complete setof services and (2) adapting the network services on the nodeto its current environment. One reason why complete mid-dleware solutions are missing may be its high complexity.It would require expertise in both application management,data management, network service management, energy us-age, security, and other domains. Not many are specializedin all these domains. A more easy to realize approach iscomposing a middleware by using the know-how of multiplegroups. It should be possible to combine multiple special-

ized middleware components to create one, more generalpurpose, middleware.

To meet this objective, our middleware pattern consists of ahierarchical architecture consisting of three middleware lay-ers, where each layer makes use of the services offered bythe layer below. Coherence of components is high withineach layer, while coherence between layers should stay lim-ited. Figure 3 shows an overview of this middleware pattern.Each layer contains a number of components which imple-ment a service of the layer. By implementing services inseparate components, it will be easier to replace and reusethem. We now zoom in at each layer.

3.1 ApplicationsWe define sensor network applications as the software thatis responsible for three concerns: (1) describing when (e.g.each 5 minutes), and where (e.g. in each container) whichdata (e.g. the temperature) needs to be collected, (2) inter-preting the collected data (e.g. a temperature higher then50 degrees requires special attention), and (3) reacting onit (e.g. send warning to maintenance personnel). WSNapplications can be run on a central application server ordistributed on the sensor nodes. In the former case the ap-plication will not run on the sensor nodes, but makes use ofthe data management service offered by the WSN.

8/2/2019 Bartel En

4/4

3.2 Application management layerThe application management layer is responsible for parti-tioning the sensor network applications into separate tasks,assigning sensor network resources to these tasks and dis-tributing the tasks over the sensor network. Most of itslayer implementation will not be on the sensor nodes but onthe application deployment server of the sensor network.

3.3 Data management layerThe data management layer is responsible for offering, gath-ering, and storing data. The local and remote applicationsindicate their information needs to the data managementlayer. This layer gathers the needed data by sampling thelocal sensors and by cooperating with other sensor nodesin the neighborhood. Further the data management layercan save energy by allowing multiple applications to benefitfrom the same sensor readings.

3.4 Network service management layerThe network service management layer offers a wide varietyof network services (routing, data aggregation, distributedposition determination, time synchronization, etc.) to the

upper layers. This layer is the only network and applicationdependent middleware part. It deals with both the sensornetwork and application heterogeneity. The network servicemanagement component realizes this by adapting the net-work service implementations towards the local sensor net-work properties, the local infrastructure availability, and theservice requirements of the applications. Further the net-work layer gives all support needed for joining and leavingthe sensor network (detecting WSNs, authenticating WSNs,detecting WSN borders, etc.). The services in the middle-ware need to be placed in separate, replaceable componentsto make it feasible to replace them.

3.5 InterfacesAs already mentioned, most existing middleware solutionsfocus on a single theme. This makes it possible to com-bine middleware solutions with different themes to constructmiddlewares able to meet the requirements of a wide varietyof applications. The usage of standardized interfaces is hererequired. For each layer should be specified which servicesthe layer offers and how their interfaces look like.

4. CONCLUSIONS AND FUTURE WORKThis paper identifies three recurring sensor middleware themesbased on a survey of state-of-the-art sensor middleware andit proposes a new layered middleware pattern that combinesthe three identified themes necessary to deliver the neededapplication, data and network service management support.This pattern should make it possible to combine middlewaresolutions to form one, more general purpose, middleware.

The proposed middleware pattern offers four advantagescompared to most current middleware solutions: First, re-sources are saved since only a single middleware solution isneeded for all applications. Multiple applications can herebenefit from the same service components. Secondly, themiddleware is able to adapt the used network service im-plementations towards the current network and applicationenvironment. Thirdly, it allows integrating different exper-tises by combining middleware layers. Fourthly, code reuse

is supported by implementing each middleware service in aseparate component.

Concerning future work, we will refine the middleware pat-tern in an industrial case study on multimodal containertransport. We have to complete the services offered by eachlayer and standardize their interfaces. Further we will builda proof-of-concept prototype of our middleware pattern.

5. REFERENCES[1] http://www.hoise.com/vmw/05/articles/vmw/lv-vm-

04-05-39.html.

[2] K. Chintalapudi, J. Paek, N. Kothari, S. Rangwala,J. Caffrey, R. Govindan, E. Johnson, and S. Masri.Monitoring Civil Structures with a Wireless SensorNetwork . IEEE Internet Computing, March/April2006.

[3] R. Gummadi, O. Gnawali, and R. Govindan.Macro-programming wireless sensor networks usingkairos. In DCOSS, pages 126140, 2005.

[4] S. Hadim and N. Mohamed. Middleware: Middlewarechallenges and approaches for wireless sensornetworks. IEEE Distributed Systems Online, 7(3),2006.

[5] W. B. Heinzelman, A. L. Murphy, H. S. Carvalho, andM. A. Perillo. Middleware to support sensor networkapplications. IEEE Network, 18(1):614, 2004.

[6] P. Levis and D. Culler. Mate: a tiny virtual machinefor sensor networks. In ASPLOS-X: Proceedings of the10th international conference on Architectural support

for programming languages and operating systems,pages 8595, New York, NY, USA, 2002. ACM Press.

[7] T. Liu and M. Martonosi. Impala: a middlewaresystem for managing autonomic, parallel sensorsystems. In PPoPP 03: Proceedings of the ninth ACMSIGPLAN symposium on Principles and practice ofparallel programming, pages 107118, New York, NY,USA, 2003. ACM Press.

[8] S. Madden, M. J. Franklin, J. M. Hellerstein, andW. Hong. Tinydb: an acquisitional query processingsystem for sensor networks. ACM Trans. DatabaseSyst., 30(1):122173, 2005.

[9] P. J. Marron, A. Lachenmann, D. Minder, J. Hahner,R. Sauter, and K. Rothermel. TinyCubus: A flexibleand adaptive framework for sensor networks. In

Proceedings of the Second European Workshop onWireless Sensor Networks (EWSN 2005), pages278289, January 2005.

[10] M. Welsh and G. Mainland. Programming sensornetworks using abstract regions. In NSDI, pages2942, 2004.

[11] G. Werner-Allen, K. Lorincz, M. Welsh, O. Marcillo,J. Johnson, M. Ruiz, and J. Lees. Deploying a wirelesssensor network on an active volcano. IEEE InternetComputing, 10(2):1825, 2006.