A Survey on Resource Management in IoT Operating Systems

and

Bashir, Ali Kashif

and

Kim, Sung Won

(2018)A Survey on Resource

Management in IoT Operating Systems.

IEEE Access, 6. pp. 8459-8482.

ISSN 2169-3536

Downloaded from:

http://e-space.mmu.ac.uk/622914/

Publisher:

Institute of Electrical and Electronics Engineers (IEEE)

DOI:

https://doi.org/10.1109/access.2018.2808324

Please cite the published version

Received January 8, 2018, accepted February 9, 2018, date of publication February 21, 2018, date of current version March 12, 2018.

Digital Object Identifier 10.1109/ACCESS.2018.2808324

A Survey on Resource Management in

IoT Operating Systems

ARSLAN MUSADDIQ1_{, YOUSAF BIN ZIKRIA}1_{, (Senior Member, IEEE), OLIVER HAHM}2_,

HEEJUNG YU1, ALI KASHIF BASHIR 3, (Senior Member, IEEE), AND SUNG WON KIM 1

1_{Department of Information and Communication Engineering, Yeungnam University, Gyeongsan 38541, South Korea} 2_{Zuehlke Engineering GmbH, 65760 Eschborn, Germany}

3_{Faculty of Science and Technology, University of the Faroe Islands, 100 Faroe Islands, Denmark} Corresponding author: Sung Won Kim ([email protected])

This work was supported by the 2017 Yeungnam University Research Grant.

ABSTRACT Recently, the Internet of Things (IoT) concept has attracted a lot of attention due to its capability to translate our physical world into a digital cyber world with meaningful information. The IoT devices are smaller in size, sheer in number, contain less memory, use less energy, and have more computational capabilities. These scarce resources for IoT devices are powered by small operating systems (OSs) that are specially designed to support the IoT devices’ diverse applications and operational requirements. These IoT OSs are responsible for managing the constrained resources of IoT devices efficiently and in a timely manner. In this paper, discussions on IoT devices and OS resource management are provided. In detail, the resource management mechanisms of the state-of-the-art IoT OSs, such as Contiki, TinyOS, and FreeRTOS, are investigated. The different dimensions of their resource management approaches (including process management, memory management, energy management, communication management, and file management) are studied, and their advantages and limitations are highlighted.

INDEX TERMS Internet of Things, operating systems, resource management, Contiki, TinyOS, FreeRTOS.

I. INTRODUCTION

The demands on Internet of Things (IoT) technologies have grown rapidly due to the various application fields and the advancements in wireless communications

technolo-gies [1], [2]. The term things in the Internet of Things

is a piece of equipment having a sensing, actuating, stor-age, or processing capability. These devices possess unique characteristics, i.e., little memory, reduced battery capacity, and limited processing power [3]. The IoT has great potential to impact our lives in the future. From home automation to healthcare systems, the IoT has numerous applications to improve industries and society by enabling smart com-munication between objects and devices in a cost-effective manner [4], [5]. Therefore, it is predicted that there will be about 50 billion IoT devices by 2050 [6]. Due to the expan-sion of IoT networks in the last decade, various hardware platforms have been developed to support IoT sensors and actuators. Similarly, a number of operating systems (OSs) have gradually been developed to run these tiny sensors [7]. Various IoT communications standards have emerged from different organizations. For example, the Internet

Engineering Task Force (IETF) [8], the International

Telecommunication Union-Telecommunication (ITU-T) [9], the Institute of Electrical and Electronics Engineers (IEEE),

the European Telecommunications Standards Institute

(ETSI) [10], the International Organization for Standard-ization (ISO) and the International Electrotechnical Com-mission (IEC) [11], One Machine-to-Machine (M2M) [12] and the 3rd Generation Partnership Project (3GPP) [13] are actively working to provide efficient IoT communi-cations protocols. The IETF currently has various work-ing groups (WGs) that deal with IoT-related protocols on any layer above the link layer (e.g., at the network layer). The IETF Routing over Lossy and Low-Power Network (ROLL) WG (RFC 6550) [14] is focused on providing standardization of the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL). Similarly, the IETF IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (RFC 4944) [15] works on IPv6 networking protocol opti-mization using IEEE 802.15.4. The IETF 6loBAC WG (RFC Ed Queue) [16] provides specifications for transmis-sion of IPv6 packets on master-slave/token-passing (MS/TP) networks. The IETF 6TiSCH Operation Sublayer (6TOP) WG (RFC Ed Queue) [17] defines the mode of operation 2169-35362018 IEEE. Translations and content mining are permitted for academic research only.

for IPv6 using an IEEE 802.15.4e (6TiSCH) network. Data-gram Transport Layer Security (DTLS) in a Constrained Environment (DICE) was drafted by the IETF WG DICE (RFC 7925) [18]. At the application layer, the IETF Con-strained Application Protocol (CoAP, RFC 7252) provides web services to constrained devices [19]. Concise Binary Object Representation (CBOR, RFC 7049) provides binary representation of structured data [20]. The Object Signing and Encryption (COSE) WG (RFC Ed Queue) focuses on creating CBOR-based signing and encryption formats [20]. Application layer security for data exchange with CoAP using the COSE format is provided by IETF’s Object Security of CoAP (OSCoAP, RFC 7744) [21].

Similarly, ITU-T provided an overview of the IoT and its reference model [22]. ITU-T Task Group 15 (TG-15) is working on smart grid communications aspects of the IoT [23]. Similarly, ITU-T TG 17 is focusing on secu-rity and identity management aspects of the IoT [24]. An ISO/IEC joint technical committee does not develop standards but it provides current and future IoT trends and requirements [25]. The IEEE defines an architectural frame-work for the IoT [26]. The IEEE P2413 frame-working group provided a description of ‘‘various IoT domains, definitions of IoT domain abstractions, and identification of common-alities between different IoT domains’’ [27]. The IoT IEEE 802.15 working group is dealing with medium access con-trol (MAC) and physical layer specifications for wireless personal area networks (WPANS), a mesh topology capa-bility in WPANs, and short-range wireless optical commu-nications using visible light. ETSI has developed a low-throughput network (LTN) as a wide area network (WAN) for the IoT [28]. One M2M is a standardization body that consists of eight world standard development organizations. Their goal is to develop a common standard for M2M com-munications. 3GPP is also working to meet IoT requirements [29]. LTE Release 12 [30] from 3GPP provides a power-saving mode and a lower overhead signaling procedure to provide energy efficiency [31]. An IoT OS should be flexible enough to support these protocols without violating the needs of resource-constrained tiny devices.

IoT devices have limited memory and power and require real-time capabilities in some scenarios. Additionally, they should support heterogeneous hardware along with efficient connectivity and security mechanisms [32]. Connecting and operating this huge number of devices in an efficient way is one of the most important design goals for the research community. In an IoT system, the fundamental research issue is to manage the available resources in an ordered and con-trolled manner. The ultimate objective of an IoT resource management mechanism is to satisfy IoT device requirements efficiently [33].

IoT devices are classified into two general categories; i.e., high-end IoT devices and low-end IoT devices [7]. High-end devices contain more processing power and energy, such as smartphones and Raspberry Pi. The low-end devices, on the other hand, are too resource-constrained. Therefore,

a traditional OS, such as Linux, cannot run these small resource-constrained devices. Hence, the IoT cannot achieve its full potential until there is a de facto standard OS providing support to run these low-end devices across a heteroge-neous network [6]. Moore’s law [34] is not applicable to IoT devices in terms of processing power. However, it can be applied to device size and energy efficiency [35]. The low-end devices possess very little random access mem-ory (RAM) and few processing capabilities. The IETF [8] developed the IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) standard adaptation layer to enable

low-power low-data-rate communications [36]. These

devices also require real-time capabilities in scenarios like vehicular communications, health care systems, and factory automation and surveillance applications. Providing commu-nications with energy efficiency and reliability is the main objective of the IoT. IoT low-end devices contain small amounts of memory and little processing power. Therefore, in order to satisfy low-end device resources, choosing a suitable lightweight OS is of vital importance. Several OSs have been proposed by numerous companies that offer a different approach to fundamental problems.

The future IoT environment needs to handle and perform tasks independently. Similarly, an ultra-dense network yields computational complexity. In order to cope with IoT low-end–device challenges, such as limited resources, and dis-tributed and dense environments, there is considerable need for an efficient resource management mechanism in an IoT OS [37]. An IoT OS is primarily responsible for managing the device’s resources efficiently. Various OSs have presented different solutions to satisfy low-end devices’ resource needs. To achieve this goal, various mechanisms are provided by the different OSs to provide proper functioning of sensing nodes. Among various proposed OSs for low-end devices, the Contiki [38], TinyOS [39], and FreeRTOS [40] are most prominent for operating in a resource-starved network. IoT low-end devices usually operate with limited battery power. Consequently, providing an energy-efficient OS is of the utmost importance [41]. These low-end devices transfer the sensed data using a communications protocol. In order to be energy-efficient, the communications protocols should save the maximum amount of energy. Protocols at the transport layer, MAC layer, and network layer need to be energy-efficient [42]–[44].

IoT devices require computational capabilities for their sensing operations. These constrained sensing motes do not offer extensive memory and processing capabilities (usually 100 kB flash memory and 10 kB RAM). For example, Cross-bow’s Telos B mote provides only 10 kB of RAM and 48 kB of flash memory. Due to this limitation, IoT devices need to manage their resources efficiently. Additionally, densifica-tion, randomness, and uncertainty make IoT device resource management a challenging task. An OS acts as a resource manager for this complex IoT system [32]. To handle the limited processing power and memory, an OS requires an effective process and memory management mechanism. IoT

devices are battery-operated and are mostly deployed in remote environments. Thus, energy management provided by an OS is highly important. The main objective of an IoT system is to provide a sensing operation and transfer the sensed data to the base station for further processing. The communications design, signal processing, data reception, data transmission, and radio sleep/wake mechanism need to be efficient in terms of energy and communications. IoT OSs store, catalog, and retrieve the data using a file system. There-fore, the provision of an efficient, robust, and appropriate file system is highly desirable in IoT OSs.

Moreover, an IoT OS should be highly concurrent to support these low-end–device sensing operations. Hence, the importance of efficient resource allocation in the OS for low-end devices motivates us to write this paper. In this paper, we consider the IoT low-end device resource manage-ment solutions offered by various OSs. To the best of our knowledge, this is the first paper that encompasses detailed information about the resource management mechanisms in Contiki, TinyOS, and FreeRTOS. Various resource manage-ment operations, including process managemanage-ment, memory management, energy management, communications manage-ment, and file management (and their advantages) are dis-cussed in order to make the low-end devices more and more resource-efficient and flexible. Thus, this study has taken all the resource management mechanisms into considera-tion. A list of abbreviations is provided in Table 1, whereas Table 2 provides a comparison of this study and already existing surveys on tiny sensor device OSs.

The contributions of this paper compared to the recent literature in the field are as follows.

a. It provides a literature review related to IoT OSs. b. It covers the resource management aspects of Contiki,

TinyOS, and FreeRTOS, including:

• process management

• memory management

• energy management

• communication management, and

• file management

c. It provides future research directions and challenges in resource management of IoT OSs.

The remainder of this paper is structured as follows. Section II provides an overview of related work. Section III discusses resource management classifications in detail. Section IV provides open research issues and recommendations, fol-lowed by Section V, which concludes the paper.

II. RELATED WORK

Over the years, several OSs for the IoT have emerged. Contiki, TinyOS, and FreeRTOS emerged as predominant OSs to provide support to IoT devices. This section dis-cusses the recent survey papers related to IoT OSs, e.g., Hahm et al. provided a detailed analysis of various require-ments to satisfy low-end IoT devices [7]. The survey dis-cussed various OSs that could become the de facto standard. OSs in this survey are categorized into three types, including

TABLE 1.List of abbreviations.

event-driven OSs, multithreading OSs, and pure real-time operating systems (RTOSs). Along with the key design choices, the characteristics of each category are presented

TABLE 2. Overview of comparison between this study and available surveys.

in the study. Based on the key design choices and low-end device requirements, the most prominent OS representing each category is identified.

Similarly, Amjad et al. discussed several aspects of TinyOS design in detail [45]. This survey encompassed the design paradigm and main features of TinyOS. It has event-driven concurrency, a programming layout based on NesC (a dialect of the C programming language), a monolithic architecture, and a non-preemptive task scheduler. TinyOS memory man-agement, energy manman-agement, and energy-efficient commu-nications protocols were presented. TinyOS uses a software thread integration (TOSSTI) mechanism for energy conserva-tion, which helps an OS utilize busy–wait time in an efficient manner [46]. Similarly, an energy tracking mechanism is also utilized by TinyOS [47]. To maintain network stability and lifetime, TinyOS supports several communications pro-tocols at the transport layer, MAC layer, and network layer. In addition, simulators for TinyOS and its various sensing applications are also discussed in the paper.

Strazdins et al. surveyed wireless sensor network (WSN) deployments and analyzed the collected data to study the design rules for a WSN OS using 40 deployment scenar-ios [48]. Deployments from 2002 to 2011 are reviewed to study different WSN applications, including environmen-tal monitoring, animal monitoring, human-centric applica-tions, infrastructure monitoring, smart buildings, and military applications. The authors studied Contiki, TinyOS, LiteOS, and MansOS, and proposed 25 design rules. The rules

include suggestions related to the task scheduler, networking protocol, and energy-efficiency mechanism.

TinyOS and Contiki are the two best-known OSs for low-end devices. A comparison between these two OSs is pre-sented in a survey by Reusing [49]. The main requirements an OS should fulfill for a sensor network include concur-rency, flexibility, and energy efficiency [50]. The contrast between TinyOS and Contiki is shown based on these require-ments. Special emphasis was placed on a programming model and execution model, along with the hardware platforms supported by both OSs. This survey indicates that TinyOS might be more useful in a resource-constrained environment, whereas Contiki provides more flexibility in the network.

Farooq and Kunz highlighted major challenges for an OS design, and identified the advantages and limitations in an OS for a WSN [51]. For example, Contiki follows a modular kernel concept. It is a layered approach in which application modules are independent and can be linked with a kernel at boot time. In this way, the kernel provides only core services, while other services can be added when required. Hence, it reduces the memory footprint and decreases boot time. However, the kernel may crash due to modules that contain bugs. Similarly, TinyOS follows a monolithic architecture similar to Linux. The monolithic architecture helps to reduce modular interaction costs. However, it may make the OS unreliable and hard to maintain, because no clear boundaries are provided between modules. The alternative is a microker-nel architecture.

FIGURE 1. Resources management classification.

FreeRTOS is an example of a microkernel structure which provides robustness against bugs in the components. The microkernel provides minimum functionalities to the kernel. Hence, the kernel size is reduced significantly. All other func-tions are provided by servers running at the user level. There-fore, OS functionalities are extendable, and failure in one user-level server does not crash the kernel itself. The disad-vantage is poor performance due to user-to-kernel boundary crossing. The OS architecture, programming model, schedul-ing mechanism, memory management, and communications protocol support a major design goal for an IoT OS. Along with resource sharing, support for real-time applications is of vital importance. It is pointed out that some OSs support a priority application capability, whereas few provide real-time applications. Some miscellaneous features, including communication security, file system support, simulation sup-port, and programming language, are also discussed.

Dariz et al. compared Contiki and TinyOS with a real-time OS named ChibiOS to study the safety-relevant application in a WSN [52]. Another OS called LiveOS was introduced to conserve memory and energy for a WSN [53]. Over the years, various OSs have emerged in the WSN community. One of the critical issues for an OS is dealing with a large number of resources to provide ubiquitous services to IoT low-end devices [54]. In this study, we focus on three well-known OSs: Contiki, TinyOS, and FreeRTOS. This study aims to cover all the resource management aspects of a low-end–device OS.

III. RESOURCE MANAGEMENT CLASSIFICATION

OS provides a layer of abstraction for the hardware by manag-ing the resources on each IoT device [55]. The OS provides a programming interface and manages processor time. IoT devices operate in resource-constrained concurrent environ-ments, and to handle this concurrent application, a suitable execution model must be provided by OS. The execution model must provide memory efficiency [56]. Similarly, OS (being battery-powered) must provide a sleep mode when no

application is running [57]. Providing energy efficiency to the communication components is more challenging for an OS. The communication components must wake up during a communication period. Therefore, an OS handles energy efficiency during communication using various mechanisms, for example, a separate radio duty cycling procedure [58], a virtual carrier-sensing mechanism with a network alloca-tion vector, and time-division multiple access (TDMA)-based methods. Not all IoT devices have storage like flash memory. Therefore, an appropriate file system is required to provide storage needs for some applications. The file system needs to efficiently map the data into sectors to make writing and reading of data more efficient. Therefore, an OS must provide a full file system interface [59], [60].

The communications needs of diverse applications are handled by a communications architecture. Considering the device’s resource scarcity, the communications protocols must be energy- and memory-efficient during data collection, event detection or tracking, device synchronization, neigh-bor discovery, and data delivery [61], [62]. To address the resource management challenges for low-end IoT devices, various resource management mechanisms and schemes have been proposed. These resource management schemes fall into five subsections.

The flow chart of resource management in OS for low-end devices is shown in Figure 1.

A. PROCESS MANAGEMENT

In the context of resource management, the kernel manages processes and threads to share information, protect process resources, and assign system resources in a safe way. In the IoT environment, multiple activities may occur during a cer-tain time period. Managing these activities and processes by fairly sharing resources is essential, and it depends on the OS execution model.

The Contiki and TinyOS follow an event-driven execution model to provide memory efficiency and low complexity of

state machines in the event-driven TCP/IP stack [63], [64]. Event handlers continuously wait for internal or external events, such as an interrupt. The kernel allocates the mem-ory stack to the process, and an event handler follows the run-to-completion mechanism. All the processes effectively share the same stack and utilize limited memory efficiently. Some events are queued and processed in first in, first out (FIFO) fashion. The event-driven concurrency model introduces certain complexities if multiple events occur. The task in an event-driven model cannot be blocked during run-time. Sometimes, time-critical tasks need to be exe-cuted first. Therefore, real-time performance of the event-driven approach is poor. Hence, an OS needs multiple event handlers.

Low-end IoT devices offer only few kilobytes of RAM. The multithreading approach allocates a stack of memory to each thread even if the thread is not utilizing memory. Hence, most of this memory is unused. Therefore, a more effective hybrid model is required for better memory effi-ciency and low programming complexity. The Contiki sup-ports a novel, lightweight, stackless threading mechanism called a protothread [65]. The protothread utilizes a multi-threaded model without increasing multiple-stack overhead. In an event-driven approach, the program runs to completion, which is not desirable in some scenarios, especially in a system where a high-priority task is present. A protothread simplifies the event-driven programming model by providing a conditional locking wait statement that enables a program to execute a blocking wait without introducing an additional stack for each protothread. Between the beginning and end of each protothread, there is a conditional wait statement. This conditional wait statement blocks the program if there is an interruption. In other words, the thread is blocked only if an explicit blocking wait statement is used. In this way, the number of explicit state machines in the event-driven approach is reduced, with memory overhead of only two bytes per protothread. The protothread is a better alternative for memory efficiency. However, providing process synchroniza-tion between protothreads is not possible.

Sometimes blocking certain components may interrupt the whole sensing application. TinyOS Thread (TOSThread) is a complete implementation of a preemptive application-level thread library to achieve maximum concurrency without increasing resource usage [66]. TOSThreads categorize all event-based code into kernel-level threads and application-level threads. Kernel-application-level threads are given the highest pri-ority, and cannot be interrupted by application-level threads. An application-level thread makes a system call applica-tion programming interface (API) that does not interrupt the TinyOS code itself; rather, it sends a message to the kernel thread. Application-level threads execute only if kernel-level threads are not active. The basic architecture of a TOSThread is shown in Figure 2. The overall structure consists of five ele-ments: a single kernel-level thread, a number of application-level threads, a task scheduler, a thread scheduler, and system-call APIs. A number of application threads run

FIGURE 2. TOSThreads architecture (adapted from [66]).

concurrently and make a call to the kernel-level threads through API slots. The thread scheduler provides con-currency between application-level threads and system-call APIs. TOSThread provides a preemptive behavior to TinyOS but increases the computational complexity. To provide emptive execution in a simple manner, the TinyOS pre-emptive original (TOS-PRO) approach was introduced [67]. This approach provides increased flexibility for scheduling without introducing extra complexity into TinyOS.

FreeRTOS is based on a microkernel architecture and utilizes a multithreading approach [68]. Each process can be interrupted, and the scheduler can switch between threads [69]. It provides a real-time, preemptive multitasking environment for low-end devices. It ensures execution of a higher priority task in any given time period. If two tasks are given equal priority, the scheduler divides execution time between them. This execution follows a priority-based round-robin implementation. The FreeRTOS kernel is structured

using four C files (task.c, list.c queue.c and croutine.c),

where task.c provides scheduling functionalities by using

structures and functions in the list.cfile. The queue.c file

provides a thread-safe queue to implement inter-task

commu-nication and synchronization, andcroutine.cimplements

sim-ple lightweight tasks [70]. The IoT OS process management overview is given in Table 3.

B. MEMORY MANAGEMENT

Memory management provides techniques for allocating and deallocating memory for various processes and threads. OS offers two common methods for memory allocation, i.e., static allocation and dynamic allocation. In static mem-ory management, OS allocates memmem-ory to the system that cannot be altered during run-time. But a dynamic manage-ment technique provides flexibility in memory acquisition at run-time. Static allocation cannot predict how much memory will be needed, especially in real-time scenarios. Similarly, memory over-provisioning may result in memory overhead. With dynamic allocation, if the allocated memory is not freed, it may result in a memory leak.

TABLE 3. An overview of process management.

The memory size for sensor devices is constrained due to the device’s physical size and the cost. Static memory con-tains the program code, and dynamic memory concon-tains run-time variables, the buffer, and the stack. IoT low-end devices as classified by IETF require about 10 kB of RAM and about 100 kB of flash memory. The Contiki C library provides a set of functions for allocation and de-allocation of memory for the heap. For example, the memb macro(), and memb_alloc(), and memb_free() functions are used for memory declaration, allocation, and de-allocation, respectively [71]. The memory allocation function needs to handle memory fragmentation. If memory is fragmented, allocation may fail to allocate all the unused memory. The managed memory allocator function mmem() in the Contiki frees the allocated memory from fragmentation by compacting it when blocks are unused. However, dynamic allocation may lead to stack overflow, and requires more space. TinyOS is based on the NesC pro-gramming language [72]. To cope with sensor node hardware constraints, the language does not support dynamic memory allocation, the program states and memory are declared at compile time. In this way, memory fragmentation and run-time allocation failure are prevented. Similarly, maintaining an additional data stack to manage the dynamic heap is not required [73]. In the earlier version of TinyOS, the basic building block (i.e., memory safety) was not available [74]. However, new updates and revisions provided memory safety and memory safety–check features. Safe TinyOS was

developed mainly to provide memory safety to sensor nodes [75]. Similarly, Untrusted Extension for TinyOS (UTOS) utilizes a sandboxing concept to provide enhanced memory safety features, compared to Safe TinyOS [76]. To provide memory safety features to memory-constrained devices, CCured is leveraged [77]. CCured provides a red line that draws a boundary between trusted and untrusted exten-sions. The untrusted extensions cannot access the hardware and network resources directly. An extension communicates with the rest of the system through a proper UTOS system call interface. The extension is terminated if it violates the safety model of the system. The CCured compiler inserts dynamic safety checks before every operation.

Restarting an extension is still faster than rebooting a TinyOS application. To make the memory more efficient, unstacked C is used, which is a source-to-source transforma-tion to translate a TinyOS multithread program into stackless threads. Since these programs do not have a separate stack, their memory overhead is reduced significantly. Dynamic memory-like capabilities can be offered in TinyOS by using a component named TinyAlloc through an interface called MemAlloc. Additional memory management and capacity are provided through a TinyPaging mechanism, which makes use of flash storage [75]. TinyAlloc allows double referenc-ing, which means that the memory region is referenced indi-rectly through another array that contains it current address. Hence, TinyAlloc can alter the memory address in the

TABLE 4. An overview of memory management.

intermediate array, and move the memory region freely with in the heap. The MemAlloc interface in TinyAlloc returns a pointer handle to the newly assigned memory region, and also frees the memory region and returns the handle pointer to allocated memory. Tinypaging uses virtual addresses. The memory region is allocated a virtual address. Before using it, a dereferencing function takes the virtual address and returns the physical address for that memory. It also reduces the need to use an additional intermediate array. Hence, Tinypaging combines these concepts and works with virtual addresses to exchange parts of memory into flash.

The additional threads in TinyOS that provide more exe-cution and concurrency support may require more mem-ory usage. Therefore, memmem-ory usage prediction is required for TinyOS applications. With a real-time operating sys-tem (FreeRTOS), the kernel allocates memory dynamically for every event. The malloc() and free() functions are not desirable in a real-time operating system due to the fact that dynamic memory allocation has typically deterministic run-times, needs extra code space, and suffers from mem-ory fragmentation. To eliminate these problems, FreeRTOS introduced two new functions: pvPortMalloc() and vPort-Free() [78]. These functions provide three heap implemen-tations for memory allocation, depending on the system design [79]. Heap_1 does not allow de-allocation of memory once it is allocated. It is suitable for a system where allocated memory size always remains the same (for example, with application tasks that do not vary with time and that are created before the kernel is started). Heap_2, in contrast to heap_1, allows previously allocated memory to be freed.

It does not combine adjacent free blocks into a larger memory block. This scheme is suitable for systems where tasks are created dynamically. Heap_3 is similar to the malloc() and free() function allocations, and make a safe thread. This scheme is not memory-efficient, and may increase the kernel code size. The memory management aspect of IoT OS is summarized in Table 4.

C. ENERGY MANAGEMENT

IoT devices consume energy during sensing, data processing, and data transfer. The management of limited energy has been a key issue for these devices due to the fact that these sensors are deployed mostly in remote environments and function without human intervention. Therefore, OS should provide an energy-efficient mechanism to prolong the life of an IoT network [80]. The management of a limited energy budget is rudimentary, and can be accomplished through both hardware and software techniques [81]. Hardware-based approaches require additional hardware, which increases system cost. Software-based techniques are more practical, but may intro-duce additional overhead. Energy efficiency can be achieved through network protocol design and OS scheduling aspects, e.g., sleep/wake and duty-cycle modes are employed in most OSs to conserve energy [62]. Reducing energy consumption through a software mechanism requires a comprehensive view of the application at a different layer of the system, and is an essential condition for OS.

The Contiki kernel offers no explicit power-saving mech-anism. The applications provide a power-saving mode by

FIGURE 3. TinyOS software thread integration (TOSSTI) (adapted from [46]).

TABLE 5. Predicted energy consumption (in mJ) and node lifetime for TinyOS 1.1.7 component (adapted from [82]).

utilizing an event queue size. The application can put the CPU into sleep mode when the event queue is empty [63]. The Contiki network-level energy-saving mechanisms are discussed in more detail in Section D.

TinyOS utilizes software thread integration (STI) for energy conservation [46]. The node faces idle–busy time during sensing, processing, and transmission. The idle time is too short to perform traditional context switching. With STI, the processor can reclaim this time to perform other useful tasks, as depicted in Figure 3. Similarly, the processor can boost battery life by switching to low-power mode sooner. The TinyOS overall system response time also improves, which supports higher priority task processing. In this way, the scheduler can provide the effects of pre-emption at the task level. Hence, it enhances the concurrency model of the scheduler.

Allocating the energy dynamically by predicting the power consumption of nodes can be helpful to conserve energy. For example, accurate prediction of power consumption (AEON) is an energy prediction tool for sensor nodes [82]. TinyOS application energy prediction based on AEON is shown in Table 5. Table 5 shows the amount of energy consumed by each component. For example, the radio con-sumes most of the energy, thus, the CPU idle–active mode

duration can be altered to extend node lifetime. Similarly, the TinyOS programming mode supports an energy-tracking mechanism to track energy consumption of various compo-nents. An energy-aware target tracking (EATT) algorithm is implemented in TinyOS using a clustering and data aggre-gation technique [83]. The tracking algorithm is executed by the cluster head (CH) that performs data collection, aggre-gation tracking, and result propaaggre-gation to send the results to the desired location. Through energy tracking optimization, the number of CPU cycles can be minimized. However, this mechanism is not suitable for mobile devices, and may intro-duce additional memory usage. A distributed energy-aware wake-up counter was tested in TinyOS to provide updated link status in real time [84].

In an event-driven system, the threads of execu-tions or tasks spend a portion of their time waiting for an interrupt, or for a time period to expire. In FreeRTOS, these tasks are referred to as being in a blocked state [85]. If all the tasks are in a blocked state, FreeRTOS creates and runs a task called idle task. Therefore, when the processor is idle, it can go into power-saving mode. This is implemented in FreeRTOS using an idle task hook function [86]. The idle task is given the lowest priority, and the idle hook function gets called only if there is no higher priority task available [87].

TABLE 6. An overview of energy management.

Hence, this function provides an automatic power-saving mechanism to the FreeRTOS processor. This mechanism may be beneficial in some scenarios, but if the frequency of the ticks is too high, the processor will waste energy and time in entering and exiting idle mode. Hence, the power savings through this mechanism are not beneficial. Therefore, to provide an appropriate power-saving mechanism, a tickless idle technique was introduced [88]. Tickless idle is a power management technique for FreeRTOS that provides more power saving during processor idle states. It uses a time-tracking mechanism to disable a periodic tick source for a period of time to put the processor into deep sleep mode until a higher priority external or kernel interrupt occurs. However, it introduces run-time overhead. The energy management aspects of IoT OSs is presented in Table 6.

D. COMMUNICATION MANAGEMENT

Providing seamless continuous and ubiquitous communica-tion between IoT devices is the ultimate goal of an IoT OS. IoT networking is complicated by the devices’ wireless nature, heterogeneity, density, and diverse transmission pat-terns [89]. Therefore, communications support at the MAC layer, the transport layer, and the network layer impacts overall IoT network performance. There is a plethora of IoT communication protocols available in the literature [90]. Some of these protocols are widely accepted and standard-ized. The IoT communications protocols should focus on energy efficiency rather than providing higher throughput. The networking stack for an IoT OS must support higher-level services, including data dissemination and accumulation. It also requires managing low-level services, including radio management, queue management, and MAC support [91]. Apart from these requirements, there is a need to consider the devices’ unique traffic characteristics, and consequently, a need to manage the quality of service (QoS). For example, in the smart metering scenario, devices periodically transmit a small burst of data. A detailed tabular overview of commu-nication management section is provided in Table 7.

1) CONTIKI SUPPORT FOR COMMUNICATION PROTOCOLS

The Contiki provides two networking stacks, i.e., a uIPv6 net-stack and a Rime communications net-stack [92]. uIPv6 is the

implementation of the TCP/IP protocol stack for eight-bit microcontrollers, and can be configured with 6LowPAN, RPL routing for low-power and lossy networks, User Data-gram Protocol (UDP) and Constrained Application Pro-tocol (CoAP) [93]. Similarly, the Rime communications stack is designed for low-power radio. It supports single-hop unicast, single-single-hop broadcast, and multi-single-hop commu-nications. In multi-hop scenarios, Rime allows applications to implement routing protocols other than the Rime stack– implemented protocols. The Contiki network stack layer model is shown in Figure 4. The Contiki network stack layer is a little bit different than the traditional OSI layer. It covers all the OSI layers; however, there is a radio layer, a radio duty cycle layer, and a MAC layer present in between the network layer and the physical layer [94].

a: CONTIKI SUPPORT FOR MAC LAYER PROTOCOLS

IoT resource management under a MAC protocol is usually achieved in terms of energy efficiency [42]. The MAC proto-col approach developed for a duty-cycle IoT aims to reduce radio idle listening duration to minimize energy consumption. Idle listening is the time the node spends listening to the medium, even if no packet is present. The X-MAC protocol is implemented in the Contiki, and it provides a low-power listening mechanism [95]. If a node sends data, it transmits a preamble. The receiver wakes up, detects the preamble, and stays in the idle state to receive the data. In this basic approach, the receiver stays in the wake-up state until the preamble is finished, and it then starts the data- and acknowl-edge (ACK)-packet exchanges (Figure 5). The receiver may have woken up at the start of the preamble. This results in wasted energy. X-MAC replaces the low preamble with short strobe frames [96]. The receiver receives one strobe and transmits a strobe-ACK. The sender then proceeds with data transmission. Hence, a short preamble further decreases the time and energy consumption. However, X-MAC wakes up each node for a short active period in this procedure. The node goes to sleep mode again after an active period, which is 5% to 10% of the wake-up interval.

Contiki 2.4 introduced a carrier sense multiple access (CSMA) MAC protocol that simply detects a collision and

FIGURE 4. Contiki network stack (adapted from [94]).

FIGURE 5. X-MAC medium access (adapted from [96]).

FIGURE 6. ContikiMAC mechanism of sending data packet (adapted from [97]).

retransmits the packets. However, this retransmission infor-mation is not passed to the upper layers in order to save computational costs. Hiding this information may affect the overall routing operation. Therefore, a new power-saving mechanism called the ContikiMAC radio duty cycling pro-tocol was introduced in Contiki 2.5 [97]. The ContikiMAC radio duty cycle mechanism was inspired by the X-MAC duty cycling procedure [98].

ContikiMAC periodically wakes up the radio to listen for a packet transmission. The sending node continuously sends the data frame to the receiver until it gets an acknowledgment. The packet’s destination field reduces overhearing, i.e., the node can go into sleep mode if it is not the packet destination. The receiver wakes its radio to listen for packet transmis-sion. After detecting the packets, the receiver stays awake

to receive the full transmission. Once reception of packets is done, it sends a link layer acknowledgment. This mechanism is illustrated in Figure 6.

The wake-up duration timing needs to be precise. To pro-vide power-efficient wake-up timing, Contiki uses a mecha-nism called clear channel assignment (CCA), which utilizes the received signal strength indicator (RSSI) value to predict channel availability. An RSSI value lower than a given thresh-old returns ‘‘CCA positive,’’ indicating the channel is free. Similarly, an RSSI value greater than the threshold amount returns ‘‘CCA negative,’’ indicating the channel is busy. Con-tikiMAC follows precise timing constraints. ConCon-tikiMAC timing is illustrated in Figure 7;tiis the time duration between

two data packet transmissions, which must be greater than the time required to transmit and receive the ACK, i.e.,ta+td.

FIGURE 7. The ContikiMAC transmission and CCA timing (adapted from [97]). The intervaltcbetween two CCAs (tr) must be greater than

ti to ensure two CCAs detect a frame. ContikiMAC uses a

phaselock mechanism introduced by WiseMAC [99]. In this mechanism, the transmitter can estimate the wake-up sched-ule of the receiver with the ACK packet and can transmit data frames repeatedly just before the receiver is expected to be in the wake-up state. This phaselock mechanism in ContikiMAC reduces both energy and channel utilization, but at the risk of collision.

Some other MAC layer protocols were designed and tested with the Contiki OS. RAWMAC, a cross-layer approach is implemented in Contiki [100]. It exploits the Contiki RPL [101] protocol at the routing layer, and ContikiMAC at the MAC layer. It uses RPL’s directed acyclic graph (DAG) and aligns node wake-up internally estimated by the Contiki-MAC phase lock mechanism with its parent node to minimize data collection delay. Another MAC protocol implemented in Contiki is called GinLITE [102].

b: CONTIKI SUPPORT FOR NETWORK LAYER PROTOCOLS

IETF provides IPv6 routing in low-power and lossy net-works. RPL specifies how to construct a destination-oriented directed acyclic graph (DODAG). Each node is given a rank based on an objective function (OF). The rank provides the position of the node in the network. The OF calculates the rank of the node using a path calculation in a low-power and lossy network (RFC 6551) [103]. The node joining the RPL network first listens to a DODAG information object (DIO) message. If a node is unable to receive the DIO message, it will broadcast a DODAG information solicitation (DIS) message, which compels the neighboring node to broadcast the DIO message. Using the DIO message, the OF selects the parent node. The packet is forwarded to each parent node until the packet reaches the sink. When traffic is required to flow in the opposite direction, the routing state at every node is built using a DODAG destination advertisement object (DAO) message. The node sends a DAO message to its parent node, which will forward it through the parent’s parent node to the sink [104]. Tsiftes et al. proposed a mechanism to implement RPL protocols inside uIPv6 [101]. Similarly, Ko et al. [105] tested the ContikiRPL implementation using two OFs, i.e., OF0 and a minimum rank objective function

with hysteresis (MRHOF). ContikiRPL separates the OF into various modules. First, the protocol logic module main-tains DODAG information and the node’s parent-associated information. Second, the message-construction and parsing module provides the RPL ICMPv6 message format and data structure to ContikiRPL. Third, the OF modules provide an OF API. ContikiRPL provides a forwarding table mechanism for uIPV6 instead of taking a forwarding packet decision per packet. The link cost is estimated by a neighbor infor-mation module and is updated to the forwarding table. The uIPv6 layer forwards the outgoing packets to the 6LoWPAN layer, which provides header compression and fragmentation, and then, the packet is forwarded to ContikiMAC.

RPL faces congestion and packet loss problems during heavy traffic. Similarly, RPL has a fixed traffic configuration, it cannot adapt to IoT applications’ varying traffic patterns. Mobility is another crucial issue that causes link breakage and invalid routes in DAGs. To address these problems, Tahir et al. proposed an extension of RPL called backpressure RPL [106], which combines the RPL OF with backpres-sure routing. Congestion issues in the 6LowPAN layer are evaluated in Contiki using a non-cooperative game theory mechanism [107].

Some other routing protocols have been implemented in the Contiki, e.g, the Mesh_under Cluster_based Rout-ing (MUCBR) protocol proposed by Al-Nidawi et al. [108] reduces the node energy consumption and radio duty cycle by implementing a clustering structure under the 802.15.4 stan-dard. Similarly, another mechanism is proposed to provide an improved RPL routing metric [109]. It combines a node resid-ual energy ratio (RER) and a battery discharge index (BDI) along with expected transmission count (ETX) for parent selection and rank computation.

c: CONTIKI SUPPORT FOR TRANSPORT LAYER PROTOCOLS

A traditional TCP/IP cannot be implemented in limited-resources devices; uIP provides the minimum features needed to implement the full TCP/IP stack [110]. It contains simple TCP and UDP transport layer protocols. However, UDP in uIP does not support broadcast or multicast transmission. Similarly, UDP checksums are also not provided in uIP.

2) TINYOS SUPPORT FOR COMMUNICATION PROTOCOLS

The basic communications paradigm of TinyOS is the active message (AM), a single-hop protocol [111]. AM is a sim-ple networking primitive where each message includes an identifier to be invoked on the target node to pass the AM to its handler. In this way, this event-based communication between nodes provides a TinyOS publish/subscribe-based communications architecture. The GenericComm component in TinyOS 1.x provides AM communications interfaces, which provide single-hop unicast, and broadcast commu-nications. TinyOS supports two multi-hop communications protocols called dissemination and TYMO (which is an implementation of the Dynamic Manet on Demand Routing Protocol (DYMO)) [112], [113]. Dissemination protocols are designed to reduce temporary disconnections and packet losses by ensuring the reliable delivery of data to every node in the network.

a: TinyOS SUPPORT FOR MAC LAYER PROTOCOLS

Various MAC protocols have been tested with TinyOS. For example, B-MAC provides a low-power operation inter-face [114]. It introduced an adaptive preamble sampling mechanism, which reduces radio duty cycling and idle listen-ing. Similarly, X-MAC is a low-power listening approach that uses a short preamble to conserve energy [98]. The receiving node’s address information is embedded in the preamble to resolve the overhearing problem, which in turn, saves energy for the non-receiving node. It also uses the idea of a short strobed preamble, which is created by adding pauses in the short preamble. The strobe preamble enables the receiving node to interrupt a preamble as soon as it wakes up and imme-diately recognizes its own address. Then, it transmits an ACK in the next pause after the preamble. In this way, instead of waiting for the entire preamble to complete, a node can start receiving packets without wasting time and energy. Similarly, a transmitter also does not need to send the remaining short preambles.

Similarly, TinyOS provides a MAC mechanism called TinyOS LPL, which is similar to the ConikiMAC tech-nique [58]. TinyOS LPL allows the radio to implement sleep/wake cycles at user-defined intervals. The LPL receiver energy-saving mechanism saves energy by performing short, periodic receive checks. A node wakes up during every LPL period to sense the channel. If there is activity on the channel, the receiver node will switch its radio on to receive packets and send an ACK. The transmitter stops packet transmission upon receiving an ACK. The transmitter sends a packet only during the receive check interval of the receiver. In a tradi-tional LPL mechanism, the sending node transmits a very long preamble to span a complete receive check period. The receiver node radio stays awake during the full duration of the sending node preamble, and waits for the data pack-ets after that. Staying awake for a long period and reading bits consumes lots of energy. TinyOS LPL improved this mechanism by replacing the long preamble with a smaller

packet transmission. Along with that, a low-power interface was introduced, which allows the user to deploy nodes with a pre-defined duty cycle percentage or sleep time. The TinyOS LPL mechanism provides energy efficiency through a radio duty–cycling mechanism. However, the default inter-packet spacing (IPS) in TinyOS LPL is 8 ms, which may result in lower throughput. With the higher IPS (8 ms) the average packet reception ratio (PRR) is 11.67%.

A wide variety of MAC protocols were designed in order to provide energy efficiency to a sensor network. Due to com-patibility problems, the sensor networks are not interoperable. To overcome this problem; a MultiMAC network stack to run multiple MAC protocols using a single radio interface was introduced [115]. The MultiMAC protocol stack uti-lizes three known protocols, CSMA with collision avoidance (CSMA/CA), LPL MAC, and TDMA MAC, on top of the same radio driver. It introduces the concept of using a virtual gateway to enable sensor network interoperability using het-erogeneous MAC protocols. The MultiMAC network stack architecture is depicted in Figure 8.

FIGURE 8. The architecture of MultiMAC network stack (adapted from [115]).

The CC2420 driver manages the data transmission, recep-tion, and frame transmission timing. Similarly, the hardware abstraction layer (HAL) provides multiplexing of different MAC protocols. The HAL is responsible for dispatching the received frame to the correct MAC protocols using a MAC-id in the frame, performs address recognition, and sends auto-matic ACK packets for each MAC. Each MAC protocol is provided a virtual physical layer address to isolate them from one another.

b: TinyOS SUPPORT FOR NETWORK LAYER PROTOCOLS

ContikiRPL, TinyRPL is based on the IETF RPL (RFC 6550) [13]. TinyOS 2.x utilizes an interface provided by the Berkeley low-power IP stack (blip), which implements an IPv6 stack based on 6LoWPAN specifications [116]; blip utilizes 6LoWPAN header compression, neighbor discov-ery, and DHCPv6 to provide IPv6 in the upper layer. The blip architecture is shown in Figure 9. The IP forwarding abstraction allows RPL implementation on top of ICMv6.

FIGURE 9. The basic architecture of the blip stack. As explained in ContikiRPL, the packet is forwarded once DODAG is constructed using a DIO message. Then, TinyRPL saves its route in the blip forwarding module. Both Con-tikiRPL and TinyRPL implement OF0 and MRHOF objec-tive functions for route selection. However, the routing in RPL depends on other layer functions, as well. For example, the MAC layer retransmission timeout affects the RPL link discovery function. It is been shown that the ContikiRPL retransmission timeout is two times the TinyRPL retrans-mission timeout because of the MAC layer retransretrans-mission timeout difference between them [105].

Load balancing under heavy traffic in RPL is carried out efficiently by queue utilization (QU) [117]. The proposed QU-RPL mechanism aims to achieve load balancing by offering a better parent-selection method, which results in less congestion at both the link level and the queue level, along with a better packet reception ratio. During DODAG construction, the DIO message contains information about the RPL node rank and routing metrics. The QU-RPL pro-cedure added new QU information in DIO. During heavy traffic and fast Tickletime, the amount of overhead can cause severe delay in a large IoT network. Similarly, the pro-posed algorithm is required to add the battery’s remaining energy information during parent selection. In the same way, the Tickletimer resetting strategy depends on network size. It requires a more efficient Tickletimer strategy for better out-put. Providing multimedia application support in this scenario is also very challenging due to constrained environment and overhead costs.

TinyOS Opportunistic Routing Protocol (TORP) for WSNs is designed to conserve energy by implementing an efficient forwarding mechanism [118]. Similarly, the Low-Energy Adaptation Clustering Hierarchy (LEACH) protocol was tested with TinyOS [119]. LEACH forms node clusters using their RSSI values. Then, the local cluster head (CH) is declared a router to communicate with the base station. In this protocol, energy conservation is based on the idea of prevent-ing long distance communications by each node, since only the CH is responsible for communicating with the base sta-tion. Another energy-efficient routing protocol named Bea-con Vector Routing (BVR) is implemented in TinyOS [120].

It defines a beacon vector routing metric and routes the packets in a greedy manner to the next closest hop, which is calculated by a beacon vector distance metric. A proactive distance-vector protocol (Babel) is implemented in TinyOS to support low-power sensor operation [121]. Babel is based on Destination-Sequenced Distance-Vector (DSDV) routing and Ad Hoc On-Demand Distance Vector (AODV) proto-cols. Location-aided routing (LAR), Destination-Sequenced Vector Routing (DSVR) and an event-driven data-centric routing protocol are also implemented in TinyOS to support sensors’ battery lifetime [122].

c: TinyOS SUPPORT FOR TRANSPORT LAYER PROTOCOLS

IoT applications demand a certain level in quality of ser-vice plus specific resource requirements. TinyOS does not provide any specific transport layer protocol implementa-tion. The blip interface in TinyOS provides a UDP socket layer as a basic transport layer implementation [116]. The UDPShell provided by blip contains simple commands, including help, echo, uptime, ping, and ident, to provide debugging commands to the sensor node. Similarly, blip also offers a very simple TCP stack. In order not to exhaust the sensor resources, the TinyOS TCP implementation does not do receive-side buffering. The new packets are dispatched does not do transmitter-side buffering; the dropped segment is automatically retransmitted instantly [123].

Besides the above-mentioned transport layer support, TinyOS supports a variety of transport layer protocols to con-serve energy. For example, Sensor Transmission Control Pro-tocol (STCP) was implemented and tested in TinyOS [124]. In STCP, most of the functionalities are implemented at the base station. Thus, a considerable amount of energy is conserved in the sensor nodes. The sensor nodes asso-ciate themselves with the base station using a session ini-tiation packet, which informs the base station about the number of flows, data types, and transmission types, and reliability requirements. Likewise, the Hybrid and Dynamic Reliable Transport Protocol (HDRTP) was proposed using TinyOS [44]. It has been shown that HDRTP enhances sensor node performance in terms of success rate, average latency, and average delivery ratio. Similarly, various transport layer

protocols were tested on TinyOS, e.g., a post-order–based protocol [125], the Energy-efficient and Reliable Transport Protocol (ERTP) [126] and the Rate-Controlled Reliable Transport Protocol (RCRT) were implemented and tested in TinyOS [127].

3) FREERTOS SUPPORT FOR COMMUNICATION PROTOCOLS

FreeRTOS utilizes third-party additional tools and applica-tions to provide networking support, e.g., Real Time

Engi-neers Ltd. provides the FreeRTOS+TCP configuration [128].

The FreeRTOS+TCP configuration allows Ethernet-based

IPv4 protocol networking solutions. Similarly, a third-party networking port stack e.g., uIP and IwIP, is utilized in a constrained environment [129].

a: FreeRTOS SUPPORT FOR TRANSPORT LAYER PROTOCOLS

FreeRTOS, being a minimalistic OS, does not provide a native MAC layer implementation. However, a third-party implementation is available. For example, IoT-LAB provided a FreeRTOS-based MAC layer implementation to provide better real-time support [130]. They implemented three MAC layers, including CSMA, TDMA, and X-MAC. This CSMA implementation provides a user-defined number of transmit-ting requests before packet dropping. TDMA is useful to han-dle a large number of nodes operating on the same channel. X-MAC provides a low-power duty cycling MAC mechanism that is suited to low-traffic networks. Schoofs et al. provided an 802.15.4 MAC implementation on a FreeRTOS micro-kernel [131]. In this configuration, MAC is considered an application that is run by a FreeRTOS task as a FreeRTOS MAC task and is given the highest priority.

b: FreeRTOS SUPPORT FOR NETWORK LAYER PROTOCOLS

Real Time Engineers Ltd. provides FreeRTOS+TCP, which

is an open-source TCP/IP stack [128]. It is based on a Berke-ley sockets interface supporting an Ethernet-based IPv4 stack that offers support for UDP and TCP, and lwIP is based on a TCP/IP protocol suite with low RAM usage. IwIP is suitable for devices with 10 kB RAM. Hence, it is suitable for IoT low-end devices. Most of the FreeRTOS demos make use of an old IwIP version. At the network level, it supports Internet Proto-col, Internet Control Message Protocol (ICMP) and Internet Group Management Protocol (IGMP). IwIP utilizes basic IP functionalities, it sends, receives, and forwards packets, but does not handle fragmented IP packets with IP options. The OS does not use function calls and data structures directly in the code. In order to make IwIP more portable, an OS uses an emulation layer to provide the IwIP functions. The emulation layer provides a common interface between the kernel and the IwIP code. This interface provides services that include a timer used by TCP/IP. It processes synchronization (semaphores) and has a message processing mechanism that uses an abstraction called mailboxes. The uIP implemented in Contiki does not support all UDP and multicast features,

i.e., uIP can send UDP multicast messages, but is unable to join multicast groups and receive multicast messages [110]. Unlike uIP, IwIP provides the necessary UDP and multicast components. FreeRTOS also supports ports of an embedded network stack called Nanostack [132], which was developed by Sensinode. It is based on a 6LowPAN implementation and decreases RAM usage by executing as a single task under FreeRTOS. Similarly, 6LowPAN compresses the IPv6 head-ers to make them useful for resource-constrained sensor devices.

c: FreeRTOS SUPPORT FOR TRANSPORT LAYER PROTOCOLS

FreeRTOS uses TCP and UDP as transport

proto-cols. FreeRTOS+UDP is a socket-based fully thread–aware

stack for FreeRTOS. It provides a Berkeley socket–like interface with compact code size that makes it useful for communication between limited-resource IoT devices. The

FreeRTOS+TCP stack, on the other hand, provides a more

reliable stream service. Therefore, TCP contains 50% of the total code size of the lwIP stack [129].

E. FILE MANAGEMENT

A typical IoT network consists of thousands of tiny devices that sense the environment and process raw information. This information sometimes needs to be stored. In the past, a wire-less sensor network was communication-centric and used to transfer sensed data to one or more sensor devices or a base station. However, in recent years, the presence of onboard flash storage in IoT hardware platforms has provided a stor-age capability to the sensor network. As a sensor node’s mem-ory is a scarce resource, an efficient file system is required, although not every IoT scenario requires a file system. Contiki provides a flash-based file system called Coffee, which gives support to flash-based sensor devices [133]. A typical IoT device contains a few kilobytes of RAM. The onboard flash-based storage provides more memory capa-bilities. The file system must support storage-centric sen-sor applications and networking components’ storage needs. In other words, how to store and retrieve the data in an efficient manner is handled by the file system. The OS in this scenario is required to support the file system in order to satisfy the IoT resource requirements. TinyOS, on the other hand, uses a single-level file based on the assumption that a node runs a single application at a time [134]. Similarly,

FreeRTOS+FAT is a DOS-compatible, open source file

sys-tem for FreeRTOS [135]. Table 8 summarizes the overview of file management.

1) CONTIKI FILE SYSTEM

Contiki File System (CFS) is a virtual file system to provide an interface to different file systems [133]. Building stor-age abstraction is a challenging task in a limited-resource environment (little code and a small RAM footprint) [136]. In this scenario, Contiki provides a base for building such an abstraction to support various resource-constrained devices. The two file systems that implement CFS with full

TABLE 8. An overview of file management.

functionalities are CFS-POSIX and Coffee. CFX-POSIX on the Contiki platform runs in native mode. Other file systems supported by CFS are also available, such as CFS-EEPROM, CFS-RAM, and CFS-XMEM, but these file systems are con-strained to a single file only. Coffee, on the other hand, sup-ports a file system for flash (EEPROM)-based sensor devices. Each file system uses the CFS API for reading, writing, and extracting files in a mechanism similar to the Portable Operat-ing System Interface for Unix (POSIX) API. Coffee provides a programming interface to develop an independent storage abstraction. Coffee uses a small RAM footprint profile, and requires 5 kB ROM for the code and 0.5 kB RAM at run-time. Hence, it is suitable for resource-constrained devices. Coffee allows multiple files to coexist on the same onboard flash chip, and provides 92% of the achievable direct flash driver throughput. In order to provide better memory management, the concept of micrologs was introduced. A microlog, unlike the conventional log structure, allows configuring the logs of individual files, providing a tradeoff between space and speed. Flash memory may increase the chance of memory corruption if it erases the page every time. Coffee spreads the spectrum evenly to reduce the risk of corruption.

2) TINYOS FILE SYSTEM

TinyOS supports a single-level file system. It assumes that a node runs a single file in any given time period [134]. Therefore, a single-level file system is sufficient (e.g. TinyOS 1.x uses a microfile system called Matchbox, which provides an interface to read, write, delete, and rename files [137]). Matchbox is designed to provide reliability and low-resource consumption. The Matchbox filing system is very simple; it stores files in an unstructured way and provides only sequential reads and append-only writes. Other third-party file system implementations are also present, e.g. TinyOS FAT 16 supports SD cards aimed at reducing the overall power consumption of sensor nodes. TinyOS 2.x is based on the NesC programming language, which provides an abstrac-tion layer that separates hardware interfaces and provides a framework for developing a portable application [138]. The portable implementation of the FAT file system allows a node to store a large amount of data. Similarly, the Efficient

Log-structured Flash (ELF) file system for microsensors is implemented in TinyOS [139]. The ELF log structure pro-vides better memory efficiency, low-power operation, and tailored support for the common types of sensor files.

3) FREERTOS FILE SYSTEM

FreeRTOS uses the Super Lean FAT File System

(FreeRTOS+FAT SL). FreeRTOS+FAT (FAT12/FAT16/

FAT32) is a DOS/Windows-compatible embedded file system with the main objective of minimizing both flash and RAM footprint (<4 kB and<1 kB, respectively).

IV. OPEN RESEARCH ISSUES AND RECOMMENDATIONS

To develop a practical and efficient IoT OS, many research challenges need to be addressed. The OS should mainly focus on the severe resource shortages and requirements for diverse IoT applications. In this section, we first discuss the general IoT OS research directions, and we then pinpoint some spe-cific research directions.

A. SMALL MEMORY FOOTPRINT

For general research directions, we first argue that more research should be put into the effort to utilize a small mem-ory footprint while providing a developer-friendly API and adding sophisticated features, which may require adding a new programming language or extensions of existing ones. An IoT device contains only a few kilobytes of memory. Hence, the fundamental characteristics of an IoT OS are to reduce the code size and utilize the minimum memory in an efficient manner.

B. ENERGY EFFICIENCY

Another general research direction is to consider a practi-cal energy-efficiency mechanism to prolong the IoT device battery lifetime by designing more efficient network proto-cols. Similarly, leveraging the hardware features in a smarter manner can lead to better energy efficiency.

C. RELIABILITY OF IoT DEVICES

The reliability of IoT device operation is extremely cru-cial, especially if they are deployed in a remote location.

To support IoT complex deployments, OS reliability can be achieved by using a microkernel, memory protection units, static code analysis, etc.

D. REAL-TIME SUPPORT

IoT devices require diverse applications; some of them pro-vide real-time operation. These real-time sensings tend to be time-sensitive. Thus, a timely real-time operation guarantee is another challenge faced by the IoT OS.

E. SCHEDULING MODEL

The IoT OS also faces some limitations during task execu-tions that affect the processor and which can lead to extra burden and load on the processor. They can also affect the system’s energy efficiency and real-time capabilities.

F. NETWORK BUFFER MANAGEMENT

The network buffer is the main component of the IoT oper-ation. This area requires extensive research to efficiently allocate limited memory to the packets.

G. PROGRAMMING LANGUAGE

Choosing a standard programming language, such as C or

C++, or an OS-specific language like NesC, can affect

per-formance, safety, and portability.

H. PROGRAMMING MODEL

The IoT environment could have diverse application needs; application development is highly affected by the program-ming model. Therefore, the limitation with the programprogram-ming structure also needs to be addressed.

I. HARDWARE ABSTRACTION LAYER

Research to reduce the amount of overhead in designing the HAL could benefit the overall OS efficiency, especially in dense and lossy networks. On the other hand, it is very important that the HAL be well-designed and portable to different platforms.

J. REAL-TIME OS ISSUES:

Managing a real-time OS is quite challenging. In a complex IoT system, a simple RTOS task may result in complex run-time behavior. Extensive research is required to provide proper task priorities and processor shared timing. FreeRTOS utilizes a multi-threading approach where each process can be interrupted, and the higher priority task can be executed in any given time period, which can delay low priority– task execution time. Similarly, the dependency between tasks may block execution of certain tasks, which may also result in unnecessary delay. Priority inversion, timing properties, and task dependencies require further investigation for RTOS systems. Predicting real-time behavior is very difficult; tasks may execute slower than predicted; they may fail during execution, or can have unexpected delays. Therefore, imple-menting an RTOS in the IoT environment, especially for

time-critical applications, might cause a problem. Hence, dealing with these RTOS challenges is an important research direction.

K. COEXISTENCE

With the growing application scenarios of IoT networks in a limited frequency spectrum, coexistence technologies are an ongoing research problem for OS and radio designers. It is a diverse research area that requires an optimal design of the physical, MAC, and network layers. Achieving wireless coex-istence can provide spectrum resource sharing, traffic off-loading, and optimal connectivity for diverse IoT services.

Besides the above-mentioned challenges; we also highlight some specific issues, which are yet to be fully addressed.

L. CONTIKI PROTOTHREADS

Contiki provides multi-threading using protothreads, which are stackless and lightweight. Each process runs to com-pletion, and does not allow interrupt handlers to post new events. If an IoT application requires priority for processes and threads, Contiki would not be an ideal OS choice. Hence, extensive research could be done to provide proper process synchronization in Contiki.

M. TinyOS SCHEDULING

The TinyOS scheduling mechanism is not suitable for all application scenarios. For example, the application of encryp-tion security task execuencryp-tion time is very long. If the execuencryp-tion time of some tasks is longer, compared to others, it can affect the baud rate. Similarly, if the local task frequency is high, the OS may lose the other tasks, which affects the overall IoT communications system. TinyOS also fails to handle execution of abnormal tasks, which can lead to a system crash.

N. FreeRTOS SCHEDULING

FreeRTOS is a small real-time OS and provides a very basic scheduling procedure, i.e., highest priority first. Therefore, it does not offer the possibility of hard real-time scheduling. FreeRTOS is well suitable to a small embedded system that has limited, predefined tasks. Research should be done on designing FreeRTOS to handle large IoT system tasks with more advanced scheduling mechanisms.

O. MEMORY PROTECTION IN CONTIKI

Contiki supports a dynamic memory management mecha-nism. It does not provide a memory protection unit (MPU). Hence, this area still needs to be explored.

P. X-MAC

X-MAC uses a stream of strobes for broadcasting. The strobes do not contain a destination address, which forces each node to wake up for a specific time period. It also does not pro-vide a collision avoidance mechanism, i.e., no clear channel assessment is provided.