Comprehensive Survey of The Iot Open Source Oss: Iet Wireless Sensor Systems October 2018

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/328031606
Comprehensive Survey of the IoT Open Source OSs
Article in IET Wireless Sensor Systems · October 2018

DOI: 10.1049/iet-wss.2018.5033
CITATIONS READS
2 1,886
4 authors:
Mahmoud H. Qutqut Aya Al-Sakran

Applied Science Private University Applied Science Private University
19 PUBLICATIONS 111 CITATIONS 5 PUBLICATIONS 9 CITATIONS
SEE PROFILE SEE PROFILE
Fadi Almasalha Hossam S. Hassanein

Applied Science Private University Queen's University
22 PUBLICATIONS 170 CITATIONS 608 PUBLICATIONS 7,074 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Data Offloading Framework Using Mobile Small Cells and Urban WiFi View project
Robust Crowdsensing for Intelligent Road Services View project
All content following this page was uploaded by Mahmoud H. Qutqut on 17 June 2019.
The user has requested enhancement of the downloaded file.

IET Wireless Sensor Systems
Review Article
Comprehensive survey of the IoT open- ISSN 2043-6386

Received on 5th February 2018
Revised 27th September 2018
source OSs Accepted on 27th September 2018
doi: 10.1049/iet-wss.2018.5033
www.ietdl.org
Mahmoud H. Qutqut1,2 , Aya Al-Sakran1, Fadi Almasalha1, Hossam S. Hassanein2

1Faculty of Information Technology, Applied Science Private University, Amman 11931, Jordan
2Telecommunications Research Laboratory, School of Computing, Queen's University, Kingston, Canada ON K7L 2N8
E-mail: [email protected]
Abstract: The Internet of things (IoT) has attracted a great deal of research and industry attention recently and is envisaged to
support diverse emerging domains including smart cities, health informatics, and smart sensory platforms. Operating system
(OS) support for IoT plays a pivotal role in developing scalable and interoperable applications that are reliable and efficient. IoT
is implemented by both high-end and low-end devices that require OSs. Recently, the authors have witnessed a diversity of OSs
emerging into the IoT environment to facilitate IoT deployments and developments. In this study, they present a comprehensive
overview of the common and existing open-source OSs for IoT. Each OS is described in detail based on a set of designing and
developmental aspects that they established. These aspects include architecture and kernel, programming model, scheduling,
memory management, networking protocols support, simulator support, security, power consumption, and support for
multimedia. They present a taxonomy of the current IoT open-source OSs. The objective of this survey is to provide a well-
structured guide to developers and researchers to determine the most appropriate OS for each specific IoT devices/applications
based on their functional and non-functional requirements. They remark that this is the first such tutorial style paper on IoT OSs.
1 Introduction emerging into the IoT environment to facilitate IoT deployments

and developments. Additionally, several research works have been
The Internet of things (IoT) can be described as a dynamic devoted to improve OS performance and capabilities in different
distributed networked system that represents the most energising dimensions.
technological revolution nowadays [1]. IoT is a network that To this end, we provide a comprehensive overview of the most
consists of a massive number of things (e.g. sensors, machines, or common open-source OSs for IoT. The choice of open-source OSs
appliances) communicating, sending, and receiving data via the is because we can have more information about their requirements
Internet [2]. The number of physical objects that are connected to and functionalities, allowing a thorough investigation of such OSs.
the Internet has been exponentially growing [3]. According to This paper is written in a tutorial style, where each OS is described
Gartner Inc. report, there will be about 21 billion connected in-depth according to a group of design and development aspects
devices by the year 2020 [4]. There are many domains and fields that we define. We remark that this is the first such tutorial style
that the IoT can play an essential role and improve the quality of paper on this topic. The primary objective of this paper is to
our lives [5]. These domains and fields range from health provide an easy to follow and well-structured guide for researchers
informatics, smart transportation, smart sensory platforms, to and developers targeting IoT platforms. First, we establish a set of
emergency cases where human decision making might be difficult design and development aspects for IoT OSs to help in evaluating
[6]. and understanding each OS in-depth. Second, we present a
IoT devices have constrained functionalities and minimal taxonomy to provide a classification of the different kinds of open-
footprint, which consume lower internal storage, memory, and source OSs for IoT from different perspectives. Then, we study
computation power than typical devices [7]. They are also battery each OS from the following aspects; architecture and kernel,
operated or embedded within integrated circuits. Some IoT devices programming model, scheduling, memory management,
can survive for a month to several years before a new battery networking protocols, simulator, security, power consumption, and
placement is required [8]. However, now, due to the IoT revolution, support for multimedia. This paper reveals the strengths and
the functionalities of these devices are expanding. So the device or weaknesses of each OS presented in this paper. Finally, we provide
the controller must be more intelligent in monitoring several several comparative analysis of the presented OSs in this paper and
inputs, updating events to gateways, or devices as well as receiving summarise their features.
commands from the gateways or other devices [9]. IoT enables The remainder of this paper is organised as follows. Section 2
physical objects to see, hear, and perform several tasks by allowing presents a general overview of IoT and its challenges and existing
them to communicate with each other to share information and to OSs for IoT environment. Section 3 shows the related aspects of
coordinate in order to make decisions [9]. IoT devices are designing and developing an IoT OS. Section 4 illustrates a
considered heterogeneous, and they are used in different proposed taxonomy for open-source IoT OSs. In Section 5, we
applications. Various types of applications require different discuss open-source OSs for low-end IoT devices, whereas in
architecture and hardware support that can operate on low-power Section 6 we present open-source OSs for high-end IoT devices.
sources. Hence, having an operating system (OS) that satisfies all Section 7 provides three comparisons between the discussed IoT
the requirements for IoT devices in various domains is almost OSs followed by the conclusion of this paper in Section 8.
impossible [10]. The IoT is implemented by both high-end and
low-end devices that required appropriate OSs. High-end devices
can operate using traditional OSs (such as Linux), whereas low-end 2 Background
devices operate with limited capabilities OSs that cannot perform In this section, we provide an overview of IoT and its challenges.
the same task of traditional OSs. Furthermore, OS support for IoT We also elaborate on why we need different and modified OSs for
plays a pivotal role in deploying reliable and scalable large-scale the IoT.
IoT deployments. Over the years, we have witnessed diverse OSs
IET Wirel. Sens. Syst. 1

© The Institution of Engineering and Technology 2018
2.1 Internet of things scalable IoT architecture, called middle-ware layer, to support a
large number of heterogeneous devices and work independently
The number of Internet-connected devices and machines is from messaging protocol standards [22].
increasing exponentially [11]. These devices and machines create a
Architecture: IoT includes an increasing number of heterogeneous
dynamic network that consists of billions of things/objects
interconnected devices and sensors that are often transparent and
communicating with each other. One of the main goals of IoT is to
invisible. Owing to the number of these devices and machines, a
facilitate the collection of data from one point to another at any
single architecture cannot be applied to all these heterogeneous
time and anywhere through efficient, secure, and reliable
devices [24]. Heterogeneous reference architectures adapted to IoT
connections [5]. IoT is characterised by its exceptionally
environment should be open, and they should not restrict users to
identifiable items, things, and their virtual representations in an
use fixed or end-to-end solutions [24]. Also, they should be
Internet-like structure [12]. Things can interact with each other at
flexible to deal with different deployments such as identifications
any time and place, in any way, and from any device. They can
(radio-frequency identification, tags), intelligent devices, and smart
enter and leave the network without the need to be restricted to a
objects [24].
single physical location to exchange data [13]. In IoT, millions, if
not billions, of heterogeneous devices should be connected to the
Internet [14]. These devices vary in computational power, available 2.3 OSs for the IoT environment
memory, communication, and energy capacity. The IoT Like any new software, an OS has to be integrated with existing
environment consists of protocols, network designs, and service IoT environment. To keep the complex IoT environment running, a
architectures that deal with a massive number of IoT objects and new OS has to be customised to meet specific requirements. Owing
devices to exchange data [15]. Thus, the IoT needs to support to some constraints existence in many traditional OSs, they are
multiple objects based on different types of radio interfaces with impractical to be used in IoT as IoT devices are designed with
various numbers of requirements regarding the available resources limited resources [25]. The adoption process of an OS requires that
[16]. IoT applications apply to different domains and disciplines the OS should be able to operate IoT devices efficiently. In addition
such as smart homes, environmental monitoring, health care, to that each IoT device may need to be customised to make use of
inventory and products management, smoke and fire detectors, its components that may not be available in other devices.
transportation, security, and surveillance systems [17, 18]. Nowadays, we are surrounded by many smart devices that are
different in their levels of complexity depending on their purposes.
2.2 IoT challenges All of them have a processor, a memory to store data, and other
peripherals [9]. To adapt to the constraints of typical IoT devices
One of the crucial challenges in IoT is to manage, maintain, and
successfully, it is necessary to have an appropriate OS that allows
deal with an enormous number of heterogeneous devices and the
easy control, connectivity, and communications. We are witnessing
data generated by them. This massive number of connected things
some OSs for IoT implementations and large-scale deployments
and objects lead to many technical and application challenges. The
[25]. However, there is a rapid need for development tools,
main challenges and issues in IoT are presented below:
standardisation, easy maintenance, and porting of applications
across a wide variety of hardware platforms.
Heterogeneity: IoT connects and manages a massive number of
heterogeneous devices (e.g. full-fledged web servers and other
devices) constitute a critical challenge that has different operating 3 Designing and developmental aspects of IoT
conditions, platforms etc. to provide advanced applications that can OSs
improve our life [18]. As a result, the complexity will be increased.
The OS is the most basic system software which runs directly on
Hence, developing applications that run on all platforms will
hardware resources to act as an intermediate between applications/
become extremely difficult, and increases the need for standard
users and hardware. An OS mainly contains various components
interoperable architecture [18]. Also, data should be exchanged of
but necessary a kernel, utility software, and system shell [26]. The
large-scale heterogeneous network elements in dynamic local
kernel is the essential part of an OS. It is a programme that
autonomy with highly efficient network convergence [18].
manages all activities in the system and gives permissions to other
Security issues: Owing to the number of heterogeneous devices software and users to perform any action [26]. The traditional OSs
that are exchanging data over the Internet, there is a risk of people are designed for workstations and personal computers (PCs) with
privacy. This is because these devices will record huge amounts of plenty of resources. For this reason, they are not appropriate for
data about people daily lives that could be pieced collectively to IoT devices with constrained resources and diverse data-centric
create an in-depth portrait of their presence [19]. So, it is essential applications. IoT devices need a customised type of OS
to ensure a secure data channel between the participated devices in considering their unique characteristics. Moreover, IoT devices
IoT. Also, it is a must to have a secure and reliable connection require an entirely different architecture of OS and an extensive
between heterogeneous devices in the IoT environment [19]. range of hardware support. In this section, we present the main
Scalability: With a massive number of heterogeneous devices such characteristics and criteria to be considered when designing and
as smart sensors and light bulbs which are fitted with minimal developing an OS for IoT devices. These characteristics and
processing and storage units, scalability becomes a crucial criteria are discussed below.
challenge for the current growth of IoT [20]. For example,
calculation of daily temperature variations around all the country
3.1 Architecture and kernel models
may require millions of devices resulting in a substantial amount of
data that cannot be easily processed and managed. That is why IoT Architecture is one of the most critical criteria for designing an OS.
needs data compression and data fusion to reduce this significant The core software component of an OS is known as kernel. The
data volume [21]. architecture of an OS has an effect on the size of the core kernel
Interoperability: One of the significant challenges in IoT and on how to provide services to applications. There are mainly
applications is interoperability for crossing layers among different five standard architectures for OS: monolithic, microkernel, virtual
IoT devices and deployments [22]. Interoperability challenge machine, modular, and layered architecture [27]. We will discuss
appears when heterogeneous devices use different data formats and all OS architectures in the following sections.
various protocols to collaborate in communication and data
exchange [23]. In IoT applications, there are multiple competing 3.1.1 Monolithic architecture: This architecture model does not
application-level protocols, function, and devices exist to provide follow any specific structure, where the OS architecture is working
communication interoperability. Each of these protocols maintains in the kernel space such as Linux and Unix. It is also called multi-
unique characteristics and messaging architecture for different tier architecture because monolithic applications are divided into
types of IoT applications. These traditionally are built with four or more layers such as presentation, application, database, and
different languages and protocols. So, it is essential to design a business layers. It mainly consists of a set of primitives or system
2 IET Wirel. Sens. Syst.

calls to access input/output (I/O) devices, memory, hardware microcontrollers, sensors, and devices to run on IoT devices. SDK
interrupts, the central processing unit (CPU) stack, file systems, consists of a set of libraries [33]. Also, a standard programming
and network protocols [27]. The monolithic kernel has better interface (API) should be provided such as portable OS interface
throughput than other kernels because they handle many aspects of (POSIX) or standard template library (STL) to facilitate software
computer processing at the lowest level [28]. Hence, it requires to development and simplify the porting of existing software [34]. In
incorporate code that deals with many devices, I/O, interrupt addition to that, when a code is propagating, a whole OS can be in
channels, and other hardware operators [28]. The main a dysfunctional state because multiple programmes will be running
disadvantage of this kind of architecture is that its functionality has concurrently. This transition time between programmes is
high complexity because all its components are placed in one considered wasted time, and thus, draining energy. In this regard,
element [28]. So, if any programme component modified, the an efficient and robust reprogramming technique must be used to
entire application has to be rewritten which may lead to crashes in propagate and maintain the new code promptly [35].
installation [28].
3.3 Scheduling
3.1.2 Microkernel architecture: This architecture model is
divided into a number of separated processes [28]. Some of these The selection of the scheduling strategy is tightly bound to the
processes run in the kernel space and some run in the user space. capabilities of a system to fulfil real-time requirements in order to
The microkernel architecture provides only the main functionalities support different priorities and degrees of interaction with users
of OSs such as scheduling, inter-process communication (IPC), and [34]. There are different scheduling algorithms such as priority-
synchronisation. All other OS functionalities including device based and non-priority-based schedulers. Priority-based
drivers and system libraries operate in threads [28]. The schedulers are classified into preemptive and non-preemptive.
microkernel architecture provides high implementation flexibility. Preemptive schedulers select the highest priority task to run even if
So, it allows to add additional features such as plugins to the core there is another running task. Non-preemptive schedulers will wait
application, and provide extensibility efficiently and easily. till the lower running task completes its execution in the processor
Moreover, it allows other OSs to be built on top of this microkernel [36]. Preemptive scheduling is called so because interrupting the
such as Windows NT [28]. processes during execution is possible. The processor might switch
from the ready or waiting state to the running state. Non-
preemptive scheduling takes place when a process terminates or
3.1.3 VM architecture: This architecture allows the user to run turns from running to a waiting state. It is called non-preemptive
one OS on another OS to enable a higher degree of software because processes cannot be interrupted or scheduled [36].
portability and flexibility [29]. An OS that executes in this
architecture is called guest OS, and the VM is usually called a
hypervisor [29]. The hypervisor can be run on the top of an OS. 3.4 Memory management and performance
The VM is often implemented as a combination of real machine In a traditional OS, memory management refers to the method of
and virtualisation software. The hypervisor provides access to the allocating and deallocating memory for operations. There are two
hardware resources for the OS through specific interfaces. Its main conventional memory management techniques: static and dynamic
advantage is its portability, whereas its main disadvantage is its low memory management methods [27]. The static memory
system performance [29]. management method is simple and useful when dealing with
limited memory resources. However, the results are inflexible due
3.1.4 Modular architecture: This architecture allows to replace or to the run-time memory allocation which cannot occur. On the
add kernel components dynamically at run time. In a modular other hand, the dynamic memory management method is more
kernel, some components with similar functionality will be located flexible because memory can be allocated and deallocated at run
in separate files called modules that can be configured and handled time. A process memory protection is also important which means
for various types of functionalities easily [28]. protection of one process address space from another to prevent
unauthorised interfering or data loss [27]. The OS should be
3.1.5 Layered architecture: This architecture consists of several designed with the smallest footprint to provide the fastest
layers, in which each layer is built on top of the one below [30]. performance including memory operations. Memory management
The bottom layer (layer 0) is the hardware layer, and the highest and performance are significant characteristics of IoT device and is
layer (layer n) is the user interface layer. The layered architecture is the primary reason why so many sophisticated OSs cannot be
manageable, easy to understand, and reliable. The main easily adapted to IoT devices [32].
disadvantage is that they are not a very flexible architecture from
an OS design perspective because it requires an appropriate 3.5 Communication and networking protocols support
definition of the different layers and precise planning of the correct
placement of a layer [30]. Another important aspect of choosing or designing an OS is the
communication and networking protocol supported. Protocols
specify interactions among different communicating entities. They
3.2 Programming model and development environment exist at different levels in a telecommunication connection [37].
Programming model represents the style of programming applied Choosing an optimised communication and networking protocol
to create a software which is primarily used to guide the for a particular application is highly essential [37]. Especially, with
development through programming languages. Many factors a wide range of communication and networking protocols such as
influence the choice of an appropriate programming model such as wireless fidelity (WiFi), ZigBee, Bluetooth, and second-generation
concurrency control mechanism, memory hierarchy design, and (2G)/3G/4G cellular technologies etc. [37]. There are also several
other factors [31]. There are two types of programming models: new growing communication and networking protocols such as
multithreading and event-driven programming [31]. Multithreading thread as an alternative for home applications, and Whitespace TV
is the most familiar model for developers but it is not considered technologies that can be applied in cities. Relying on the
well suited for resource-constrained devices such as sensors. Event- application and its factors such as data requirements, security,
driven programming is the most common model for writing power consumption will dictate the choice of the most appropriate
programmes. It is useful for developing IoT devices but deemed communication and networking protocols [38]. IoT devices can be
inconvenient for traditional application developers [27]. directly connected using cellular technologies such as 2G/3G/4G
Sometimes the behaviour of devices and their algorithms may cellular, or they can be connected through a gateway, making a
need to be modified either because of their functionality or energy- local area network, to get a connection to the Internet [37, 38]. The
consumption properties. Hence, the OS should be able to be mentioned technologies of ubiquitous computing such as
reprogrammed and upgraded when required [32]. However, a embedded sensors, light communication, and Internet protocols
software development kit (SDK) for an OS provides the software (IPs) are essential for IoT [37]. However, they impose several
framework for the programmers for interfacing with different challenges and introduce the need for specific standards and

communication protocols [37]. Processes communicate with each technology of secure electronic products and intellectual property
other within the same system or with a different one or even with of software [42].
other processes on heterogeneous devices. Therefore, IoT OSs
must provide communication and networking protocols and 3.8 Power consumption
heterogeneity must also be taken into consideration as well [27,
37]. Power efficiency is a crucial constraint with portable devices that
run on battery source [43]. Power models are developed from
3.6 Simulation support physical measurements on the hardware platform. In certain
situations, batteries are required to operate for 10 years at least.
Simulator refers to the process of imitating one OS into another OS Even though that power utilisation is mainly dependent on
or another device. Simulations and emulations can also make hardware selection, OSs which sustain power management features
programmes to run on OSs which were not intended formerly for are capable to efficiently manage applications to enhance battery
them [27]. The OS simulator provides varying degrees of life and allow for long sleep cycles as much as possible [44]. The
scalability and detail for understanding the behaviour of IoT OS represents the primary software component and determines the
devices throughout two main aspects of a computer system's total power in many modern application executions. The selection
resources which are memory and process management. The of OS can have a significant impact on the power consumption of
primary user interface for OS simulator contains a CPU, where all an OS in both active and passive manners. An active manner when
codes are available to the simulator to create multiple instances of there is active power management as the OS can take specific
the code as separate processes [27]. actions to control, limit, or optimise the device power
consumption, whereas in a passive mode, the architectural features
3.7 Security of the OS have an indirect effect on power consumption [44].
With the tremendous progress of IoT, more and more objects/things 3.9 Supporting multimedia
will be connected to the Internet. So, it is essential to ensure a
secure data channel between the participated devices in IoT [39]. Some IoT applications may require that OSs support time
Also, it is a must to have a secure and reliable connection between constrained data types such as streaming media applications,
heterogeneous devices in IoT environment [19, 39]. The IoT distributed games, and online virtual environments. Most
entities will mostly neither be a single-use, nor sole-ownership traditional OSs are incompatible with these timing constraints, and
solution. The devices, things, and the control policies could have a they are also poorly matched to the multimedia processing since
different use, policies, administration, and connectivity domains. user requirements changing dynamically. Moreover, supporting
Consequently, devices will be ordered to have open access to some commercial real-time multimedia software has the additional
data users. On the basis of the fact that the collected information requirement that the OS must provide for controlling and
may contain personal information of the users, so it is essential to communicating resource usage among independent real-time
ensure the security of the devices in IoT. Generally, these IoT activities. Moreover, audio and video sources generate data that
devices are limited in the resources, memory, and computational needs exhaustive processing to be compressed and decoded for
power. Moreover, they are more susceptible to attacks than other streaming. The data exchange occurs from these sources to other
endpoint devices such as computers, tablets, or smartphones. One destinations such as loudspeakers and video situated on the
of the challenges facing the security of IoT is its components spend computer or at another remote station. Multimedia data is
most of the time unattended, so that they can be physically processed on the way from the source to the sink through copying,
attacked. Another challenge is that most of the communications in moving, and transmitting operations. OSs manage the resources
IoT are wireless, which makes eavesdropping extraordinarily easy. where the data processing occurs. The OS must be able to process
Also, IoT devices cannot apply complicated security schemes due audio and video, and the amount of data that has to be transferred
to their limited capabilities [40]. can be substantial [45].
Security is a top priority and should be considered in the Fig. 1 summarises the main features and aspects discussed in
hardware too as similar to conventional desktop computers, severe this section. We use these design and development aspects to
challenges exist. IoT devices will be expanded to most aspects of evaluate the open-source IoT OSs discussed in our survey.
our lives, so we have to overcome these difficulties and challenges
[41]. 4 Classifications of IoT OSs
To provide security, there are several traditional security
techniques such as patch upgrades, security scanning, virus OSs can be classified based on different criteria. For example, they
checking and killing, intrusion detection, and other security can be classified by their source code either open or closed. Also,
techniques. However, these techniques and tools can be used for a they can be categorised according to the purpose of their design
small part of the IoT system that can hardly overcome with the into either specially designed IoT OS or customised version of an
rapid growth of security threats and attacks. Trusted platform existing OS. Another classification for OSs is to divide them into
module (TPM) security system of IoT is a technology designed to Linux based or non-Linux based. Finally, OSs can be classified
provide hardware-based and security-related functions. TPM based on the targeted devices whether high-end IoT devices or low-
hardware chips can be used with any OS [42]. A TPM chip stores end IoT devices.
cryptographic keys to be used for encryption that set on computer's In open sources, the source is available to anyone so that the
motherboard. When enabled, the TPM provides full disc user can use the freely distributed code, and modify it even for
encryption capabilities. It becomes the ‘source of trust’ for the commercial purposes to fit a particular requirement such as Linux
system to provide integrity and authentication to the boot process. OS. Closed source OSs use code that is implemented by private
It holds hard drives locked until the system completes an parties and is kept unpublished to have full control over the OS and
authentication check or a system verification. The chip includes the keep its proprietary [9]. An OS is usually classified into two
following trusted modules: user, perception, terminal, network, and different software ecosystems. The first is Linux based, and the
an agent. These modules are specially designed to avoid the second is non-Linux based. Linux OS is an open-source cross-
different security threats in the applications of IoT [42]. Moreover, platform based on Unix OS that can be installed on PCs, servers,
security problems of IoT can be described from the network layer and other hardware. On the other hand, non-Linux OS is not based
such as sensor attacks, sensor abnormalities, radio interference, on Linux or Unix; rather it depends on other OSs such as Windows
network content security, hacker intrusion, and illegal and ReactOS.
authorisation. However, IoT may face many security issues at the The last classification of IoT OSs is based on the capability and
application layer such as database access control, privacy performance of IoT devices; they can be classified into two
protection technology, information leakage tracking technology, categories. The first category is for high-end IoT devices which
secure computer data destruction technology, and protection include single-board computers such as the Raspberry Pi (RPi).
High-end IoT devices can run traditional OSs such as Linux. The

Fig. 1 Overview of the designing and developmental aspects of IoT OSs
Fig. 2 Proposed taxonomy of open-source IoT OSs
second category is for low-end IoT devices, which have limited needed to setup hardware [47]. Different components are grouped
resources and cannot run by traditional OSs. An example of low- with the scheduler to run on the mote platform. The mote platform
end IoT devices is Arduino. has very insufficient physical resources depending on which
In this paper, we target the most used and state-of-the-art open- components are active. Typical TinyOS motes consist of a 1
source IoT OSs due to the limit on the number of pages. For the microprocessor without interlocked pipeline stages (MIPS)
closed source IoT OSs, we recently published a paper on this topic processor and tens of kilobytes of storage. A component is an
[46]. Fig. 2 shows a proposed taxonomy of open-source IoT OSs independent computational element that shows one or more
based on low-end or high-end IoT devices, and on Linux based and interfaces. Components have three computational abstractions:
non-Linux based from a high-level perspective either. commands, events, and tasks. Mechanisms for inter-component
communication are commands and events, whereas tasks are used
5 OSs for low-end IoT devices to express intra-component concurrency. A command is a request
to perform some service while the event signals represent the
In this section, we will describe the most widely used low-end OSs completion of service [27, 47]. Fig. 3 shows the architecture of
for IoT devices from the aspects and criteria presented in Section 3. TinyOS. The scheduler schedules operation of those components.
The main objective of this section is to provide an exhaustiveness Each component consists of four parts: command handlers, event
understanding of each low-end IoT OS. handlers, an encapsulated fixed-size frame, and a group of tasks.
Commands and tasks are performed in the context of the frame and
5.1 TinyOS operate on its state. Each component declares its commands and
events to allow the modularity and easy interaction with other
TinyOS is an open-source non-Linux-based OS designed explicitly components [32].
for low-end IoT devices, embedded and wireless devices such as
sensor node networks, smart buildings, and smart sensory
platforms [47]. TinyOS is built based on a set reusable software 5.1.2 Programming model and development
component [47]. It is written using NesC programming language, environment: TinyOS supports an event-driven concurrency
which has a similar syntax to C language [47]. Each TinyOS model which consists of split-phase interfaces, deferred
component has a frame and a structure of private variables. These computation, and asynchronous events [31]. TinyOS is
components have three computational abstractions: commands, programmed in NesC for memory limitations of sensor networks
events, and tasks [47, 48]. Commands are used to call a component which are similar but not compatible with the C language. It allows
to do a specific task. Events are mechanisms for entering writing pieces of reusable code which explicitly indicates their
component communication, while tasks are used to represent dependencies [47]. Also, TinyOS uses a mechanism called Trickle.
component concurrency [49]. Trickle is an algorithm used for propagating and maintaining code
updates when needed. Trickle applies a polite gossip policy, where
nodes occasionally broadcast code to all neighbour nodes, and
5.1.1 Architecture and kernel models: TinyOS has a monolithic remain silent. When a node hears an older summary of its own, it
architecture and uses a component-based architecture that depends broadcasts an update rather than sending a network signal with
on the application requirements. This reduces the size of the code packets. Then, the algorithm manages the process of sending, so
each node only hears a small trickle of packets which is just
enough to stay up to date. Trickle propagates new code within
seconds and makes the maintenance cost less in terms of time
(propagation of new code to all neighbours’ nodes) [35]. The
primary challenge in TinyOS development is the creation of
flexible and reusable components [49].
5.1.3 Scheduling: The task scheduler in TinyOS is a simple non-

preemptive first-in–first-out (FIFO) scheduler using a bounded size
scheduling data structure. The TinyOS scheduler sets the processor
to sleep when the tasks are completed; to maximise CPU utilisation
as well as the OS performance [50].
5.1.4 Memory management and performance: TinyOS uses

static memory allocation with memory protection. There are no Fig. 3 Architecture of TinyOS (reproduced from [27])
concepts of dynamic memory allocation such as hidden heaps,
dynamic memory, or function pointers because TinyOS 5.1.9 Supporting multimedia: TinyOS supports full IP network
programmes are organised in components and are written in NesC stack, with standard IP protocols such as UDP, TCP, and hypertext
language [47]. TinyOS has a small footprint as it uses a non- transfer protocol (HTTP) that are used to stream multimedia
preemptive FIFO task scheduling. It applies synchronisation clock content. The frameworks available for video codecs and
in software, which increases the number of entries in the task multimedia streaming are limited in this OS and have no extended
queue at compile time when the system begins with 1, 32 kHz, or support. Moreover, real-time transport protocol (RTP) is not found
1 MHz. in the base of TinyOS [53].
5.1.5 Communication and networking protocols 5.1.10 More about TinyOS: TinyOS applies fully non-blocking
support: TinyOS has built-in support for common network split-phase operations that enable developers to re-define the kernel
protocols such as transmission control protocol (TCP), user API by choosing an existing set of operations or by implementing
datagram protocol (UDP), ICMPv6, IPv6, IPv6 over low-power one system call stack. In this method, all I/O operations that last
WPAN (6LoWPAN), IPv6 routing protocol for low-power and longer than a few hundred microseconds are asynchronous and
lossy networks (RPL), and constrained application protocol have a callback known as deferred procedure calls [47].
(CoAP), in addition to hydrogen routing protocol that is used for
reliable communication [51]. 5.2 Contiki OS
5.1.6 Simulation support: To validate the analysis model of Contiki is an open-source non-Linux-based OS for low-end IoT
TinyOS applications, a TinyOS Simulation (TOSSIM) simulation devices designed especially for IoT. It is lightweight, highly
environment has been developed. TinyOS simulation (TOSSIM) portable, and multitasking OS that runs on tiny low-power
provides a high flexibility simulation of TinyOS applications which microcontrollers with minimal memory. Contiki OS is written in C
work by replacing components with simulation implementations programming language. It uses 2 kB of RAM and 40 kB of read-
[47]. Moreover, TOSSIM provides developers an integrated only memory (ROM). Nowadays, Contiki can be run on various
environment of the network and troubleshooting capabilities. hardware platforms such as Alf and Vegard RISC processor (AVR),
Server-side applications can be connected to a TOSSIM proxy only MSP430, and Z80 [31, 52, 54].
if it is a real sensor network. Hence, facilitating the transition
between the simulation and real deployments [47]. TOSSIM also 5.2.1 Architecture and kernel models: In contrast to TinyOS.
provides support integration for troubleshooting and debugging Contiki OS has a modular architecture [25]. The core of Contiki
applications directly on the mote. Unfortunately, TOSSIM does not OS mainly consists of multiple lightweight event schedulers and a
support gathering power measurements [47]. polling mechanism. The event schedule is responsible for
dispatching events to run processes and periodically calls
5.1.7 Security: TinyOS uses TinySec library which was processes’ polling handlers, which identifies the action of the
developed using the NesC programming language and polled process [31]. On the other hand, the polling mechanism
implemented by the link layer to provide confidentiality, message identifies high priority events. Polling mechanism is used by
authentication, integrity, and semantic security [52]. The default processes that operate near the hardware to check the status
block cipher encryption in TinySec is Skipjack algorithm that is updates of hardware devices. All processes that implement a poll
used with cipher block chaining (CBC-CS) method. Skipjack has handler are requested in order of their priority [54]. Fig. 4 shows
an 80 bit key length that provides immunity to brute force attacks the architecture of Contiki OS. Contiki OS contains sensor data
[52]. Skipjack generates message authentication code (MAC) handling, communication protocols, and device drivers as services.
method which utilises CBC-MAC [52]. However, CBC-MAC has Each service has its interface and implementation.
security lacks since it furnishes semantic security with an 8 B
introduction vector which includes only a 2 B counter overhead per 5.2.2 Programming model and development
packet [52]. TinySec holds <10% energy, inactivity, and transfer environment: Unlike TinyOS, the programming models in Contiki
speed overhead [52]. support both multithreading and event-driven using protothreads.
The main advantage of protothreads is their very minimal memory
5.1.8 Power consumption: TinyOS provides efficient low-power overhead with no extra stack for a thread. Since events run to
consumption operation and limited storage using a simple completion, Contiki does not allow interruption of handlers to post
execution model [44]. TinyOS execution model is based on split- new events, and it does not allow process synchronisation [27].
phase operations and interrupts handlers. It allows the scheduler to Programming models with Contiki are defined by events in a way
decrease its random access memory (RAM) utilisation and easily that all tasks are executed in the same context [52]. Protothreads
maintains sync code. This avoids the need for threads and allowing mechanism runs on top of the event-driven kernel. A protothread
all programmes to execute on a single stack. However, it implies process is invoked whenever a process receives an event, and the
that if one sync code runs for a long term, then it prevents other protothreads mechanism decides which memory should be
sync code from running; which can negatively influence system allocated [55]. Contiki is implemented by system libraries which
responsiveness [44]. are connected with programmes. Programmes can be connected
with libraries in three ways. The first way, the programmes can be

simulation environment to allow testing of code before running it
on the target hardware devices [62].
5.2.7 Security: Contiki OS uses ContikiSec transport layer

security (TLS)/datagram transport layer security (DTLS), which is
a secure network layer, and contains three modes: authentication,
confidentiality, and integrity in communication. ContikiSec uses
low-energy utilisation and security while complying with a little
memory footprint [52].
5.2.8 Power consumption: Contiki is intended to run on low-

power devices that may need to keep running for quite long time
on batteries [63]. To help the improvement of low-power devices
power consumption, Contiki provides software-based power
profiling mechanism for estimating the system power utilisation
and for knowing where the power was consumed giving power
awareness [62].
5.2.9 Supporting multimedia: Contiki supports full IP network

Fig. 4 Architecture of Contiki OS (reproduced from [27]) stack protocols such as UDP, TCP, and HTTP that are used to
stream multimedia contents. The frameworks available for video
statically connected with libraries that are part of Contiki core. codecs and multimedia streaming are limited in this OS and has no
Second, programmes can be statically linked with libraries that are extended support. Moreover, RTP protocol is not found in the base
part of the loadable programme. Third, programmes can call of Contiki.
services using a specific library. Libraries that are applied as
services can be replaced dynamically at the running time. Consider 5.2.10 More about contiki OS: One of the essential features of
a programme that uses the memcpy() and atoi() functions to copy Contiki is dynamic loading; which is the ability to link modules at
memory and to convert strings to integers, respectively. The run time [64]. Contiki transferred nodes can be battery-operated
memcpy() function is a frequently used C library function; whereas because of the ContikiMAC radio duty cycling mechanism which
atoi() is used less often. Therefore, in this example, memcpy() has allows nodes to sleep between each relayed message [65]. Unlike
been included in the Contiki core but not atoi(). The memcpy() TinyOS that has no blocking operations, Contiki provides some
function will be linked against its static address in the core when conditional blocking of functions in a sequential instruction block.
the programme is linked to produce a binary. The object code for
the part of the C library that implements the atoi() function must, 5.3 Real-time OS for IoT (RIOT) OS
however, be included in the binary programme [31]. Moreover,
Contiki uses loadable modules to perform dynamic code The RIOT is known as ‘the friendly OS for the IoT’. RIOT is an
reprogramming and upgrading. With loadable modules, only open-source non-Linux-based OS specialised for low-end IoT
specific parts of the codes need to be modified when a single devices with a minimum of 1.5 kB of RAM and 5 kB of ROM
programme is changed [56]. Besides, Contiki provides a command- [66]. RIOT provides a uniform abstraction over the details of
line shell which is useful during development and debugging of different IoT hardwares. It was developed by a grassroots
Contiki systems [57]. community using C programming language. RIOT can run on
various platforms including embedded systems, and it is easy to
5.2.3 Scheduling: The scheduling used in Contiki OS is similar to use. It supports many functionalities such as interruption handling,
TinyOS, in which both use FIFO scheduling strategy. In Contiki, memory management, IPC, and synchronisation. Moreover, RIOT
all event-driven scheduling is done at a single level and events has many advantages such as reliability, predictability,
(preemptive multitasking); events are executed as they arrive [31]. performance, and scalability [67].
5.2.4 Memory management and performance: Unlike TinyOS, 5.3.1 Architecture and kernel models: In contrast to the other
Contiki supports dynamic allocation or deallocation of memory OSs such as TinyOS or Contiki. RIOT has a microkernel
through mmeb() and mmem() as well as malloc(). The memb() architecture, which has been designed to work on several IoT
memory block allocator is the most frequently used. The mmem() platforms with different CPU architectures (32 bit, 16 bit, 8 bit)
managed memory allocator is used infrequently and it uses the such as ARMv7, ARM Cortex-M0 + , MSP430, and some recent
standard C library malloc() heap memory allocator [58]. In AVR microcontrollers. The microkernel architecture of RIOT OS
addition, Contiki uses Contiki coffee file system technique for data was developed using C + +, and it supports full multithreading that
storage inside the sensor network. It allows multiple files to exist provides a developer-friendly API and allows C + + and ANSI C
on the same physical onboard flash memory [58]. application programming. RIOT kernel will never crash because it
supports error device drivers. The architecture design of RIOT also
5.2.5 Communication and networking protocols contains POSIX compliance [42, 68]. Fig. 5 shows the structure of
support: Contiki OS supports many protocols such as CoAP and RIOT, which is divided into four layers. The first layer is the
the message queue telemetry transport (MQTT) [59]. In addition to kernel; which consists of the scheduler, inter-process
that, the two main communication stacks are uIP and Rime stack communication, threading, thread synchronisation, supporting data
that consists of a set of custom lightweight protocols for power structures and type definitions. The second layer is platform
constrained wireless networks [59]. Contiki supports a full IP specific code (CPU boards), which contains the configuration for
network stack with standard IP protocols such as UDP, TCP, and that particular CPU. The third layer is device drivers, which consist
HTTP [60]. Also, it has support for 6LoWPAN adaptation layer, of the drivers for external devices such as network interfaces,
the RPL IPv6 multi-hop routing protocol, and the CoAP RESTful sensors, and actuators. The fourth layer comprises of libraries,
application-layer protocol [61]. network code, and applications for demonstrating features and
testing. Moreover, this layer includes a collection of scripts for
various tasks as well as predefined environment documentation
5.2.6 Simulation support: Cooja simulator supports Contiki, (doc) [67].
which is a useful tool for Contiki OS application development.
Cooja makes simulation colossally less demanding by providing a

Fortunately, the first situation will happen once in a while. Then,
when RIOT's kernel gets called again, a task switch can be
performed in very few clock cycles [71]. Moreover, RIOT OS is an
exceptionally suited software platform to optimise energy
consumption on battery-powered microcontroller (MCU)-based
devices and consumes less energy [68].
5.3.9 Supporting multimedia: RIOT supports full TCP/IP

network stack protocols such as UDP, TCP, and HTTP that are used
to stream multimedia content. It has many onboard modules which
are essential for developing multimedia applications [71].
5.4 LiteOS
Fig. 5 Architecture of RIOT OS (reproduced from [66]) LiteOS is an open-source Linux-based lightweight OS designed to
run on low-power devices. This makes LiteOS suitable for a wide
5.3.2 Programming model and development range of areas including wearable, smart homes, connected
environment: RIOT is similar to Contiki that it also supports vehicles, and microcontrollers. LiteOS can be installed on devices
preemptive multithreading. RIOT is developed using standard that run by Google Android OS, and it can connect with other
programming languages such as ANSI C and C + + [69]. With third-party devices. It is developed purposely to provide a Unix-
RIOT, developers can code the application once and run it on like OS for IoT developers and to provide programmers with
various IoT hardware devices. Moreover, RIOT provides common familiar programming paradigms such as a hierarchical file system
programmer APIs such as Berkeley software distribution (BSD) developed using LiteC programming language and a Unix-like
sockets or POSIX thread (pthread) functionalities [70]. Besides, shell [27, 74].
RIOT can run and debug the same as in Linux and MacOS using a
set of popular debugging tools such as GNU Debugger (GDB) and 5.4.1 Architecture and kernel models: In contrast to RIOT,
Valgrind [67]. The C + + programming capabilities used in RIOT LiteOS has a modular architecture divided into three subsystems;
allow RIOT to use powerful libraries such as the Wiselib, which LiteShell, LiteFS, and the kernel [32] as shown in Fig. 6. LiteShell
contains algorithms for routing, clustering, time sync, localisation, is a Unix-like shell that provides support for shell commands such
and security. RIOT has other programming features such as as file management, process management, and debugging.
dynamic linking support, Python interpreter, and energy profiler LiteShell resides on a base station or a PC. This leverage allows
[71]. Also, RIOT provides virtualisation, where the code and more complex commands as the base station, or PC has abundant
application can run as a simple Unix process. RIOT uses Wireshark resources. The LiteShell can only be used with user intervention.
for packet analysing [67]. Some local processing is done on the user command by the shell
and then transmitted wirelessly to the intended IoT node. The IoT
5.3.3 Scheduling: Together with Contiki. RIOT implements node does the required processing of the command and sends a
preemptive priority-based and tickless scheduling, where each task response back which is then displayed to the user. When a mote
has a priority in execution that helps the scheduler to select the does not carry out the commands, an error code is returned. The
highest priority task to run on CPU. RIOT tasks with the highest second architectural component of LiteOS is its file system,
priority are executed first, and if there are more than one high LiteFS, which consists of sensor nodes as a file and it mounts a
priority tasks, a round-robin (RR) mechanism will be used [71]. sensor network as a directory and then lists all one hop sensor
nodes as a file. A user on the base station can use this directory
5.3.4 Memory management and performance: In RIOT OS, structure just as the traditional Unix directory structure and can
both dynamic and static memory allocations are provided for also use legitimate commands. The third subsystem of LiteOS is
applications [72]. RIOT OS does not have a memory management the kernel which resides on the IoT node. The kernel supports
unit (MMU) or floating point unit. However, it has a low memory concurrency multithreading, dynamic loading, and uses RR and
footprint in the order of a few kBs [66, 68]. priority scheduling, which allows developers to register event
handlers through callback functions [27].
5.3.5 Communication and networking protocols
support: RIOT OS supports several networking protocols 5.4.2 Programming model and development
including TCP/IP v4 and v6 and the latest standards for connecting environment: LiteOS is a multitasking OS that supports
constrained systems to the internet engineering taskforce (IETF) multithreading. In LiteOS, processes run applications in separate
6LoWPAN [72]. In addition to that, RIOT has built-in support for threads. Each thread has its allocated memory which helps in
other IoT-related network protocols such as CoAP and RPL [73]. protecting the memory. LiteOS also provides support for event
handling [27]. Also, it supports dynamic reprogramming and
replacement mechanism through the user application.
5.3.6 Simulation support: At the time of writing this paper, RIOT Reprogramming can be performed either if the source code of the
OS does not have a simulator. Rather, we can have a full-scale OS is available or not. If it is available, it will be easily recompiled
simulation for RIOT applications from Contiki–Cooja simulator for with new memory settings, and all pointers of the old version will
IoT [67]. be redirected, whereas if the source code is not available, it uses a
differential patching mechanism to upgrade the older version. Also,
5.3.7 Security: RIOT supports powerful attack detection LiteOS supports online debugging including variable watches and
capabilities called secure cyber-physical ecosystem (CPS). CPS is a vast number of breakpoints. Additionally, it contains extensive
a system that interacts, monitors, and controls smart objects development libraries [76].
through complicated processes. When an attack is detected, then
the reaction to it occurs [69]. 5.4.3 Scheduling: LiteOS implements both priority-based and
RR scheduling in the kernel. The task to be executed is chosen
5.3.8 Power consumption: The simplicity of microkernel from the ready queue using priority-based scheduling. When a task
architecture of RIOT is the main characteristic to enable maximum requires a resource that is not available currently, the task allows
energy efficiency [67]. RIOT context switching can happen in two interrupts and goes to sleep mode [32].
situations. The first situation is when a corresponding kernel
operation gets called by itself such as a mutex locking. The second
situation is when an interruption happens in a thread switch.
wireless support including LTE and mesh networking [60]. LiteOS
supports Windows XP, Windows Vista, and Linux in addition to
both MicaZ and IRIS nodes. Moreover, it supports both plug-and-
play routing stack. Other advantages of LiteOS are that it has an
extremely lightweight event logging and it has a built-in
hierarchical file system. Finally, LiteOS snapshots a thread state
and can restore it to a previous state [74].
5.5 FreeRTOS
FreeRTOS is an open-source non-Linux, multitasking, preemptive,
and mini real-time OS for low-end IoT devices mainly developed
using C and some assembly functions [80]. It is very scalable,
simple, easy to use, and highly portable. Its main strength is the
small kernel size, which makes it possible to run different small
applications. Another strength is that FreeRTOS supports an
extensive variety of hardware architectures, which make it a good
choice to be used with different IoT applications [81, 82].
5.5.1 Architecture and kernel models: FreeRTOS has a

microkernel real-time operating system (RTOS) architecture, which
is designed to be small, simple, and easy to use [28]. FreeRTOS
Fig. 6 Architecture of LiteOS (reproduced from [75])
kernel is specifically designed for embedded processors. FreeRTOS
consists of hardware layer, device driver, FreeRTOS kernel, and the
5.4.4 Memory management and performance: LiteOS
tasks to be performed. Fig. 5 shows the architecture of FreeRTOS.
implements dynamic memory allocation with an almost zero
overhead through system calls using malloc() and free() API
functions. The malloc() function allocates memory using a pointer. 5.5.2 Programming model and development
If the size of memory is zero, then malloc() returns to either NULL environment: FreeRTOS is professionally developed. It is free
or a unique pointer value that can be passed to free() function. The open source and fully supported, even when used in commercial
free() function frees the memory space, which must have been applications. However, FreeRTOS decreased the debugging efforts
returned by a previous call to malloc() function. This enables due to the lack of hardware abstraction layer (HAL) by using the
adapting the size of dynamic memory as required by an application STM32Cube MCU firmware [83]. In addition, FreeRTOS supports
[77]. multiple threads, mutexes, semaphores, and software timers [77].
All FreeRTOS kernels contain three or four C files (depends on the
usage of coroutines) which are; (i) list.c, (ii) queue.c, and (iii)
5.4.5 Communication and networking protocols
tasks.c, and one microcontroller source file are needed. The tasks.c
support: LiteOS does not have any built-in networking protocols
performs most of the scheduler assembler functionalities. The list.c
that support real-time applications [77]. LiteOS provides support
defines the structures and functions to be used by file tasks.c. The
for long-distance connection based on technologies such as long-
queue.c performs thread-safe queues that are used for
term evolution (LTE) and NodeB (NB)-IoT, and short-distance
synchronisation and intertask communication. These files are
connection based on communication protocols such as ZigBee and
included in the .zip file related only to the applications which make
6LoWPAN [74].
the code more readable and maintainable. FreeRTOS API is
designed to be simple and easy to use [84].
5.4.6 Simulation support: AVRORA simulator can be used to
emulate LiteOS on physical IoT devices. AVRORA is a set of
5.5.3 Scheduling: The scheduler used in FreeRTOS is either a
simulation tools for programmes written for the AVR
fixed prioritised preemptive or cooperative scheduler strategies
microcontroller. AVRORA contains an adaptable system for
depending on the configuration of the scheduler [77]. A fixed-
simulating and prototyping programmes, which allows Java API
priority scheduling ensures that the processor executes the highest
experimentation, profiling, and investigation [78].
priority task that is ready to be executed at any given time by using
the RR scheduling policy [77].
5.4.7 Security: In terms of security, LiteOS provides independent
user space and application separation through a set of system calls.
5.5.4 Memory management and performance: FreeRTOS
The authentication mechanism is needed between the base station
supports dynamic memory allocation, and its memory footprint is
and mounted motes, especially low-cost authentication
small [84].
mechanisms. To ensure the security of communications between
the sensors and systems, LiteOS has a security component by
embedding Hi3519 chip Huawei Lite OS that can be implemented 5.5.5 Communication and networking protocols
to security cameras and portable high-definition camera [74]. support: FreeRTOS uses 6LoWPAN and CoAP networking
protocols [85] in addition to the open source, and thread-safe
TCP/IP stack for FreeRTOS called FreeRTOS + TCP [85].
5.4.8 Power consumption: LiteOS supports ultra-low-power
consumption; it can be used to run MicaZ motes having 128 B of
flash memory, 4 kB of RAM, and 8 MHz CPU. LiteOS battery can 5.5.6 Simulation support: FreeRTOS can be simulated in both
power a device for five years or more [74, 79]. Windows and Linux OSs using the following simulators. Win32
simulator using visual studio 2015 for Windows OS and developed
by Dushara Jayasinghe [84], whereas POSIX/Linux simulator is
5.4.9 Supporting multimedia: LiteOS does not support any
used for Linux OS using GNU compiler collection (GCC) and
implementation of networking protocols that support multimedia
Eclipse provided by William Davy [84].
applications [27].
5.5.7 Security: FreeRTOS uses WolfSSL, which is a lightweight
5.4.10 More about LiteOS: LiteOS offers many novel features
TLS/secure sockets layer (SSL) library. WolfSSL is used to provide
including zero configuration, auto-discovery, auto-networking, fast
security, authentication, integrity, and confidentiality of
boot, a hierarchical file system, a wireless shell interface for user
communications over the FreeRTOS. WolfSSL is best suited for
interaction and real-time operations. It also provides extensive

the embedded system since it is 20 times smaller in footprint
compared with the OpenSSL library [84, 86].
5.5.8 Power consumption: In order for the microcontroller to

function in the low-power state, FreeRITOS uses idle task hook.
Using this method, it decreases power consumption through
process tick interruptions. However, if too many tick interruptions
occur, the power consumption will increase more than the power
saving limit. The tickless of FreeRTOS is an idle mode that stops
the periodic tick interrupt during idle periods. This makes a
correcting adjustment to the RTOS tick count value when the tick
interrupt is restarted [84] (Fig. 7).
5.5.9 Supporting multimedia: FreeRTOS is designed for low-

powered applications, which leaves the expensive encoding/
decoding process to external devices. However, the TCP and UDP
stack support in FreeRTOS can be used to implement some
applications limited to image contents using Javascript and
HTML5.
Fig. 7 Architecture of FreeRTOS (reproduced from [80])
5.5.10 More about FreeRTOS: This OS is recommended to

handle time-critical tasks that require user control and sensor
monitoring as it can be handled through multiple threads, software
timers, and semaphores along with tickless mode for low
consumption of resources while running various applications.
5.6 Apache Mynewt OS

Apache Mynewt is an open source, Linux-based, and real-time OS
originally developed by Runtime Inc. and hosted by Apache.
Mynewt OS targets low-end devices that have limited memory and
storage capabilities that need to operate for a long time under
power constraints. Additionally, Mynewt OS has many powerful
features such as precise reconfigurability of concurrent connections
and granular power controls [87].
Fig. 8 Architecture of ARM Mbed OS (reproduced from [91])
5.6.1 Architecture and kernel models: Mynewt OS has a 5.6.8 Power consumption: Mynewt has low-power consumption;
modular architecture. Mynewt targets ARM Cortex M0–M4 and devices operate in sleeping mode to conserve battery power and
RISC-V architectures with a plan to extend the hardware support to maximise power usage [87].
MIPS architecture [88]. Also, Mynewt OS is supported on the
Arduino Zero, Arduino Zero Pro, and Arduino M0 Pro processors
5.6.9 Supporting multimedia: At the time of writing this paper,
[88, 89].
there is no support for multimedia contents or devices in Apache
Mynewt OS.
5.6.2 Programming model and development
environment: Mynewt OS supports multithreading tasks [89].
5.6.10 More about Apache Mynewt: HAL is used in Mynewt to
Developers can debug code by setting breakpoints, avoiding stack
provide a uniform interface for peripherals across different
smashes, and eliminating stolen interrupts [89].
microcontrollers, which allow direct access to peripherals for
granular power control [89].
5.6.3 Scheduling: Mynewt OS supports tickless preemptive
priority-based scheduling [89].
5.6.11 ARM Mbed OS: ARM Mbed is an open-source Linux-
based OS for low-end IoT devices licenced under Apache Licence
5.6.4 Memory management and performance: Mynewt OS 2. ARM cores introduce it for 32 bit ARM Cortex M
supports memory heap and memory pool allocation [87]. microcontrollers. It supports all essential open standards for
connectivity and device management. ARM Mbed OS provides a
5.6.5 Communication and networking protocols platform that includes the following features: connectivity, security,
support: Mynewt OS provides full support for the TCP/IP suite. It cloud management services, and device management
also supports protocols for constrained networks such as CoAP and functionalities that are required by IoT devices [33, 90].
6LoWPAN [87]. Also, Mynewt OS has full implementation of the
Bluetooth low-energy 4.2 stack, Bluetooth mesh, LoRa PHY, and 5.6.12 Architecture and kernel models: ARM Mbed OS
LoRaWAN [87]. supports monolithic architecture [25]. ARM Mbed OS runs on 32
bit ARM embedded architecture and supports a few other platforms
5.6.6 Simulation support: Mynewt can be simulated using the [91]. Fig. 8 shows the architecture of ARM Mbed OS and its
Quick Emulator (QEMU). different layers.
5.6.7 Security: Apache Mynewt OS enables secure remote 5.6.13 Programming model and development
updates to maintain ongoing security. Also, Mynewt OS provides environment: ARM Mbed OS uses a single thread and adopts an
safe bootloader to verify firmware integrity and authenticity [89], event-driven programming model [91]. ARM Mbed OS is
and uses security manager protocol for pairing and transport developed using C and C + + programming languages. Moreover, it
specific key distribution for securing radio communication [89]. has many programming features that allow developers to select
from different types of microcontrollers. Also, Mbed API can keep
application code readable, simple, and portable [91].

5.6.21 More about ARM Mbed OS: The Arm Mbed device
connector can connect IoT devices to the cloud without needing
any additional infrastructure [91].
6 OSs for high-end IoT devices

In this section, we will describe the most widely used OSs for high-
end IoT devices from the aspects and criteria presented in Section
3.
6.1 uClinux OS
uClinux is an open-source Linux-based OS for high-end devices. It
is an extension to the Linux kernel. uClinux kernel includes a
collection of Linux 2.x kernel releases intended for single
microcontrollers without an MMU. Also, it has a set of user
applications, libraries, and toolchains. This OS needs special
support for inter-processor communication [77, 78].
6.1.1 Architecture and kernel models: uClinux OS follows a

monolithic architecture [95]. uClinux kernel supports various CPU
platforms such as ColdFire, Axis ETRAX, and others. The primary
difference with Linux OS is it has MMU-less. However, uClinux
OS additionally supports different file systems including files
designed especially for the embedded solutions similar to Linux
OS. There have been previous attempts to achieve compatibility
between uClinux and Linux to make uClinux as similar as possible
to Linux. These attempts proposed several applications that
Fig. 9 Architecture of uClinux OS (reproduced from [96])
developed under general public licence. These applications should
support MMU-less version of Linux with slightly few changes
5.6.14 Scheduling: Mbed OS includes a basic non-preemptive [95]. Fig. 9 shows the architecture of uClinux OS.
scheduler with limited synchronisation and communication
primitives to support its communication and cloud protocols [91].
environment: uClinux OS supports multithreading programming
5.6.15 Memory management and performance: ARM Mbed model [97]. uClinux includes a cross-compiler platform that is built
OS supports dynamic memory allocation [91]. from the GNU compiler tools (GCC). Its architecture is x86 which
is often built without the ability to be modified on any uClinux
5.6.16 Communication and networking protocols target. Debugging can be performed using GNU debugger (gdb)
support: Mbed OS provides support for many communication [98].
protocols such as WiFi, Bluetooth low energy, Lightweight M2M
(LwM2M), and Ethernet [92]. Also, it supports several networking 6.1.3 Scheduling: uClinux implements priority-based preemptive
protocols including HTTP/CoAP stack with TLS and DTLS for scheduling [77].
end-to-end IP (v4 and v6) security with 6LoWPAN, SSL, and
MQTT [10, 93].
6.1.4 Memory management and performance: uClinux is
derived based on Linux 2.0 kernel and is designed for
5.6.17 Simulation support: Mbed OS can be simulated using microcontrollers without MMUs, so any process can read and write
QEMU, which is a generic and open-source machine emulator and other process memory. It provides dynamic and static memory
virtualiser [94]. allocation [99]. However, uClinux OS has the downside in memory
management hardware that does not fit low-end IoT device [25].
5.6.18 Security: Untrusted and malicious codes are blocked in
Mbed OS for IoT platforms as the communications between device 6.1.5 Communication and networking protocols
and cloud, and the life cycle of the system itself occurs through support: uClinux OS uses uIP and lwIP networking protocols [95].
uVisor which separates security domains on Arm Cortex-M3, M4, uClinux also has a wide networking and communication protocols
and M7 microcontrollers with a memory protection unit [91]. support including a full TCP/IP stack, IPv6, WiFi, and other
There are two mechanisms to guarantee security in Mbed by networking protocols [95].
integration with the application development. The first is Mbed
TLS for cryptographic and SSL/TLS capabilities. The second is
Mbed OS uVisor for hardware-enforced secure domains [94]. 6.1.6 Simulation support: uClinux can be simulated using GDB/
ARMulator and SWARM-Software ARM-arm7 emulator.
ARMulator is developed using C programming language and
5.6.19 Power consumption: The Mbed OS has support for an provides more than just an instruction set simulator; it provides a
advanced power management technique that increases power virtual platform for system emulations. It can emulate an ARM
efficiency and improves throughput [94]. This technique allows to processor and other ARM co-processors [98].
turn off some external devices and processor to power down
unused devices inside the processor chip and enter low-power sleep
modes. It is also possible to modify the clock rate on Mbed OS 6.1.7 Security: uClinux OS applies a shepherd process to manage
from 128 to 48 MHz [94]. security issues [100]. A shepherd process is responsible for
accessing security association, and later dropping that access when
a root trip happens. uClinux consists of three main primitives;
5.6.20 Supporting multimedia: Imaging modules can be register, start, and finish. Each of these primitives communicates
integrated easily to Mbed OS through a set of imaging sensors with the kernel to execute their particular functions. Moreover,
available as an extension. Streaming media contents can be uClinux applies the encrypted storage security technique which
achieved using a simple TCP connection or any other high-level forces cryptographic overheads. uClinux supports run-time
communication protocols [94]. interception of the different system calls. For example, running and

open files can make such calls take longer time. When a root trip
starts, shepherd process uses a register to perform any security
actions through communication to the kernel and must be allowed
to drop its security association before that root trip finishes. When
a register finishes its function, the shepherd process can perform its
task to achieve the security. Such as, the mount-efs reads the
UCLinux file system (UCFS)'s secret key from/etc/crypt.key
unseals it and pipes it into cryptsetup. Then, sets up a
cryptographic loopback device, and mounts the file system. Next,
its security association becomes accessible; a shepherd process
uses start action to put the shepherd process to sleep and only
wakes it up when a root trip happens. When it wakes up, it must
drop its security association. Finally, when the shepherd process is
sure that its security association is protected, it uses finish
preemptive through communication to the kernel to complete the
root trip. Hence, allow untrusted programmes to run with a
privileged effective user. In this way, any number of security
associations can be fully protected [100].
6.1.8 Power consumption: uClinux supports power management

techniques which can be modified, so that the idle process can be
called when no other processes are running. This makes the kernel Fig. 10 Architecture of Raspbian OS (reproduced from [105])
enter into a sleep mode until further processing is required. The
kernel uses a kernel ticker to wake up the system 100 times per 6.2.3 Scheduling: Raspbian utilises real-time preemptive
second which causes a problem. However, this problem can be scheduling [106].
solved by building a tickless kernel that only calculates when the
process needs to wake up. This solution reduces the number of 6.2.4 Memory management and performance: Raspbian OS
interrupts occurred [98]. supports a virtual memory technique that is performed by hardware
through MMU. Raspbian also offers virtual memory swapping
6.1.9 Supporting multimedia: uClinux provides support for which divides the hard disc into parts to exchange fractions of main
multimedia through a software project for the record, convert, and memory. Hence, allowing occupied regions that did not take
processing audio and video streams called FFmpeg. FFmpeg uses sufficient time to become available for allocation [104].
HTTP server for live broadcasts processing and gst-real time
streaming protocol (RTSP) streaming server which is a library on 6.2.5 Communication and networking protocols
top of GStreamer. The gst-RTP server is designed to enable many support: Raspbian OS supports a wide range of communications
sources to connect, rebroadcasting, and transmit video and audio through serial peripheral interface (SPI), UART, I2c, and universal
streams over a network to single or multiple users [98]. GStreamer serial bus (USB). It also implements the full stack of TCP/IP and
supports multimedia processing, encoding, and streaming libraries Bluetooth. Similar to other Linux distributions, Raspbian OS has
[98]. support for almost all networking protocols that are imported from
Debian distribution. In addition, a free open-source library for LTE
6.1.10 More about uClinux: uClinux OS supports a vast number and other wireless protocols are available to be used easily with
of devices, filesystems, networking protocols, and applications Raspbian [105].
(such as GNU software). The source code of uClinux is available
to end users and developers. It is tested and refined by many 6.2.6 Simulation support: Raspbian OS can be simulated using
programmers and users. Moreover, systems running uClinux OS QEMU ARM which is a CPU architecture emulator and
may be configured in different ways other than that of the familiar virtualisation tool. QEMU is capable of emulating an ARM
Unix-like Linux distribution. architecture which is very similar to the RPi boards. This allows
booting an RPi image directly to x86 or x86–64 systems. However,
6.2 Raspbian OS to deal with the QEMU virtualised hardware which is not a core
component of the RPi, Raspbian OS must have a RPi kernel for
Raspbian is an open-source Linux-based OS for high-end devices QEMU to control the QEMU kernel image [103].
based on Debian (Linux) and optimised for RPi hardware [101].
Raspbian provides more than 35,000 packages that can be installed
from the terminal. It has a pre-compiled software in a simple 6.2.7 Security: Raspbian OS supports many encryption,
format for easy installation [102]. RPi is a credit-card-sized and authentication, and authorisation techniques that suit most IoT
inexpensive single-board computer that can to be run by Linux and applications. The open-source community provides support for this
other lightweight OSs [103]. It can be run on multiple low- OS and for most encryption algorithms that are available from
performance ARM processors [103]. Raspbian repositories. Customised security requirements can be
easily integrated into Raspbian OS even if it requires modification
in core libraries. Encryption algorithms such as AES 128, AES
6.2.1 Architecture and kernel models: Similar to uClinux OS, 256, data encryption standard (DES), and Blowfish are available in
Raspbian OS follows a monolithic architecture [104]. Fig. 10 all framework libraries in addition to HTTP secure and virtual
shows the architecture of Raspbian OS. private network protocols [105]. Selective encryption algorithms
for multimedia streaming are also supported in Raspbian OS [107].
environment: Like uClinux OS, Raspbian OS supports 6.2.8 Power consumption: One of the great things about creating
multithreading [105]. It is written using Python programming a cluster with ARM-based processors is low-power consumption;
language, and the code can be modified according to the each RPi uses about 2 W of power (when running at 700 MHz)
requirements of an application [105]. A considerable number of [103]. Raspbian OS power consumption is based on the RPi boards
programming languages have been adapted for Raspbian OS such used and type of applications running on the device itself. Table 1
as Python, C, C + +, Java, Scratch, and Ruby; all installed by summarised the power consumption using different RPi boards
default on the Raspbian OS [105]. Also, scripting languages such [105].
as HTML5, Javascript, and JQuery are supported [105].

Table 1 Power consumption of different RPi boards [105]
Pi mode Pi state Power consumption
a + idle, high-definition multimedia 80 mA (0.4 W)
interface (HDMI) disabled, light-
emitting diode (LED) disabled
a + idle, HDMI disabled, LED disabled, 160 mA (0.8 W)
USB WiFi adapter
b + idle, HDMI disabled, LED disabled 180 mA (0.9 W)
b + idle, HDMI disabled, LED disabled, 220 mA (1.1 W)
USB WiFi adapter
model 2 B idle, HDMI disabled, LED disabled 200 mA (1.0 W)
model 2 B idle, HDMI disabled, LED disabled, 240 mA (1.2 W)
Fig. 11 Architecture of Android Things OS (reproduced from [111]) USB WiFi adapter
zero idle, HDMI disabled, LED disabled 80 mA (0.4 W)
6.2.9 Supporting multimedia: Raspbian OS can perform live zero idle, HDMI disabled, LED disabled, 120 mA (0.7 W)
audio and video streaming by using session initiation protocol USB WiFi adapter
(SIP) and RTP protocols [105]. Raspbian OS employs code-excited
linear prediction compression algorithms to ensure low latency and
high-quality communication [102, 108]. Moreover, it supports HD 6.3.4 Memory management and performance: Android Things
videos and music [105]. Also, GStreamer is supported on Raspbian OS implements dynamic memory allocation through system calls
OS; which supports streaming, encoding and packing of various [77] and it has a small memory footprint [111].
multimedia formats such as flv and H264 [105]. A full list of
supported plugins can be found in [101]. In addition, a special
camera module is available for RPi boards and Raspbian OS [105]. 6.3.5 Communication and networking protocols
The module supports 1080p30, 720p60, and VGA90 video modes. support: Android Things OS supports WiFi, bluetooth low energy,
The camera is connected through camera serial interface port ZigBee, IPV6, and other networking protocols [112].
available on RPi, and there are several third-party libraries built for
it including the Python Picamera library [105]. 6.3.6 Simulation support: Android Things OS is not yet
supported on Android Studio Android Virtual Device as other
6.2.10 More about Raspbian OS: Raspbian OS has a desktop Android platforms. However, it can be employed on RPi 3, Intel
environment called Lightweight graphical X11 desktop Edison, and NXP Pico in order to be used for the initial simulation
environment. It is very similar to Windows and Mac desktops and [111].
provide an attractive user interface [101]. Moreover, it includes
Wayland display server protocol which allows efficient use of the 6.3.7 Security: As Android Things OS is an open software based
graphics processing unit for hardware accelerated graphical user on Android, it allows building applications smoothly and quickly.
interface drawing functions for Robots [102]. Hence, there will be more security loopholes such as virus attacks
and hacking [111]. Android Things OS uses verified secure boot
6.3 Android Things OS and signed over-the-air updates which make it more secure [111].
Android Things OS provides full disc encryption so all data will be
Android Things is an open-source Linux-based OS for high-end protected. Everything on the drive will be encrypted including the
IoT devices. It is developed by Google and derived from Android files which keep exact copies of the data that the user has been
OS. Android Things OS is coded using a specialised programming working on such as temporary files [111].
language called Weave, which is a common cross-platform
language. Android Things OS can run on high-end IoT devices 6.3.8 Power consumption: Android Things OS is running on
offering a few tens of megabytes of memory because it depends on WiFi and Bluetooth low energy using the minimum system
the lower levels of Android which can keep running on requirements such as low memory and small processors. Hence, it
insignificant system requirements such as light bulbs. It has a user- needs less power requirement to run [111].
friendly interface which makes it easier to set up hardware. Also,
Android Things may run wearable devices due to both environment 6.3.9 Supporting multimedia: Android Things OS can fully
common characteristics, and the energy-consumption restriction support high-performance multimedia streaming and processing
[33, 90, 109, 110]. Android Things supports many hardware [111]. It supports the same stack of Android OS media contents
platforms such as Intel (X86), Edison (Dual-core Atom 500M), such as H264, MP3, and VP9 [111]. This processing includes
minnowboard, Qualcomm (Arm), dragonboard (MSM8916, QCore several tasks such as image and video analytics and data processing
A53), Marvell (Arm), ABox Edge (IAP140, QCore A53), that can be processed inside the device instead of processing on the
Freescale (Arm), and Rockchip (Arm) [111]. The structure of cloud [111].
Android Things OS is shown in Fig. 11.
6.3.10 More about android things: Google Cloud Platform
6.3.1 Architecture and kernel models: In contrast to Raspbian components (such as Firebase) can be easily integrated with
OS, Android Things OS has a modular architecture [112]. Android Things OS [112]. Developers will be able to use different
cloud services for storage, state management, and messaging [112].
6.3.2 Programming model and development When it comes to Weave, SDK will be embedded in the devices for
environment: Similar to Raspbian OS, Android Things OS local and remote communications. Moreover, Weave is an
supports multithreading and a number of Android SDKs such as independent protocol that can be as Zigbee, Z-Wave, and Bluetooth
APIs and AdMob, where authentication is required for user input Smart. What makes Android Things OS unique is that it is
[112]. Moreover, Android Things OS developers can develop their compatible with all Android Source Packages [111].
programmes using C and C + + programming languages in addition Other open-source OSs: There are a few open-source OSs that
to Java [111]. are still growing and not popular or deprecated that are not covered
in this paper such as Pyxis, Ubuntu Snappy Core, and Ostro. For
6.3.3 Scheduling: Android Things OS scheduler supports either example, through many searches, we revealed very little about
prioritised preemptive or cooperative depending on the Pyxis OS which has been deprecated and replaced by Pyxis 2. It
configuration of the scheduler [113]. does neither seem to be a PPC64, nor it is CentOS/Linux based. It

Table 2 Programming features summary for open-source IoT OSs
OS Kernel Scheduler Programming model Language support Real time
TinyOS monolithic non-preemptive FIFO event driven NesC not supported
Contiki modular preemptive FIFO event driven, protothreads C partially supported
RIOT microkernel preemptive priority, multithreading C, C + + supported
tickless
LiteOS modular preemptive priority (RR) multithreading LiteC + + not supported
FreeRTOS microkernel preemptive, optional multithreading C supported
tickles
Mynewt modular preemptive multithreading Go (golang), C supported
Mbed monolithic non-preemptive single thread C, C + + supported
uClinux monolithic preemptive multithreading C partially supported
Raspbian modular, monolithic preemptive multithreading Python, C, Ruby, Java, PHP, C + +, supported
Node.js
Android Things modular preemptive multithreading Weave using C, C + + supported
Table 3 Recommended hardware requirements for IoT OSs

OS Min-RAM, kB Min-ROM, kB Processor/CPU, MHz
TinyOS 1 4 7.4, 8 bit
Contiki 2 30 8 bit
RIOT 1.5 5 16–32 bit
LiteOS 4 128 8 MHz
FreeRTOS 10 12 32 bit
Mynewt 8 64 12–200 MHz
Mbed 16 32-bit 32
uClinux 512 512 200
Raspbian 512–256 — ARM Cortex-A53
Android Things 128 32 [111] ARM, Intelx86, MIPS [102]
looks such as a custom OS written in C# for Arduino used and state-of-the-art open-source OSs for IoT. We first
microcontrollers. It also appears to be a small project developed investigate the design and development aspects of IoT OSs. Then,
around 2010 with no updates afterward. Other OSs still work very we propose a taxonomy to classify and categorise the state-of-the-
hard to shine in the field but the competition is high as this area is art and most used IoT OSs. We provide an extensive overview of
growing dramatically. open-source IoT OSs, where each OS explained in details based on
the established designing and developmental aspects. These aspects
7 Comparisons of IoT OSs are; architecture and kernel models, programming model, and
development environment, scheduling, memory management and
In this section, we provide several summarised tabular overviews performance, communication and networking protocols, simulator,
of all OSs listed in this survey. Table 2 summarises the security, power consumption, and multimedia support. We survey
programming features of all OSs discussed in this paper. This table each OS's characteristics, advantages, and disadvantages. Also,
lists the programmability features for each OS in terms of the several comparisons concentrating on the similarities and
kernel and architectural usage for a basic application, scheduling differences between the discussed OSs are presented. We remark
type, programming model, supported programming language, the that this is the first such tutorial style paper on IoT OSs.
ability of reprogramming, and supporting of real time. We noted Finally, we argue that each IoT OS has some limitations
that the common programming languages used in IoT OSs include depending on the targeted deployment scenario. For that reason, it
C, C + +, and Java. Java always runs on top of an IoT OS. So, the is challenging to have an OS that satisfies all requirements.
choice is not between C/C + + or Java; it is whether C or C + + and Moreover, choosing an appropriate OS for IoT applications is
Java. critical to the success of IoT deployments and implementations.
Table 3 provides a summary of the hardware requirements for The developer must carefully study the strengths and weaknesses
the surveyed IoT OSs. This table defines the OS hardware of the candidate OSs to make the best choice. As each IoT OS has
configuration requirements in terms of RAM and ROM usage for a its pros and cons that can be used to identify the appropriate OS
basic application, processor, and main supported hardware based on the functional, non-functional, power consumption,
platform. The purpose of hardware specifications is to give sensors connectivity, communication methods, and many other
appropriate design decisions for devices that will run by IoT OSs. requirements. Thus, this research is designed to bridge the existing
Finally, we briefly summarise the primary technical aspects of gap in knowledge of the adoption and implementation of OSs for
IoT OSs in Table 4. It highlights implementation aspects in terms IoT from different aspects. This survey provides an easy to follow
of the remote scriptable wireless shell, remote file system interface and well-structured guide in a tutorial style for researchers and
for networked nodes, file system, online debugging, dynamic developers targeting IoT OSs.
memory, simulation support, and list of supported network
technologies and protocols.
9 Acknowledgment
8 Conclusion This work made possible by a financial support from the Applied
Science Private University in Amman, Jordan.
The proliferation of the IoT is dramatically increasing and already
covers many prominent domains and disciplines such as smart
cities, smart sensory platforms, and intelligent transit systems. OS
support is vital in facilitating the development and subsistence of
IoT. In this paper, we provide a comprehensive study of the most

Table 4 Technical aspects comparison of IoT OSs
OS Remote Remote File system Online Dynamic Simulator Network stack and protocol
scriptable file system debugging memory supported supported
shell
TinyOS noa no single level yesc No TOSSIM, BLIPd, TinyRPL, CoAP, WiFi, LTE,
(ELFb, PowerTossim MQTT, LoWPAN, TCP, BBRe, IPv6,
matchbox) Bluetooth, multi-path routing
Contiki nof no single level no yes Netsim, Cooja, RPL, uIP, uIPv6, MQTT,
MSPSim, Java 6LoWPAN, CoAP, WiFi, Bluetooth
nodes
Riot OS yes yes hierarchical yes yes Cooja simulator TCP, UDP, IPv6, 6LoWPAN, RPL,
CoAP, CBORg, UBJSONh,
OpenWSN, WiFi, Bluetooth, LTE,
MQTT
LiteOS yesi yes hierarchical yes yes AVRORA simulator NB-IoT, 6LoWPAN, ZigBee, LTE,
Unix-like Bluetooth
FreeRTOS yes yes hierarchical yes yes QEMU uIP, lwIP, TCP, LoWPAN, CoAP,
MQTT
Mynewt yes yes hierarchical yes yes QEMU BLE, IPv6, 6LoWPAN, HTTP, TCP,
CoAP, MQTT, UDP, LoRa PHY,
LoRaWAN
ARM Mbed yes yes hierarchical yes yes QEMU 6LoWPAN, Ethernet, Zigbee LAN,
HTTP, Zigbee IP, WiFi, BLE, IPv6,
CoAP, MQTT
uClinux yes yes hierarchical yes yes GDB/ARMulator uIP, lwIP, WiFi, Bluetooth, LTE,
IPv6, MQTT
Raspbian yes yes hierarchical yes yes QEMU RTP, LTE, HTTP, TCP, MQTT
Android yes yes hierarchical yes yes RPi 3, Intel Edison, IPv6, Zigbee, Z-Wave, Bluetooth
Things and NXP Pico Smart
aThrough the application specific shell such as Simple cmd exists.
bExecutable and Linkable Format.
cThrough the Clairvoyant.
dBerkeley Low-power IP.
eBottleneck Bandwidth and Round-trip.
fThrough the mote shell.
gConcise Binary Object Representation.
hUniversal Binary JSON.
iThrough the base PC, Unix commands.
References [14] Internet of Things (IoT) Connected Devices Installed Base Worldwide from
2015 to 2025 (in billions). Available at https://www.statista.com/, accessed
[1] Ma, H.: ‘Internet of things: objectives and scientific challenges’, J. Comput. August 2017
Sci. Technol., 2011, 26, (6), pp. 919–924 [15] Lee, J., Sung, Y., Park, J.: ‘Lightweight sensor authentication scheme for
[2] Mattern, F., Floerkemeier, C.: ‘From the internet of computers to the Internet energy efficiency in ubiquitous computing environments’, Sensors, 2016, 16,
of things’, in Sachs, K., Petrov, I., Guerrero, P. (Eds.): ‘From active data (12), pp. 2044–2059
management to event-based systems and more’ (Springer, Berlin, Germany, [16] Tarkoma, S., Ailisto, H.: ‘The Internet of things program: the Finnish
2010), vol. 33, (2), pp. 242–259 perspective’, IEEE Commun. Mag., 2013, 51, (3), pp. 10–11
[3] Zhu, Q., Ruicong, W., Chen, Q., et al.: ‘IoT gateway: bridging wireless sensor [17] Al-Turjman, F., Alturjman, S.: ‘Context-sensitive access in industrial Internet
networks into internet of things’. Proc. IEEE/IFIP Eighth Int. Conf. of things (IIoT) healthcare applications’, IEEE Trans. Ind. Inf., 2018, 14, (6),
Embedded Ubiquitous Comput. (EUC), Hong Kong, China, December 2010, pp. 2736–2744
pp. 347–352 [18] Miorandi, D., Sicari, S., De Pellegrini, F., et al.: ‘Internet of things: vision,
[4] Gartner Inc.: ‘Gartner says 8.4 billion connected ‘Things’ will be in use in applications and research challenges’, Ad Hoc Netw., 2012, 10, (7), pp. 1497–
2017, up 31 percent from 2016’. Available at https://www.gartner.com/ 1516
newsroom/id/3598917, accessed June 2017 [19] Roman, R., Zhou, J., Lopez, J.: ‘On the features and challenges of security
[5] Sundmaeker, H., Guillemin, P., Friess, P., et al.: ‘Vision and challenges for and privacy in distributed Internet of things’, Comput. Netw., 2013, 57, (10),
realizing the Internet of things’ (European Commission, Brussels, 2010) pp. 2266–2279
[6] Islam, S., Kwak, D., Kabir, M., et al.: ‘The Internet of things for health care: a [20] Balakrishna, C.: ‘Enabling technologies for smart city services and
comprehensive survey’, IEEE Access., 2015, 3, pp. 678–708 applications’. Proc. IEEE Int. Conf. Next Generation Mobile Applications,
[7] Keoh, S., Kumar, S., Tschofenig, H.: ‘Securing the Internet of things: a Services and Technologies (NGMAST), Paris, France, September 2012, pp.
standardization perspective’, IEEE Internet Things J., 2014, 1, (3), pp. 265– 223–227
275 [21] Wang, L., Alexander, C.: ‘Big data analytics and cloud computing in Internet
[8] Mainwaring, A., Polastre, J., Szewczyk, R., et al.: ‘Wireless sensor networks of things’, Amer. J. Inf. Sci. Comput. Eng., 2016, 2, (6), pp. 70–78
for habitat monitoring’. Proc. ACM Int. Works Wireless Sensor Networks and [22] Sarkar, C., Nambi, A., Prasad, R., et al.: ‘DIAT: a scalable distributed
Applications, Atlanta, GA, USA, September 2002, pp. 88–97 architecture for IoT’, IEEE Internet Things J., 2015, 2, (3), pp. 230–239
[9] Al-Fuqaha, A., Guizani, M., Mohammadi, M., et al.: ‘Internet of things: a [23] Qin, Z., Denker, G., Giannelli, C., et al.: ‘A software defined networking
survey on enabling technologies, protocols, and applications’, IEEE Commun. architecture for the Internet-of-things’. Proc. IEEE Network Operations and
Surv. Tutor., 2015, 17, (4), pp. 2347–2376 Management Symp. (NOMS), Krakow, Poland, June 2014, pp. 1–9
[10] Why the Need for Special Operating Systems for IoT and Wearable Devices? [24] Chen, S., Xu, H., Liu, D., et al.: ‘A vision of IoT: applications, challenges,
Available at https://dzone.com/, accessed June 2017 and opportunities with China perspective’, IEEE Internet Things J., 2014, 1,
[11] Cisco Visual Networking Index.: Global Mobile Data Traffic Forecast (4), pp. 349–359
Update, 2016–2021. Available at https://www.cisco.com/ [25] Hahm, O., Baccelli, E., Petersen, H., et al.: ‘Operating systems for low-end
[12] Razzaque, M., Milojevic-Jevric, M., Palade, A., et al.: ‘Middleware for devices in the Internet of things: a survey’, IEEE Internet Things J., 2016, 3,
Internet of things: a survey’, IEEE Internet Things J., 2016, 3, (1), pp. 70–95 (5), pp. 720–734
[13] Roman, R., Najera, P., Lopez, J.: ‘Securing the Internet of things’, IEEE [26] Silberschatz, A., Galvin, P., Gagne, G.: ‘Operating system concepts’ (Wiley,
Comput. Netw., 2011, 44, (9), pp. 51–58 New York, USA, 2013, 9th edn.)
[27] Farooq, M., Kunz, T.: ‘Operating systems for wireless sensor networks: a
survey’, Sens. J., 2011, 11, (6), pp. 5900–5930

[28] Will, H., Schleiser, K., Schiller, J.: ‘A real-time kernel for wireless sensor [58] Tsiftes, N., Dunkels, A., He, Z., et al.: ‘Enabling large-scale storage in sensor
networks employed in rescue scenarios’. Proc. IEEE Conf. Local Computer networks with the coffee file system’. Proc. Int. Conf. Information Processing
Networks (LCN), Zurich, Switzerland, October 2009, pp. 834–841 Sensor Networks, San Francisco, CA, USA, August 2009, pp. 349–360
[29] Dunlap, G., King, S., Cinar, S., et al.: ‘Revirt: enabling intrusion analysis [59] Klauck, R., Kirsche, M.: ‘Bonjour Contiki: a case study of a DNS based
through virtual-machine logging and replay’. Proc. Symp Operating Syst. discovery service for the Internet of things’. Proc. Int. Conf. Ad hoc, Mobile,
Design and Implementation (OSDI), Seattle, USA, December 2002, pp. 211– and Wireless Networks (ADHOC-NOW), Berlin, Germany, June 2012, pp.
224 316–329
[30] Bandyopadhyay, D., Sen, J.: ‘Internet of things: applications and challenges in [60] Kuladinithi, K., Bergmann, O., Pötsch, T., et al.: ‘Implementation of CoAP
technology and standardization’, Wirel. Pers. Commun., 2011, 58, (1), pp. 49– and its application in transport logistics’. Proc. Wkshps on Extending the
59 Internet to Low power and Lossy Networks, Chicago, IL, USA, April 2011,
[31] Dunkels, A., Groonvall, B., Voigt, T.: ‘ContikiVA lightweight and flexible pp. 1–7
operating system for tiny networked sensors’. Proc. Annual IEEE Int. Conf. [61] Kovatsch, M., Duquennoy, S., Dunkels, A.: ‘BA low-power CoAP for
Local Computer Network (LCN), Tampa, FL, USA, November 2004, pp. contiki’. Proc. IEEE Eighth Int. Conf. Mobile Ad hoc and Sensor Syst.
455–462 (MASS), Valencia, Spain, October 2011, pp. 855–860
[32] Chien, T., Chan, H., Huu, T.: ‘A comparative study on operating system for [62] Contiki.: The open source OS for the Internet of things. Available at http://
wireless sensor networks’. Proc. Int. Conf. Advanced Computer Science and www.contiki-os.org/, accessed on August 2017
Information Syst., Jakarta, Indonesia, December 2011, pp. 73–78 [63] Tsiftes, N., Eriksson, J., Dunkels, A.: ‘Poster abstract: low-power wireless
[33] Azure IoT device SDK for C. Available at https://docs.microsoft.com/en-us/ IPv6 routing with ContikiRPL’. Proc. Ninth ACM/IEEE Int. Conf.
azure/, accessed August 2017 Information Processing in Sensor Networks, Stockholm, Sweden, April 2010,
[34] Baccelli, E., Hahm, O., Günes, M., et al.: ‘OS for the IoT – goals, challenges, pp. 406–407
and solutions, OS for the IoT – goals, challenges, and solutions’. Wkshps [64] Munawar, W., Alizai, M., Landsiedel, O., et al.: ‘Dynamic TinyOS: modular
Interdisciplinaire sur la SÃl'curitÃl’ Globale (WISG), Troyes, France, January and transparent incremental code-updates for sensor networks’. Proc. IEEE
2013, pp. 1–6 Int. Conf. Commun. (ICC), Cape Town, South Africa, May 2010, pp. 1–6
[35] Levis, P., Culler, D., Shenker, S., et al.: ‘Trickle: a self-regulating algorithm [65] Kalyoncu, S.: ‘Wireless solutions and authentication mechanisms for Contiki
for code propagation and maintenance in wireless sensor networks’. Proc. based Internet of things networks’, PhD Thesis, Halmstad University, 2013
USENIX/ACM Symp. Networked System Design and Implementation [66] RIOT Documentation. Available at https://riot-os.org/api/, accessed on
(NSDI), San Francisco, CA, March 2004, pp. 15–28 September 2017
[36] Abdelsamea, M., Zorkany, M., Abdelkader, N.: ‘Real time operating systems [67] Emmanuel, B., Gündoğan, C., Hahm, O., et al.: ‘RIOT: an open source
for the Internet of things, vision, architecture and research directions’. Proc. operating system for low-end embedded devices in the IoT’, IEEE Internet
World Symp. Computer Applications and Research, Cairo, Egypt, March Things J., 2018, doi: 10.1109/JIOT.2018.2815038
2016, pp. 72–77 [68] Roussel, K., Song, Y., Zendra, O.: ‘RIOT OS paves the Way for
[37] Deniz, U., Al-Turjman, F., Celik, G.: ‘An overview of Internet of things and implementation of high-performance MAC protocols’. Proc. Fourth Int. Conf.
wireless communications’. Proc. Int. Conf. Computer Science and Sensor Networks (SENSORNETS), Angers, France, April 2015, pp. 5–14
Engineering (UBMK), Antalya, Turkey, October 2017, pp. 506–509 [69] Baccelli, E., Hahm, O., Petersen, H., et al.: ‘RIOT and the evolution of IoT
[38] Sulyman, A., Oteafy, S., Hassanein, H.: ‘Expanding the cellular-IoT umbrella: operating systems and applications’, ERCIM News, April 2015, 101
an architectural approach’, IEEE Wirel. Commun., 2017, 24, (3), pp. 66–71 [70] Petersen, H., Adjih, C., Hahm, O., et al.: ‘IoT meets robotics-first steps, RIOT
[39] AlTurjman, F., Alturjman, S.: ‘Confidential smart-sensing framework in the car, and perspectives’. Proc. ACM Int. Conf. Embedded Wireless Systems and
IoT era’, J. Supercomput., 2018, 74, (10), pp. 5187–5198 Networks (EWSN), Graz, Austria, February 2016, pp. 269–270
[40] Atzori, L., Iera, A., Morabito, G.: ‘The Internet of things: a survey’, Comput. [71] Milinkovi, A., Milinković, S., Lazic, L., et al.: ‘Choosing the right RTOS for
Netw., 2010, 54, (15), pp. 2787–2805 IoT platform’, NFOTEH-JAHORINA, 2015, 14, (3), pp. 504–509
[41] Perrig, A., Szewczyk, R., Wen, V.: ‘SPINS: security protocols for sensor [72] Baccelli, E., Hahm, O., Gunes, M., et al.: ‘RIOT OS: towards an OS for the
networks’, Wirel. Netw., 2002, 5, (8), pp. 521–534 Internet of things’. Proc. 32nd IEEE Conf. Computing Communications
[42] Xiong, L., Zhou, X., Liu, W.: ‘Research on the architecture of trusted security (INFOCOM), Turin, Italy, April 2013, pp. 79–80
system based on the Internet of things’. Proc. Int. Conf. Intell. Computer [73] Shang, W., Afanasyev, A., Zhang, L.: ‘The design and implementation of the
Technology and Automation, Shenzhen, Guangdong, China, March 2011, pp. NDN protocol stack for RIOT-OS’. Proc. IEEE Globecom Wkshps (GC
1172–1175 Wkshps), Washington, DC, USA, December 2016, pp. 1–6
[43] Demir, S., Al-Turjman, F.: ‘Energy scavenging methods for WBAN [74] Huawei LiteOS. Available at http://www.huawei.com/, accessed on
applications: a review’, IEEE Sens. J., 2018, 18, (16), pp. 6477–6488 September 2017
[44] Lajara, R., Pelegri-Sebastia, J., Solano, J.: ‘Power consumption analysis of [75] Vanitha, V., Palanisamy, V., Johnson, N., et al.: ‘LiteOS based extended
operating systems for wireless sensor networks’, Sensors, 2010, 10, (6), pp. service oriented architecture for wireless sensor networks’, Int. J. Comput.
5809–5826 Electr. Eng., 2010, 2, (3), pp. 432–436
[45] Hamoudy, M., Qutqut, M., Almasalha, F.: ‘Video security in Internet of [76] Cao, Q., Abdelzaher, T., Stankovic, J., et al.: ‘The LiteOS operating system:
things: an overview’, Int. J. Comput. Sci. Netw. Secur. (IJCSNS), 2017, 17, towards Unix-like abstractions for wireless sensor networks’. Proc. Int. Conf.
(8), pp. 199–255 Information Processing in Sensor Networks (IPSN), USA, April 2008, pp.
[46] Al-Sakran, A., Qutqut, M., Almasalha, F., et al.: ‘An overview of the Internet 233–244
of things closed source operating systems’. Int. Wireless Communications and [77] Gaur, P., Tahiliani, M.: ‘Operating systems for IoT devices: a critical survey’.
Mobile Computing Conf. (IWCMC), Limassol, Cyprus, June 2018 Region 10 Symp. (TENSYMP), Ahmedabad, Pakistan, May 2015, pp. 33–36
[47] Levis, P., Madden, S., Polastre, J., et al.: ‘TinyOS: an operating system for [78] Hammad, M., Cook, J.: ‘Lightweight deployable software monitoring for
sensor networks’, in Weber, W., Rabaey, J., Aarts, E. (Eds.): ‘Ambient sensor networks’. Proc. IEEE 18th Int. Conf. Computing Communications
intelligence’, vol. 1 (Springer, New York, 2005), pp. 115–148 and Networks, Washington, D.C., USA, August 2009, pp. 1–6
[48] Levis, P., Lee, N., Welsh, M., et al.: ‘TOSSIM: accurate and scalable [79] Ranjan, A., Sahu, H., Misra, P.: ‘A survey report on operating systems for tiny
simulation of entire TinyOS applications’. Proc. Int. Conf. Embedded networked sensors’, arXiv preprint arXiv:1505.05269, May 2015
Networked Sensor Systems, CA, USA, November 2003, pp. 126–137 [80] Deharbe, D., Galv'ao, S., Moreira, A.: ‘Formalizing FreeRTOS: first steps in
[49] Gay, D., Levis, P., Culler, D.: ‘Software design patterns for TinyOS’. Proc. formal methods: foundations and applications’. Proc. 12th Brazilian Symp.
ACM Conf. Languages, Compilers, and Tools for Embedded Syst., IL, USA, Formal Methods (SBMF), Gramado, Brazil, August 2009, pp. 101–117
June 2005, vol. 40, pp. 40–49 [81] Andersson, K., Andersson, R.: ‘A comparison between FreeRTOS and
[50] Hill, J., Culler, D., Horton, M., et al.: ‘Mica: the commercialization of RTLinux in embedded real-time systems’, Linkoping University, 2005
microsensor motes’, Sens. Mag., 2004, 19, pp. 40–48 [82] Hos'ek, P.: ‘Supporting real-time features in a hierarchical component
[51] Sruthi, M., Rajkumar, R.: ‘A study on development issues over IOT system’, MSc thesis, Charles University, 2010
platforms, protocols and operating system’. Int. Conf. Innovations in [83] Yang, C., Chih, H.: ‘An open source audio effect unit’. Proc. IEEE Int. Conf.
Information Embedded and Communication Systems, Coimbatore, India, Systems, Man, and Cybernetics (SMC), Budapest, Hungary, October 2016,
March 2016 pp. 638–643
[52] Casado, L., Tsigas, P.: ‘Contiki Sec: a secure network layer for wireless sensor [84] FreeRTOS. Available at http://www.freertos.org/, accessed on September
networks under the Contiki operating system’. Proc. Nordic Conf. Secure IT 2017
Systems, New York, NY, USA, October 2009, pp. 133–147 [85] Kruger, C., Hancke, G.: ‘Implementing the Internet of things vision in
[53] Ma, H.: ‘Experimental evaluation of a video streaming system for wireless industrial wireless sensor networks’. Proc. IEEE Int. Conf. Industrial
multimedia sensor networks’. Proc. Tenth IEEE IFIP Annual Mediterranean Informatics, Budapest, Hungary, July 2014, pp. 627–632
Ad Hoc Network Workshops, Sicily, Italy, August 2011, pp. 165–170 [86] Johny, A., Jayasudha, J., Anurag, R.: ‘Security in automotive domain using
[54] Farooq, M., Aziz, S., Dogar, A.: ‘State of the art in wireless sensor networks secure socket layer’, Int. J. Eng. Innov. Technol., 2013, 3, (4), pp. 214–219
operating systems: a survey’. Proc. Int. Conf. Future Generation Information [87] Apache Mynewt OS. Available at https://mynewt.apache.org/, accessed on
Technology, Berlin, Heidelberg, December 2010, pp. 616–631 October 2017
[55] Dunkels, A., Schmidt, O., Voigt, T., et al.: ‘Protothreads: simplifying event- [88] Kordestani, M., Bourdoucen, H.: ‘A survey on embedded open source system
driven programming of memory-constrained embedded systems’. Proc. Int. software for the Internet of things’. Proc. Free and Open Source Software
Conf. Embedded Networked Sensor Systems, Boulder, CO, USA, October Conf., Muscat, Oman, February 2017, pp. 27–32
2006, pp. 29–42 [89] An Operating System for Arduino. Available at https://www.arduino.cc/,
[56] Dunkels, A., Finne, N., Eriksson, J.: ‘Run-time dynamic linking for accessed on September 2017
reprogramming wireless sensor networks’. Proc. Fourth ACM Conf. [90] Malche, T., Maheshwary, P.: ‘Harnessing the Internet of things (IoT): a
Embedded Networked Sensor Systems (Sensys), Boulder, CO, USA, October review’, Int. J. Adv. Res. Comput. Sci. Softw. Eng., 2015, 5, (8), pp. 320–323
2006, pp. 15–28 [91] Mbed IoT Platform. Available at https://www.mbed.com/en/platform/,
[57] Dunkels, A., Mottola., L, Tsiftes, N., et al.: ‘The announcement layer: beacon accessed on September 2017
coordination for the sensornet stack’. Proc. Wireless Sensor Networks Conf.
(EWSN), Bonn, Germany, February 2011, pp. 211–226

[92] Persson, P., Angelsmark, O.: ‘Calvinâ merging cloud and IoT’. Proc. Int. [102] Prasad, S., Mahalakshmi, P., Sunder, A., et al.: ‘Smart surveillance
Conf. Ambient Systems Networks and Technology (ANT), London, UK, June monitoring system using Raspberry Pi and PIR sensor’, Int. J. Comput. Sci.
2015, pp. 210–217 Inf. Technol., 2014, 5, (6), pp. 7107–7109
[93] Balsamo, D., Elboreini, A., Al-Hashimi, B., et al.: ‘Exploring ARM Mbed [103] Kiepert, J.: ‘Creating a Rraspberry Pi-based Beowulf cluster’, Boise State
support for transient computing in energy harvesting IoT systems’. Proc. University, May 2013, pp. 1–17
Seventh IEEE Int. Wkshps Advances in Sensors and Interfaces, Vieste, Italy, [104] Silva, S.: ‘A Linux microkernel based architecture for OPENCV in the
June 2017, pp. 115–120 Raspberry Pi device’, Int. J. Sci. Knowl. (IJSK), 2014, 5, (2), pp. 44–52
[94] arm MBED. Available at https://www.mbed.com/, accessed on September [105] The MagPi Magazine. Available at https://www.raspberrypi.org/magpi/
2017 tutorials/, accessed on September 2017
[95] Nikkanen, K.: ‘Uclinux as an embedded solution’, Bachelor's thesis, Turku [106] Murikipudi, A., Prakash, V., Vigneswaran, T.: ‘Performance analysis of real
Polytechnic Institute, 2003 time operating system with general purpose operating system for mobile
[96] Lu, Z., Zhang, X., Sun, C.: ‘An embedded system with uClinux based on robotic system’, Indian J. Sci. Technol., 2015, 8, (19), pp. 1–6
FPGA’. Proc. Pacific-Asia Wkshps on Computational Intelligence and [107] Almasalha, F., Khokhar, A., Hasimoto-Beltran, R.: ‘Scalable encryption of
Industrial Application (PACIIA), Wuhan, China, December 2008, pp. 691– variable length coded video bit streams’. Proc. IEEE 35th Conf. Local
694 Computer Networks (LCN), Denver, CO, USA, October 2010, pp. 192–195
[97] Wang, M., Liu, F.: ‘Research and implementation of uCLinux-based [108] Bagal, N., Pandita, S.: ‘A review: real-time wireless audio–video
embedded browser’. Proc. Second IEEE Asia-Pacific Service Computing transmission’, Int. J. Emerg. Technol. Adv. Eng., 2015, 5, (4), pp. 168–170
Conf., Tsukuba Science City, Japan, December 2007, pp. 504–508 [109] MartinFerna'ndez, F., CaballeroGil, P., CaballeroGil, C.: ‘Authentication
[98] uClinux in the GDB/ARMulator. Available at http://www.uclinux.org/pub/ based on non-interactive zero knowledge proofs for the Internet of things’,
uClinux/utilities/armulator/, accessed on September 2017 Sensors, 2016, 16, (1), p. 75
[99] Teng, J., Tseng, C., Chen, Y., et al.: ‘Integration of networked embedded [110] Amorim, V., Delabrida, S., Oliveira, R.: ‘A constraint-driven assessment of
systems into power equipment remote control and monitoring’. Proc. operating systems for wearable devices’. Proc. Computing Systems
TENCON IEEE Region Conf., Chiang Mai, Thailand, November 2004, vol. Engineering (SBESC), Joao Pessoa, Brazil, November 2016, pp. 150–155
100, (3), pp. 566–569 [111] Android Things. Available at https://developer.android.com/things/, accessed
[100] Kyle, D., Brustoloni, J.: ‘Uclinux: a Linux security module for trusted- on October 2017
computing-based usage controls enforcement’. Proc. ACM Wkshps on [112] Android Platform Architecture. Available at https://developer.android.com/
Scalable Trusted Computing, New York, NY, USA, November 2007, pp. 63– guide/platform/index.html, accessed on September 2017
70 [113] Akula, P., Yamuna, V., Ananda, C., et al.: ‘Development of data logger for
[101] Vujovic, V., Maksimovic, M.: ‘Raspberry Pi as a wireless sensor node: MAV using FREERTOS ON PIC32’, Int. J. Eng. Sci. Res. Technol., 2015, 4,
performances and constraints’. Proc. Int. Convention Information and (9), pp. 2277–9655
Communication Technology Electronics and Microelectronics (MIPRO),
Opatia, Croatia, May 2014, pp. 1013–1018

View publication stats

Comprehensive Survey of The Iot Open Source Oss: Iet Wireless Sensor Systems October 2018

Uploaded by

Copyright:

Available Formats

Comprehensive Survey of The Iot Open Source Oss: Iet Wireless Sensor Systems October 2018

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Comprehensive Survey of The Iot Open Source Oss: Iet Wireless Sensor Systems October 2018

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Comprehensive Survey of the IoT Open Source OSs

Article in IET Wireless Sensor Systems · October 2018

Mahmoud H. Qutqut Aya Al-Sakran

SEE PROFILE SEE PROFILE

Fadi Almasalha Hossam S. Hassanein

SEE PROFILE SEE PROFILE

Robust Crowdsensing for Intelligent Road Services View project

The user has requested enhancement of the downloaded file.

Comprehensive survey of the IoT open- ISSN 2043-6386

Mahmoud H. Qutqut1,2 , Aya Al-Sakran1, Fadi Almasalha1, Hossam S. Hassanein2

1 Introduction emerging into the IoT environment to facilitate IoT deployments

IET Wirel. Sens. Syst. 1

2 IET Wirel. Sens. Syst.

IET Wirel. Sens. Syst. 3

4 IET Wirel. Sens. Syst.

Fig. 2 Proposed taxonomy of open-source IoT OSs

5.1.3 Scheduling: The task scheduler in TinyOS is a simple non-

5.1.4 Memory management and performance: TinyOS uses

6 IET Wirel. Sens. Syst.

5.2.7 Security: Contiki OS uses ContikiSec transport layer

5.2.8 Power consumption: Contiki is intended to run on low-

5.2.9 Supporting multimedia: Contiki supports full IP network

IET Wirel. Sens. Syst. 7

5.3.9 Supporting multimedia: RIOT supports full TCP/IP

5.5.1 Architecture and kernel models: FreeRTOS has a

IET Wirel. Sens. Syst. 9

5.5.8 Power consumption: In order for the microcontroller to

5.5.9 Supporting multimedia: FreeRTOS is designed for low-

5.5.10 More about FreeRTOS: This OS is recommended to

5.6 Apache Mynewt OS

10 IET Wirel. Sens. Syst.

6 OSs for high-end IoT devices

6.1.1 Architecture and kernel models: uClinux OS follows a

IET Wirel. Sens. Syst. 11

6.1.8 Power consumption: uClinux supports power management

12 IET Wirel. Sens. Syst.

IET Wirel. Sens. Syst. 13

Table 3 Recommended hardware requirements for IoT OSs

14 IET Wirel. Sens. Syst.

IET Wirel. Sens. Syst. 15

16 IET Wirel. Sens. Syst.

IET Wirel. Sens. Syst. 17

View publication stats

You might also like