Master of Science Thesis Stockholm, Sweden 2009
C H R I S T O P H E R O L S S O N
Operations in Wireless Sensor
Networks
K T H I n f o r m a t i o n a n d C o m m u n i c a t i o n T e c h n o l o g y
Programming
Disconnected Operations
in Wireless Sensor
Networks
Masters Thesis
Christopher Olsson
cholss@kth.se 2009‐12‐09 Examiner: Professor Gerald Q. Maguire Jr. Royal Institute of Technology (KTH) Supervisor: Luca Mottola, Ph.D. Swedish Institute of Computer Science (SICS)Wireless sensor networks, networks of nodes communicating wirelessly with sensing capabilities, are becoming more popular and are utilized by an increasing number of applications. Some wireless sensor networks are implemented because the usual network solutions of an always connected network could not be applied. Specifically this thesis is concerned with the case when the connection between the end-user and the network is not always available, i.e., there is only intermittent connectivity.
This masters thesis gives an introduction and provides some background knowledge concerning wireless sensor networks, specifically focusing on disconnected operation. A set of building blocks will be presented to help programmers deal with programming disconnected operations. Examples to demonstrate our solution is implemented as shell commands using the Contiki operating system. Our solution was tested in the field and compared against a common, monolithic, programming approach. This practical example shows the potential significance of this thesis project in real world applications and allowed an evaluation of both the qualitative and quantitative aspects of our solution. The results of our evaluation prove that our solution offers an easier interface for the programmer to work with at the cost of possible less memory space.
Sammanfattning
Trådlösa sensornätverk, nätverk med noder som kommunicerar trådlöst och har sensorer, blir mer populära och används av i ett ökande antal applikationer. Några trådlösa sensornätverk används för att en vanlig nätverkslösning med ständigt uppkopplade noder inte går att genomföra. Det här examensjobbet är specifikt inriktat på fall när en uppkoppling mellan slutanvändaren och nätverket inte alltid är tillgängligt, t.ex. när det bara är tillfällig uppkoppling.
Detta examensarbete ger en introduktion och bakgrund till trådlösa sensornätverk med fokus på programmering av frånkopplade operationer. Ett antal byggstenar har tagits fram för att hjälpa programmerare att programmera frånkopplade operationer. Exempel för att styrka vår lösning i vår rapport kommer att implementeras som shell-kommandon i operativsystemet Contiki. Vår lösning kommer att testas i verkligheten och jämföras med ett vanligt, monolitisk, programmeringsangreppssätt. Detta praktiska exempel kommer visa den potentiella nyttan av detta examensarbete i verkliga applikationer och tillåta utvärdering av kvalitativa och kvantitativa aspekter på vår lösning. Resultaten från vår utvärdering bevisar att vår lösning erbjuder ett enkelt gränssnitt för programmeraren att arbeta med till en kostnad av möjligen mindre minnesplats.
Table of Contents
Abstract ... i List of figures ... iv List of tables ... v Abbreviations ... vi 1 Introduction ... 1 1.1 Problem statement ... 2 1.2 Method ... 3 1.3 Thesis structure ... 3 2 Background ... 5 2.1 Background on WSN applications ... 5 2.1.1 Traditional WSN applications... 5 2.1.2 Disconnected WSN applications... 5 2.2 System software ... 8 2.2.1 Operating systems ... 8 2.2.2 Programming abstractions... 11 2.2.3 Reprogramming... 13 2.3 Related work ... 13 3 Motivation ... 15 3.1 Connection to a WSN... 15 3.2 Challenges ... 16 3.2.1 General ... 17 3.2.2 Disconnected operation ... 173.2.3 Programming Disconnected Operations ... 18
4 Classification of disconnected WSNs ... 19
4.1 Classification model... 19
4.2 Other classification parameters ... 21
5 Design and implementation... 23
5.1 General problem... 23
5.2 Design of a general solution... 23
5.3 Proposed Modules ... 24 5.3.1 Userwait ... 24 5.3.2 Buffer/Store... 25 5.3.3 Replicate... 26 5.3.4 Collect ... 27 5.3.5 Schedule ... 28 5.4 Implementation ... 29 5.4.1 Contiki Shell... 29 5.4.2 Alternatives ... 29 5.4.3 Implementation details ... 30 6 Evaluation ... 35 6.1 Evaluation scenarios... 35
6.1.1 Scenario with mobile nodes ... 35
6.1.2 Scenario with static nodes ... 35
6.1.3 Shell implementation ... 35 ii
6.1.4 Monolithic implementation ... 37
6.2 Results ... 38
6.2.1 Qualitative ... 38
6.2.2 Quantitative ... 40
7 Conclusions and Future work... 51
7.1 Conclusions ... 51
7.2 Personal reflections ... 51
7.3 Future work ... 52
References ... 53
List of figures
Figure 1: The components of a mote... 1
Figure 2: The ARGO project with nodes deployed ... 7
Figure 3: Sensor system for remote water monitoring... 8
Figure 4: Architecture showing a connection between a mote and an end-user. ... 15
Figure 5: Gateway connecting an end-user with a WSN. ... 16
Figure 6: The end-user is disconnected from the WSN. ... 16
Figure 7: Fixed entry point... 19
Figure 8: Any entry point ... 19
Figure 9: Three types of network topologies. ... 19
Figure 10: Mobile WSN containing mobile motes, e.g. motes attached to animals. . 20
Figure 11: WSN classification graph with three dimensions... 20
Figure 12. Isolated nodes accessed one by one... 21
Figure 13. Isolated nodes accessed through a fixed gateway... 21
Figure 14: Utilization of modules in different ways ... 23
Figure 15: Userwait module with sub-modules ... 25
Figure 16: Stack and queue policy ... 31
Figure 17. Replicate command with “send through” functionality... 32
Figure 18: Replicate command data passing... 32
Figure 19: Execution of a cyclic task ... 34
Figure 20: Two nodes, A and B, move along the dotted lines in the numbered order to connect to the sink and upload data. ... 36
Figure 21: Power consumption over time for the mobile scenario using the shell-solution. ... 41
Figure 22: Energy consumption for the mobile scenario using the monolithic solution. ... 42
Figure 23: Energy consumption of all nodes for each solution in the mobile scenario ... 43
Figure 24: Accumulated energy consumption over time for the mobile scenario ... 43
Figure 26: Energy consumption for the static scenario using the shell solution... 44
Figure 27: Energy consumption for the static scenario using the monolithic solution. ... 45
Figure 28: Energy consumption of all nodes for each solution in the static scenario 45 Figure 29: Accumulated energy consumption over time for the static scenario... 46
List of tables
Table 1. Examples of applications classified according to the proposed model... 21
Table 2: Example of a classification table. [2]... 22
Table 3: Events for the mobile scenario using the shell solution... 41
Table 4: Events for the mobile scenario using the monolithic solution ... 42
Table 5: Mobile scenario power consumption. ... 43
Table 6: Static scenario power consumption ... 46
Table 7: Measurements ... 47
Table 8: Confidence interval calculation results ... 47
Table 9: Shows bytes of code... 47
Table 10: Shows bytes programmed to the nodes... 48
Table 11: Disconnected operation commands overhead... 49
Table 12: Description of coupling types for software modules ... 49
Table 13: Design coupling for the two solutions ... 50
Abbreviations
BTS Base-station Transceiver
CLI Command Line Interface
DARPA (U.S.) Defence Advanced Research Projects Agency DTN Delay Tolerant Network
DTNRG Delay-Tolerant Networking Research Group FIFO First In, First Out
HW Hardware LIFO Last In, First Out
LOC Lines Of Code
MEMS Micro Electro-Mechanical System
OS Operating System
RAM Random Access Memory
RTOS Real Time Operating Systems
ROM Read-Only Memory
WSN Wireless Sensor Network
1 Introduction
A wireless sensor network (WSN) [1] is a wireless network consisting of sensor devices, deployed to monitor physical or environmental conditions. The network nodes, in WSNs called motes, are characterised by having constrained resources, often deployed on a large scale, should have low production cost, be adaptable to environmental changes, and operate unattended (i.e., autonomously). The network must adapt to changes, such as the loss of nodes or obstacles in the terrain attenuating or blocking transmissions. Researchers have in the past defined a wireless sensor network as “large-scale ad hoc, multihop, unpartitioned,
network of largely homogenous tiny, resource-constrained, mostly immobile sensor nodes that would be randomly deployed in the area of interest” [2]. While this is true for most
applications, there are those that do not follow this definition, but are still considered WSNs. An example of the use of a traditional WSN is monitoring battlefields with sensors used as sentries, to provide alerts whenever an enemy is moving in its vicinity [3]; where motes are fully connected with each other and the end-user. Other less classical networks are GlacNet [4] and a project in the Baltic Sea’s Bothnian Bay [5] that both are neither large-scale ad hoc networks nor have the motes been randomly deployed.
When a connection from the end-user to the network cannot always be sustained it is considered “disconnected” during this time. In the last two scenarios mentioned above programming a network that is to operate over a temporary disconnected medium is called programming disconnected operations.
Due to the advantages and possibilities of WSNs there is a wide range of applications where WSNs can be used. They are most commonly used in military applications and environmental studies, e.g. deploying sensors over a battlefield to detect enemy intrusion instead of using landmines [3] or measuring environmental changes in bodies of water [5,6]. Other common application areas where WSNs are used are: monitoring homes, monitoring vehicle traffic, monitoring people’s health, monitoring wildlife habitats, surveillance, disaster discovery, mobile entertainment, home automation, security, and lots more. In the future we expect WSNs to be used in cooperating smart everyday things.
A typical mote consists of a transceiver unit, processing unit, power supply, and one or more sensors; as shown in Figure 1. Depending on the application there might be extended storage space (flash memory), a power generating unit (e.g. a solar cell), or additional hardware that is related to the requirements of the application.
Figure 1: The components of a mote; sensors, power supply, memory, ADC (analog-to-digital converter), MCU (Micro Controller Unit), and transceiver unit.
The deployment of motes can either be done one at a time (carefully positioned at a specific location, e.g. inside machines to monitor temperature and hardware failure) or at random (scattered over a large area for instance from an airplane or a cannon). The flexibility in deployment methods has large advantages over wired sensor networks and also broadens the application spectrum. There are also cases where the environment prohibits the use of a wired sensor network or where it is not feasible to use wired sensor nodes, e.g. when motes are attached to moving objects or deployed in large numbers over a large area. In this setting it is impossible to deploy and wire all nodes. ARGO [6] is such an example, a WSN with thousands of motes floating all over the world’s seas following currents and communicating wirelessly.
The majority of WSNs today use a radio link to communicate [7], but light (an example is given in [8]) or even sound is sometimes used. While radio is not the least power consuming method [2], it is the most convenient because of its wide range of use. On a typical mote the radio is the most power consuming subsystem, and since power is the scarcest resource of the node, power usage by the radio should be kept at a minimum. This has lead to research efforts concerning how to minimize power consumption. This research will continue in the future as the volume to store energy is getting smaller due to technology advances. Better power utilisation will make it possible to make really small motes. For example, “Smart dust” motes are only a few cubic millimetres in volume [8].
An approach to save energy is to use aggregation [9]. Another solution is to compress the data [10] at the node before transmission since processing instructions uses less power than transmitting additional bytes over a radio link. Another method is letting the nodes power down their radios during periods of time when there is no need to transmit data. It should be noted that this last approach also causes the node to be disconnected for the period of time that its radio is powered down.
Technology advances will result in smaller nodes, higher processing capabilities, and greater memory resources. The hardware challenge to produce these devices is to keep their power usage and manufacturing cost at a minimum. The software should adapt algorithms and protocols to save energy, increase robustness, enable self configuration, increase fault tolerance, and ease usage. There is also a need to simplify the implementation, maintenance, and the user interface to the network.
While in the future it might be possible to use technologies that allow us to send data over greater distances and at lower energy costs to sustain a connection where it is currently impossible, we might never be able to create a fully reliable connection when we are monitoring nodes in a changing environment. For this reason this thesis topic is not only of interest today, but also in the future.
1.1 Problem statement
Programming disconnected operations today is a problem due to the very limited number of abstractions provided to programmers. In this thesis, an application driven approach will be proposed. The proposed solution should be applicable as a general solution. We will identify, implement, and evaluate a set of building block functionality to simplify programming disconnected WSN applications. The results will be tested through programming example software and also used in a real life application. It is hoped that this set of building blocks will increase the interest in developing WSN applications for as wide a variety of scenarios as possible, specifically including those that must support disconnected operation.
With the increased interest of WSNs it is important to look into new ways to further expand the use of WSNs. However, the desired characteristics of a WSN change with the specific requirements that an application has. This thesis is specifically concerned with situations when implementing a WSN cannot be done without considering disconnected operations, in particular when connections between the end-user and the WSN cannot be sustained.
Disconnected operation could be due to limited power when the communication distance is so great that it requires a large amount of energy to keep the connection alive or when the power needed to send a large amount of data exceeds the nodes’ power resources. The project “Sensor Networks to Monitor Marine environment with Particular Focus on Climate Changes” [5, 11] by SICS and partners is an example of disconnected operation due to the first of these limits (high power consumption due to large distance between the end-user and the senor node). Another reason for periodically closing the connection could be because the end-user’s control station cannot remain within range of the WSN. For example, when measuring volcano activity, as done by researchers at Harvard’s Sensor Networks lab [12]; although the WSN must be expendable in the case of an eruption, they cannot afford to put the base station too close to the volcano because of the risk losing the equipment and data. Over such long distances it might be wise to shut down the connection to save energy when nodes are not experiencing any volcanic activity.
A problem in these scenarios is developing the disconnected WSN applications, as the connection between the end-user and WSN cannot be sustained. Most work that has addressed the problem of disconnected operations has been based upon application specific solution, while this thesis seeks to develop a solution that can be applied to many different applications. To keep the interest for new applications growing it is crucial that WSNs be portable to as many different scenarios as possible.
1.2 Method
The main goal in this thesis is to provide a solution to help programmers program disconnected operations for WSNs. The solution will be general so it can be adapted to more environments that examined in this thesis. By targeting disconnected operations this thesis will contribute to the WSN community in a unique way -- not seen up to this point.
The solution presented in this thesis will be implemented and tested against another possible solution for programming disconnected operations. Looking at both qualitative and quantitative aspects of our solution will be a part of our analysis and together with live testing will show the significance of the proposed solution in real applications.
1.3 Thesis structure
This thesis begins with background literature study (chapter 0) where the fundamentals of WSNs and its software are described.
Chapter 3 will take the reader deeper into the issues of disconnected scenarios and programming. While chapter 4 presents a new model for categorizing disconnected WSNs and shows the effects of different parameters.
In chapter 5 the design of our solution will be presented and later how it will be implemented. This is followed by evaluating the solution in chapter 6, looking at both qualitative and quantitative aspects.
Conclusions and results are presented in chapter 7, together with a description of future work.
2 Background
In this chapter the background for this thesis will be presented, including a look at some specific applications and software of current interest (such as operating systems and programming abstractions).
2.1 Background on WSN applications
WSNs have found their way into a wide variety of application areas. The most common are military, environmental, health, and other commercial applications. Applications using these WSNs can be used for monitoring, surveillance, targeting, damage assessment, disaster detection, tracking, automation, etc.
2.1.1 Traditional WSN applications
Up to this point defining a traditional WSN has been difficult since almost all WSN applications have been unique applications. Some WSNs have nodes distributed in great numbers, others only a couple nodes; some nodes are randomly distributed, other carefully positioned at exact locations; etc. Since this thesis focuses on disconnection, a traditional WSN is considered as one that does not deal with the issues due to disconnection.
A traditional WSN application is a military application using sensors in cooperation with mines [3]. In this application sensor are placed on a battlefield, near the ground, always connected to each other - so that if one node is removed the end-user is alerted. In this application power efficiency is very important since it takes more energy to send data from nodes that cannot have an antenna placed high above the ground, thus radio communication requires more energy when nodes are at ground level. By communicating between the nodes it is possible for other nodes to take action when an enemy tampers with a real mine to create a breach lane, e.g. a mine nearby the breach could use rocket thrusters to move into the breach lane, filling the gap of the disabled mine. This is discussed as a feature of the Self Healing Minefields application mentioned in [3].
Another typical application is monitoring seabird nesting and behaviour at Great Duck Island [13]. To identify important areas of further work, a WSN application was used to avoid potential impacts of human presence on the animals being monitored. Nodes could be placed in nests before the breeding season when the island was inhabited to later measure data about nesting birds. Motes send data to a base station that is accessed through the internet via a two-way satellite link. In their implementation the mote data is always accessible, hence there is no need to approach the deployment site until after the breeding season when birds are no longer nesting. For operating “off the grid” this report discusses the use of disconnected operations as a possible solution, but did not implement such a solution.
2.1.2 Disconnected WSN applications
Scenarios for disconnected applications are commonly found in environmental monitoring, such as monitoring moving animals or geological activities at remote and hazardous locations. Usually the area that the motes need to cover is so great that it is inefficient from an energy resource and hardware cost perspective to maintain a constant connection. In general, an application has to be prepared for disconnected operation when monitoring the behaviour of moving objects (which have motes attached to or incorporated in them). Consider the case of monitoring the movements of cars [14]. Cars could act as carriers for the
nodes - utilizing energy from the car’s batteries or generator. Since it may be difficult or uneconomical to provide wireless coverage of the entire road grid, the cars may continuously or periodically make measurements when driving around – but only transfer this data to the end-user when passing fixed base stations, for example, the base stations could be affixed to traffic lights or street lights as these sites also have electrical power available to them and might even have network connectivity. Similarly, passing cars can be used to gather data from sensors monitor structures, e.g. bridges [15].
The ZebraNet project [16] is another example of mobility in WSN, in this case by using a mobile control-station to gather data from nodes attached to zebras. Researchers follow the herd in vehicles to collect data. As there is not a fixed location to send data to, a flooding protocol is used for short range connectivity together with a direct-connection protocol for long range. Gathered data is flooded to nearby neighbours, thus the base-station only needs to come in contact with a few nodes to collect data. To improve this further the direct-connection protocol is used for long distance radio links -- when limited bandwidth and limited storage space at the node does not noticeable affect the efficiency of the protocol due to the small amount of data being sent. This optimizes energy consumption. The connection is set up by nodes only during the day, when nodes search for a station. If a control-station is nearby, then data is uploaded. Since the researchers themselves determine when to collect data, they control the disconnection between the control-station and the nodes.
David Jea, et al. [17] propose to use so called “data mules”, mobile elements moving around in the vicinity of the deployment area, to collect data from nodes. This concept of data mules is seen in other projects, such as ZebraNet. This method addresses both bottlenecks at access points (hotspots) and data load balancing, but presumes the possibility of having a mobile element, which is not always the case in environmental monitoring. It has also high latency, might not be sufficiently scalable, and for many applications does not fully address the problems related to disconnection, although it gives a general solution to handle disconnected operations in many cases.
Another example of mobility in WSNs is when monitoring whale activity [18]. Several control-stations are placed along paths that whales travel or at regularly visited feeding grounds. When the whale surfaces and exposes their radio antenna data is uploaded to a nearby Shared Wireless Infostation Model (SWIM) control-station. Data is shared among whales so that only a single whale needs to access a SWIM control-station and when a whale uploads its data the previously stored copy is erased. A timestamp is used to determine when data on a whale’s memory storage has become obsolete. SWIM stations can work together as an ad hoc network to transfer data to shore or use a satellite connection, whenever a satellite passes over the area. This network topology is “multi disconnected”: (1) the nodes on the whales are disconnected from each other and the station and (2) the SWIM control-station could be disconnected from the end-user on shore if a satellite is used to gather data from the control-station, since the satellite might not always be in such a position that a connection can be established.
A project that both has mobile nodes and is deployed over a large area is the ARGO project [6]. Over 3000 floats (floating motes) are deployed in the world’s seas (Figure 2) measuring the temperature and salinity in the water down to a depth of 2000m.
Figure 2: The ARGO project with nodes deployed (updated 4-Mar-2009) Source: www.argo.ucsd.edu
By using a satellite tracking system it is possible to measure the velocity of the ocean current by looking at the movement of the floats. Most of the time floats are underneath the surface, typically for a 10-day period, without the possibility to connect to the satellite. When a float surfaces it will transmit data for 6-12 hours, then start another dive. All of the floats are disconnected from each other and only communicate via a satellite to the end-user.
As a result of the high cost of monitoring remote areas, especially bodies of water, such environments are poorly monitored. A solution to the problem of high cost and rarely gathered results is to use sensor networks as proposed in [5, 11], deploying buoys in the Baltic Sea (Figure 3). The buoys are anchored with a line to the sea bottom. On this line a bin containing several nodes will travel, measuring data at specific depths as determined by a pressure sensor. Light and acceleration sensors are attached on top of the boy. For powering the system rechargeable batteries are used. The batteries are recharged by both solar cells and a wave energy generator.
The potentially large amount of measurement data requires more storage space than what the node’s RAM can offer. For this application flash memory cards are used. To minimize the energy-cost for transmitting data, the data is compressed before transmission. Transmission is planned to be done by GPRS which has a long range, but at the cost of high energy consumption. Additionally nodes can only be placed near the coast where there is GSM coverage. To further minimize energy consumption the GPRS link between the buoy and control station is disconnected when transmission is completed and remains disconnected during measurements.
Figure 3: Sensor system for remote water monitoring (exploiting solar and wave powered recharging of the on-board batteries).
Illustration: Bo Reinerdahl
An application where nodes are not mobile, but still may be disconnected is monitoring glacier movement [3]. In this example the WSN is often disconnected from the end-user due to the distance and medium between nodes, base-station, and end-user. When monitoring glaciers the nodes do not communicate with each other and only temporarily communicate with a base station above the glacier on a scheduled basis. This is because the density of the ice reduces signal propagation. Synchronization of the nodes to a schedule is done by using GPS timing. Note that the end-user might always be able to access the base-station through a satellite connection.
2.2 System software
Software development for WSNs occurs primarily on the operating system level or the application layer, or between them using middleware. Middleware is used to connect applications with operating system (OS) and network services [19]. Operating systems differ extensively from OSs for personal computers, but share functionality and needs to a great extent with OSs for embedded systems. When programming applications for WSNs many challenges, such as those mentioned in section 3.2, are a constant concern.
2.2.1 Operating systems
Operating systems for WSNs often needs to deal with resource constrained devices. A typical sensor node is equipped with an 8-bit microcontroller, on the order of 100 Kbytes for code memory, and up to 20 Kbytes of RAM. Such a device has limited processing power, memory, and available energy. The number of different devices is increasing and the application specific nature of sensor networks contributes to this diversity. Therefore, it is desirable that the OS is portable across hardware platforms. Other desired features of the OS are that it should use little code space, support reprogramming of the nodes (during run-time), use little memory allocation, utilize energy efficient algorithms, and in general be efficient about using its resources. Creating an implementation that meets all of these requirements
can be quite difficult; therefore it is common that OSs specialize in certain application areas in order to meet some of the requirements very well at the cost of not meeting others.
One way to minimize memory resources is to use an event-driven kernel. A multi-threaded model, in comparison, consumes larger amounts of memory and every thread must have its own stack in memory. Since the system does not know how much stack space the thread needs when memory is allocated at thread creation the stack is over provisioned. On the other hand while event-driven systems work well in sensor network applications; the event-driven programming model can be difficult to manage for programmers. Code generation could facilitate programming such event-driven applications [20].
Examples of potential OSs for wireless network devices are:
• Contiki - Light weight event-driven OS that targets WSNs, provides power profiling, dynamic programming, and node shell command line interface (CLI)[21]
• eCos – A fully pre-emptive real time operating system (RTOS) running one process with multiple threads, supporting many different platforms [22]
• LiteOS – UNIX like OS that specifically targets WSNs, provides shell command line interface, multi-threaded kernel, hierarchical file system, dynamic programming, and online debugging [23]
• Magnet OS – Single system image (Java virtual machine), power-aware algorithms for component distribution, statically partitions applications and dynamically places them on the network [24]
• Mantis – Multi-threaded OS that targets WSNs, designed to deal with complex tasks such as compression, aggregation, and signal processing; but still be lightweight [25] • MicroC/OS-II – Priority based pre-emptive RTOS with multitasking kernel,
performing scheduling with tasking aware interrupt service routines [26]
• Nano-RK – Pre-emptive reservation based RTOS. Supports fixed-priority fully pre-emptive scheduler and reservation on system resource consumption [27]
• Nemesis – Designed to distribute multimedia applications. It has few hardware abstractions and uses shared libraries resulting in a small kernel [28]
• NutOS – Non pre-emptive multithreaded RTOS that featuring events and dynamic heap memory allocation. Uses libraries instead of a fixed kernel block, thus reducing the footprint [29]
• Tiny OS – Light weight event-driven OS that targets WSNs, completely non-blocking with a single stack [30]
The hardware of a WSN mote and normal embedded devices are similar allowing OSs for embedded devices to be run on WSN devices; although WSN devices do not necessarily require the real-time properties which are normal in an OS for embedded devices. Three of these OSs are described in the following sections. These examples were chosen because Contiki was developed at SICS and was selected earlier for the project, LiteOS is a UNIX like OS - with a similar user interface to Contiki, and TinyOS is widely used and has expanded into many different areas.
2.2.1.1 Contiki
Contiki [21] was created as a light weight OS for constrained networked embedded systems. While the kernel is event-driven, the OS supports pre-emptive multi-threading, thus benefitting from both event-driven systems and pre-emptive multi-threading. The multi-threading is implemented as an optional application library that can be linked with
programs that explicitly require it. The type of thread used in Contiki has been called a protothread [31].
For reprogramming nodes during run-time, Contiki uses ELF-files for dynamic linking. This allows loading and unloading of individual applications or services during runtime [32].
In Contiki, the kernel provides a minimum of abstractions. Instead abstractions are provided by libraries that have nearly full access to the underlying hardware. Contiki is designed to be portable and has been ported to 14 different platforms and 5 different CPU architectures [33].
To interact with a network node a command-line shell, running on the nodes, can be used. This shell offers UNIX-like commands.
Software-based power profiling is another feature of Contiki. This allows the programmer to measure the energy consumption of a node. Nodes in WSNs seldom have hardware mechanisms for measuring their energy consumption; this is to keep down the cost of the node since a large number of them might have to be produced. By implementing a software-based on-line energy estimation tool, it is possible to estimate the node’s energy consumption. This a valuable tool when building a WSN and when evaluating different energy saving algorithms and communication protocols. While the results from this tool are close to reality, they are still estimations. The possibility to see differences and trends in energy consumption for different ways of using of the node and for different algorithms is very valuable. Extensive related work in this area has been done by Tajana Simunic Rosing at Department of Computer Science and Engineering, University of California, San Diego [34].
2.2.1.2 LiteOS
To fulfil the need of an easy to use an OS with a well known interface LiteOS [23] was created, giving programmers a familiar programming environment. LiteOS features a subset of UNIX-like commands, hierarchical UNIX-like local file system, kernel support for dynamic loading and native execution for multithreaded applications, online debugging, and dynamic memory.
The LiteOS architecture can be divided into three categories: kernel, file system, and user environment. The kernel in LiteOS is thread-based, but allows events in user applications using call-back functions. Scheduling is either round-robin or priority based. LiteOS supports dynamic loading and unloading of user applications. All applications are compiled into a modified HEX format; lhex, that is very small in size. Reprogramming is done on the application level using lhex-files.
The file system used in LiteOS is called LiteFS and is similar to the UNIX file system in how it represents different entities, such as data, application binaries, and device drivers. A radio, sensor, and LED are examples of supported device drivers. Read/write operations are mapped directly to hardware, e.g. writing a message to the radio would broadcast it.
The LiteOS user environment consists of a UNIX-like command line interface to sensor nodes. The shell, called LiteShell, runs on the end-user’s PC providing a front-end that interacts with the user. The nodes receive translated messages as compressed tokens that are easy to parse. This approach minimizes the run-time footprint on the nodes, while allowing the shell to be easily extended.
2.2.1.3 TinyOS
TinyOS [30] is a tiny embedded operating system targeting WSNs. The entire operating system requires only 226 bytes of RAM and 3.5KB of instruction memory. TinyOS started out as a project at University of California, Berkeley in corporation with Intel Research, as a project in the DARPA NEST program (Smart Dust [8]). It is one of the first OSs targeting WSNs and was developed to cope with technological advances in integrated, low-power, CMOS communication devices and sensors.
The philosophy behind TinyOS is to get the work done as quickly as possible, and then go to sleep as soon as possible. TinyOS is interrupt driven and uses an event-driven architecture so that high concurrency can be handled in a very small amount of memory space. Scheduling is implemented through a two-level structure; short hardware events are preformed immediately while longer applications are run as tasks. The tasks can be pre-empted by events, are time flexible, and run in FIFO order, in comparison to events that are time-critical and use first-in first-out (FIFO) semantics.
Programs are built out of software components that communicate with each other via interfaces. A component consists of four parts: command-handlers, event-handlers, a fixed-size memory segment frame, and tasks. Tasks, commands, and handlers execute in the context of frames.
Since frames are of fixed size, static memory allocation enables the allocation size to be known at compile time, reducing memory allocation overhead. Memory is organized as a single shared stack, no heap, and no function pointers.
2.2.2 Programming abstractions
Programming WSN applications differs very little from programming other embedded hardware, as the fact that OSs can be used in both environments proves. As noted earlier, real-time properties are often required in embedded systems, but are not always required in WSNs.
On top of the operating systems, additional abstractions are often provided to facilitate programming and to hide complexity. Examples of such an abstraction are TinyDB [35] for TinyOS, implemented as a library. TinyDB handles cooperative data acquisition using macroprogramming. Conversely, in node-centric programming the focus is on an individual node rather than the aggregate system. The programmer writes code for each node which may enable the executing code to be more efficient, but is more time-consuming, error prone, and requires significant expertise in the area. Macroprogramming offers a more generic solution by way of high-level programming, by utilizing suitable programming abstractions [36].
To support such programming abstractions, OS-specific programming languages are often developed, such as NesC [37] for TinyOS, which is an extension of the C-programming language. Another WSN-specific programming language, but one not bound to an OS, as it is platform independent, is SPIDEY [38].
2.2.2.1 TinyDB
TinyDB is a system that gathers data via queries from nodes running TinyOS. Instead of writing embedded C-code for each node, TinyDB offer a SQL-like interface together with additional parameters to specify the data to be extracted. Given a query TinyDB collects the data, filters it, aggregates it, and routes it to the end-user.
The goal of TinyDB is to make programming a WSN application significantly easier. Specifically, it allows data-driven applications to be developed and deployed quicker than what was previously possible. Some of the features provided in TinyDB are: metadata management through a metadata catalog, high level queries with a declarative query language, network topology tracking, multiple queries, and incremental deployment via query sharing that allows for nodes with TinyDB to be added to the network at a later stage.
Example 1: Query for TinyDB
In Example 1 sensor nodes monitor rooms in a building. The code is used to learn which rooms are in use; by defining a room as being ‘in use’ as having an average amount of light greater than a threshold and an average volume larger than v. This will be checked every fifth minute.
2.2.2.2 SPIDEY
The programming language SPIDEY was created to meet the new challenges emerging in decentralized architectures, where several data sinks might be used to collect data. SPIDEY offers a high-level, application oriented way of defining logical neighbourhoods. The neighbourhoods can be defined declaratively based on the type of nodes, together with requirements about the cost of communication.
SPIDEY was conceived to be an extension of an existing programming language, making it available to a wide range of OSs. Programming in SPIDEY revolves around two concepts: nodes and neighbourhoods, code examples for each concept can be seen in Example 2.
Example 2: SPIDEY code for a logical node (top) and logical neighborhood (bottom).
A node is defined by a node template. This template is later used to derive actual instances of logical nodes. A static declaration represents information that does not vary in time; unlike
dynamic information, such as sensed data. A node is created by binding attributes to constant values or functions.
A neighbourhood is first defined as a template, which defines the nodes belonging to the neighbourhood. The logical neighbourhood is then instantiated by specifying where and how it is supposed to be constructed and maintained. In the bottom code example of Example 2 a neighbourhood template is defined as consisting of temperature sensors whose reading is above a given threshold, then instantiated in terms of nodes that meet or exceeds a threshold of 100, are a maximum of 2 hops away, and for which communication requires spending less than a maximum of 30 “credits”. These credits represent the communication cost – each node has a function to calculate this cost.
No matter what OS is used and which abstraction that is used to implement the application, there might be several reasons that changes need to be made to the programming after deployment. Reprogramming of the network can therefore be expected in most applications.
2.2.3 Reprogramming
From the perspective of constrained resource programming, WSNs and other embedded devices share many similarities since it is important not to waste energy or memory space as both could significantly shorten the application’s lifetime. Even though the first step of programming is important and builds a foundation on top of which changes might be made, it is important that the system offers reprogramming in an as easy to use way as possible [39].
There are different methods for reprogramming nodes: full system image replacement, changing different small parts of the binary image, passing interpreted code, virtual machines, and loadable native code modules. One challenge of reprogramming is to keep the energy cost as low as possible during the reprogramming phase, both by minimising the number of bytes sent over the network and minimizing the effort it takes to process the data at each node. Virtual machines have the advantage over native code that the code can be smaller, but the drawback is usually increased energy spent on interpreting the code, especially for long running programs [21]. In some scenarios using long running programs the run-time processing eats up the energy saved by the smaller code. Replacing the full system image is an easy and straight forward approach, but has a high overhead. Editing parts of the binary image during run-time works well for networks where all nodes run the same binary image, but can easily become complicated if they do not. With loadable modules only parts of the system need to be modified, but this method requires support from the OS. The best reprogramming solution would be to use a mix of a virtual machine code and native code, giving good energy efficiency [32].
After setting up a WSN there might be several reasons why a software update is needed. There might be problems with bugs in the software that were not discovered before deployment, or the network needs some new functionality. Since it might not be plausible or even feasible to collect all nodes in order to reprogram them; thus it is in the interest of the programmer that the nodes support reprogramming during run-time.
2.3 Related work
Most related work concerning disconnected operations concerns disconnections within the WSN. However, a small amount of work has been done when the disconnection occurs between the end-user (base-station) and the rest of the WSN. In particular, some work has been done regarding data management [14] [40] and storage [41]. Other work is more related
to networking within the WSN, for example DARPA’s Disruption Tolerant Networking program [42], other DARPA funded DTN programs, and research by the Delay-Tolerant Networking Research Group (DTNRG) [43]. One project related to this thesis is the “Disruption Tolerant Shell” project by Martin Lucac et al. [44]. However, their work is application driven as for a certain scenario they are looking at synchronisation between nodes and management, not from a general point of view toward disconnected operations.
The above projects focus on routing of packets within the WSN. This thesis approaches a similar problem with disconnection, but at an abstract software level, with an aim of offering a tool for programmers to program disconnected operations. We have not found any published prior work that deals with disconnection in the fashion presented in this thesis.
3 Motivation
This chapter examines more deeply the issues that arise in disconnected scenarios and programming for applications that must address these issues. First we will identify different ways of connecting and being connected to a WSN, then look at challenges in WSNs scenarios due to disconnected communication.
3.1 Connection to a WSN
There are three important cases when a connection between an end-user and the WSN is not available. Sometimes a connection between the end-user and the WSN and (even) inside the WSN is deliberately disconnected; for example, periodically disconnecting to save power. In other cases it may only be possible to sustain a connection on an irregular basis; for example, when monitoring a heard of moving animals [13]. Finally, there is the case of a broken connection because of unreliable links, failed nodes, or other unpredicted events that causes a temporarily prevented connection. The whole chain of connections from one mote to the end-user is shown in Figure 4.
Figure 4: Architecture showing a connection between a mote and an end-user.
Three types of connectivity are described by Kay Römer and Friedemann Mattern: connected, intermittent, and sporadic [2]. If there is always a connection between nodes, then the network is connected; if nodes may be occasionally partitioned, then the connectivity is said to be intermittent; and if nodes are isolated most of the time and only communicate with other nodes occasionally, then the connectivity is sporadic. In this thesis the last two types, intermittent and sporadic, are both considered as disconnected scenarios.
The area addressed by this thesis has many similarities with other topics, such as: “delay-tolerant networking” (DTN), “disruption tolerant networks”, and “opportunistic connectivity”, amongst others. In most of these topics the focus is on the connections within the WSN, specifically the network layer dealing with routing of packets. However, little research has focused on investigating how to program solutions for when there is not continuous connectivity between the end-user and the rest of the WSN.
Whenever we want to access a WSN for any reason, be it for (re-)programming the nodes, updating software, querying nodes for their current status, changing tasks, or acquiring data, this access can be done in different ways. Generally we communicate via some kind of gateway. This gateway could be one of the motes, a data sink, or a special control-station or base-station. The gateway node might also function as an access-point for the rest of the WSN to access other networks.
The different ways of connecting to a WSN and the different types of WSNs increases the complexity of the system. This thesis project tries to simplify this process. We will assume in
all our scenarios that an end-user wishes to connect to a WSN. In general this end-user will be connected via a wired or wireless connection to a node that could be part of the WSN, but might not always be part of the WSN. See Figure 5.
Figure 5: Gateway connecting an end-user with a WSN.
The disconnection that is discussed in this thesis concerns both the connection between the node that is directly connected to the end-user and the connection from this node to the rest of the WSN (as shown in Figure 6). An alternative way of describing this disconnection is that the WSN is partitioned into one part that the end-user is able to communicate with and another part of the WSN that is currently disconnected from the first part.
Figure 6: The end-user is disconnected from the WSN.
3.2 Challenges
Challenges concerning WSNs can be divided into two areas: hardware and software. Hardware challenges are to increase performance, create flexible platforms, and reduce the component sizes and cost. Hardware advances such as processor speed and memory capacity amongst others have followed Moore’s Law, resulting in the speed or capacity doubling every second year for a given cost. Software challenges are related to programming environments, algorithms, and efficient code. It is not only important to make best use of hardware resources, but also to facilitate programming by the programmers.
To follow trends in embedded systems and offer WSNs solutions in a wide variety of applications it is important that these challenges are met. Also, it is important that suitable program building blocks (often implemented as libraries) be available in the programming environments that the programmers are most likely going to use.
3.2.1 General
An important area of software challenges is producing an easy to understand environment and interface for programmers to work with. Not only experienced programmers will use the network, but researchers who might not have a background in programming computer networks may need to develop applications for a WSN. Therefore, making it easy to create, deploy, and operate a WSN is important, as it does not matter how energy efficient software is if no one uses it. This leads to a more human centric focus for programming WSN applications. This is in contrast to the traditional node centric focus of developing software for embedded systems, which viewed programmers' time as having low cost.
In WSN applications the constraints due to limited resources are always an important to address. While hardware advances give greater processing capabilities, larger memory resources, and smaller components – there is still a need for cheaper, less power consuming, and more flexible platforms.
A major challenge in producing software for WSN is due to the scarce energy resource of the node. Thus the challenge is to produce energy efficient software, as this will increase the lifetime of the network. For nodes that do not have the possibility to recharge their battery (or be refueled), if the energy consumption can be halved, the lifetime of the node is doubled.
3.2.2 Disconnected operation
Programming WSNs is often done in conjunction with a specific application implementation, making the solution suitable only for this specific application and not reusable for disconnected networking. Not only are all deployments of WSNs with disconnected applications unique in their application, but also their solution to disconnected operation is also unique. Therefore, many applications might benefit from a common solution. One challenge is to create such a common solution.
Another issue in disconnected networks that does not relate to routing packets and making good use of storing and collecting data is the user interface for programming disconnected operations. The expanding use of WSNs in different applications today results in scenarios where the programmer needs to operate the WSN over an intermittent or sporadic connection. This is a challenge that is not solved by any of the applications mentioned in section 2.1.2.
Most of the typical challenges of disconnected operations lie within the WSN, for instance collecting results and routing packets within the WSN. Examples of problems that can occur during result collection include a mote experiencing a memory overflow while waiting for connectivity to be re-established in order to transmit its measurements. Another challenge can be the uncertainty that a given software update has disseminated fully, i.e., that every mote has been updated.
When the end-user issues a data collection request, this request is spread through the WSN to cause the relevant motes to return their sensed data. When the WSN needs to be reprogrammed there is a similar course of events. In both cases the end-user relies on the routing of the packets to ensure that every node gets the relevant information. When all nodes within the WSN have direct connectivity with the end-user the end-user can ensure that each node receives the information. A more difficult case is when the end-user can only communicate directly with one or a small number of nodes, thus the user must depend upon these nodes to act as relays for the required communication.
3.2.3 Programming Disconnected Operations
We have so far shown that there are a number of applications that are affected by disconnection (see section 2.1.2), and will continue to be so in the future. A novel approach to programming an abstraction to handle such disconnection and the challenges that follow is needed. Today no such abstraction exists.
When programming disconnected operations it is important to know what kind of disconnection you are programming for. When the WSN is in a disconnected state it is usually the WSN that has disconnected itself by turning off its transceiver or the connection was for some reason lost. In the first case, it is the WSN that activates and deactivates the connection, i.e. connectivity is determined by how the WSN was programmed to function. In this case the end-user usually knows for how long the connection will be down, or knows what the schedule of connectivity is planned to be. If this time is known by the end-user, then programming disconnected operations is much easier since the end-user does not have to synchronize when the node will be reachable by the end-user with the time the end-user is accessing the network. Another way around this is tell the nodes about the desired operation(s) and when there is a connection execute these operations. In this case, buffering of operations and possible associated data is needed. Also necessary is some way of marking operations with a timestamp or a comparable identification of the state of the network so no an isolated node starts to execute old operations when it (re-)connects after a long time.
It is obvious (by definition) that sending packets between nodes is impossible when they are disconnected from each other. In the case of packet-switched communication, every problem that arises from this disconnection is related to packets not being sent or received. Unfortunately, unexpected disconnections can occur when updating software in the network, when reprogramming, during data collection/transfer, and when querying nodes for status.
There can also be indirect effects when programming if the WSN is partially disconnected. For example, when using data management equalization algorithms (to spread load or storage of data over nodes [40]) and altering information dissemination, as the end-user might not know that some parts of the network are currently disconnected.
4 Classification of disconnected WSNs
A classification model is needed to classify different WSNs and eventually their differences in disconnection. Knowing these differences it should be possible to better adapt the approach to the problem of disconnected operations. Classification of a WSN can be done in different ways and a WSN can be characterized in different ways using different parameters.
4.1 Classification model
In the classification model for disconnected WSNs presented here three parameters are used. These three parameters are: entry point, network topology, and mobility of the network. Details for each of these parameters will be presented below.
Entry point characterization concerns the means of connecting to a WSN. The entry point
refers to the connection from the end-user to the gateway to the WSN. One way to connect is through a fixed gateway, i.e., always using the same (intermediate) node to access the WSN – as illustrated in Figure 7. A second way is to connect to any random node or a subset of nodes that are connected to the rest of the WSN – as illustrated in Figure 8.
Figure 8: Any entry point Figure 7: Fixed entry point
The network topology can be divided into three categories: fully connected nodes,
disconnected islands of nodes, and isolated nodes. These three types of network topologies are shown in Figure 9. Due to characteristics of WSNs categorising a WSN based upon network topology is not a straight forward task. If the network should be able to adapt to changes in topology, then a failing node might change the topology from fully connected to disconnected islands or a disconnected island might change to isolated nodes. Note that a fully connected network could transition in stages (i.e., via link failures to become disconnected islands) to isolated nodes, or this transition from fully connected to only isolated nodes could even happen in a single step. In this thesis we are assuming that the system finds itself most of the time and that a change in network topology is unlikely and temporary.
Mobility of the network is a third parameter for classifying a WSN. The network (as a
whole) or parts of the network could be mobile. Mobility of the nodes may lead to changes in the network topology (as described above). Recent work by David Culler et al. [46] discusses that “mobility changes everything” in WSN. A common scenario for mobility in WSNs is when a node (mote) is attached to an animal, as shown in Figure 10. Note that if multiple nodes were carried by the animal, then the network formed by these nodes would be mobile. One of the important questions is if the nodes are moving coherently together (i.e., all moving on the same path), in this case there is a different expectation for the stability of the network topology, than in the case when paths of the nodes are not coherent (i.e., they are moving along different paths). In this second case, link failures will be more likely.
Figure 10: Mobile WSN containing mobile motes, e.g. motes attached to animals.
These three parameters enable us to classify a WSN in a three dimensional space. With two classes of entry point (fixed or mobile), three network topologies (fully connected, Disconnected islands, and isolated nodes), and with or without network mobility – results in 12 different classes (as illustrated in Figure 11).
Some of the combinations in the classification graph are not relevant to this thesis project. For example a WSN with isolated nodes, where the nodes do not communicate with each other for any reason, that the end-user must access through each individual node (i.e., each node is the only entry-point to access this node) gives no programming challenge and if a wire is used to connect to the node is not a wireless network by definition; hence it is not of further interest in this thesis. While a collection of isolated nodes with a fixed entry-point that must be used to communicate with any of the nodes (i.e., this entry point acts as a gateway) is clearly a WSN – since the nodes are communication with the gateway wirelessly. These two scenarios are shown in Figure 12 and Figure 13.
Figure 13. Isolated nodes accessed through a fixed gateway.
Figure 12. Isolated nodes accessed one by one.
The examples above suggest that there is an intermediate situation that is of interest: when the user can communicate with isolated nodes or disconnected islands via a number of different gateways. There is also the related situation when a fully connected network has multiple gateways – this situation is interesting as it increases the robustness of the communication between the end-user and the nodes; as a link failure that results in a partitioning of the network into disconnected islands might still provide connectivity with the end user if there is at least one gateway to each node or island.
Table 1. Examples of applications classified according to the proposed model.
Mobility Entry Point Network topology Example
Yes Fixed Fully Connected
Yes Fixed Isolated Islands ZebraNet [13]
Yes Fixed Isolated Nodes Argo [6]
Yes Any Fully Connected
Yes Any Isolated Islands
Yes Any Isolated Nodes
No Fixed Fully Connected
No Fixed Isolated Islands
No Fixed Isolated Nodes Glacier [4]
No Any Fully Connected Rolls Royce WIDAGATE [47]
No Any Isolated Islands
No Any Isolated Nodes Buoys [11]
4.2 Other classification parameters
In other classification models, for classifying WSN applications, many other parameters have been used. Kay Römer et al. [2] looked at a design space using the following parameters to differentiate applications: deployment (in regard to method and time), mobility of nodes, resources, implementation cost, energy source, heterogeneity, modality, topology, coverage, connectivity, size, and lifetime. Table 2 shows an example of this method of classification for two disconnected WSNs: ZebraNet and a WSN used for herding.
Table 2: Example of a classification table. [2]
Deployment Mobility Resources Cost Energy Heterogeneity Modality ZebraNet Manual,
one-time
all, continuous,
passive
matchbox - battery nodes, gateway radio
Herding Random, iterative
all, continuous,
passive
brick - battery homogeneous radio
Infrastructure Topology Coverage Connectivity Size Lifetime ZebraNet Base station,
GPS Graph Dense (every animal) sporadic Tens-thousands One year
Herding Satellite Star Sparse Intermittent 1300 deployed,
3000 planned
4-5 years
Another example of classification of WSN applications is given in [36], where a two-dimensional classification model is described. The model has two parameters, space and time, which are each divided into two segments: global and local for space, and periodic and event-driven for time.
As described above, this thesis utilizes its own classification method. This method will be used later to (1) evaluate the implementation of the solution and (2) to make programming disconnected operations easier.
5 Design and implementation
This chapter begins with a presentation of the general problem and its general design solution. Following this is an examination of specific problems derived using the classification model presented in the previous chapter. From these specific problems a set of building blocks will be presented. The following chapter evaluates these building blocks, also called modules.
5.1 General problem
As stated in section 1.1 on page 2, a WSN application programmer who is developing disconnected WSN applications must currently implement an application specific solution, as a general solution or solutions do not currently exist. A general solution that addressed the problem of disconnected operations could be applied to many different applications. Simplifying the development of disconnected WSN applications could foster the development of new WSN applications by an expanded set of developers.
5.2 Design of a general solution
To simplify programming of disconnected operations we introduce a number of modules as a part of the solution (illustrated in Figure 14). These modules can be used in conjunction with other modules or by themselves and allows for different implementations with different functionality. A module can communicate with other modules on the same node or through the network with modules on other nodes. The end-user might both give input and receive output from modules. Due to the use of a common interface, these different implementations can be interchanged with each other to meet the needs of a specific application. The re-use of hardware and software modules has been successful in many other areas, by reducing development time and effort, increasing quality - as an improvement in a module can be applied to all instances of its use, enabling “best of breed” selection of modules, etc. In the following sections we will present this common interface and some of the modules that we believe are necessary to address the problems faced when developing applications for disconnected WSNs.
One of the benefits of this modular design is that it permits the application programmer to easily replace one module with another. For example, a module used to communicate with other nodes could be replaced by another module that has a different power profile. This can have significant benefits, if only local optimizations are necessary to meet the application’s overall power requirements.
5.3 Proposed Modules
After examining a number of WSN applications a need for a general solution to enable these applications to be used in conjunction with disconnected operation is considered. We in this chapter propose a small set of modules to facilitate the development of future disconnected WSN applications. The modules are: UserWait, Buffer/Store, Replicate, Collect, and Schedule. These modules will each be described in detail in the following subsections.
5.3.1 Userwait
A common feature of many WSN application is the need for a process to execute up to some point (specified by the programmer), where it should wait for the user to continue the process. The initial execution of this process could be activated by an end-user connecting to the WSN or initiated automatically based on some event (time of day, sensor threshold, completion of another task, etc.). Userwait divides a series of processing into portions that can be executed without the presence of the user and wait barriers that require communication with the end user before the processing can continue.
A typical example of when such a module would be used is in a disconnected WSN where the end-user is only connected to the network for a limited time. The nodes will run the userwait module individually when measuring data and storing it locally. When the end-user connects and announces its presence the nodes will react to this and start sending their stored data to the end-user.
5.3.1.1 Design
The design of this module could be divided into two sub-modules: one sub-module that manages the execution of the process and the other sub-module communicates with the end-user and acts on the first sub-module by allowing it to continue the execution of the process. The first sub-module could be further divided into three parts: one part that handles execution of the process before the break, one part that handles the break and waiting for the end-user to connect, and a third part that handles the execution of the following process. This is illustrated in Figure 15.
Figure 15: Userwait module with sub-modules
5.3.1.2 Requirements
The programmer specifies what is to be executed before waiting for input from the end-user and what is to be executed afterwards. Communication between the two sub-modules (1) announces that the first module has completed its execution and that the second sub-module is waiting before proceeding (2) communication from the end-user to the sub-module, and (3) communication from this end-user signalling module to the sub-module that is waiting indicating that the end-user wants the processing to continue.
5.3.1.3 Discussion
This design could be used to allow a measurement process to collected data in a WSN that will be buffered (by the first sub-module) until the end-user connects and activates the third sub-module (e.g. sending measured data to the end-user).
Announcing the presence of the end-user could be done by broadcasting the end-user’s presence over the whole WSN independent of the entry point that is being used by this user to connect to the (previously disconnected) WSN.
More generally we can think of the activity as: Execute process; signal that you are at the barrier; wait at the barrier; execute the process. As there can be multiple such barriers in the WSN, especially if the WSN is being used to perform several different tasks. This implies that we need labels for the barriers – so that the end-user can know which barrier the execution is waiting at, in order to be able to say which of these is to continue.
5.3.2 Buffer/Store
In many WSN applications there is a need to temporarily store data. In both connected and disconnected WSNs this is needed.
An example of when a buffer/store module would be used is when data traversing through the network, or between different modules, needs to wait for a certain event to happen before it can continue. In a disconnected scenario it is likely that the buffer/store module will be used by another module made for disconnected scenarios (e.g userwait module) and therefore might have dual functionalities for better utilization, e.g. it might both write and read data depending on the situation.
5.3.2.1 Design
The Buffer/Store module stores data locally at a node when given data. The stored data will now be available from this buffer, for use by other modules. This module is simple in its design and different implementations of this module can be constructed depending on the policy used for storage. In a disconnected scenario this module would store data when given input and should be able to output all its previous data upon request. Depending on the policy the data that has been output could be removed from the buffer or not.
5.3.2.2 Requirements
To identify this buffered data some sort of identifier is needed. The data can be retrieved later using this identifier. The module must be able to receive input in some way and return the buffered data as output. This data could be stored in a local file system.
5.3.2.3 Discussion
The Buffer/Store module functionality is needed both for buffering scenarios and for persistent storage in the nodes of the WSN. Many different implementations of this module are possible and each of them might be useful in specific situations depending on the application.
These different implementations have different properties, hence raising a number of questions, such as whether the data can be asked for only once or more than once; whether asking for the data using this identifier is idempotent, i.e., that it returns the same data, or if it only returns the data currently stored using this identifier; when should data be deleted; when can identifiers be re-used; what is the valid scope of an identifier (for example is it a locally valid ID or globally valid ID – in the later case can it be guaranteed to be unique); … . These questions need to be taken into consideration when implementing a new module.
5.3.3 Replicate
In many applications copies of data values need to be made available to more than one node, i.e., the data needs to be replicated. As this is a general problem, it should have a general solution; but the solution may need to be parameterized. Forwarding data from one node to another can be achieved by the degenerate case of replication to a single node.
An example where the replicate functionality is helpful is in mobile disconnected WSNs where data gathering relies on nodes being in the vicinity of a sink that collects data. The end-user would not always be able to connect to moving nodes, but the sink would be static and might always reachable. A node that will never be near the sink could replicate its data to other nodes that might upload their own data along with the replicated data from other nodes to the sink when the node is near a sink.
