Professional Documents
Culture Documents
I. Introduction
This paper explains the common approach of using operating system programming to develop
software for constrained devices in the IoT. This approach has become the norm when
programming for sensor nodes, as the usage of a base operating system greatly reduces the need
to duplicate functionality and simplifies the porting of software across different hardware
platforms. Moreover energy-efficiency when communicating as well as compatibility between
nodes can be increased as the underlying architecture of the operating system can be shared
across different types of nodes. Also, in effort to speed up development and testing, the native
approach to programming is explained in this chapter together with how virtual topologies can be
used for native devices to simulate high-depth networks.
Cloud computing and Internet of Things (IoT), two different yet related technologies, are both
already part of our lives. Their massive adoption and use is expected to increase further, making
them important components of the future Internet. Emerging security models are foreseen as
disruptive and an enabler of a large number of application scenarios as Botta, W. de Donato,
addressed On the Integration of Cloud Computing and Internet of Things, [1]. Ahmat [2]
addressed a novel paradigm of the next generation security risks when Cloud and IoT are merged
together and the security risks facing cloud providers.
II. Operating System Programming
a programming model where code is programmed for a certain operating system kernel, which
in turn will compile the code to machine code for the intended target hardware. Code written for
a certain operating system kernel can be reused and applied to other kinds of hardware which the
operating system supports. In contrary, when writing code for a certain platform, specific APIs
and libraries are used to compile the code to machine code making the code non-portable to other
platforms. As such, the operating system model is preferable as it is more portable as well as less
cumbersome, as it provides a higher abstraction layer to work with.
III. Native Programming
Both Contiki OS and RIOT OS support native programming. The native platform emulates the
hardware needed for nodes and allows the node to run with the complete software stack of the
1
International Conference on Internet of Things and Big Data
23-25 April, 2016 || Rome, Italy
node OS on a regular UNIX-like desktop, comparable to that of virtual machine solutions such as
Virtual box and VMware. The benefit of using the native port is that no actual node hardware is
needed, as everything is simulated and run within a regular Linux distribution. As hardware is
emulated, the programmer is not restrained by physical limitations of nodes such as RAM and
ROM size during development. Node communications are allowed within a controlled
environment, without disturbances such as noise. Native programming allows for fast
development and testing as these can both be done using the desktop machine, compared to
programming directly for hardware as this requires the compiled code to be uploaded to the
nodes.
2
International Conference on Internet of Things and Big Data
23-25 April, 2016 || Rome, Italy
sniffers is included within the Operating Systems Contiki and RIOT. To defend against the
privacy and security risks, the Industrial big data requires a cyber security concept capable of
addressing such risks at all possible levels of abstraction. Some solutions for protecting the
embedded devices at the core of industrial big data based smart system.
VI. Devices
The links with customizable link loss rate forward packets which it is physically able to receive,
making direct communications from far-away nodes invisible to the sniffer. Multiple sniffers
could be used in order to fully cover a large 802.15.4 network in order to analyze all packets.
The devices within an 802.15.4 network can be divided into different categories depending on
their function and place within the network. Depending on which type a device belongs to,
different software and hardware can be applied.
Internet of Things (IoT) will comprise billions of devices that can sense, communicate, compute
and potentially actuate. Data streams coming from these devices will challenge the traditional
approaches to data management and contribute to the emerging paradigm of big data. Emerging
Internet of Things (IoT) architecture, large scale sensor network applications, federating sensor
networks, sensor data and related context capturing techniques, challenges in cloud-based
management, storing, archiving and processing of sensor data [3].
Devices in the Internet of Things (IoT) generate, process, and exchange vast amounts of security
and safety-critical data as well as privacy-sensitive information, and hence are appealing targets
of various attacks [4]
Recently, an emerging theory named compressed sensing (CS) has been extensively investigated,
with which the data or signals can be efficiently sampled and accurately reconstructed with much
fewer samples than Khaleds theory [7]. However, for the first time, our work studies information
acquisition in IoT and WSNs with CS from the perspective of data-compressed sampling, robust
transmission, and accurate reconstruction to reduce the energy consumption, computation costs,
and data redundancy and increase the network capacity. A common task of an IoT end node is to
transmit the sensed data to a specific node or fusion center (FC); however, how to efficiently
acquire, store, and transmit among a large number of source nodes remains a challenge [9].
3
International Conference on Internet of Things and Big Data
23-25 April, 2016 || Rome, Italy
RELIABLE WIRELESS
SENSOR
NETWORKS IN SMART HOME
TECHNOLOGICAL
APPLICATIONS
IEEE XBee RF Module & Hardware
802.15.4 XBee
Performance of the network, as a smart home WSN might include many different types of sensor
and actuating nodes, which will all share the network with the safety-critical nodes. Aspects such
as the power usage of the nodes, the general throughput and delays in the network need to be
considered not only for the safety-critical part of the network, but for the network as a whole.
4
International Conference on Internet of Things and Big Data
23-25 April, 2016 || Rome, Italy
X. Message Complexity
As there is no requirement from the algorithm to pinpoint the location of the fault, i.e. for the
server to be able to tell which node or link is responsible for the fault, no information of
participation from nodes needs to be carried in the message itself. this functionality would
however be rendered mute, as the algorithm relies on the absence of return messages to detect
fault, and as such, any information carried in the message would be unattainable for the server in
the case of an undelivered message. As such, the message length can be kept short, with the only
requirement that the message from each round should be unique, as to avoid stored messages
from previous rounds to intervene with a current keep-alive round, causing a false negative.
Since messages are sent from end node to end node, the total amount of messages required for
every node to announce its continued presence on the network can be reduced to the total amount
of uplinks for the safety-critical sub-topology times two. The safety-critical sub-topology is
5
International Conference on Internet of Things and Big Data
23-25 April, 2016 || Rome, Italy
dened as all safety-critical nodes uplinks as well as the uplinks of any local coordinator which
has any safety-critical node as its descendants.
Init: The server initiates the keep-alive round by creating and storing a nonce. It will then send a
message containing the nonce to the first node in the keep-alive round which has been previously
defined by the server. The server will at this point start a timer.
Forward: Any node that receives the keep-alive message will relay the message to its next
neighbor which is the node next in line to receive the message. This will be repeated by every
node participating in the algorithm until the message reaches the last of the participating nodes in
the predefined list of nodes. This node will then relay the message to the server, using the
predefined variable next neighbor.
Reset: If and when the server receives the message, it checks the message nonce with the stored
nonce for the round, and if it matches, the server will reset its timer and then re-initiate the
algorithm according to INIT. If the server fails to receive the message before the timer runs out,
or the nonce received cannot be matched with the stored nonce, failed and one or more of the
following actions may be taken.
Conclusion
As for wireless communications, it is not currently possible reach the same reliability and
response level as a closed circuit system, but wireless sensor networks have the advantage of
being both cheaper and easier to install compared to a closed circuit system. As such, an
approach where safety-critical devices are managed in a wireless sensor network rather than a
closed circuit system may be realizable in homes or other areas where cost is of a major concern.
The comparative cost of such an installation compared to that of a closed circuit system might be
that modest that a wireless sensor network approach to security should rather be compared to a
non-security premise than a closed circuit system as a wireless security approach can offer some
security at a comparably small investment. Issues exist, such as finding a suitable algorithm to
the variables used by the proposed algorithm, in order to reach a fast-response system where the
numbers of false positives are kept low.
6
International Conference on Internet of Things and Big Data
23-25 April, 2016 || Rome, Italy
References
1. Botta, W. de Donato, V. Persico, and A. Pescape, On the Integration of Cloud Computing and
Internet of Things, Proceedings of the 2nd International Conference on Future Internet of Things
and Cloud (FiCloud), pp. 2729, 2014.
2. K. Ahmat Emerging Cloud Computing Security Threats Technical Report, Cornell University
Open Archive Library, 2015.
3. A. Zaslavsky, C. Perera, and D. Georgakopoulos, Sensing as a service and big data, in
International Conference on Advances in Cloud Computing (ACC-2012), Bangalore, India, July
2012, pp. 2129.
4. A.-R. Sadeghi, C. Wachsmann, and M. Waidner, Security and Privacy Challenges in Industrial
Internet of Things, in Proceedings of the 52Nd Annual Design Automation Conference, ser.
DAC 15. New York, NY, USA: ACM, 2015, pp. 54:154:6. [Online]. Available:
http://doi.acm.org/10.1145/2744769.2747942
5. J. Rittinghouse and J. Ransome, Cloud Computing: Implementation, Management and Security,
CRC Publisher, 2010.
6. Security and high availability in cloud computing environments , IBM Global Technology
Services Technical White Paper ,IBM , June 2011
7. S. Kumar, B. Kadow, and M. Lamkin, Challenges with the introduction of radio-frequency
identification systems into a manufacturers supply chain for a pilot study, Enterprise Inf. Syst.,
vol. 5, no. 2, pp. 235253, May 2011.
8. H. Mamaghanian, N. Khaled, D. Atienza, and P. Vandergheynst, Compressed sensing for real-
time energy-efficient ECG compression on wireless body sensor nodes, IEEE Trans. Biomed.
Eng., vol. 58, no. 9, pp. 24562466, Sep. 2011.
9. M. Raginsky, S. Jafarpour, Z. T. Harmany, and R. Calderbank, Performance bounds for
expander-based compressed sensing in Poisson noise, IEEE Trans. Signal Process., vol. 59, no.
9, pp. 41394153, Sep. 2011.