Opportunistic computing for wireless sensor networks

Opportunistic computing for wireless sensor networks ∗ Marco Avvenuti, Paolo Corsini, Paolo Masci and Alessio Vecchio Dip. di Ingegneria dell’Informazione, Università di Pisa Via Diotisalvi 2, I-56122 Pisa, Italy {firstname.lastname}@ing.unipi.it

Abstract Wireless sensor networks are moving from academia to real world scenarios. This will involve, in the near future, the design and production of hardware platforms characterized by low-cost and small form factor. As a consequence, the amount of resources available on a single node, i.e. computing power, storage, and energy, will be even more constrained than today. This paper faces the problem of storing and executing an application that exceeds the memory resources available on a single node. The proposed solution is based on the idea of partitioning the application code into a number of opportunistically cooperating modules. Each node contributes to the execution of the original application by running a subset of the application tasks and providing service to the neighboring nodes.

1 Introduction and motivation Wireless sensor networks (WSNs) are massively distributed networks that do not require any external infrastructure and are typically used to monitor a physical phenomenon. Sensor network applications can play a key role in many different areas, such as intrusion detection and surveillance, wildlife monitoring, precision agriculture and building monitoring. The physical proximity of sensors to the observed phenomenon and the programmability of nodes can increase the level of accuracy and adaptability of the sensing process with respect to traditional solutions [1]. The number of nodes in a sensor network can be quite large, in the order of hundreds or even thousands elements. Also, depending on the application and on the operating area, nodes can be either randomly deployed or manually positioned. In any case, they have to run for long periods unattended. The cost of nodes must be kept as low as possible, they must be energy efficient, and their size must be ∗ This work is partially supported by Fondazione Cassa di Risparmio di Pisa, Italy (SensorNet Project).

c 1-4244-1455-5/07/$25.00 2007 IEEE

small. Because of all these constraints, hardware resources of nodes are extremely limited. In the last few years several hardware platforms, with similar characteristics, have been designed and put into production to enable the development of WSN applications. Examples include Mica and Mica2, produced by Crossbow, and Telos, produced by Moteiv. All these systems have been used as the hardware base in a large number of research projects, especially in the area of software systems. Generally, the amount of program memory that is available on a single node ranges from 48 to 128 KBytes. It should be noted that, since these kinds of systems have been designed and manufactured to be used in research projects, both the form factor and production costs are not adequate for their adoption in real ubiquitous computing scenarios. A massive adoption of WSNs requires to reduce the size and cost of nodes by an order of magnitude. Obviously, this also implies a significant reduction of the computing and storage capabilities of nodes. This trend is confirmed by the advent of alternative platforms such as Spec [5], an experimental node architecture designed at Berkeley. Spec is a prototype of “mote on a chip”: microcontroller, wireless radio transceiver, and analog-to-digital converter are packed all together on a single die of a cubic millimeter. Only few external passive components are necessary. In order to optimize the power consumption, Spec uses dedicated hardware accelerators for low level primitives. The total amount of memory available for both data and programs is 3KBytes. It is commonly accepted that, because of the lack of resources, classical strategies for computing and communication cannot be applied to the world of WSNs. This pushed the definition of new paradigms, such as opportunistic networking and computing. With opportunistic networking, routing and forwarding schemes are designed to benefit from the randomness and uncertainty of the network topology. The basic idea behind opportunistic networking is that two nodes may be able to communicate even if a completely connected path never exists between them. Communication is generally obtained

through extensive buffering of messages at intermediate nodes, waiting for the chance to get closer to the destination. Opportunistic networking has been successfully used to extend the capacity of the wireless channel beyond the classical theoretical limit [4] and to enhance network coding and outperform traditional routing schemes [7]. Readers interested in a more comprehensive list of works and projects related to opportunistic networking are redirected to [12]. With opportunistic computing, the execution of applications is supported by spare computational resources available somewhere in the network. No assumption is made on the availability and on the position of such resources. Currently, opportunistic computing is mainly applied in wired networks to facilitate the construction of grid-based applications. In WSNs, research related to opportunistic computing is in the early stages. In this paper we discuss the adoption of the opportunistic computing paradigm to overcome the problem of executing applications when the size of programs is larger than the amount of memory available on a single node. We propose a technique based on the idea of dividing the application into smaller and cooperating code fragments. Each fragment of the application fits the resources available on a single node, and an opportunistic cooperation between nodes – either on the path to the base station or within a given region – produces the global computation.

2 Opportunistic computing for WSNs Programs for wireless sensor networks are specialized for the particular scenario of operation. Formerly, programs were developed in low-level languages, but in the last few years Java- and C-like languages gained popularity. The use of high-level languages gave an impulse to the production of programs with modular structure, where modules represent both parts of the application logic and services of the operating system. Moreover, they stimulated the implementation of large libraries that can be accessed by developers to pick up modules and generate new programs with reduced effort. From the point of view of programs, WSNs are usually homogeneous, i.e. all nodes execute the same code. Also, because of the special target of WSNs, programs usually reveal a recurring execution pattern: they basically perform a loop i) to gather values from the sensing equipment, ii) to elaborate such data, iii) to send results to the base station. Values obtained from the sensing equipment represent the main input stream of the application level. Elaboration of local data is usually carried out to reduce the amount of information transmitted by the wireless radio transceiver, and thus to save energy (e.g. data can be compressed, or events signaled only when detected). Transmissions towards the base-station are performed with the cooperation of other

get samples from the sensing equipment


SENSING MODULE

SENSING MODULE


SENSING MODULE

COMPUTATION MODULE

COMPUTATION MODULE

COMPUTATION MODULE

task A

task A

task A

task B

task B

task B

NETWORK MODULE

send results towards the base station

NODE 1

NETWORK MODULE


NETWORK MODULE

NODE 2


NODE 3

(a) Computing on a single node get samples from the sensing equipment

task A

NODE 1

task B

NETWORK

NETWORK

NETWORK MODULE

COMPUTATION MODULE

COMPUTATION MODULE

SENSING MODULE


MODULE


NODE 2

MODULE


NODE 3

(b) Opportunistic computing on a pool of nodes

Figure 1. Application decomposition

nodes (multihop communication) because of the limited radio range. Proposed idea: The sequence of operations carried out on a single node during the execution of the original program, can be replaced by the opportunistic and distributed execution of tasks on a set of nodes (see Figure 1). The modular architecture and recurring schemes of execution of WSN applications ease the decomposition of a single large program into a set of smaller programs. Specialization of nodes, that execute just a part of the original program, acts as a workaround to the limits imposed by the scarce availability of memory. A side effect of distributed execution is the necessity of coordination between involved nodes, with associated costs in terms of both algorithms and communication. In the following we discuss some simple forms of opportunistic computing and we report a preliminary evaluation of the approach, that shows that a complete and efficient execution of the original program may be achieved. This can be obtained, in WSNs, by exploiting the large number of nodes and connections available.

2.1 Application scenarios

In this section we discuss the adoption of opportunistic computing applied to two typical application scenarios.

Base Station

A A

A A A

sion is thus performed opportunistically when a compressor node is encountered along the path from the source to the base station. 2.1.2 Opportunistic computing within geographical regions

A A A A

A A A

(a) Without compression Base Station

A B

A A A

B B A A

A B A

(b) With opportunistic compression

Figure 2. Opportunistic compression along the path to the base station (A: sensing nodes, B: compressor nodes)

2.1.1 Opportunistic computing along the path to the base station Let us consider a WSN where each node periodically senses the environment, stores sampled data in local memory, and, after having collected a given number of values, sends them towards the base station. To decrease the amount of energy used for communication, nodes compress the payload of packets before injecting them into the network. If the program that performs all these operations cannot be stored in the nodes’ program memory, the application can be split into two parts: one that performs the basic application cycle, i.e. data acquisition and packet transmission/forwarding, and another one that performs compression of data and packet forwarding. The network is now composed of two types of nodes (see Figure 2): sensing nodes, that execute the basic application cycle, and compressor nodes, that wait for incoming packets, compress them, and forward them towards the base station. When a sensing node has acquired enough values, it sends the packet to the node that is the next-hop towards the base station. If the node that receives the packet is a compressor, the packet gets compressed and forwarded to the base station. Otherwise, the packet is just forwarded. Packet compres-

Opportunistic computing can be useful not only when data travels from the source node to the base station, but also within a given geographical region (e.g. a node and its neighbours). Let us consider an event detection application, where nodes collect a number of samples from the analog-todigital converter, and then analyse such data in order to detect events. In WSNs, detection of interesting events should be performed without the aid of the base station, not only to reduce the energy consumption, but also to obtain a prompt response [8]. Nevertheless, the identification of interesting events may require a complex data analysis (e.g., a transformation into the frequency-domain to detect the seismic activity in a volcano [13]). Let us consider an application that periodically acquires environmental data, stores n samples, and performs an analysis over such values to take proper actions when interesting events are detected. If the entire application exceeds the resources available on a single node, the application can be split into two parts: one that collects data and reacts on event detection, the other that performs the complex analysis on-demand. Also in this case there are two different kinds of nodes in the network: sensing nodes and analyzer nodes. Whenever a sensing node has collected n values, it looks for an analyzer node within its neighbour set. If an analyzer node is available, then the analysis can be performed locally, without sending packets to the base station via a multihop path.

2.2 Evaluation We implemented a prototype of the applications presented above. The applications were written in nesC [3], for the TinyOS [6] operating system. The execution of the prototype applications was simulated in TOSSim [9], the simulator bundled with the TinyOS distribution. Compressing packets along the path to the base station. The aim of the experiment is to collect information on the number of compressed and uncompressed packets for different percentages of compressor nodes. In the considered scenario, the network comprises 256 nodes randomly placed. The routing protocol is based on a distance-vector algorithm that selects the route with minimum hop-count. The amount of traffic generated by sensing nodes does not saturate the network capacity. Figure 3 shows the percentage of compressed packets against the percentage of compressor nodes. It can be noted

Number of compressed packets (%)

100

80

60

40

20

0 10

15

20

25

30

35

40

45

50

Number of compressor nodes (%)

Figure 3. Percentage of compressed packets

Reduction of the average distance (%)

100

sensing and analyser nodes and, whenever a sensing node has collected enough values, it looks for an analyzer node within its neighbour set. If such a node is found, then data is analyzed locally, otherwise it is forwarded towards the base station. We measured, for the two versions of the application, the average number of hops that have to be traversed to deliver a data packet to the node that performs the analysis. In the considered scenario, the network comprises 256 sensing nodes randomly positioned, plus a percentage of analyser nodes. Routing is based on a distance-vector algorithm that selects routes with minimum hop-count. Analyser nodes do not participate to the routing of packets. Figure 4 shows the reduction of the average distance achieved with opportunistic computing. Also in this case the obtained benefits are significant: even when adding a small number of analyser nodes (∼ 20%), the average number of hops that are traversed by packets that need to be analysed is reduced in average by 60%.

80

3 Adaptive opportunistic computing 60

40

20

0 10

15

20

25

30

35

40

45

50

Number of analyzer nodes (%)

Figure 4. Reduction of the average distance between sensing nodes and analyzer nodes with opportunistic computing

that, even when using a small fraction of compressor nodes (∼ 25%), nearly half of the routed packets get compressed. We performed similar experiments with networks of different size (64 and 128 nodes) obtaining coherent results. Analyzing data within geographical regions. The aim of the experiment is to evaluate the effects of opportunistic computing when the available program memory does not permit to include the code responsible for both sensing and analysing data within a single node. We compared the performance of two versions of the same application. The first version is not based on opportunistic computing and requires the intervention of the base station to analyse the data (i.e. the network is entirely composed of sensing nodes, and data packets are routed to the base station where they get analyzed to reveal events). The second version makes use of opportunistic computing: the network is composed of both

As shown by the experiments described in the previous section, the performance of the global application depends on the percentages of nodes that run the different code fragments. However, choosing the number of nodes that have to execute a given function is usually difficult: the behavior of WSN applications depends on many factors, such as size of the network, topology, traffic pattern, etc. A simple solution, to increase the availability of a given module, consists of adding new nodes after the WSN has already been installed in the field. For example, in the scenario related to the compression of data packets, new compressor nodes could be added to increase the compression rate up to the desired level. Nevertheless, to ease the adoption of the opportunistic computing model, the network should be able to dynamically adapt the amount of nodes that run a given fragment, in order to maximize the performance of the system. Code mobility can be useful to enable network reprogramming at a local scale: by moving/copying a code fragment from node to node, it is possible to increase the availability of a given functionality within the network. Some platforms, such as Spec, natively provide support for network reprogramming through a specially designed memory system that dynamically maps page frames into any part of program or data memory. With such mechanism, programs can be transferred over the wireless channel and stored into data memory. Then, the program can be mapped into the program memory in few CPU cycles without the need of copying the code. This drastically decreases the amount of resources needed to implement code mobility/replication.

Node 1

Node 1

A

A

Node 2

A Node 5

Node 2

A Node 5

Node 3

A

B

A

Node 2

A

A

Node 5 Node 3

A

Node 1

Node 3

A A

B B

Node 4

Node 4

A

Node 4

A

B Node 8

A

A Node 6

A Node 6

Node 6 A

Request

Code downloading

Request

A

Node 7

Reply

Reply

(a) Initial

(b) Role changing

(c) Final

Figure 5. Load-balancing of energy consumption

3.1 Balancing of energy consumption Let us suppose that a region of the network contains a set of nodes that execute application tasks A and B, as shown in Figure 5(a) (for the sake of simplicity the discussion is limited to two different application modules, but it can be easily extended to the case where the application is partitioned in a larger number of modules). Node 3 is the only one that executes task B, and provides service to all its neighbors (e.g., event detection through analysis of the data provided by the other nodes). Under these assumptions it may happen that node 3 runs out of energy before its neighbors, because it has to serve all their requests. To keep stable the number of nodes that execute task B, and thus prolonging the lifetime of the entire application, nodes could change their roles during runtime. This would introduce a simple form of load balancing in terms of energy consumption. Sometimes direct swapping of roles can be unfeasible because of the limited memory available. For example, if node 4 has to take the role of node 3, it downloads the code of task B from node 3 and overwrites its current code. Thus, node 3 cannot download from node 4 the code related to task A. However, this problem can be solved through the intervention of other nodes. For example, Node 3 can download the code concerning its new role from another neighbor, such as node 1 (Figure 5(b)). As shown in Figure 5(c), node 4 provides service to a different set of nodes, with respect to node 3. However, if this process is carried out all over the network, then the performance of the global application can be unaffected.

4 Related work A technique that can be used in a middleware layer to support opportunistic pervasive computing applications for

WSNs is presented in [2]. The technique is based on the use of domain-oriented virtual machines that expose sensor and actuator resources to the programmer. Virtual machines are node-specific, to reflect the specific sensors and actuators available on a given node. The proposed architecture pushes the development of opportunistic applications as collections of cooperating and communicating mobile agents (executed by the virtual machines). Agents are implemented as a set of event handlers that are executed in response to events. This limits the complexity of the execution layer and makes agents compliant with the event-based programming model of WSNs. Our approach shares with this solution the purpose of supporting the execution of opportunistic pervasive computing applications, i.e. to take the best advantage of resources that happen to be available in the network. However, while we deal with the problem of running applications on homogeneous and limited hardware, the system described in [2] defines an ontology and runtime support that are useful when the network includes sensors and actuators of different nature. In [11] the authors argue that sensor networks should be programmed at global scale: proper tools should shield the developer from low-level details of resource management, concurrency and in-network processing. In particular, the authors designed a functional macroprogramming language, called Regiment, that can be used to provide a high-level specification of the network behavior. Then the specification is automatically translated into node-level programs. The essential abstraction in Regiment is the region stream, a spatially distributed, time-varying collection of node states. By using region streams, the programmer can identify a set of nodes characterized by some geographical or logical properties, such as the nodes located in the nearby of a specific anchor node. This “macro”-approach operates at a different level with respect to our technique: with re-

gion streams, the programmer defines the behavior of the network, while we strive to demonstrate that the code that should be executed on a single node can be decomposed and opportunistically executed. The problem of resource allocation in a WSN has been faced through techniques based on market-regulated selforganization [10]. Nodes are programmed to behave as selfinterested agents that try to maximize their revenue, and every action that contributes to the global goal of the network results in a payment to the node taking the action (these actions include basic tasks such as listening for incoming radio messages or reading a value from a sensor). By setting the revenue associated to every action, the programmer can tune the behavior of the whole WSN. The authors also discuss the use of heterogeneous budgets and prices for actions as a way to specialize the behavior of some nodes, e.g. to push them to take certain actions. For example, a fraction of nodes could be configured to act as routers by setting the reward to 0 for all actions with the exception of listening, aggregating, and sending. Similarly, other nodes could be pushed to act as sensors by giving them a high reward for actions related to data acquisition and sending. Whatever is the level of the programming abstractions, in the existing literature it is silently assumed that the application code fits the resources of the nodes. Our goal was to remove such assumption, and face the problem of executing programs that exceed the available memory.

5 Further work and conclusions In this paper we proposed the adoption of the opportunistic computing paradigm to face the problem of storing and executing an application that exceeds the resources available on a single node. The application code can be partitioned in a number of simple modules that opportunistically cooperate to carry out a complex task. Depending on the scenario, different kinds of cooperation can be envisioned. In some cases, execution relies on the probability of finding a node that implements the next step of the computation while data moves, along the routing tree, towards the base station. In other cases, a node may ask its neighbors for the available services. The described scenarios were based on randomlygenerated topologies. Future work will investigate the relationships between the topology of the network and positioning strategies of application modules. For example, if the topology of the network is predetermined, e.g. because it is imposed by some environmental requirements, specific positioning schemes could be able to maximize the performance of the global application. Another possibility under evaluation is the use of mobile nodes to bring computational resources within the network.

References [1] I. Akyldiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. Wireless sensor network: a survey. Computer Networks, 38:393–422, 2002. [2] J. Domaszewicz, M. Roj, and A. Pruszkowski. Opportunistic pervasive computing with domain-oriented virtual machines. In Proceedings of the 9th EUROMICRO Conference on Digital System Design, pages 598–605, Washington, DC, USA, 2006. IEEE Computer Society. [3] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The nesC language: a holistic approach to networked embedded systems. SIGPLAN Notices, 38(5):1–11, 2003. [4] M. Grossglauser and D. N. C. Tse. Mobility increases the capacity of ad hoc wireless networks. Networking, IEEE/ACM Transactions on, 10(4):477–486, 2002. [5] J. Hill, M. Horton, R. Kling, and L. Krishnamurthy. The platforms enabling wireless sensor networks. Communcations of the ACM, 47(6):41–46, 2004. [6] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for networked sensors. SIGPLAN Notices, 35(11):93–104, 2000. [7] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Médard, and J. Crowcroft. Xors in the air: practical wireless network coding. In Proceedings of the 2006 conference on applications, technologies, architectures, and protocols for computer communications (SIGCOMM), pages 243–254, New York, NY, USA, 2006. ACM Press. [8] A. Lédeczi, A. Nádas, P. Völgyesi, G. Balogh, B. Kusy, J. Sallai, G. Pap, S. Dóra, K. Molnár, M. Maróti, and G. Simon. Countersniper system for urban warfare. ACM Transaction on Sensor Networks, 1(2):153–177, 2005. [9] P. Levis, N. Lee, M. Welsh, and D. Culler. TOSSim: accurate and scalable simulation of entire TinyOS applications. In Proceedings of the First International Conference on Embedded Networked Sensor Systems (SenSys), pages 126–137, New York, NY, USA, 2003. ACM Press. [10] G. Mainland, D. Parkes, and M. Welsh. Decentralized, adaptive resource allocation for sensor networks. In Proceedings of the 2nd USENIX/ACM Symposium on Networked Systems Design and Implementation, pages 23–23, Berkeley, CA, USA, May 2005. USENIX Association. [11] R. Newton and M. Welsh. Region streams: functional macroprogramming for sensor networks. In Proceeedings of the 1st international workshop on data management for sensor networks, pages 78–87, New York, NY, USA, 2004. ACM Press. [12] L. Pelusi, A. Passarella, and M. Conti. Opportunistic networking: data forwarding in disconnected mobile ad hoc networks. Communications Magazine, IEEE, 44(11):134– 141, 2006. [13] G. Werner-Allen, K. Lorincz, J. Johnson, J. Lees, and M. Welsh. Fidelity and yield in a volcano monitoring sensor network. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, pages 381– 396, Seattle, WA, USA, November 2006.