R. Baldoni R. Beraldi M. Dominici L. Querzoni

(1)

M I D L A B M i d d l e w a r e L a b o r a t o r y

http://www.dis.uniroma1.it/~midlab

M I D L A B M i d d l e w a r e L a b o r a t o r y

!

http://www.sm4all-project.eu/

R. Baldoni R. Beraldi M. Dominici L. Querzoni

Diﬀusing events through JMS on the Sun SPOT platform A practical experience report

Context

Wireless sensor networks (WSNs) are today starting to become widely adopted technology for a number of different settings and applications: from industry settings for controlling m a c h i n e b e h av i o u r t o s e c u r i t y, f r o m environmental control to vehicular applications.

Many applications built on WSNs consider nodes that must periodically sense the surrounding environment using their on-board transducers and report the sensed values or alarms (caused by abrupt changes in these values) to a central host that will act accordingly. This event-based interaction between the nodes and the central host is typical of publish/subscribe applications. In this poster we report our initial experiences developed while porting an open source Java Messaging System (JMS) implementation (JORAM) on the Sun SPOT platform.

The SM4All Project

Salient characteristics of such middleware are the dynamicity of its components, its tolerance to faults and rapid scaling of the network, while maintaining security requirements fulfilled and operating on embedded devices with limited resources in terms of power consumption and memory usage.

This work was mainly motivated by activities the authors are undertaking within the Smart Homes 4 All (SM4All) project. Goal of the project is the design and implementation of an innovative middleware platform for interworking of smart embedded services in domotic environments, through the use of composability and semantic techniques for dynamic service reconfiguration.

As the middleware should be broadly deployable, keeping down the overall costs of the solution is an objective of the project. From this point of view, both the JMS standard and the Sun SPOT platform are in principle good candidates for integration inside the future SM4All architecture. Scope of this work is thus to explore the possibilities of the integration between these two technologies and their current limits.

!

Setup

We deployed a very primitive testing platform constituted by a single Sun SPOT equipped with light and temperature sensors, running an application whose only purpose was to publish events. A SPOT base station connected via USB to a PC was used to receive events published by the sensor. The events, still encapsulated in SOAP messages are then delivered via USB to the SOAP proxy running on the PC. The proxy decapsulate the event and deliver it to the JORAM server that can then handle it.

38 CHAPTER 2. EVENT DISTRIBUTION IN WSNS

Fig. 2.9: Sun SPOT

wireless channel

SOAP message event Sun SPOT

sensor Sun SPOT

base station

USB PC

Tomcat container

JORAM server SOAP

Proxy

Experiments

Test 1: the SPOT publishes 100 (1 message every 6 seconds) messages with dummy content; no data is read from the on-board transducers. The left graph shows how the energy consumption remains quite stable during the whole experiments. The battery lifespan of a SPOT running this test is about 10 hours and 30 minutes. The right graph shows the runtime memory allocation of the SPOT JVM during the test execution.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Battery consumption (mAh)

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Memory usage (MBytes)

Titolo

Figure 2: (Test 1) the sensor publishes 100 dummy messages and sends them to the server.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Memory usage (KBytes)

Time (sec)

Figure 3: (Test 2) the sensor publishes 100 dummy messages but does not send any message.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

memory usage (KBytes)

Time (sec)

Figure 4: (Test 3) the sensor periodically reads the temperature and publishes the value.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 5: (Test 4) the sensor periodically check if the light amount has incremented over a predefined threshold.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 6: (Test 5) same as before but no message is sent.

Test 2: the SPOT executes exactly the same code used in test 1 but does not send any message. The main goal of this test was to check how much energy is drained by the radio stack during message transmission.

The left graph shows a sever cut in energy consumption with respect to the previous experiment: this test could run for about 15 hours and 45 minutes before exhausting the SPOT power reserves.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Titolo

Figure 2: (Test 1) the sensor publishes 100 dummy messages and sends them to the server.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Time (sec)

Figure 3: (Test 2) the sensor publishes 100 dummy messages but does not send any message.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Time (sec)

Figure 4: (Test 3) the sensor periodically reads the temperature and publishes the value.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 5: (Test 4) the sensor periodically check if the light amount has incremented over a predefined threshold.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 6: (Test 5) same as before but no message is sent.

Test 3: the SPOT publishes 100 (1 message every 6 seconds) messages containing the current room temperature obtained through the onboard transducer. This test was designed to recreate a typical scenario for a WSN application. Both graphs show how reading values from the onboard sensors has a negligible impact on the overall energy consumption whose value is dominated by energy drained by the radio stack. The memory allocation behaviour appears unchanged with respect to Test 1.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Titolo

Figure 2: (Test 1) the sensor publishes 100 dummy messages and sends them to the server.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Time (sec)

Figure 3: (Test 2) the sensor publishes 100 dummy messages but does not send any message.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Time (sec)

Figure 4: (Test 3) the sensor periodically reads the temperature and publishes the value.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 5: (Test 4) the sensor periodically check if the light amount has incremented over a predefined threshold.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 6: (Test 5) same as before but no message is sent.

Test 4: the SPOT checks light intensity every 10 minutes (over 8 hours) and publishes a message if the variation with respect to the previous value exceeds a predefined threshold. Between two consecutive reads the SPOT is put in deep-sleep mode; this operation mode has a strong positive impact on energy consumption (the test could last 13 days).

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Titolo

Figure 2: (Test 1) the sensor publishes 100 dummy messages and sends them to the server.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Time (sec)

Figure 3: (Test 2) the sensor publishes 100 dummy messages but does not send any message.

0,08 0,09 0,10 0,11 0,12 0,13 0,14 0,15 0,16

0 100 200 300 400 500 600 700

Time (sec)

0 50 100 150 200 250 300 350 400 450 500

0 100 200 300 400 500 600 700

Time (sec)

Figure 4: (Test 3) the sensor periodically reads the temperature and publishes the value.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)

Figure 5: (Test 4) the sensor periodically check if the light amount has incremented over a predefined threshold.

0,01 0,03 0,05 0,07 0,09 0,11 0,13 0,15

0 50 100 150 200 250 300 350 400 450 500

Time (min)

0 50 100 150 200 250 300 350 400 450 500

Time (min)