Ministry of Higher Education and

Scientific Research

University of Manouba
National School for Computer Science

Realization of a WSN platform for

Real-time environmental monitoring

Authors:
Supervisor:
Moudhaffer Azizi
Mrs. Leila Nasraoui
Amine Arfaoui

May 1, 2017
1
Contents

1 General Presentation 8
1.1 General concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 The Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 WSN nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.3 The border router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.4 WSN communication models . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.5 WSN and IoT Communication protocol stack . . . . . . . . . . . . . 10
1.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Requirements and specifications 15

2.1 Study of the existent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 The operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Hardware development platform . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Application Layer Protocol for the WSN platform . . . . . . . . . . . 16
2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Design 19
3.1 General design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 General Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Potential Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Potential WSN topologies . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Potential WSN Data sending paradigms . . . . . . . . . . . . . . . . 23
3.2.4 Final choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Overview of the project . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.4 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.5 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2
 3.3.6 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Development 31
4.1 Software environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Border router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 UDP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 UDP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Main application development . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6.3 Overview of the realized work . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 General conclusion 42

3
List of Figures

1.1 An example structure of a WSN. . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 The typical architecture of the sensor node. . . . . . . . . . . . . . . . . . . 9
1.3 The protocols stack of a WSN. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 The MQTT protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 OS requirements support comparison. . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Use case diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Sequence Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Service oriented architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Event driven architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Star topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Tree topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Bus topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Mesh topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Final choice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Project overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 The protocols stack of a WSN. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 The protocols stack of a WSN. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 The protocols stack of a WSN. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 MQTT subscribe/publish model. . . . . . . . . . . . . . . . . . . . . . . . . 28
3.13 Protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.14 Sequence diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.15 Deployment diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Data sent to the broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Running the border router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Running the border router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Setting up of the socket at the client side. . . . . . . . . . . . . . . . . . . . 33
4.5 Sending a UDP-packet at client side. . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Server replying back to a client. . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Real time monitoring dashboard. . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8 Data traveling from the broker into real time monitoring and database. . . . 37
4.9 Historical data dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.10 Data fetched from the Database into Dashboard nodes. . . . . . . . . . . . . 38
4.11 Code for fetching data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4
4.12 data sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.13 Database schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.14 Code for fetching data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1 Time-line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5
Listings

4.1 compile border router image . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 tunslip6 bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 run tunnel application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 server IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6
General Introduction
Today, smart grid, smart homes, smart water networks, intelligent transportation, are
infrastructure systems that connect our world more than we ever thought possible. The
common vision of such systems is usually associated with one single concept; the Inter-
net of things (IoT), where through the use of sensors, the entire physical infrastructure is
closely coupled with information and communication technologies; where intelligent moni-
toring and management can be achieved via the usage of networked embedded devices. In
such a sophisticated dynamic system, devices are interconnected to transmit useful measure-
ment information and control instructions via distributed sensor networks. This project is
focused on the implementation of a platform that is able to monitor through the Internet
a set of environmental readings with the use of a low-power devices with limited processing
capabilities under an IPV6 local WSN .
In this project, a comparison between the features of the major communication protocols
for the IoT will be drawn , the choice of the network topology and the application archi-
tecture will be explained and the reason of running contiki os on our sensing devices will
be highlighted . Furthermore, a final note on the used hardware must be mentioned, in the
implementation part of this project although we made a feature comparison between some
sensor motes models, the use of Inertial-z1 as hardware development platform was not a
choice ,not just because of its availability at that current time but also because we have been
able to obtain a respectful number of them with the help of our supervisor.

7
Chapter 1

General Presentation

1.1 General concepts

1.1.1 The Wireless Sensor Network
Today sensors are everywhere; in our cars, in our mobile devices and even in our homes.
Even though sensors surround us for many years, the concept of having wireless networks of
sensors is relatively new. Wireless Sensor Networks are used today as a common foundation
for constructing IoT applications and systems mainly because of its small form factor and low
power needs. A WSN can in general be described as a network of nodes (or otherwise a group
of sensors) that are scattered in a certain area and, cooperatively sense the environment and
send the information to a central node that processes it and may produce some control
commands and/or enable interaction between persons or computers and the surrounding
environment.

Figure 1.1: An example structure of a WSN.

1.1.2 WSN nodes

Also called motes, they can be placed in the area according to many different topologies. As
one can observe from the above figure, in this specific WSN topology it is not mandatory
that every node has a network link with the sink node, as it could be reached through other
nodes with multiple hops. This example shows a multi-hop wireless mesh network topology.

8
This kind offers the greater scalability among other topologies. Every node maintains a link
to other nodes within range (i.e. its neighbors) and the decision on which one to use is
reached by the used routing protocol according to the number of hops and the latency of
every route. The nodes of a WSN cannot always be of the same type, but they must support
the same standards and protocols in order to be able to communicate with each other.The
hardware of a sensor node generally includes 5 parts:

Figure 1.2: The typical architecture of the sensor node.

Power source : rechargeable or non-rechargeable batteries, solar sources, temperature dif-

ferences, or vibration.

Sensors : Capture physical data from their environment. The continual analog signal
produced by the sensors is digitized by an analog-to-digital converter and sent to
controllers for further processing.

ADC : Converts Analog signal to digital signal.

External memory : The most relevant kinds of memory are the on-chip memory of a
micro-controller and Flash memory (off-chip), RAM is rarely, if ever, used. Flash
memories are used due to their cost and storage capacity. Memory requirements are
very much application dependent.

Micro-controller : performs tasks, processes data and controls the functionality of other
components in the sensor node.

A wireless transceiver : Sensor nodes often make use of ISM band, which gives free radio
spectrum allocation and global availability. Radio frequency-based communication is
the most relevant that fits most of the WSN applications. WSNs tend to use license-free
communication frequencies: 173, 433, 868, and 915 MHz and 2.4 GHz

9
The functionality of both transmitter and receiver are combined into a single device known
as a transceiver. The operational states are transmit, receive, idle, and sleep.

1.1.3 The border router

It is the connection link between the Internet and the WSN mesh network. It converts IPv6
frames into mesh networks frames because of the differences they have in order for the latter
to be as small as possible for use in constrained devices such as WSN nodes.

1.1.4 WSN communication models

Wireless Sensor Networks (WSN) are following the Device-to-Gateway communication model
where the devices are the WSN motes and the gateway is the combination of the Sink node
and the Border Router. That model is used in WSNs because of its feature ability to
overcome proprietary device restrictions in connecting IoT devices. This, of course, means
that device interoperability and standards are very important considerations in the design
and development of interconnected IoT systems. According to the Internet Society, there are
three more communications models for the IoT that will only be mentioned epigrammatically,
since the focus of this thesis is only on WSNs used in IoT. The first one is the Device-to-
Device (D2D) communication model also referred as Machine to Machine (M2M) in industrial
use and describes two or more devices that directly connect and communicate between one
another, rather than through an intermediate application server or base station. Another
one is the Device-to-Cloud communication model where the IoT device connects directly to
an Internet cloud service like an application service provider to exchange data and control
message traffic. Finally, there is the Back-End Data- Sharing model which is a more complex
model that enables multiple applications to process the shared data coming from IoT devices
and produce a collective result.

1.1.5 WSN and IoT Communication protocol stack

At this point it should be noted that even though IoT is still under development in terms
of standardizing and protocol adoption, it has a large set of protocols already available that
are actually similar to the ones available for the Internet. The following table contains
the majority of the protocols and standards that were encountered while going through the
literature and can be described as the IoT stack.

IEEE 802.15.4
One of the most widely used mesh network communication standards is IEEE 802.15.4. It
defines the Physical (Layer 1) layer and the Data-Link (Layer 2) layer, and more specifically
the Medium Access Control (MAC) sublayer of that layer, of the OSI model. The first
revision of the 802.15.4 standard was released in May 2003. Today, several standardized and
proprietary network (or mesh) layer protocols run over 802.15.4 based networks, including

10
 Figure 1.3: The protocols stack of a WSN.

IEEE 802.15.5, ZigBee, 6LoWPAN, Wireless HART, and ISA100.11a. This standard is
designed with one simple target in mind; to achieve the lowest power consumption. According
to this, it is designed for use in low cost, low speed communication between low power devices.
As a result, this standard describes a slower and smaller range wireless communication
method compared to the IEEE 802.11, which is the Wi-Fi we all use every day, with the
tradeoff of significant lower power consumption. The basic specifications include a 10 meter
(maximum 20 meters) communications range with a transfer rate of up to 250 kbps with other
options of 100 kbps, 40 kbps, and 20 kbps available as well. Devices are able to communicate
in one of the three possible frequency bands for operation (868/915/2450 MHz). Finally, it
uses CSMA/CA protocol as a MAC mechanism and two addressing modes; 16-bit short and
64-bit IEEE addressing.

6LoWPAN
6LoWPAN is an abbreviation of “IPv6 over Low Power Wireless Personal Area Networks”.
The 6LoWPAN concept comes from the idea that ”the Internet Protocol could and should
be applied even to the smallest devices and that low-power devices with limited processing

11
capabilities should be able to participate in the Internet of Things. 6LoWPAN enables
constrained devices that are unable to handle the traditional IP stack to function, and
connect to an IPv6 network, such as the Internet. The mapping from the IPv6 to the IEEE
802.15.4 was not an easy task to carry out, because of the many differences mainly in terms of
packet size, address resolution and maximum transmission unit (MTU) of the two networks.
It was finally achieved by compressing and encapsulating the IPv6 and UDP headers.

Internet Protocol version 6 (IPv6)

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP); the
communications protocol that provides an identification and location system for computers
on networks, and routes traffic across the Internet. IPv6 was developed by the Internet
Engineering Task Force (IETF) to deal with the problem of IPv4 address exhaustion. IPv6
uses 128 bit addresses, theoretically allowing 2128, or approximately 340 trillion addresses.
As a result, it is safe to conclude, that IPv6 is, as one may put it, over satisfying the need of
addresses not only for our computing devices but also for all the IoT devices that will ever
be available. Finally, IPv6 introduces a new set of features that were not implemented on
the previous version (IPv4) that make the IP protocol more reliable and easy to configure.
Two examples are the simplified address assignment with the use of a mechanism called
Stateless Address Auto configuration (SLAAC) and the transfer of the responsibility for
packet fragmentation from routers to the end points.

UDP
UDP uses a simple connectionless transmission model with a minimum of protocol mecha-
nism. UDP provides checksums for data integrity, and port numbers for addressing different
functions at the source and destination of the datagram. It has no handshaking dialogues,
and thus exposes the user’s program to any unreliability of the underlying network: there
is no guarantee of delivery, ordering, or duplicate protection. If error-correction facilities
are needed at the network interface level, an application may use the Transmission Control
Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for
this purpose. UDP is suitable for purposes where error checking and correction are either not
necessary or are performed in the application. UDP avoids the overhead of such processing
at the level of the network interface. Time-sensitive applications often use UDP because
dropping packets is preferable to waiting for delayed packets, which may not be an option
in a real-time system.

MQTT
MQTT (formerly known as Message Queue Telemetry Transport) is an Internet of Things
connectivity protocol that runs on top of the TCP protocol, developed by IBM for lightweight
Machine-to-Machine communications. It implements a publish/subscribe interaction model
where the client devices do not need to impulsively request for updates; thus, reducing in
that way the drain on resources and on power on the IoT nodes and making it optimal for
use on high-latency or unreliable networks. For the same reason it is also used on mobile

12
phone applications such as Facebook Messenger. In 2013 IBM submitted MQTT v.3.1 to
the OASIS specification body and successfully completed the standardization of MQTT.

Figure 1.4: The MQTT protocol.

MQTT protocol follows the server/client schema with the server in this particular case
to be called broker. The clients do not communicate directly with each other, in fact all the
messages (publishes) travel through the broker. Every message, except from its text (from
now on referred to as payload), has a topic and each client can subscribe to various topics.
Topics are organized in a hierarchical manner (called topic levels), with the form of file
paths such as in a computer’s file system; e.g. “home/bedroom/light/status”. The broker
receives the publish message from a client and is then responsible for relaying the message
to every other client that has subscribed to this particular topic. It is easy to understand
that MQTT was designed for one-to-many and many-to- many communications and with
the assumption that a pre-defined relationship between participating nodes exists, because
there are no discovery or content negotiation mechanisms in the protocol. On the figure
above (figure 1.3) a simple publish/subscribe example is depicted. MQTT has five basic
methods/functions described by its specification, and could also have more, depending on
the broker’s implementation; they are:

• Connect

• Disconnect

• Subscribe

• Unsubscribe

• Publish

13
 Another important feature of the MQTT protocol is the support of three different levels
of QoS (Quality of Service). The term “QoS level”, is, in fact, a form of agreement between
sender and receiver of a message regarding the guarantees of delivering a message. MQTT’s
QoS levels are the following:

• Level 0:at most once (fire and forget).

• Level 1:at least once (deliver at least once).

• Level 2:exactly once (deliver exactly once).

The assurance of the QoS levels greater than zero is achieved with the use of ACK
(acknowledge) packets between the published and the broker. Designed as a lightweight
protocol for use on constrained devices, MQTT has some additional features towards that
target. Namely, it has support for persistent sessions and message queuing for single clients,
and the ability to retain messages on selected topics.
The first feature is really helpful on unreliable networks where clients get often disconnected
from the broker, and also saves a lot of resources on the client because there is no need to
re-subscribe to all the topics after a reconnection. When a persistent session is configured,
during the first connection of a client to the broker, it is ensured that all the subscriptions
to the topics done by that client will be retained if the client gets unexpectedly disconnected
from the broker. Additionally, all the messages that were published on the retained topics,
with QoS greater than zero, will be sent to the client after it gets reconnected.
The ability of the broker to retain the last message (together with its QoS) on a selected
topic on the other hand is useful for newly connected clients because they are immediately
updated about the status and they do not need to wait for the publishing client to send
the next status update. Finally, MQTT supports Last Will and Testament (LWT) messages
and a configurable Keep Alive time interval for client-broker connections. The LWT feature
is used in order to notify other clients about an ungracefully disconnected client by sending
them a pre-defined (during the client’s initial connection to the broker) message to a pre-
defined topic (also QoS and retained flag could be pre-defined). Secondarily, the configurable
keep alive time interval is the longest possible period of time, which broker and client can
endure without sending a message, and is really important for mobile networks due to their
peculiar handling of TCP packets

1.2 Conclusion
All along this chapter we shed some light on some known concepts about Wireless Sensor
Networks. In the following chapter, we are going to present the requirements and specifica-
tions in order to determine the functionalities of the output solution.

14
Chapter 2

Requirements and specifications

2.1 Study of the existent

2.1.1 The operating system
The operating system is the foundation of the IoT technology as it provides the functions for
the connectivity between the nodes. However, different types of nodes need different levels
of OS complexity; a passive node generally only needs the communication stack and is not
in need of any threading capabilities, as the program can handle all logic in one function.
Active nodes and border routers need to have a much more complex OS, as they need to
be able to handle several running threads or processes, e.g. Routing, data collection and
interrupts. To qualify as an OS suitable for the IoT, it must comply with the following
requirements:
• Low Random-access memory (RAM) footprint
• Low Read-only memory (ROM) footprint
• Support Multi-tasking
• Power management (PM)
• Soft real-time
For reference, the below table shows a comparison of the most popular OS for IoT:

Figure 2.1: OS requirements support comparison.

15
2.1.2 Hardware development platform
When it comes to WSN, the second important decision that must be made, after the choice
of OS, is the decision of which hardware platform to use. Today there are a lot of available
options:
• Ultra-low power and limited resources platforms: Zolertia z, MSB430, CC2538SoC.
• Medium power platforms: Arduino.
• More powerful platforms: Raspberry Pi.
Except from power consumption and performance capabilities, extensibility in terms of
enough I/O connections and popular interfaces support, as well as community support,
must also been considered.

2.1.3 Application Layer Protocol for the WSN platform

A comparison between the different application layer protocols shall be made at this point,
it will be articulated only between the protocols that use TCP or UDP as their trans-
port protocol, because the other ones using HTTP as transport protocol are not suitable
for lightweight implementations on constrained devices due to the overhead introduced by
HTTP. As a result, the HTTP itself, and the SOAP protocol will not be included in the
comparison.

2.2 Requirements
2.2.1 Functional requirements
Our application must provide the user with the following functionalities
Display gathered data in real time: The user must be able to view readings from the
deferents devices in real time.
Synthesize data reports: The user must be able to view historical data of previous read-
ings
Generate charts of preexisting data: The application must provide some charts and vi-
sual reports.

2.2.2 Non-functional requirements

• Efficient manipulation of the different services.
• Easy to use user interface for a rich user experience.
• Ability to change some configuration settings.
• Ergonometric interface]

16
2.3 Specification
2.3.1 Use case diagram
The bellow use case diagram illustrates the main functionalities of the system and the ap-
plication

Figure 2.2: Use case diagram.

Once the user opens the web interface (main page), he finds the latest received read-
ings: The temperature value, the acceleration variation and the battery level of each node
in the WSN, the information is displayed as gauge(with minimum and maximum value),
charts(Time as x and readings as y), text and numerical values . Also (still on the home
page) the user can read the time of last update and an indicator shows weather or not a
node is active. Moreover, the user can switch to another page where he can see the historical
environmental data and can chose the time interval of the readings that he wants.

2.3.2 Sequence Diagram

The diagram above describes the mechanism of dynamically generating the UI web page
and the interaction between the user, the web server, the application server, the database
and the WSN . When the user requests for historical readings, he makes an HTPP request
to the web server through a web browser which responds by delivering a static content to
the client, then the application server and group of scripts and parse the request, query
a database server to retrieve required information, and then employ formatting scripts to
generate HTML code addressing the request. This newly generated code, created at runtime
based on a user’s input, is dashboard dynamic Web page.
On the other hand When the user requests for the real time data readings the application

17
 Figure 2.3: Sequence Diagram.

server remains waiting for data coming from the scripts responsible for connecting to the
WSN through the Internet. The incoming data is then parsed and analyzed to create or lets
say change/refill the user interface with the newest values. This process indicates that the
application has to be event-driven programmed where there is generally a main loop that
listens for events, and then triggers a callback function when one of those events is detected
(it’s a paradigm used in graphical user interfaces)

2.4 Conclusion
This phase was our main focus. Meetings with our supervisor were held in order to determine
the requirements like who is going to use the system? How will they use the system? What
data should be input into the system? What data should be output by the system? These
were general questions that got answered during a requirements gathering phase.
In this chapter, we have detailed the functional and nonfunctional requirements. Therefore
the different features of the project and the needs for the application are set clear for the
next phase.

18
Chapter 3

Design

3.1 General design

Specifying requirements is indeed crucial to any application development, but what’s more
important, is knowing how to express and model those requirements in a more eloquent way.
In this spirit, this chapter aims to represent the different design strategies we applied to
extract and highlight the underlying aspects of our network and our application .

3.2 General Design

3.2.1 Potential Architectures
Event Driven architecture
An event-driven architecture consists of event creators and event consumers. The creator,
which is the source of the event, only knows that the event has occurred. Consumers are
entities that need to know the event has occurred; they may be involved in processing the
event or they may simply be affected by the event. Event consumers typically subscribe to
some type of middleware event manager. When the manager receives notification of an event
from a creator, it forwards that event to all registered consumers. The benefit of an event-
driven architecture is that it enables large numbers of creators and consumers to exchange
status and response information in near real-time.

19
 Figure 3.1: Service oriented architecture.

Service Oriented architecture

Service-oriented architecture (SOA) is an approach used to create an architecture based
upon the use of services. One of the most important functions carried out by services are
producing data. A key motivation for the application of Service Oriented Architecture when
designing and implementing distributed systems is to achieve loose coupling among different
modules of the system. This approach keeps implementations amendable and makes the
reuse of existing modules easier. Another benefit of using the service-based approach is the
ability to extend the system functionality dynamically by interconnecting different end nodes
or composing new services out of existing ones.

Figure 3.2: Event driven architecture.

20
Choice of architecture
Our integration design is based on “EDA” , in fact :
• The sensor motes ,or let’s say the WSN don’t know what consumers may be interested in
an event .
• The sensor motes don’t know how each consumer may react to an event, and indeed expects
that different consumers may react differently
• The communication is one-way: The announcers(WSN motes ) doesn’t want to wait for
the consumers(clients) to react, indeed doesn’t know when they’ve all reacted, and isn’t
interested in the results from the reactions

3.2.2 Potential WSN topologies

Star Topology
Star networks are connected to a centralized communication hub (sink) and the nodes cannot
communicate directly with each other. The entire communication must be routed through
the centralized hub. Each node is then a “client” while the central hub is the “server or
sink” as shown in Fig..

Figure 3.3: Star topology.

Tree Topology
The network use a central hub called a root node as the main communication router. In
the hierarchy, central hub is one level below from the root node. This lower level forms a
star network. The tree network can be considered a hybrid of both the Star and Peer to
Peer networking topologies as shown in Fig 2.2. In sensor network path may be single hop
or multi hop, sensor node for getting data sense the environment and sent them to the sink
and sensor forwards them to its parent after receives data messages from its children. It is
important to find an optimal shortest path tree with maximum lifetime and shorter delay
but slightly high time complexity and but more suitable for distributed implementation.

21
 Figure 3.4: Tree topology.

Bus Topology
In this topology, there is a node send message to another node on the network sends a
broadcast message onto the network that all other nodes see, but only the intended recipient
actually accepts and processes the message. Bus topology is easy to install but congestion
of traffic and single path communication. However, bus networks work best with a limited
number of nodes. If more than a few dozen nodes are added to a network bus, performance
problems will likely result.

Figure 3.5: Bus topology.

Mesh topologies
Mesh topologies involve message can take any of several paths from source to destination.
(Recall that even in a ring, although two paths exist, messages can only travel in one di-
rection.) A mesh network in which every node connects to every other is called a full mesh
and there is partial mesh networks also exist in which some devices (nodes) connect only
indirectly to others .

22
 Figure 3.6: Mesh topology.

Choice of topology
Since our WSN doesn’t have a large number of motes and and because we wanted to centralize
the process of sending data to the client, we used the “Star topology”.

3.2.3 Potential WSN Data sending paradigms

It is known that data sensing and reporting in WSNs is dependent on whether the application
is real time or not. Moreover we can categorize data reporting in WSN into 2 sending
paradigm

• time driven :Report data in the cycle time. (LEACH)

• event driven :Report data in the event. (TEEN)

The time driven delivery scheme is meant for applications that need cyclic monitoring Hence
the nodes will periodically turn their sensors and transmitters, in order to sense the envi-
ronment and send data periodically In the case of event-driven and scheme, sensor nodes
reply instantly to abrupt modifications in the sensed features because of the occurrence of a
specific query, which is suited to real time situations. It is possible to make a blend of these
2 schemes .
Choice of the WSN Data sending paradigms
Since our platform is for environmental monitoring it have to send data periodically and
it can face some severe real time situations that need to be closely monitored and rapidly
updated, that’s why we chose a mixture of time driven and event driven paradigms. In
fact, this allow the transmitters to change their different time-cycles based on the current
situation of the monitored environment.

23
3.2.4 Final choice

Figure 3.7: Final choice.

3.3 Detailed Design

3.3.1 Overview of the project
The bellow figure reveals an overview of the project:

Figure 3.8: Project overview.

24
3.3.2 Software
Operating system for Sensor motes
Contiki OS meets all the requirements and it is the one we will use on this project. It is
an open source and community supported operating system designed for use in IoT and it
is written in C language. It is currently supporting a large number of different MCUs and
radios. As for protocols, its supports the commonly used TCP/IPv4 and IPv6 with the uIP
(micro-IP) stack, and it also supports the 6LoWPAN stack and its own stack called RIME.
The network stack implemented in Contiki is slightly different than the usual model typi-
cally adopted in TCP/IP. In-between the Physical and the Network layers, where, usually,
the MAC is located, Contiki has three different layers: The Framer, the Radio Duty-Cycle
(RDC) and the Medium Access Control (MAC). All these layers could be configured at
compilation time by using their respective global variables. Contiki also has threading capa-
bilities with a thread system called Protothreads and includes also libraries for a wide range
of popular applications such as HTTP, Constrained Application Protocol (CoAP), UDP, and
FTP servers, as well as other useful programs and tools, among them a MQTT client. One
of Contiki’s most prominent feature is the support of IP protocols, being one of the first
embedded operating systems to provide IPv6 support.

Figure 3.9: The protocols stack of a WSN.

25
3.3.3 Network
Hardware development platform
Zolertia Z1 Z1 is equipped with a second generation MSP430F2617 low power microcon-

Figure 3.10: The protocols stack of a WSN.

troller, which features a powerful 16-bit RISC CPU @16MHz clock speed, built-in clock
factory calibration, 8KB RAM and a 92 KB Flash memory. Also includes the well-known
CC2420 transceiver, IEEE 802.15.4 compliant, which operates at 2.4GHz with an effective
data rate of 250Kbps. Z1 hardware selection guarantees the maximum efficiency and robust-
ness with low energy cost. Built-in sensors

ADXL345 Accelerometer The ADXL345 is a small, thin, low power, 3-axis accelerometer
with high resolution (13bit) measurement at up to ±16 g. Digital output data is
formatted as 16-bit twos complement and can be accessed through either a SPI (3- or
4-wire) or I2C digital interface. ADXL is connected to msp430 through the USCIB1
used as I2C.

TMP102 Temperature The TMP102 is a two-wire, serial output temperature sensor

available in a tiny SOT563 package. Requiring no external components, the TMP102
is capable of reading temperatures to a resolution of 0.0625◦ C. The TMP102 is ideal
for extended temperature measurement in a variety of communication, computer, con-
sumer, environmental, industrial, and instrumentation applications. The device is
specified for operation over a temperature range of -40◦ C to +125◦ C. TMP102 is con-
nected to msp430 through the USCIB1 used as I2C.

Raspberry Pi
The Raspberry Pi is a series of credit card–sized single-board computers developed in the
United Kingdom by the Raspberry Pi Foundation. Raspberry Pi is an open source hardware
technology combined with a programming language and an Integrated Development Envi-
ronment (IDE). The Raspberry Pi platform allows the user to create custom hardware and
applications to control it via its Name sake programming language. Many software languages

26
 Figure 3.11: The protocols stack of a WSN.

are available on the Raspberry Pi and we are interested in two. These are the C++ and
Python. The Raspberry Pi is a low cost, small and portable size of computer board. It can
be used to plug-in to computer monitor or television, keyboard, mouse. The Raspberry Pi
uses an SD card for storage, which is fast and has no moving parts and the Pi is completely
silent.
Product Overview

• Broadcom BCM2836 SoC full HD multimedia applications processor

• 1GB SDRAM operates at 450MHz

• 40 pin extended GPIO

• 10/100 Ethernet RJ45 onboard network

• 4 USB 2.0 ports

• CSI camera port for connecting the Raspberry Pi camera

• DSI display port for connecting the Raspberry Pi touch screen display

• Featured with MicroSD slot

• Composite RCA and HDMI port

• Multi-channel HD audio over HDMI, stereo from 3.5mm jack

27
Application layer protocol of the WSN (MQTT)
Firstly, based on the comparison table[table 1.3], it is easy to see that MQTT offers greater
QoS options against the other protocols, which makes it perfect for use on unreliable net-
works. On top of that, it is based on TCP instead of the unreliable UDP transport protocol,
making it an even more reliable choice. One of the disadvantages of MQTT is that it has no
discovery capabilities, but that is not a problem in this case, mainly because the scenarios
of use for WSN nodes in IoT assume that all the properties (the sensors that are available
and their names/topics) are already known and therefore there is no need for discovery. The
other drawback of MQTT is that it is not a synchronous communication protocol. Once
again, this is not a problem in our case, as there is no special need for synchronous commu-
nications between the WSN nodes and it is eventually counterbalanced by the large options
of QoS. Finally, MQTT is the second most popular (after HTTP) IoT messaging protocol
used today for IoT applications according to a recent survey (IoT Developer Survey 2016 )
done by the Eclipse IoT Working Group, IEEE IoT and Agile IoT on April of 2016 and this
is an extra reason why MQTT was chosen.

Figure 3.12: MQTT subscribe/publish model.

Quick summary

Figure 3.13: Protocol stack.

28
3.3.4 Sequence diagram

Figure 3.14: Sequence diagram.

3.3.5 Data storage

IoT is about taking really large volumes and fast-arriving sources of data. This data may
have little or no value on a record-by-record basis, but when you put the data together in
aggregate, it starts to have a lot of value. To work with data like that at that’s moving
quickly and is at very large volume you need technology that’s able to work with those
kinds of demands. Typically this means we need to be able to throw lots of hardware at the
situation. The amount of hardware we are using can vary depending on seasonality, or time
of day, or an important event. Being able to scale elastically and accommodate very large
volumes of fast moving data is one piece of the equation. What we want is a system that can
flexibly adapt to new sources of input and evolve gracefully to accommodate those sources
– without taking the system offline, and without incurring lots of engineering overhead to
make changes. That means we need a very flexible and dynamic data model. We believes
that MongoDB excels in all of these IoT areas.

29
3.3.6 Deployment diagram

Figure 3.15: Deployment diagram.

3.4 Conclusion
In this chapter, we got a more detailed vision of how the implantation of the project is going
to be. The deployment diagram along with the sequence diagram makes it a good transition
for the next phase. In this phase the system and software design is prepared from the
requirement specifications which were studied in the previous phase. System Design helps
in specifying hardware and system requirements and also helps in defining overall system
architecture. The system design specifications serve as input for the next phase of the model.

30
Chapter 4

Development

4.1 Software environment

Software Version Functionality
windows WINDOWS 8.1 Operating system
Ubuntu 14.04.5 LTS Operating system
Contiki OS 2.0 Operating system for WSN motes
Sublime text 3 Text editor
Latex Documentation

4.2 Data format

The bellow figures reveals the format of the data traveling from the WSN to the broker and
then to the client. There a 7 fields:

Figure 4.1: Data sent to the broker.

31
 The application turn the acquired data into a time series document in a MongoDB
collection

4.3 Border router

To build up the network, we must first set up the border-router software. This build-up is
done in two steps: First, the border-router needs the UDP, The PC must run the tunslip6 ap-
plication in order to tunnel all data from the 6LoWPAN network to the normal IP-network.
The code source for the border router can be found in: “border-router.c” We then compile
the application to the intended Zolertia Z1 node. This can be done using:

Listing 4.1: compile border router image

make border−r o u t e r . upload TARGET=z1
This application is compiled directly in the simulator when using Cooja. After the bor-
der router application is installed onto the node, we then can bridge the 6LoWPAN-network
with the IP-network using the tunslip6 application. We compile it using:

Listing 4.2: tunslip6 bridging

g c c t u n s l i p 6 . c −o t u n s l i p 6
When compiled, the “tunnel IP over serial line” application can be ran using:

Listing 4.3: run tunnel application

sudo . / t u n s l i p 6 aaaa : : 1 / 6 4 −v3
When everything runs well, we then see the IPv6 address of the edge-router, along with
its corresponding local link IPv6 address

Figure 4.2: Running the border router.

32
 When data is traveling from the 6LoWPAN-network, it is shown as: “from slip to tun”.
In the opposite way the tunnel application will output: “from tun to slip”.

4.4 UDP client

The code is in “udp-client[node id].c”, where node id is either 30 or 70. The first important
function to be mentioned is the ”set − global − address()”.

Figure 4.3: Running the border router.

After this function, we will print the addresses with the function print−local−addresses().
This function only prints the address of the server and the client. The next step is done by
opening a connection to the remote server. Therefore the client opens a local socket through
which it can send data.

Figure 4.4: Setting up of the socket at the client side.

The server and client can only communicate if the sockets are set up in the right way. A
socket is defined by two parameters:

The IP-addresses: client and server should know the IP address of their partner, usually
the client initiates the connection, and the server replies.

Port numbers: both server and client can only communicate if their listening and writing
ports match.

After the socket has been set up, the client is able to send data to the server and to receive
data back. Sending data is done by using for example the timer. This method ensures a

33
 Figure 4.5: Sending a UDP-packet at client side.

regular sending interval. The sender method is called through a callback method of the
timer. To send information to the server, the method send − packet() is used.
To receive packets from a remote device (server) the other function tcpiph andler is used.
This function is called when the tcpipe vent is raised in the main loop

4.5 UDP server

The UDP-server of Contiki follows more or less the same rules as the UDP-client. There are
however some major differences compared to the client.

• The server only binds itself to a socket. When the socket is created, the server will
wait until an incoming connection arises. At that moment, a tcpip event will be arisen
and the server parses the incoming data.

• Since the server only binds to its own socket, it will not create a client socket before-
hand. In order to respond back to a client, the server will only create a socket for the
client when data comes in from a client. The socket is then used to reply back to that
particular client.

Some additional details should be noted before proceeding to the programming of such a
node. The server’s IP address will be given by the nodes nodeid and nodemac. Therefore,
we will compile the application in mode 3. This results in the IP-address of the server being
set up as follows:
Listing 4.4: server IP address
u i p i p 6 a d d r (& ipaddr , 0 xaaaa , 0 , 0 , 0 , 0 , 0 , 0 , 0 ) ;
u i p d s 6 s e t a d d r i i d (& ipaddr , &u i p l l a d d r ) ;

34
 the IP address of the server is set by the nodeid and nodemac, combined with the IPv6-
prefix of the network. This address should be used in UDP-client applications in order to
reach the server. Also, the UDP-port of the server should be the same as the one used in the
UDP-client. In order for the server to reply back to a clients request, the server implements
following method

Figure 4.6: Server replying back to a client.

4.6 Main application development

Node-RED is a tool for wiring together hardware devices, APIs, and online services. It is
built on Node.js, a JavaScript runtime platform for building fast, scalable network applica-
tions. Node.js uses an event-driven, non-blocking I/O model. Node-RED is a powerful tool
for building Internet of Things (IoT) applications with a focus on simplifying the ‘wiring
together’ of code blocks to carry out tasks. It uses a visual programming approach that
allows developers to connect predefined code blocks, known as ‘nodes’, together to perform
a task. The connected nodes, usually a combination of input nodes, processing nodes and
output nodes, when wired together, make up a ‘flows’.

4.6.1 User interface

Node-RED’s dashboard nodes provide a comprehensive set of UI components for building
basic dashboards suitable for the Internet of Things (IoT) – offering graphs, gauges, basic
text as well as sliders and inputs. However, there will always be situations when we need
something custom. Lucky for us there is a solution which is the template node.

35
Real time dashboard
The bellow figure shows the dashboard for real time monitoring. The values are refreshed
each 20 seconds (20 seconds can be adjusted of course).

Figure 4.7: Real time monitoring dashboard.

The dashboard displays the following measurements:

• Temperature

• Acceleration

• Battery level

The figure illustrates how the User-side application works, a data flow comes from the
MQTT-SUBSCRIBER node (on the left), its format is then adjusted and transformed from
a JSON String to a JSON Object before adding the client’s local time as a JSON field using
a JavaScript function (the time takes the format of a Unix Time stamp in milliseconds).
After that a ”switch” node directs the message to 2 different flows based on the node-id field
(id) , each sub-flow store the data into a Database and extract the values into UI nodes.

Historical data dashboard

The bellow figure shows the dashboard of the gathered data from our database. It’s possible
to adjust the period of time of the report The dashboard displays the following measurements:

• Temperature

• Acceleration

• Battery level

36
 Figure 4.8: Data traveling from the broker into real time monitoring and database.

Figure 4.9: Historical data dashboard.

In this figure , a flow comes from the periodical event/flow generator node (on the
left),after adding the database query in the message, the flow duplicates to a couple of
flows. The flows go into the MONGODB nodes where the retrieval of the JSON files from
the 2 database collections takes place based on their date field, the the useful data is then
extracted and passed to the Dashboard nodes.

37
Figure 4.10: Data fetched from the Database into Dashboard nodes.

Figure 4.11: Code for fetching data.

38
4.6.2 Database
The bellow figures illustrate the structure of our database. Each node has its own collection
of data as following:

Figure 4.12: data sample. Figure 4.13: Database schema.

39
4.6.3 Overview of the realized work

Figure 4.14: Code for fetching data.

40
4.7 Conclusion
All along this chapter we have presented the work that needed to be done on both the software
and the hardware. We then presented the actual system via some graphical interfaces

41
Chapter 5

General conclusion

As part of the design and development project, we were assigned to design and realize an
application for monitoring wireless sensor networks. The first step in the realization of our
project was to conduct a study of the exiting wireless sensing network implantations which
led us to become familiar with WSN related concepts.
It’s only fair to state that the implantations were highly relative to the domain and that
there was no major WSN solutions to critic in the first place.
We then began the analysis and specification of needs and we have determined the differ-
ent needs that our application should satisfy and the features it should offer to the user.
Thereafter, we were interested in the conceptual study of the application from which we
have identified the general architecture and the different UML diagrams, namely use case
diagrams and sequence diagrams. Finally, we outlined the hardware and software tools used
during the implementation of our project. The connection of the WSN itself was not easy
as we had to first understand how the network motes operate. Connecting our network to
the broker was easy.
We have also introduced Screenshots that describe the various features of our application.
We had many difficulties working on this project especially since we were new to the field.
This experience was constructive and interesting. Thus, we were able to little time acquire
knowledge about the concepts of WSN, in the same way, we have been able to put our the-
oretical knowledge into practice. This project allows one to understand the structures and
the topology of today’s IoT networks. Else such networks can be deployed all over the world
the makes our everyday life smarter and more efficient.

Problems encountered
During the development phase some problems were encountered, especially with the proper
configuration of border router and also with some bugs on the msp430-gcc compiler that
prevented us from using the full 92 Kilobytes of flash memory available on the Zolertia Z1.
While the latter was not a major issue for us, it must be taken care of for future expansion
of the above implementations because some of them have almost reached the ROM usage
limit of 56 Kilobytes. As an additional note on this chapter, the lessons learned from this
work will be mentioned. Firstly, it should be noted that a slightly large amount of time was

42
used for researching the available MQTT client implementations for Contiki. This, however,
could be bypassed if Contiki had a continuously updated and detailed list of the built in
support of protocols and applications.

Open issues
In the future, we intend to develop a secure MQTT implementations for use on the IoT by
exploiting more layers of the OSI Model, with the use of the compressed version of IPSec
designed for constrained devices, or the Transport Layer, with the use of, the most popular,
TLS. Furthermore, a more comprehensive comparison of the IoT protocols with the perfor-
mance assessment of them could also be done. On a topic not strictly related to this project,
a great area of research, where much work still needs to be done, is the interoperability
in IoT. As already mentioned, IoT contains very different communication, and not only,
protocols. As a result, a method for enabling IoT devices using different communication
protocols to communicate with each other, either by using a “smart” bridge or by using
protocol conversion/translation on the application layer, would be really groundbreaking.

Time-line

Figure 5.1: Time-line.

43
Bibliography

44
45