Wireless Sensor Network Operating System Design Rules Based on Real-World Deployment Survey

: Wireless sensor networks (WSNs) have been a widely researched ﬁeld since the beginning of the 21st century. The ﬁeld is already maturing, and TinyOS has established itself as the de facto standard WSN Operating System (OS). However, the WSN researcher community is still active in building more ﬂexible, efﬁcient and user-friendly WSN operating systems. Often, WSN OS design is based either on practical requirements of a particular research project or research group’s needs or on theoretical assumptions spread in the WSN community. The goal of this paper is to propose WSN OS design rules that are based on a thorough survey of 40 WSN deployments. The survey unveils trends of WSN applications and provides empirical substantiation to support widely usable and ﬂexible WSN operating system design.


Introduction
Wireless sensor networks are a relatively new field in computer science and engineering. Although the first systems that could be called WSNs were used already in 1951, during the Cold War [1], the real WSN revolution started in the beginning of the 21st century, with the rapid advancement of micro-electro-mechanical systems (MEMS). New hardware platforms [2,3], operating systems [4,5], middleware [6,7], networking [8], time synchronization [9], localization [10] and other protocols have been proposed by the research community. The gathered knowledge has been used in numerous deployments [11,12]. TinyOS [4] has been the de facto standard operating system in the community since 2002. However, as the survey will reveal, customized platforms and operating systems are often used, emphasizing the still actual WSN user need for a flexible and easily usable OS.
The goal of this paper is to summarize WSN deployment surveys and analyze the collected data in the OS context, clarifying typical deployment parameters that are important in WSN OS design.

Methodology
Research papers presenting deployments are selected based on multiple criteria: • The years 2002 up to 2011 have been reviewed uniformly, without emphasis on any particular year.
Deployments before the year 2002 are not considered, as early sensor network research projects used custom hardware, differing from modern embedded systems significantly. • Articles have been searched using the Association for Computing Machinery (ACM) Digital Library (http://dl.acm.org/), the Institute of Electrical and Electronics Engineers (IEEE) Xplore Digital Library(http://ieeexplore.ieee.org/), Elsevier ScienceDirect and SpringerLink databases. Several articles have been found as external references from the aforementioned databases. • Deployments are selected to cover a wide WSN application range, including environmental monitoring, animal monitoring, human-centric applications, infrastructure monitoring, smart buildings and military applications.
WSN deployment surveys can be found in the literature [13][14][15][16][17][18]. This survey focuses on more thorough and detailed review regarding the aspects important for WSN OS design. This survey also contains deployments in the prototyping phase, because of two reasons. First, rapid prototyping and experimentation is a significant part of sensor network application development. Second, many of the research projects develop a prototype, and stable deployments are created later as commercial products, without publishing technical details in academic conferences and journals. Therefore software tools must support experimentation and prototyping of sensor networks, and the requirements of these development phases must be taken into account.
Multiple parameters are analyzed for each of the considered WSN deployments. For presentation simplification, these parameters are grouped, and each group is presented as a separate subsection.
For each deployment, the best possible parameter extraction was performed. Part of information was explicitly stated in the analyzed papers and web pages, and part of it was acquired by making a rational guess or approximation. Such approximated values are marked with a question mark right after the approximated value.

Survey Results
The following subsections describe parameter values extracted in the process of deployment article analysis. General deployment attributes are shown in Table 1. Each deployment has a codename assigned. This will be used to identify each article in the following tables. Design rules are listed in the text right after conclusions substantiating the rule.
The extracted design rulesshould be considered as WSN deployment trends that suggest particular design choices to OS architects. There is no strict evidence that any particular deployment trend must be implemented in an operating system at all costs. These design rulessketch likely choices of WSN users that should be considered. System for tracking of the position of moving targets in an energy-efficient and stealthy manner 4 Line in the sand [20] 2004 A Line in the Sand: A Wireless Sensor Network for Target Detection, Classification, and Tracking

Battlefield surveillance
System for intrusion detection, target classification and tracking 5 Counter-sniper [21] 2004 Sensor Network-Based Countersniper System Opposing force investigation An ad hoc wireless sensor network-based system that detects and accurately locates shooters, even in urban environments. 6 Electroshepherd [22] 2004 Electronic Shepherd-A Low-Cost, Low-Bandwidth, Wireless Network System Domestic animal monitoring and control Experiments with sheep GPS and sensor tracking 7 Virtual fences [23] 2004 Virtual Fences for Controlling Cows Domestic animal monitoring and control Experiments with virtual fence for domestic animal control 8 Oil tanker [24] 2005 Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea Industrial equipment monitoring and control Sensor network for industrial machinery monitoring, using Intel motes with Bluetooth and high-frequency sampling 9 Enemy vehicles [25] 2005 Design and Implementation of a Sensor Network System for Vehicle Tracking and Autonomous Interception Opposing force investigation A networked system of distributed sensor nodes that detects an evader and aids a pursuer in capturing the evader 10 Trove game [26] 2005 Trove: A Physical Game Running on an Ad hoc Wireless Sensor Network

Child education and sensor games
Physical multiplayer real-time game, using collaborative sensor nodes 11 Elder Radio-Frequency Identification (RFID) [27] 2005 A Prototype on RFID and Sensor Networks for Elder Healthcare: Progress Report

Medication intake accounting
In-home elder healthcare system integrating sensor networks and RFID technologies for medication intake monitoring  Table 2 describes the deployment state and used sensor node (mote) characteristics. SVATS, sensornetwork-based vehicle anti-theft system.  Deployment state represents maturity of the application: whether it is a prototype or a pilot test-run in a real environment or it has been running in a stable state for a while. As can be seen, only a few deployments are in a stable state; the majority are prototypes and pilot studies. Therefore, it is important to support fast prototyping and effective debugging mechanisms for these phases.

Deployment State and Attributes
Despite theoretical assumptions about huge networks consisting of thousands of nodes, only a few deployments contain more than 100 nodes. Eighty percent of listed deployments contain 50 or less nodes, 34%: less than 10 nodes (Figure 1). It seems that the most active period of large-scale WSN deployment has been experienced in the years 2004-2006, with networks consisting of 100 and more nodes ( Figure 2). Another theoretical assumption, which is only partially true, is a heterogeneous network. The majority of deployments are built on homogenous networks with equal nodes: 70% of deployments. However, significant amount of deployments contain heterogeneous nodes, and that must be taken into account in remote reprogramming design. Remote reprogramming is essential, as it is very time-intensive and difficult to program even more than five nodes. Additionally, often, nodes need many reprogramming iterations after initial setup at the deployment site. Users must be able to select subsets of network nodes to reprogram. Different node hardware must be supported in a single network. Although remote reprogramming is a low-level function, it can be considered as a debug phase feature, and external tools, such as QDiff [57], can be used to offload this responsibility from the operating system.
Almost all (95%) networks have a sink node or base station, collecting the data. A significant part of deployments use multiple sinks.
Design rule 2: Sink-oriented protocols must be provided and, optionally, multiple sink support.
Almost half of deployments use a regular mote connected to a PC (usually a laptop) as a base station hardware solution.
Design rule 3: The OS toolset must include a default solution for base station application, which is easily extensible to user specific needs. Table 3 lists the sensing subsystem and sampling characteristics used in deployments. Line in the sand magnetometer and radar ? n 5

Sensing
Counter-sniper sound 1,000,000 n 6 Electro-shepherd temperature ? y 7 Virtual fences -? y  The most popular sensors are temperature, light and accelerometer sensors ( Figure 3).
Design rule 4: The WSN operating system should include an Application Programming Interface (API) for temperature, light and acceleration sensors in the default library set. When considering sensor sampling rate, a pattern can be observed ( Figure 4). Most of the deployments are low sampling rate examples, where the mote has a very low duty cycle and the sampling rate is less than 1 Hz. Other, less popular application classes use sampling in the range 10-100 Hz and 100-1,000 kHz. The former class uses accelerometer data processing, while the latter is mainly representative of audio and high sensitivity vibration processing. A significant part of applications have a variable sampling rate, configurable in run time. . Sensor sampling rate used in deployments-Low duty cycle applications with sampling rate below 1 Hz are the most popular; however, high-frequency sampling is also used; the ranges 10-100 Hz and 10-100 kHz are popular.
Design rule 5: The operating system must set effective low-frequency, low duty-cycle sampling as the first priority. High performance for sophisticated audio signal processing and other high-frequency sampling applications is secondary, yet required.
GPS localization is a widely used technology, in general; however, it is not very popular in sensor networks, mainly due to unreasonably high power consumption. It is used in less than 18% of deployments. A GPS module should not be considered as a default component. Table 4 describes energy usage and the target lifetime of the analyzed deployments.  Target lifetime is very dynamic among applications, from several hours to several years. Long-living deployments use a duty-cycle below 1%, meaning that sleep mode is used 99% of the time. Both, very short and very long, sleeping periods are used: from 250 milliseconds up to 24 hours.

Lifetime and Energy
Operating systems should provide effective routines for duty-cycling and have low computational overhead.
A significant part of deployments (more than 30%), especially in the prototyping phase, do not concentrate on energy efficiency and use a 100% duty cycle.
Design rule 6: The option, "automatically activate sleep mode whenever possible", would decrease the complexity and increase the lifetime for deployments in the prototyping phase and also help beginner sensor network programmers.
Although energy harvesting is envisioned as the only way for sustainable sensing systems [58], power sources other than batteries or static power networks are rarely used (5% of analyzed deployments). Harvesting module support at the operating system level is, therefore, not an essential part of deployments, until today. However, harvesting popularity may increase in future deployments, and support for it at the OS level could be a valuable research direction.
More than 80% of deployments have powered motes present in the network: at least one node has an increased energy budget. Usually, these motes are capable of running at 100% duty cycle, without sleep mode activation. Design rule 7: Powered mote availability should be considered when designing a default networking protocol library. Table 5 lists used motes, radio (or other communication media) chips and protocols.  Mica2 [64] and MicaZ [3] platforms were very popular in early deployments. TelosB-compatible platforms (TMote Sky and others) [2,65] have been the most popular in recent years.

Sensor Mote
Design rule 8: TelosB platform support is essential.
MicaZ support is optional, yet suggested, as sensor network research laboratories might use previously obtained MicaZ motes, especially for student projects.
Almost half of deployments (47%) use adapted versions of off-the-shelf motes by adding customized sensors, actuators and packaging ( Figure 5). Almost one third (32%) use custom motes, by combining different microchips. Often, these platforms are either compatible or similar to commercial platforms (for example, TelosB) and use the same microcontrollers (MCUs) and radio chips. Only 20% use motes off-the-shelf with default sensor modules.
Design rule 9: The WSN OS must support implementation of additional sensor drivers for existing commercial motes Design rule 10: Development of completely new platforms must be simple enough, and highly reusable code should be contained in the OS Figure 5. Custom, adapted and off-the-shelf mote usage in deployments-Almost half of deployments adapt off-the-shelf motes by custom sensing and packaging hardware, 32% use custom platforms and only 20% use commercial motes with default sensing modules.
The most popular reason for building a customized mote is specific sensing and packaging constraints. The application range is very wide; there will always be applications with specific requirements.
On the other hand, part of the sensor network users are beginners in the field and do not have resources to develop a new platform to assess a certain idea in real-world settings. Off-the-shelf commercial platforms, a simple programming interface, default settings and demo applications are required for this user class.
Chipcon CC1000 [66] radio was popular for early deployments; however, Chipcon CC2420 [67] is the most popular in recent years. IEEE 802.15.4 is the most popular radio transmission protocol (used in CC2420 and other radio chips) at the moment.
Design rule 11: Driver support for CC2420 radio is essential.
More radio chips and system-on-chip solutions using the IEEE 802.15.4 protocol can be expected in the coming years.

Sensor Mote: Microcontroller
Used microcontrollers are listed in Table 6.  Only a few deployments use motes with more than one MCU. Therefore, OS support for multi-MCU platforms is an interesting option; however, the potential usage is limited. Multi-MCU motes are a future research area for applications running simple tasks routinely and requiring extra processing power sporadically. Gumsense mote is an example of this approach [68].
The most popular MCUs belong to Atmel ATMega AVR architecture [69] and Texas Instruments MSP430 families. The former is used in Mica-family motes, while the latter is the core of the TelosB platform, which has been widely used recently. It must be noted that program memory size is always larger than RAM, sometimes even by a factor of 32. Therefore, RAM memory effective usage is more important, and a reasonable amount of program memory can be sacrificed for that matter.

Sensor Mote: External Memory
Used external memory characteristics are described in Table 7. While external memory of several megabytes is available on most sensor motes, it is actually seldom used (only in 25% of deployments). Motes often perform either simple decision tasks or forward all the collected data without caching. However, these 25% of deployments are still too many to be completely discarded.  Although very popular consumer products, Secure Digital/MultiMediaCard (SD/MMC) cards are even less frequently used (in less than 10% of deployments). The situation is even worse with filesystem use. Despite multiple sensor network filesystems already being proposed previously [70,71], they are seldom used. Furthermore, probably, there is a connection between the (lack of) external memory and filesystem usage-external memories are rarely used, because there is no simple and efficient filesystem for these devices.
Design rule 14: A convenient filesystem interface should be provided by the operating system, so that sensor network users can use it without extra complexity. Table 8 lists deployment communication characteristics.  The data report rate varies significantly-some applications report once a day, while others perform real-time reporting at 100 Hz. If we search for connection between Table 3 and Table 8, two conclusions can be drawn: a low report rate is associated with a low duty cycle; yet, a low report rate does not necessarily imply a low sampling rate-high-frequency sampling applications with a low report rate do exist [24,48,49].

Communication
Typical data payload size is in the range if 10-30 Bytes. However, larger packets are used in some deployments.
Design rule 15: The default packet size provided by the operating system should be at least 30 bytes, with an option to change this constant easily, when required.
Typical radio transmission ranges are on the order of a few hundred meters. Some deployments use long-range links with more than a 1-km connectivity range.
Design rule 16: The option to change radio transmission power (if provided by radio chip) is a valuable option for collision avoidance and energy efficiency.
Design rule 17: Data transmission speed is usually below 1 MBit, theoretically, and even lower, practically. This must be taken into account when designing a communication protocol stack.
Eighty percent of deployments consider the network to be connected without interruptions ( Figure 6)-any node can communicate to other nodes at any time (not counting delays imposed by Media Access Control (MAC) protocols). Only 12% experience interruptions, and 8% of networks have only opportunistic connectivity.
Default networking protocols should support connected networks. Opportunistic connection support is optional. Figure 6. Deployment network connectivity-Eighty percent of deployments consider a network to be continuously connected, while only 12% experience significant disconnections and 8% use opportunistic communication.

Communication Media
Used communication media characteristics are listed in Table 9.  With few exceptions, the communication is performed by transmitting radio signals over air. Ultrasound is used as an alternative. Some networks may use available wired infrastructure.
Eighty-five percent of applications use one, static radio channel; the remaining 15% do switch between multiple alternative channels. If radio channel switching is complex and code-consuming, it should be optional at the OS level.
While directionality usage for extended coverage and energy efficiency has been a widely discussed topic, the ideas are seldom used in practice. Only 10% of deployments use radio directionality benefits, and none of these deployments utilize electronically switchable antennas capable of adjusting directionality in real time [72]. A directionality switching interface is optional; users may implement it in the application layer as needed.

Network
Deployment networking is summarized in Table 10. A mesh, multi-hop network is the most popular network topology-used in 47% of analyzed cases (Figure 7). The second most popular topology is a simple one-hop network: 25%. Multiple such one-hop networks are used in 15% of deployments. Altogether, routing is used in 57% of cases. Maximum hop count does not exceed 11 in the surveyed deployments. A rather surprising finding is that almost half of deployments (47%) have at least one mobile node in the network (while maintaining a connected network).
Design rule 18: Multi-hop routing is required as a default component, which can be turned off, if one-hop topology is used. Topology changes must be expected; at least 11 hops should be supported. Additionally, 30% have random initial node deployment, increasing the need for a neighbor discovery protocol. Neighbor discovery protocols (either explicit or built-in routing) should be provided by the OS.

In-Network Processing
In-network preprocessing, aggregation and distributed algorithm usage is shown in Table 11 and visualized in Figure 8. Application level aggregation is considered here-data averaging and other compression techniques with the goal to reduce the size of data to be sent. Line in the sand y y ? 5 Counter-sniper y n y 6 Electro-shepherd n n n 7 Virtual fences n n n 8 Oil tanker n n n 9 Enemy vehicles y y y As the results show, raw data preprocessing is used in 52% of deployments, i.e., one out of two deployments reports raw data without processing it locally. The situation is even worse with distributed algorithms (voting, distributed motor control, etc.) and data aggregation: it is only used in 20% and 10% of cases, respectively. Therefore, sensor network theoretical assumptions, "smart devices taking in-network distributed decisions" and "to save communication bandwidth, aggregation is used", prove not to be true in reality. Raw data preprocessing and distributed decision-making is performed at the application layer; no responsibility for the operating system is imposed. Aggregation could be performed at the operating system service level. However, it seems that such additional service is not required for most of the applications. Data packet aggregation is optional and should not be included at the OS level. Figure 8. Deployment in-network processing-Raw data preprocessing is used in half of deployments; distributed algorithms and aggregation are seldom used.

Networking Stack
The networking protocol stack is summarized in Table 12.  Forty-three percent of deployments use custom MAC protocols, proving that data link layer problems either really are very application-specific or system developers are not wanting to study the huge amounts of MAC-layer-related published work.
The most commonly used MAC protocols can be divide into two classes: CSMA-based (Carrier Sense Multiple Access) and TDMA-based (Time Division Multiple Access). The former class represents protocols that check media availability shortly before transmission, while in the latter case, all communication participants agree on a common transmission schedule.
Seventy percent use CSMA-based MAC protocols and 15% use TDMA, and the remaining 15% is unclear. CSMA MACs are often used because TDMA implementation is too complex: it requires master node election and time synchronization.
Design rule 19: The operating system should provide a simple, effective and generic CSMA-based MAC protocol by default.
The TDMA MAC option would be a nice feature for the WSN OS, as TDMA protocols are more effective in many cases.
Routing is used in 65% of applications. However, no single best routing protocol is selected-between the analyzed deployment, no two applications used the same routing protocol. Forty-three percent of deployments used custom routing, not published before.
Routing can be proactive: routing tables are prepared and maintained beforehand; or it can be reactive: the routing table is constructed only upon need. The proactive approach is used in 85% of the cases; the remaining 15% use reactive route discovery.
As already mentioned above, the operating system must provide a simple, yet efficient, routing protocol, which performs fair enough for most of the cases. A proactive protocol is preferred.
Design rule 20: The interface for custom MAC and routing protocol substitution must be provided.
Although Internet Protocol version 6 (IPv6) is a widely discussed protocol for the Internet of Things and modifications (such as 6lowpan [73]) for resource-constrained devices have been developed, the protocol is very novel and not widely used yet: only 5% of surveyed deployments use it. However, it can be expected that this number will increase in the coming years. TinyOS [4] and Contiki OS [5] have already included 6lowpan as one of the main networking alternatives.
Design rule 21: It is wise to include a IPv6 (6lowpan) networking stack in the operating system to increase interoperability.
Reliable data delivery is used by 43% of deployments, showing that reliable communication in the transport layer is a significant requirement for some application classes. Another quality-of-service option, data stream prioritizing, is rarely used, though (only 10% of cases).

Design rule 22:
Simple transport layer delivery acknowledgment mechanisms should be provided by the operating system.

Operating System and Middleware
Used operating systems and middleware are listed in Table 13.  TinyOS [4] is the de-facto operating system for wireless sensor networks, as is clearly shown in Figure 9: 60% of deployments use it. There are multiple reasons behind that. First, TinyOS has a large community supporting it; therefore, device drivers and protocols are well tested. Second, as it has reached critical mass, TinyOS is the first choice for new sensor network designers-it is being taught at universities, it has easy installation and pretty well developed documentation and even books on how to program in TinyOS [78]. Operating systems used in analyzed deployments-Sixty percent of deployments use the de-facto standard: TinyOS. Seventeen percent use self-made or customized OSs.
At the same time, many C and Unix programmers would like to use their previous skills and knowledge to program sensor networks without learning new paradigms, nesC language (used by TinyOS), component wiring, etc. One piece of evidence of this statement is that new operating systems for sensor network programming are being developed [5,71,79,80], despite the fact that TinyOS has been here for more than 10 years. Another piece of evidence: in 17% of cases, a self-made or customized OS is used; users either want to use their particular knowledge or they have specific hardware not supported by TinyOS and consider porting TinyOS to new hardware to be too complex.
Deluge [74] and TeenyLIME [77] middleware are used in more than one deployment. Deluge is a remote reprogramming add-on for TinyOS. TeenyLIME is a middleware providing a different level of programming abstraction and, also, implemented on top of TinyOS.
Conclusion: middleware usage is not very popular in sensor networks. Therefore, there is open space for research to develop an easy to use, yet powerful, middleware that is generic enough to be used in a wide application range.

Software Level Tasks
User and kernel level tasks and services are described in Table 14. The task count and objectives are an estimate of the authors of this deployment survey, developed based on information available from research articles. Networking, time synchronization and remote reprogramming protocols are considered kernel services, if not stated otherwise.  Most of deployments use not more than two kernel services (55%) (Figure 10). For some deployments, up to five kernel services are used. The maximum service count must be taken into account when designing a task scheduler-if static service maps are used, they must contain enough entries to support all kernel services.
In the application layer, often, just one task is used, which is typically sense and send (33% of cases) ( Figure 11). Up to six tasks are used in more complex applications.
Design rule 23: The OS task scheduler should support up to five kernel services and up to six user level tasks. An alternative configuration might be useful, providing a single user task to simplify the programming approach and provide maximum resource efficiency, which might be important for the most resource-constrained platforms. Figure 10. The number of kernel level software services used in deployments-fifty-five percent of deployments use two or less kernel services. For 28%, the kernel service count is unknown. Figure 11. The number of application layer software tasks used in deployments.-Thirty-three percent of deployments use just one task; however, up to six tasks are used in more complex cases. The task count is unknown in 18% of deployments 3.14. Task Scheduling Table 15 describes deployment task scheduling attributes: time sensitivity and the need for preemptive task scheduling. Two basic scheduling approaches do exist: cooperative and preemptive. In the former case, the switch between tasks is explicit-one task yields a processor to another task. A switch can occur only in predefined code lines. In the latter case, the scheduler can preempt any task at any time and give the CPU to another task. A switch can occur anywhere in the code.
The main advantage of cooperative scheduling is resource efficiency: no CPU time and memory are wasted to perform periodic switches between concurrent tasks, which could be executed serially without any problem.
The main advantage of preemptive scheduling is that users do not have to worry about task switching-it is performed automatically. Even if the user has created an infinite loop in one task, other tasks will have access to the CPU and will be able to execute.
Preemptive scheduling can introduce new bugs, though; it requires context switching, including multiple stack management. Memory checking and overflow control is much harder for multiple stacks, compared to cooperative approaches with a single stack.
If we assume that the user written code is correct, preemptive scheduling is required only in cases where at least one task is time-sensitive and at least one other task is time-intensive (it can execute for a relatively long period of time). The latter may disturb the former from handling all important incoming events.
Twenty percent of analyzed deployments have at least one time-sensitive application layer task (most of them have exactly one), while 30% of deployments require preemptive scheduling. Even in some cases (10%), where no user-space time-sensitive tasks exist, preemption may be required by kernel-level services: MAC protocols and time synchronization.
Design rule 24: The operating system should provide both cooperative and preemptive scheduling, which are switchable as needed.

Time Synchronization
Time synchronization has been addressed as one of the core challenges of sensor networks. Therefore, its use in deployments is analyzed and statistics are shown in Table 16.  Therefore, no effective duty cycling and multi-hop routing are possible without time synchronization. Time synchronization is used in 38% of deployments, while multi-hop routing is used in 57% of cases (the remaining 19% use no duty-cycling).
Although very accurate time synchronization protocols do exist [81], simple methods, including GPS, are used most of the time, offering accuracy in millisecond, not microsecond range.
Only one of deployments used a previously developed time synchronization approach (not including GPS usage in two other deployments); all the others use custom methods. The reason is that despite many published theoretical protocols, no operating system provides an automated and easy way to "switch on" time synchronization.
Design rule 25: Time synchronization provided by the operating system would be of a high value, saving sensor network designers time and effort for custom synchronization development.

Localization
Another of the most addressed sensor network problems is localization, Table 17. Localization is used in 38% of deployments: 8% use GPS and 30%, other methods. In contrast to time synchronization, the localization problem is very application-specific. Required localization granularity, environment, meta-information and infrastructure vary tremendously: in one case, localization of the centimeter scale must be achieved; in another, the room of a moving object must be found; in another, GPS is used in an outdoor environment. In 73% of the cases, where localization is used, it is custom for this application. It is not possible for an operating system to provide a generic localization method for a wide application class. Neighbor discovery service could be usable-it can help to solve both, localization and routing problems.

A Typical Wireless Sensor Network
In this section, we present a synthetic example of an average sensor network, based on the most common properties and trends found in the deployment analysis. This example can be used to describe wireless sensor networks to people becoming familiarized with the WSN field.
A typical wireless sensor network: • is used as a prototyping tool to test new concepts and approaches for monitoring specific environments • is developed and deployed incrementally in multiple iterations and, therefore, needs effective debugging mechanisms • contains 10-50 sensor nodes and one or several base stations (a sensor node is connected to a personal computer) that act as data collection sinks • uses temperature, light and accelerometer sensors • uses low frequency sensor sampling with less than one sample per second, on average, in most cases; some sensors (accelerometers) require sampling in the range 10-100 Hz, and some scenarios (seismic or audio sensing) use high frequency sampling with a sampling rate above 10 kHz • has a desired lifetime, varying from several hours (short trials) to several years; relatively often, the desired final lifetime is specified; yet, a significantly shorter lifetime is used in the first proof-of-concept trials with a 100% duty cycle (no sleep mode used) • has at least one sensor node with increased energy budget-either connected to a static power network or a battery with significantly larger capacity • has specific sensing and packaging constraints; therefore, packaging and hardware selection are important problems in WSN design • uses either an adapted version (custom sensors added) of a TelosB-compatible [2] or a MicaZ sensor node [3]; also, fully custom-built motes are popular • contains MSP430 or AVR architecture microcontrollers on the sensor nodes, typically with eightbit or 16 with possible topology changes, due to mobile nodes or other environmental changes in the sensing region • has either a previously specified or at least a known sensor node placement (not random) • is likely to use at least primitive raw data preprocessing before reporting results • uses CSMA-based MAC protocol and proactive routing, often adapted or completely custom-developed for the particular sensing task • uses some form of reliable data delivery with acknowledgment reception mechanisms • has been programmed using the TinyOS operating system • uses multiple semantically simultaneous application-level tasks, and multiple kernel services are running in background, creating the necessity for effective scheduling mechanisms in the operating system and, also, careful programming of the applications; cooperative scheduling (each task voluntarily yields the CPU to other tasks) is enough in most cases; yet, it requires even more accuracy from the programmers • requires at least simple time synchronization with millisecond accuracy for common duty cycle management or data time stamping • may require some form of node localization; yet, the environments pose very specific constraints: indoor/outdoor, required accuracy, update rate, infrastructure availability and many other factors

OS Conformance
This section analyzes existing WSN operating system conformance to design rulesdiscussed in this paper. Three operating systems are analyzed here: • TinyOS [4]-de facto standard in the WSN community. Specific environment: event driven programming in nesC language. • Contiki [5]-more common environment with sequential programming (proto-threads [82]) in American National Standards Institute (ANSI) C programming language • LiteOS [71]-a WSN OS providing a Unix-like programming interface • MansOS [84]-a portable, C-based operating system that conforms to most of the design rulesdescribed in this paper.
The conformance to the design rulesis summarized in Table 18. The following subsections discuss the conformance of the listed operating systems, without describing their structure in detail, as they are already published in other publications [4,5,71,84].
As Table 18 reveals, the listed operating systems cover most of the design rules. Exceptions are discussed here.

TinyOS
TinyOS conforms to the majority of the design rules, but not all of them. The most significant drawback is the complexity of the TinyOS architecture. Although TinyOS is portable (the wide range of supported platforms is a proof for it), code readability and simplicity is doubtful. The main reasons for TinyOS complexity are: • The event-driven nature: while event handlers impose less overhead compared to sequential programming, with blocking calls and polling, it is more complex for programmers to design and keep in mind the state machine for split-phase operation of the application • Modular component architecture: a high degree of modularity and code reuse leads to program logic distribution into many components. Each new functionality may require modification in multiple locations, requiring deep knowledge of internal system structure • nesC language peculiarities: confusion of interfaces and components, component composition and nesting and specific requirements for variable definitions are examples of language aspects interfering with the creativity of novice WSN programmers These limitations are at the system design level, and there is no quick fix available. The most convenient alternative is to implement middleware on top of TinyOS for simplified access to non-expert WSN programmers. TinyOS architecture is too specific and complex to introduce groundbreaking improvements for readability while maintaining backwards compatibility for existing applications.
There are multiple TinyOS inconsistencies with the proposed design rules, which can be corrected by implementing missing features: • TinyOS provides an interface for writing data and debug logs to external storage devices; yet, no file system is available. Third party external storage filesystem implementations do exist, such as TinyOS FAT16 support for SD cards [85]. • TinyOS contains Flooding Time Synchronization Protocol (FTSP) time synchronization protocol [9] in its libraries. However, it requires deep understanding of clock skew issues and FTSP protocol operation to be useful • The temperature, light, acceleration, sound and humidity sensing API is not provided

Contiki
Contiki is one of the most successful examples regarding conformance to the design rulesproposed in this paper.
Contiki does not provide a platform-independent API for popular sensor (temperature, light, sound) and analog-to-digital converter (ADC) access. The reason is that Contiki's mission is not dedicated specifically to sensor networks, but rather to networked embedded device programming. Some of the platforms (such as Apple II) may not have sensors or ADC available; therefore, the API is not explicitly enforced for all the platforms.
Surprisingly, there is no base station application template included. Contiki-collect is provided as an alternative-a complete and configurable sense-and-send network toolset for simple setup of simple sensor network applications.
Portability to new platforms is partially effective. MCU architecture code may be reused. However, the existing approach in Contiki is to copy and duplicate files, even between platforms with a common code base (such as TelosB and Zolertia Z1 [63]). Portability of Contiki can be improved by creating architecture and design guidelines, where a common code base is shared and reused among platforms.

LiteOS
LiteOS conforms to the proposed design rulesonly partially. The LiteOS operating system does not include the networking stack at the OS level. Instead, example routing protocols are implemented at the user level, as application examples. No MAC protocol is available in LiteOS, nor is a unified API for custom MAC and routing protocol development present. The provided routing implements geographic forwarding, without any powered sink node consideration. No IPv6 support or packet reception acknowledgment mechanisms are provided.
Temperature and light sensor reading API is present in LiteOS; the acceleration sensor must be implemented by users.
Only AVR-based hardware platforms are supported, but no TelosB. The source code is, therefore, not optimized for porting to new hardware platforms.
Only preemptive multithreading is available in LiteOS, but no cooperative scheduling. By default, a maximum of eight simultaneous threads are allowed. Additionally, this constant can be changed in the source files. However, each thread requires a separate stack, and running more than eight parallel threads simultaneously on a platform with 4 KiB RAM memory is a rather dangerous experience that can lead to stack overflows and hardly traceable errors. Many parallel task execution is therefore realistic only in scheduling mechanisms sharing stack space between multiple threads.
No time synchronization is included in the LiteOS code base.

MansOS
MansOS [83] is a portable and easy-to-use WSN operating system that has a smooth learning curve for users with C and Unix programming experience, described in more detail in [84]. One of the main assumptions in MansOS design was the need to adapt it to many different platforms. As the deployment survey shows, this is a very important necessity.
MansOS satisfies all design ruleswith two exceptions: • IPv6 support is not built into the MansOS core; it must be implemented at a different level • MansOS provides both scheduling techniques: preemptive and cooperative. In the preemptive case, only one kernel thread and several user threads are allowed. Multiple kernel tasks must share a single thread in this case. For the cooperative scheduler (protothreads, adopted from Contiki [82]), any number of simultaneous threads is allowed, and they all share the same stack space; therefore, the stack overflow probability is significantly lower, compared to LiteOS.

Summary
The examined WSN operating systems, TinyOS, Contiki, LiteOS and MansOS, conform to the majority of the proposed design rules. However, there is space for improvement for every OS. Some of the drawbacks can be overcome by straight-forward implementation of some missing functionality. However, in some cases, a significant OS redesign is required.

Conclusions
This paper surveys 40 wireless sensor network deployments described in the research literature. Based on thorough analysis, design rules for WSN operating system design are proposed. The rules include suggestions related to the task scheduler, networking protocol and other aspects of OS design. Some of the most important concluding design rules: • In many cases, customized commercial sensor nodes or fully custom-built motes are used.
Therefore, OS portability and code reuse are very important. • Simplicity and extensibility should be preferred over scalability, as existing sensor networks rarely contain more than 100 nodes. • Both preemptive and cooperative task schedulers should be included in the OS. • Default networking protocols should be sink-oriented and use CSMA-based MAC and proactive routing protocols. WSN researchers should be able to easily replace default networking protocols with their own to evaluate their performance. • Simple time synchronization with millisecond (instead of microsecond) accuracy is sufficient for most deployments.
The authors believe that these design rules will foster more efficient, portable and easy-to-use WSN operating system and middleware design.
Another overall conclusion based on analyzed data-existing deployments is rather simple and limited. There is still the need to test larger, more complex and heterogeneous networks in real-world settings. Creation of hybrid networks and "networks of networks" are still open research topics.