Surveyed Articles:
[1] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors. In Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks, LCN’04, pages 455–462. IEEE Computer Society, November 2004. 135
[2] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, and R. Han. Mantis OS: An embedded multithreaded operating system for wireless micro sensor platforms. Mobile Networks and Applications, 10(4):563–579, January 2005.
[3] A. Eswaran, A. Rowe, and R. Rajkumar. Nano-RK: An Energy-Aware Resource-Centric RTOS for Sensor Networks. In Proceedings of the 26th IEEE International Real-Time Systems Symposium, RTSS 2005, pages 256–265. IEEE Computer Society, December 2005.
Wireless sensor networks (WSNs) are made up of a multitude of small sensor devices that have wireless communication capabilities. These devices work independently and collaborate to form a network that allows for the transportation of sensor data. The individual devices in the network often have very limited resources, which makes them resource-constrained. Despite their small size, WSNs are able to perform a wide range of tasks, from environmental monitoring to industrial control, due to the collaborative nature of the network.
The limited resources of the individual devices in the network present a challenge in terms of designing efficient and effective communication protocols and algorithms that can ensure optimal network performance in a variety of complex tasks while minimizing energy consumption and memory usage. Therefore, researchers often focus on developing innovative solutions to address the challenges presented by resource-constrained WSNs.
Developing an operating system for sensor nodes is one of the most prominent challenges for designers, as it requires finding a balance between providing an execution environment that is rich enough to enable sophisticated functionality while also remaining within the limitations of the resource-constrained devices. Developing an operating system (OS) for sensor nodes therefore involves designing lightweight mechanisms and abstractions that can provide this level of functionality. Designers must be mindful of the limitations of these devices, such as small memory, processing power, and battery life, and must develop efficient and optimized solutions that can operate within these constraints. To this end, some researchers employ mechanisms such as power management and novel task scheduling methods to further optimize the usage of the limited available resources.
In this paper, I will review the approaches taken by designers of three operating systems, and discuss their architectures, underlying algorithms for accomplishing various tasks, and techniques to overcome resource constraints. I will also highlight the pros and cons of these systems in comparison with each other as well as some prior techniques. These three OSs, namely, Contiki, MANTIS OS and Nano-RK are tailored for the purpose of use in WSNs, and are endowed with multiple design and implementation features that make them suitable for the vital tasks that sensor networks are meant for. The rest of this paper is structured as follows: Section 1 provides an introduction to the OSs in question, and the sections following it list the challenges that these three implementations attempt to address. In the final section, I discuss these approaches and provide a critical view of how they compare in terms of enabling the ultimate goals and usages of WSN operating systems.
Implemented in C, Contiki provides dynamic loading and unloading of individual programs and services. Contiki’s kernel is event-driven, but it also supports preemptive multithreading that is implemented as an optional library and can be used by any program that explicitly needs this functionality. Contiki’s memory footprint depends on the highest number of processes and events that the system is configured to handle, and has a lower bound of 230 bytes of RAM usage.
The Contiki system has two main parts: 1) the core, which is a set of services and libraries that are statically used by the base system, including the kernel itself. 2) the loaded programs, which can be dynamically loaded and unloaded at runtime. The core is saved as a binary image stored in the system before initialization, and is generally untouched after startup.
As part of the core, the service layer points to multiple services (shared libraries used by various applications), which can also be implemented and replaced at runtime. Communication stacks, device drivers and sensor data handling are all instances of services used by various Contiki applications. When a program needs a particular service, it queries the service stub library for the name of it and finds the pertaining process ID to run.
The Contiki kernel offers only the fundamental functionalities for CPU multiplexing and event handling, and does not include a Hardware Abstraction Layer (HAL). Additional features are available as system libraries that can be linked with programs as needed. To link programs with libraries, programs can either be statically linked with core libraries, or be statically linked with libraries that are part of the loadable program, or use services that implement specific libraries. Like all services, these libraries can also be dynamically replaced while the system is running. Instead of using a HAL to communicate with hardware devices, device drivers and applications have to directly interact with the hardware.
MANTIS OS is another lightweight operating system for small sensor nodes, written in C language. MANTIS performs multithreading and preemption, discussed in later sections, and is able to reduce RAM consumption into less than 500 bytes, not including thread stacks. Unlike Contiki and Nano-RK, MANTIS OS is available open source.
The architecture of MANTIS resembles a classic multithreaded system, where application-based threads reside separately from the operating system. The MANTIS System API is shared between all user-level threads, creating a cross-platform and compact architecture that can handle threads from various applications and tasks in a common way. Whereas in Contiki the network stack constitutes a service, MANTIS implements the network stack as yet another application thread. Threads can be initiated and dynamically changed at runtime.
Nano-RK, a small-footprint embedded real-time operating system written in C language, supports the classical operating system multitasking abstractions and network communications for sensor nodes. Due to the time-sensitive nature of sensor applications especially for surveillance and environment monitoring purposes, priority-based preemption is used in the system for task scheduling, to ensure that high-priority tasks are given permission to block other tasks and run in real time.
An important feature of Nano-RK, which distinguishes it from the other two OSs, is the ability to predict and assign reservations to each application and sensor, in terms of CPU processing power, network bandwidth and energy. Reservations and access control are performed statically at design time, leading to the development of embedded tools that predict an energy budget for each application.
The most limited resource in most sensor networks is the RAM, as sensor devices usually come with 8-bit microcontrollers, about 100 kilobytes of code memory and less than 20 kilobytes of RAM. Moore's Law anticipates that these devices can be considerably reduced in size and cost in the future. Even though this implies that sensor networks can be deployed to a more extensive range, it does not guarantee that resources will be less restricted.
The majority of embedded system operating systems require that a complete binary image of the system be constructed and loaded onto each device. This binary usually contains the operating system, system libraries, and the running applications. To eliminate the need for this, Contiki enables the loading and unloading of specific applications or services while the system is running. Generally, individual applications are much smaller than the entire system binary, resulting in less energy consumption during transmission over a network. Moreover, transferring an application binary takes less time than transmitting an entire system image.
Contiki uses an event-driven kernel that performs multithreading as a service in higher levels of operation (Section 3 provides a detailed description of this approach). This framework tackles the memory constraints to some extent by carrying out processes to completion and reusing variables as a result.
Unlike Contiki, MANTIS OS attempts to take a traditional multithreading approach. Due to the multi-threaded implementation, locks and stacks are used in the RAM, resulting in a stack allocation memory overhead (more on this issue can be found in Section 3). However, MANTIS also accounts for the limitations of WSNs that pose difficulties in developing multithreaded systems, e.g. limited run-time memory and energy lifetimes by using a dynamic approach to programming, which keeps the system light-weight and flexible.
Nano-RK addresses the memory limitations of WSN differently. To align with typical embedded systems requirements, this OS architecture attempts to prioritize optimizing for runtime efficiency and RAM over ROM. In Nano-RK, a static design-time configuration is also preferred over a dynamic one, as dynamic approaches require additional data storage and run-time manipulations.
Nano-RK takes a reservation-based approach to resource management, further allowing the system to prioritize using memory resources for more important and time-sensitive tasks. This style of enforcing temporal isolation and ensuring timeliness follows the reservation paradigm, as previously implemented in a Resource Kernel (RK). In this paradigm, applications define their timeliness and resource requirements, and the OS guarantees access to system resources and schedules tasks to meet the timeliness requirements. While resource kernels have been used in dynamic runtime settings, the resource reservation paradigm is also useful for static configurations. To illustrate the idea, a sensor application task can define its CPU cycle, network bandwidth, and network buffer requirements over fixed periods, which are then enforced by the kernel. Only tasks that have not depleted their reservation quota rates are eligible for scheduling, and each reservation is associated with precisely one task to accommodate the strict constraints of sensor nodes. This is unlike traditional resource kernels, which allow for multiple tasks to use a single reservation.
When operating in severely memory-limited environments, a multithreaded approach often results in significant memory consumption. Each thread necessitates its own stack, and because the stack's required size is typically hard to predict beforehand, it usually must be over-provisioned. Additionally, memory must be allocated for each stack when a new thread is created. Furthermore, stack memory cannot be shared among multiple threads concurrently and can only be utilized by the specific thread it was allocated to. A multithreaded approach also necessitates locking mechanisms to prevent concurrent threads from accessing shared resources.
To address these challenges and provide concurrency without requiring per-thread stacks or locking mechanisms, Contiki kernel uses an event-driven approach, which means that each task is treated as an event, triggering an event handler process which has to be run to completion. This means that each application task has to be done before the next begins, hence eliminating the need for a locking mechanism and allowing the reusing of variables without logic issues.
A traditional event-driven model has a few problems: First, conceptualizing a program as a state machine can sometimes be hard for programmers, making it difficult to write programs for such systems. Second, some programs are longer-lived and would take up CPU resources if no other thread/process is allowed to run concurrently. To address these challenges, Contiki has a combination of event handling and preemptive multithreading to help reduce the risk of one thread getting all resources, using preemption as a solution. That said, the multi-threading mechanism is implemented as an application library as opposed to system components, and each running program can dynamically link with this library and use concurrency and preemption, if it requires this functionality.
It is important to note that the preemption mechanisms in Contiki do not allow for events preempting each other. The goal of preemption is to prepare the system for external events such as sensor inputs, incoming communication packets. To reach this objective, events in Contiki can be preempted by interrupts coming from hardware devices or real-times system calls. An interrupt leads to an immediate polling event that may be prioritized over the running task, managed by an interrupt handler, and get back to the previously running process
Contiki uses the same stack for all threads, but splits it to allocate each part to the corresponding thread until that thread yields or is preempted. The memory requirement for this architecture is therefore quite compact, but an overhead exists for stack switching, polling and preemption.
MANTIS OS also uses preemptive multithreading. Unlike Contiki, however, MANTIS does not use an event-driven model and includes locking mechanisms such as mutex and semaphore, rendering a system more familiar to programmers. MANTIS kernel is a UNIX-style kernel with priority-based thread scheduling and time-slicing. The rationale for this design decision is that in event-driven sensor systems, The execution of tasks is sequential and uninterrupted by other tasks; however, external events may cause interruptions. Since there is only one task being executed at a time and there are no context switches, a single stack suffices in those scenarios. For simple systems with no complicated tasks, an event-driven design is ideal as it does not require polling or blocking of threads, and eliminates the memory burdens of context switching and stack allocation. That said, as WSNs move towards performing increasingly complex tasks, simplistic event-driven models may require programmers to modularize their code. Modularization implies making difficult judgments about the time requirements of the system, which is why MANTIS uses time-slicing within a multithreaded OS instead. The significance of time-slicing is that in sensor networks, certain time-sensitive tasks should not be blocked. While a traditional multi-thread approach would block a current thread to execute another, a time-sliced thread would begin executing at certain time intervals, possibly not interfering with running threads while still achieving concurrency.
In MANTIS, the memory for thread stacks is allocated by the kernel upon thread creation in the static part of the RAM. Information about all threads is stored in a thread table, including the maximum number of threads and memory overhead the system can have, which can be configured at compile time. When a thread is suspended (for example upon preemption, system calls or semaphore operations), its context is stored and a pointer to this information is written to the thread table. Similar to Contiki, MANTIS’s device drivers may send a timer interrupt to the kernel and post a semaphore that activates an interrupt-handler thread.
Nano-RK follows a POSIX time structure and an interrupt-driven approach for scheduling tasks. Real-time synchronization is supported in this system, and a shared buffer is used for all applications through a zero-copying approach that facilitates sharing information among the tasks. Semaphores and mutexes are used for guarding access to shared resources, and priority-based event scheduling is used to give way to the most important tasks while taking into account their assigned reservation of time, power and resources. In this sense, Nano-RK is similar to MANTIS in that no polling is involved and shared resources require management using locks; however, Nano-RK has the additional benefits of priority scheduling and awareness of the reservations assigned to each task.
Sensor networks are composed of a large number of interconnected sensors that work collaboratively to collect data from the environment. Communication is the process by which data is transmitted between sensors in a network. It allows sensors to share information with one another, and to communicate with a central control unit or gateway, which may be responsible for aggregating and processing the data collected by the sensors.
In a sensor network, efficient communication is critical because the data collected by the sensors is typically distributed across a wide area, and may need to be transmitted over long distances. The reliability and efficiency of the communication system can therefore directly impact the overall performance and accuracy of the sensor network.
Contiki implements communication as a service, which enables smooth protocol and hardware replacement during runtime. Additionally, the communication stack can be broken down into multiple services, facilitating the replacement of specific components of the stack during runtime. Each communication task can raise an event that has to run to completion, and all communications use one buffer, which suffices since only one process may use the buffer at a time. In this process, packets are sent from the device driver to the communication buffer and the communication service is then called to handle that packet by sending it to the program that the communication was intended for.
In MANTIS OS, wireless communication is performed using a layered network stack. The stack is implemented similar to a user-level thread. A hardware communication layer similar to that of Contiki’s also exists in MANTIS (called the COMM layer). The COMM layer is an interface for communication with device drivers such as serial, radio and USB, while also managing buffering for sent and received packets. The thread that receives a packet within a buffer is responsible for freeing the buffer once done with the packet, so that the COMM layer can use that buffer for a next communication task. This mechanism eliminates the need for copying data and helps communication using a set of shared buffers. The COMM layer is also interrupt-driven and does not require polling, which reduces the energy consumption of the system.
Similar to MANTIS, Nano-RK uses a lightweight network protocol stack for port-based communication. A periodic task is responsible for packet transmission checking and the network stack uses a zero copy buffer mechanism to manage networking buffers.
Hardware abstraction is the process of creating a software layer that shields the application developer from the details of the underlying hardware. In wireless sensor networks, hardware abstraction can provide a number of benefits:
portability: By abstracting the hardware, application developers can write code that can run on a wide range of hardware platforms without needing to rewrite it for each different platform.
flexibility: Hardware abstraction allows developers to easily swap out different hardware components or sensors without needing to modify the application code. This can make it easier to upgrade or replace components as needed.
simplification: By hiding the details of the hardware from the application developer, hardware abstraction can make it easier to write and debug code. This can save time and reduce errors.
standardization: Hardware abstraction can help to standardize the interfaces between the application and the hardware, making it easier to develop and test applications for different hardware platforms.
reduced development time: Hardware abstraction can speed up the development process by providing pre-built libraries and tools that can be used to develop applications more quickly.
Despite these advantages, Contiki’s designers believe that sensor networks are inherently application-specific and would therefore benefit more from having other specific abstractions installed as libraries and services. The only abstractions the base Contiki OS provides include CPU multiplexing and program loading. Similarly, the kernel in Contiki does not have an explicit hardware abstraction layer (HAL). By contrast, Nano-RK has a unified sensor interface abstraction that allows users to access sensor readings and actuate responses without seeing low-level details of node configurations. While the authors do not explore this in extension, it seems this part of the system can add to the flexibility of the OS by allowing new and modified hardware installations in a more efficient manner. MANTIS OS does not provide any abstractions.
Dynamic and remote reprogramming of sensor nodes is a great feature of some WSN systems that can save time and effort. Sensor networks can benefit greatly from dynamic reprogramming or retasking, as it allows for remote reconfiguration of sensor nodes over a wireless multi-hop network, even after they have been deployed in the field. This feature allows for replacement of code at runtime, and eliminates the need to go out in the field and reprogram nodes manually. Research suggests that sensor nodes should have the ability to be remotely reconfigured, especially since sensor networks may be deployed in hard-to-reach areas and can involve a large number of nodes. With this approach, the need for field visits by biologists to reprogram sensors or make changes to parameters such as sampling rates and trigger thresholds is eliminated, and performing tasks like sensor calibration or time synchronization can be done more conveniently.
Both Contiki and MANTIS attempt at facilitating dynamic reprogramming of sensor nodes. The reason for this capability is the feasibility of a flexible architecture that implements network communications as a service, so as to enable run-time replacement, i.e. services are processes that can be dynamically loaded and replaced. Hence, a statically-designed OS such as Nano-RK is not capable of supporting this feature.
Contiki allows users to perform efficient over-the-air by sending a program binary to a sensor node through wireless network, and modify existing node programs at runtime. On the other hand, MANTIS supports dynamic reprogramming through reflashing the entire OS, reprogramming a single thread, or changing a variable inside a thread. It provides a remote shell that allows users to log in and monitor the memory status of a sensor node, and debug running threads if needed. The simplest method that MANTIS uses for reprogramming involves direct communication with a sensor node, for example by connecting the node to a PC via a serial port. The user can upload a new code image to the node for reprogramming purposes, as well as inspect and change memory and threads within that node. A more sophisticated version of this protocol involves in-situ reprogramming of already-deployed nodes, which is similar to Contiki’s approach. MANTIS supports remote login and modification of variables, however the dynamic reprogramming of the full OS is work in progress.
In designing a sensor OS, memory efficiency is not the only concern as micro sensor nodes also require energy efficiency. These nodes are frequently deployed in areas without access to the electrical power grid and depend on battery power or energy harvesting techniques such as solar cells. With a set of new AA batteries, the lifetime of sensor nodes can be extended to a few months by reducing the duty cycle. Consequently, the design of a sensor OS (especially if thread-driven) must achieve not only a lightweight memory footprint, but also energy-efficient operations.
Reducing energy consumption in sensor networks often requires powering down nodes when the network is inactive. The specific power conservation mechanisms employed depend on both the applications being used and the network protocols in place. Although the Contiki kernel lacks explicit power-saving abstractions, it allows application-specific components to implement such mechanisms. The event scheduler in Contiki provides the size of the event queue to assist applications in determining when to power down the system. By monitoring the event queue, the processor can be powered down when no events are scheduled. When the processor wakes up in response to an interrupt, poll handlers are run to handle the external event.
The designers of MANTIS OS believe that although event-driven kernels are better at saving power, sensor networks should be able to handle increasingly complex tasks, which inevitably involves concurrency and multithreading. To address the power consumption problem associated with threads, MANTIS takes an interesting approach: an energy-saving thread is implemented that manages power consumption. To be specific, apart from the driver threads and user threads, MANTIS kernel generates an idle thread during startup. This thread runs with low priority and only executes when all other threads are blocked. As the idle thread is not assigned any specific task, it can be utilized for power-aware scheduling, using the capability to detect patterns in CPU utilization and adjust kernel parameters to conserve energy accordingly.
Additionally, the COMM layer in MANTIS is interrupt-driven and does not require polling, which saves power. One of the most energy-consuming tasks in WSNs is the network communications. In MANTIS, the MAC layer protocol is a part of the device driver responsible for the radio, which is located in the comm layer. The MAC layer takes charge of the network duty cycle, which involves adapting the radio to sleep mode to save energy consumption, and transmit power control.
Unlike Contiki and MANTIS which include power management in the system as a feature, Nano-RK is entirely designed as a real-time system that optimizes power consumption and in turn, maximizes battery life of the sensor. Nano-RK implements virtual energy reservations to ensure energy consumption is regulated. The energy consumed by a task is the total sum of CPU/microcontroller energy, radio interface energy, and energy required for sensors and actuators. The operating system accurately adjusts CPU and radio energy consumption by modifying the CPU and network reservation sizes.
To limit the energy consumed by sensors, Nano-RK provides sensor reservations. The unified sensor interface turns off sensors by default and allows atomic operations when accessing sensors. The operating system can set an upper limit on the number of sensor accesses over a given period. Therefore, a resource tuple of (CPU, Network, Sensor) reservations can be mapped to a particular power level. By calculating the mean power used by tasks over a hyper-period, it is possible to estimate the node's lifetime accurately. By modifying the (CPU, Network, Sensor) reservation-tuple values, the mean energy consumed by each task can be varied. This can be used to control node lifetime or distribute the system's energy budget among different tasks. Energy reservations are implemented by controlling the (CPU, Network, Sensor) reservation-tuple during pre-deployment, following the static approach adopted by Nano-RK.
In addition to the aforementioned mechanisms that attempt at addressing particularly pressing issues of traditional operating systems and optimizing the system for their particular use in sensor networks, there are a few more sophisticated features that some of the OSs offer. Although these techniques may not directly contribute to the efficiency and resource-awareness of the system, they can, for instance, help end users implement, program, and debug sensor networks more easily and efficiently.
MANTIS OS Multimodal Prototyping: The MANTIS prototyping environment enables developers to test sensor networking applications before deployment, which is critical to avoid severe consequences. The prototyping environment extends beyond simulation to provide a framework for network management and visualization applications as virtual nodes within a MANTIS sensor network.
Additionally, MANTIS allows an application developer to execute the same C code on both virtual sensor nodes and in-situ physical sensor nodes, enabling phased deployment and testing. MANTIS seamlessly integrates virtual and physical nodes within the prototyping environment, allowing multimodal prototyping in all-virtual, hybrid, and all-physical modes. Also, MANTIS enables a virtual node to leverage other APIs outside of the MANTIS API, thereby permitting it to become another node within the MANTIS network of virtual and physical nodes. This feature enables developers to build visualization and network management applications using other rendering or database APIs.
MANTIS OS Remote Shell: Current solutions for monitoring sensor networks primarily focus on extracting topology and computing network properties summaries to achieve energy-efficient monitoring. However, users may need to manage the nodes in the network in other ways. To provide this flexibility, MANTIS OS includes the MANTIS Command Server (MCS). Using the command server client (referred to as the shell) from any device equipped with a terminal, such as a laptop PC, users can log in to a node that can either be a physical node on a Nymph or Mica board, or a virtual node running as a process on a PC.
The MCS operates as an application thread that listens on the serial and radio for commands sent to either the kernel or an application. Users can inspect and modify the node's memory, change configuration settings, run or stop programs, view the thread table, or restart the node. Additionally, user applications can register their own functions to be called when a specific command is entered from the shell. The user application can receive parameters for their function after it's called, allowing applications to remain dormant until a command is issued. The shell is a valuable debugging tool as it enables users to examine and modify the state of any node without requiring physical access.
The remote shell is part of a visualization application called 'cortex' that runs on a remote laptop and is included as part of the MANTIS release. The cortex can receive sensor data and initiate commands to the sensor network. In this demo application, clicking on the LEDs will light the LED on all sensor nodes. More advanced commands are sent via the remote shell interface, which is not shown in this screenshot. The cortex application is an example of an XMOS virtual sensor node, where the server application acts as an XMOS virtual sensor node that receives sensor data packets from the real sensor network, and the visualization GUI connects to the server.
Contiki is an operating system that combines the benefits of both events and threads. It predominantly utilizes an event-driven model, but also offers multithreading as an optional application-level library, which can be linked by applications that require it. In Contiki, events are categorized as either synchronous or asynchronous. Synchronous events are scheduled immediately, while asynchronous events are scheduled later. To avoid race conditions, a polling mechanism is employed. In Contiki, device drivers and sensor data handling are implemented as services, as is communication. Implementing communication as a service facilitates run-time replacement and allows for multiple communication stacks to be loaded simultaneously. Each service comprises both interface and implementation components, with applications only being aware of the interfaces. This design enables the service implementation to be changed at run time through a stub library, which is linked with the application to access services.
MantisOS is an operating system model for sensor networks that is thread-driven. Unlike event-driven models, thread-driven models offer flexibility in application development as developers do not need to be concerned about task size. Applications are executed by spawning multiple threads, and the network stack and scheduler are also implemented as threads. An idle thread is present to run when all other threads are blocked, invoking the necessary power management routines. To maintain threads, the kernel keeps a thread table that includes thread priority, a pointer to the thread handler, and other relevant information. Scheduling between threads is accomplished via a scheduler that uses priority-based scheduling algorithms with round-robin semantics. Race conditions are avoided using binary and counting semaphores.
In MantisOS, communication is achieved through a layered network stack designed to minimize memory buffer allocation across layers. It supports the network layer routing, transport layer, and application layer (i.e., layer three and above). MAC protocol support is provided by another communication layer located in a separate lower layer of the OS, distinct from and below the user-level networking stack.
However, one of the main drawbacks of adopting a thread-driven model is that MantisOS suffers from the overheads of context switching and the memory allocated in the form of a stack for each thread.
Nano-RK is an operating system specifically designed for Wireless Sensor Networks (WSNs). It follows a reservation-based, multi-tasking approach and is developed as an extension of the Resource-Kernel (RK) paradigm. The operating system assigns priorities to each task, and higher priority tasks are given preference over lower priority ones. To ensure timely execution of time-sensitive tasks, the rate-monotonic scheduling algorithm is employed. This algorithm schedules tasks based on their rates, and deadlines are met accordingly. The applications using Nano-RK can define their resource requirements and deadlines as per their specific needs.
Nano-RK has a lightweight network protocol stack that facilitates port-based communication. The network stack is tightly integrated with the operating system, which allows for global optimizations such as automatic packet aggregation, network reservations, and buffer management. An interrupt is generated when a new data packet arrives, and it is handled by the system. The transmission of outgoing packets is managed by a periodic network task responsible for servicing all tasks.
The three operating systems each provide creative solutions to long-standing issues of sensor networks. These include small memory, high energy consumption due to network activities, and real-time, reactionary responses to environmental changes. Contiki and MANTIS OS have a deeper focus on the first problem, while Nano-RK is optimized for the other two issues. As we move forward with manufacturing smaller devices and lower resources and using them for more complex tasks, access to architectures similar to these three OSs are critical for making the best out of sensor networks and ensuring their safety and security requirements.