Hazard Detection With FreeRTOS based Wireless Sensor NetworksDiogo Filipe Tomás Guerra

Instituto Superior Técnico, Av. Professor Doutor Aníbal Cavaco Silva, 2744-016 Porto Salvo, PortugalPhone: +351-914448691, e-mail: diogoguerra@tecnico.ulisboa.pt

Abstract – In this work are studied variousoperating systems and communication protocolstacks currently used in wireless sensor networks.The aim is to find a solution for timely delivery ofinformation using a real-time operating system and aredundant and resilient protocol stack like theproposed IEEE 802.15.4E. Moreover, it addresses theadaptations made on the firmware to enablecompatibility with the in-house already conceivedplatform – MoteIST. In the end the full project cancompile and run on the MoteIST platformmaintaining compatibility with the original project.Tests were made to assert proper communicationwith the work addapted.

Index terms – Timely Delivery, FreeRTOS, WSN, 802.15.4E,

Hazard Detection and Emergency Response, OpenWSN.

I. INTRODUCTION

Wireless Sensor Networks are systems made up ofspatial distributed nodes that measure physicalquantities. This networks are suited for remotedeployment where they communicate with the world viaone or more base stations. This gateway relayinformation through a satellite constellation or othertype of special communications.

Hazard Detection and Emergency Response is anapplication of Wireless Sensor Networks. Effectivecommunication mechanisms are needed to managenetworks with large size and the usage of Real-TimeOperating Systems helps to ensure timely eventresponse minimizing accidents and loss of life.

FreeRTOS is one of the most used Operating Systemswith Real-Time characteristics ported to a wide range ofmicrocontroller architectures. Although there arecommunication stacks available in FreeRTOSenvironment, there are none natively developed tosupport wireless sensor networks.

I decided to choose a recent protocol stackIEEE 802.15.4E currently under development with theproject OpenWSN [1]. The OpenWSN project aims toprovide a complete and free implementation of aprotocol stack with a wide range of firmware andhardware platforms. The MAC implementation used isthe TSCH - Time Scheduled Channel Hopping,communication schema.

The intention is to equip the FreeRTOScommunications suite with a scalable, redundant andresilient protocol stack that enables timely delivery ofevent notifications. After this it is intended to adapt allthis changes to the in-house already conceived platform

– MoteIST [2] and making tests ensuring the protocolbehaves as expected managing a considerable datathroughput.

II. SENSOR NETWORKS

Sensor Networks (SN) have become popular insolutions for monitoring and environmental control inagriculture, industry, home automation and energymanagement applications [3],[4]. More recentlyWireless Sensor Networks (WSN) are used in remotelocation monitoring environmental factors for fireprevention [5] or earthquake warning systems [6].

Nodes in a WSN monitoring fire hazards are subject torandom failures due to battery depletion, as well as theantennas being reoriented in the wrong direction due tofalling branches, curious animals or wind. As WSNtransmit packets from node to node, the failure ofseveral nodes relatively close to each other can partitionthe network into two subnets without communication[7]. This happens because one or more key nodes in thelink between the subnets stops working. Also, if thenode responsible for detecting the emergency event in aparticular area fails to respond due to sensor elementfailure or node battery exhaustion a WSN failure occurs.

Taking the above into consideration one can easily saythat the key factor in WSN is energy efficiency. In thishazardous applications, installation is typically carriedout in a remote location, often difficult to access. Forthis reason, ensuring the lifetime of the network isimportant. This way, the cost of installing andmaintaining this type of infrastructure can be reduced,making the use of WSN a more viable solution thanother options.

A. Case Studies

In [8], 9 battery-powered motes are used to detectmethane leaks in a factory. The selected networktopology was the star topology where 1 of the nodeswas configured as the base station.

Communication in the network is performed through802.15.4[9] using ZigBee1 modules. The base stationacts as a gateway with an Ethernet communication sothat in case of emergency a team is notified. Thelifetime of the network is greater than one year and it ismentioned that the main factor limiting it is the energyconsumption of the methane sensor.

In [5] a network for the detection and monitoring offorest fires was presented. Nodes are powered by twoAA batteries and controlled by an ATMega1281microcontroller. The radio transceiver is a ZigBee

1

module. The network is organized in a mesh topologyand a base station is used to schedule "sleep" periods.This topology was chosen because it allows networkscalability. Using a duty cycle of 0.33% ensures that thelifetime of the network is greater than one year.

B. Communication Technologies in WSN

Motes have limited communication range. This factoris due not only to an inherent limitation of transmissionpower, in order to reduce interference in thetransmission medium and to increase the lifetime of thenode [10], but also thanks to power losses due to thepropagation path of the electromagnetic waves andobstacles between nodes. For this reason thetransmission of messages must be carried out usingnode-to-node routing in which the message is forwardedby intermediate nodes to the destination. Thesenetworks are referred to the mesh networks wherepackets can be transmitted with different schema's [11].

Network lifetime: The network is organized tobe functional as long as possible. It is common that thelimiting factor of the network lifetime is the energyaccessible to the nodes and so routing of the packets istypically carried out so that there is the lowest energyconsumption possible.

Fault Tolerance: In packet transmission theroute that guarantees delivery with minimumtransmission errors is chosen. Useful whencommunicating with mobile nodes, for example.

Response time: Packets are routed through thefastest transmission path, between the source node andthe gateway. Typically this is the solution that requiresless retransmissions.

The use of efficient communication protocols is anintegral and fundamental part of these networks. In thisway the Medium Access Control (MAC) is essential inWSN. MAC protocols must have good energyefficiency since the nodes have limited energy [4].

The MAC is responsible for the possibility of multiplenodes communicating using a shared medium, as is thecase of WSN, in which the device used to transmit inthe medium is the radio. Access to the medium in WSNis typically distributed, in that this access is easilyimplemented in networks with many nodes andtherefore more easily scalable. Basic ideas of distributedaccess perform random access to the medium. However,it is also possible to perform scheduled accesscommunication. In this type of access the typicalconsiderations are below.

TDMA (Time Division Multiple Access): Thetransmission cycle is divided into a fixed number ofslots. To each slot only a single node is assigned thatcan perform communication within that time withoutinterference. The communication is coordinated by anode that signals a new transmission cycle (through aspecial beacon slot) allowing synchronization of thenodes in the network. This method has the advantage of

ensuring throughput, fixed transmission delay and betterenergy efficiency. However, it suffers from limiting theresponse time (communication with this node is onlyresumed in the next scheduled slot).

TSCH (Time Scheduled Channel Hopping):This is a scheduling type that combines two differenttypes of media access, namely Frequency DivisionMedium Access (similar to TDMA where slots arereplaced with specific frequencies) and TDMA. In thistype of scheduled transmission the transmission timecontinues to be divided into slots however to this is alsoassigned a unique transmission frequency. Thisfrequency is typically signaled by the HoppingSequence (HS). This method makes the possible totalnetwork throughput greater than using only one of theprevious methods. It also allows relatively close nodesto communicate at the same time without interferencebetween them, unlike TDMA.

C. Gateway Technologies

Different technologies can be used to enablecommunication from WSN locations with the internet.

Opportunistic networks use node mobility as anadvantage for packet transfer within a network. WSN'sinstalled near a railway line can periodically exchangedata with a mobile node installed in a passing train. Afew seconds is the time it takes for the gateway toexchange packets stored during the period betweentrains with the mobile node and vice versa. This conceptcan also be applied with random animal movement inwhich routing algorithms are used according to thedesired quality of service (QoS) [12].

Figure 1: Example of a network where mobile nodes carry out

packet transport [12].

By means of satellite-enabled gateways messagetransmission is a viable option for any remote location,provided that coverage is garanteed by the operator'ssatellite constellation. This service has the advantagethat priority messages can be transmitted immediatelywith a maximum delay of a few minutes.

Figure 2: Example of a typical application of message

communication in remote areas using satellites as relays.1

1 http://www.sailboat-cruising.com/gmdss-system.html – Nov 2017.

2

Table 1: Comparison made to different popular multitasking cores to study the real-time characteristics, existence of native communication

protocols and modularity for multiple and different nodes within a heterogeneous sensor network.

Execution[13] UsedMemory

[Bytes][14]

ContextSwitch[cycles]

SupportedArchitectures

[MCU]

Supports NativeRadio

Communication

RealTimePreemptive Cooperative

Contiki[15]2 ○ ✓ <30k (1) 13 ✓ ○

FreeRTOS3 ✓ ✓ 4k – 9k 84 34 ○ ✓

Nano-RK[16]4 ✓ ✘ <18k (1) 12 (2) ✓ ✓

RiotOS[14]5 ✓ ✘ ~5k ~50 6 ✓ ✓

TinyOS[15][17]6 ✘ ✓ <4k 51 6 ✓ ○

Legend: ✓ - Meet the requirements; ○ – Partially meet requirements; ✘ - Does not meet requirements;1. Used memory includes communication protocols 2. Context switch: 45 µs on a 4 Mhz processor.

D. Real-Time Operating Systems

In emergency detection and response scenarios, inaddition to the need for protocols that perform timelycommunication, it is necessary that the OS used supportreal-time execution. Some OS's were evaluated and arepresented in Table 1.

E. Other Communication Schemas

IEEE 802.15.4 MAC is possibly the most usedprotocol in WSN. The characteristics of the 802.15.4MAC protocol are: synchronized networks access to themedium, management of guaranteed slots, validation offrames, confirmation of delivery of frames, associationand disassociation to networks. The protocol can useseveral types of media access, depending on thenetwork configuration used [9]:

IEEE 802.15.4E MAC is based on the IEEE 802.15.4protocol and therefore shares many similarities. The keyaspect of this new definition is the use of channelhopping (CH) that significantly increases the network'srobustness against external interference and multipathfading.

In addition, unlike 802.15.4, guaranteed slotmanagement is controlled by the hierarchically higherlayers and in their design the contents of thesynchronization packet is different. All other featuresdefined by 802.15.4 remain similar.

Like its predecessor, the 802.15.4E protocol definesvarious types of medium access depending on the typeof network to be used. In this case the focus will be onaccess using TSCH.

In this type of access time is defined in slots. TheAbsolute Slot Number (ASN) is incremented each slotand shared by all nodes in the same network. Assumingthere is no propagation delay for the flag package, all

nodes on the network have the same ASN. At thebeginning of a slot the channel to be used is calculatedusing [18].

(1)

The channel offset is defined by the length of the listthat defines the Hopping Sequence (HS). All nodes tthatwish to join the network expect the flag packet on awell-known and channel defined for the entire network.The flag package always contains the ASN. Figure 3exemplifies a communications schedule for thisnetwork.

Figure 3: Example of a slot allocation of an 8-node network

operating in TSCH7.

III. METODOLOGY

Synchronized networks allow better control andknowledge about the energy consumption of a network,especially when these are made up of some nodes andthe use of this network is considerable. In the examplesstudied [5], [8] the use of an 802.15.4 MAC protocoloffers some guarantees regarding network lifetime.

2 http://www.contiki-os.org/ - December 2014

3 http://www.freertos.org/ - December 2014

4 http://www.nanork.org/projects/nanork/wiki - December 2014

5 http://riot-os.org/ – December 2014

6 http://tinyos.stanford.edu/tinyos-wiki/index.php/FAQ - December 2014

7 https://openwsn.atlassian.net/wiki/display/OW/uRES – October 2016

3

CH = macHoppingSequenceList [(macASN + channelOffset) % macHoppingSequenceLength]

Using a real-time OS to detect asynchronous andunpredictable signals that provides priority responseover other tasks that are performing is an advantage. Inthis situation and through consultation of Table 1,FreeRTOS, Nano-RK and RiotOS are available.

The fact that 802.15.4E allows WSN to communicatein parallel in multiple channels in a frequency bandallows to increase robustness to interferences in thescenario where it is used, be these interferences due toother networks or due to natural phenomena such asmultipath fading.

Although OpenWSN is based on a simple OS wheretask is executed till completion, it include an adaptationof FreeRTOS as a task scheduler. This makes thisproject the most attractive option to be implemented inthe MoteIST platform and therefore the one that wasdecided to use. To test the timely delivery hypothesis itis used:

A network topology unfavorable to the WSN undertests to evaluate the delay caused by forwarding packetsbetween nodes and the impact of packet retransmissionon the success rate of communications.

Background traffic in order to saturate the networkwith less priority packet traffic. This test is performed toevidence a real network where periodic data arecollected in the network.

IV. ARCHITECTURE

OpenWSN is a project that provides solutions for easydevelopment of WSN. There are three main groups inthis project but implementation focuses on the firmware.

The firmware part of the OpenWSN project isdeveloped to be transparent to the firmware, the buildplatform used in its development, the mote where theapplication is executed and it is also prepared to supportdifferent Operating Systems.

A. OpenOS

The OpenOS scheduler performs tasks with higherpriority executed first. However, there is only a contextswitch when the current task finishes.

When a task is scheduled, the algorithm first looks fora free task buffer where it can store the informationneeded to execute it in the future. In case the task bufferis full the execution terminates in its entirety with anerror signal and subsequent reset of the platform. If it ispossible to allocate a new buffer, the algorithm searchesthe queue of the scheduled tasks for the position wherethe priority of the new task is less than the priority ofthe task currently under test and inserts it there.

B. OpenWSN and FreeRTOS

There is a structure with a global mutex, threeprocesses with different priorities and 1 semaphoreassociated with each of these processes. Each one of

these processes implement the same priority task bufferused in OpenOS. The difference is that there are threeexecution priorities (FreeRTOS processes) that generatesub-sets of tasks (OpenOS tasks).

As with OpenOS, tasks are performed in order ofpriority. The main difference is that an interrupt orinstruction when scheduling a task (managed by ahigher priority process) that overrides the priority of thecurrently running process immediately takes theprocessing time leaving the previous process (task) onhold. If the priority of the task to be scheduled is equalto or less than the current task, it is added to the taskqueue as before.

When a task finishes a new task is fetched to performaccording to:

1. The priority of execution of processes(FreeRTOS).

2. The priority of the task within the sub-groupmanaged by this process (OpenOS).

The three defined processes are:xAppHandle - is the lowest priority process

responsible for managing all the user level tasks.xSendDoneHandle - Is responsible for managing

tasks that handle packet errors rescheduling a new sendor triggering an error notification. In addition, timer andalarm priorities fall into this category.

xRxHandle - Performing at highest priority isdedicated to packet-receiving jobs scheduled by theprotocol stack machine (802.15.4e scheduler). Thesetasks perform the interpretation and handling of packetsthat target increasingly higher layers of the protocolstack.

V. DEVELOPMENT

Firstly will be the hardware adaptation to OpenWSN'swell-defined default function calls. The platform that weare going to use consists of a main board that integratesthe TI microcontroller MSP430F5438A and thesub-modules of the platform that are the radio with aTI CC2420 and the UART-USB converter with aTI TUSB3410. An example of the constituents of thedisassembled MoteIST platform can be visible below inFigure 4.

Figure 4: The components that make up the MoteIST platform.

Main PCB (TOP), Radio PCB (LEFT) and SERIAL (RIGHT)

4

A. Adaptation of the MoteIST platform

One of the components used in MoteIST that isalready developed in the stack used by OpenWSN is thesoftware library for the radio, assuming that it is alreadyoperational.

In the case of the microcontroller there are projects inthe OpenWSN with similar family as themicrocontroller used in MoteIST which is the F5 seriesand family. This is the case of motes identified in thebsp folder as wsn430v13b, wsn430v14 and telosb thatuse the MSP430F1611 microcontroller.

First a folder for the platform is created atbsp-> boards-> MoteISTv5. This folder hosts all thefiles that perform the hardware abstraction of the upperlayers.

After this the abstraction files are adapted to MoteISTaccording to their logical hierarchy. These files areadapted one by one and at each step is tested the correctoperation of these through projects, common among thevarious motes, available for this purpose.

The compilation files used by SCons, the build toolused by OpenWSN, are now defined in preparation forthe next steps. The adapted files are:

• board_info.h – Macros, interrupts and otherdefinitions.

• board.c – Peripherals configuration andplatform initialization.

• leds.c and debugpins.c• spi.c – Interface with the radio.• uart.c – Interface with the computer for debug

and gateway packets provider.• bsp_timer.c – Generic timer.• radiotimer.c – Communications state machine

timer.• eui64.c – Mote unique identification (for

network address purpose)Having the integration successfully completed theproject is tested for the use of OpenOS and finallyintegration with the protocol stack and some demoapplications.The first problem arise. There is an error linking theproject because there is not enough memory! The errordisplayed by the console can be seen below.

Figure 5: Error displayed when Compiling the OpenWSN project.

This lack of space can be justified by the occupiedROM by the protocol stack and the applications presentin the project. Although we can configure for the stackto only serve one of the transport protocols available

and to disable compilation of the applications, thefuture introduction of FreeRTOS is expected to makeavailable space for future applications minimal ornonexistent. As so, to use the full potential of themicrocontroller configurations are made to enableextended compilation in order to run bigger programs.

B. Compilation in extended mode

The MSP430 series 5 (microcontroller of theMoteIST) has two zones of ROM memory. Namely themicrocontroller (msp430f5438a) has 256 kB ofavailable ROM.

It turns out that ROM is split between LOW ROM andHIGH ROM that is used depending on the build modeused. So far the compiler was just using LOW ROMbecause in compiling with mspgcc (compiler used) itcompiles to the small memory model (small). Thememory model for which the code is compiled variesthe type of addressing performed by the microcontrollerand to use HIGH ROM it is necessary to compile withan extended memory model.

Generally, the small memory model uses 16-bitaddressing, whereas the large memory model allows foraddresses up to 20 bits (extended addressing). The useof extended addressing brings the obvious advantage inthe maximum possible size for our application (amaximum of 20 bits can address 1 MB). However, thereis the disadvantage that addressing operations usuallytake twice as many clock cycles.

This extended addressing is only possible because theALU7 and the microcontroller registers are purposelyextended to 20 bits so that the necessary operations canbe performed.

Figure 6: Block diagram of the MSP430X CPU8 architecture. We

can verify that in the CPU the Data BUS is of 16 bit, however it

allows the addressing of up to 20 bits (Address BUS ) [19].

7 ALU – Arithmetic Logic Unit.8 CPU – Central Processing Unit

5

/opt/msp430­toolchain/v3_04_05_00/bin/../lib/gcc/msp430­elf/4.9.1/../../../../msp430­elf/bin/ld: region `ROM' overflowed by 16276 bytes[...]collect2: error: ld returned 1 exit statusscons: *** [build/MoteISTv5_mspgcc/projects/common/03oos_openwsn_prog] Error 1scons: building terminated because of errors.

C. MSPGCC legacy update for MSP430-GCC

Due to a problem when linking the code, the compilerin use until now can’t be used for this extendedcompilation. Because the interrupt routines arecompiled last, the normal compilation of code occupiedLOW ROM first and then HIGH ROM. When trying tosave the ISR, which only execute specifically on LOWROM due to the microcontroller architecture, thismemory zone was already fully occupied and a linkererror occurred.

Through TI's website1 we download the latest versionof msp430-gcc for the virtual machine. After thetransfer, the installation is performed. This tool has beenconfigured in the path /opt/msp430-toolchain/ and newconfiguration is made to Scons toolchain to use thenewly installed compiler.

D. Mote Resident Monitor (MRMv3)

The Mote Resident Monitor, the bootloader used, wasupdated to allow loading of the code for the platformsince the use of a new compiler interfered with somepreconditions considered by the old versions.

The main difference of the new MRM for itspredecessors is the decoding of the files, which are sentin IHEX [20] format, to binary on the platform itself.This allows the code to be loaded from any computerthrough a small serial terminal with data flow controlinstead of a specific program for this task as before.

This modification to code loading simplifies the needsof the programs to be used, however, it does not takeinto account possible errors that may occur whenloading code into the MoteIST platform.

The status diagram in Figure 7 represents the MRMprogram that runs on the platform.

Figure 7: Status diagram representing the flow of the MRM

bootloader.

When the mote is turned on, the first operation thatMRM performs is to copy a preprogrammed interrupttable to a specific zone of RAM.

In this way it is possible to modify what themicrocontroller interprets as interrupt table, from thespace in ROM to the interrupt table just defined in RAMthrough a specialized register of the microcontroller.

After that, the configuration of the clock, theactivation of the CB's power and the configuration ofthe peripherals that will be used in the operation of theMRM are made.

In case MRM receives the program command, it iscalled the IHEX interpreter algorithm in which itremains for an indefinite time until the loadingoperation is finished or a transmission error detected bythe platform occurs.

The flowchart that succinctly represents the actionstaken by this algorithm can be seen in Figure 8.

Figure 8: Flowchart representing the algorithm for decoding the data

loaded in IHEX format.

The main operations performed by the IHEXinterpreter, responsible for decoding the received data,are well defined and are in agreement with the formatdefined by Intel HEX [20].

E. Adapting FreeRTOS for extended mode

The FreeRTOS adaptation to the existingMSP430F5438A in the group repository does notsupport extended mode.

Therefore, to use the protocol stack provided byOpenWSN it is necessary to correct the problem. Inaddition, the existing version in the repository, one ofthe first V7 versions was outdated and as there was

6

already a new V8 version was also decided to upgradethe version of FreeRTOS.

Although an attempt was made to adapt the newFreeRTOS files using the old portable files, a problemwith internal compatibilities of the FreeRTOS did notallow it to be done and another solution had to besearched.

Some more consideration has led to the idea ofadapting the portable files, kept from source by CCS,which are written mostly in Assembly language. Itwould only be necessary to arrange a form of theassembler provided in the msp430-gcc tool to integratethese files into the assembly phase.

A project on the GitHub platform that implementedthis solution was discovered. The compilation using theportable files in the FreeRTOSv8 assembly withmspgcc. Even this adaptation was performed for themicrocontroller used in our platform. The code can beaccessed at github9.

Since FreeRTOS is partially integrated with OpenWSN,as previously mentioned, all that is need to do is add andupdate the FreeRTOS files that were just modified to thecompilation environment.In addition, a project definition has been added in orderto perform the commutation of the compilation inextended mode or in simple mode.

In order to validate the implementation of theOpenWSN project we start by using sample projectsthat are possible to find in the OpenWSN project.

VI. VALIDATION

First we perform a validation of the operation of theprotocol stack used in the OpenWSN project with theminimum possible changes. This implies performing thetests with an original version using the TelosB platformFigure 9.

Figure 9: TelosB Platform.

After this, and in order to prove compatibility withother devices already known to work, such as TelosB,the first test will consist of the use of 5 motes (4MoteIST and 1 Telosb).

A. Test of the adaptation of the OpenWSN project

A MoteIST is connected to the computer and isdefined as the a gateway node. Other MoteIST areconnected to a different computer (for power) and the

9 https://github.com/sbach/msp430-freertos-smartwatch – Jan 2017

TelosB is powered by two AA batteries since thisplatform is already equipped for this purpose.

Regarding the firmware used in the platforms, 3 of theMoteIST are compiled to use FreeRTOS as theOperating System (the gateway node is included) andthe rest use the OpenOS source OS.

In order to complete the configuration, sourceapplications running on the test stack will be used.These applications run at a higher logical levelimmediately following communication protocols andare the highest level of organization in the entireOpenWSN project.

Test source applications are:• cinfo - Provides information about the mote.• cleds - Remotely lets you know and change the

status of one of the LEDs in the motes.• uecho - is an application that responds to the

Internet Control Message Protocol (ICMP)packets. The use of ICMP will be useful fortesting packet latency in the WSN under testfor a variety of conditions that will be testedlater.

In Figure 10 an example of the cinfo application presentin the OpenWSN project. This application uses theConstrained Application Protocol (CoAP) protocol, atthe application layer level, according to the OSI model.

Figure 10: image shows the result of a GET request executed in the

Mozilla Firefox browser using the CoAP Copper application.

a) to the left the MoteISTv5 info b) to the right the Telosb info.

In addition to this application there are features thatallow ICMP ping reply observable in Figure 11.

Figure 11: Command ping6 executed to a mote M16 under test.

Verification that in fact there are 5 motes (4 MoteISTv5and 1 Telosb) and the network routing tree is flatbecause the nodes are within range of each other and no

7

restrictions were applied to their topology is visible inFigure 12.

Figure 12: Natural network routing topology formed by the

OpenWSN protocol.

B. Network configuration

The test network consists of five MoteIST who arearranged on a desk. In this network there is a portalnode that connects to the computer via USB. Forpractical purposes, all nodes are powered through theexisting USB adapter in each

In the configuration of the network it was decided touse a linear topology since this way it allows to runperformance measurements with the worst type possibleof topology for the network.

The test of this type of topology is particularlyimportant in networks with synchronizedcommunication because it allows, among other factors,to test the stability of the network, the propagation ofsynchronism at several distance jumps, measure variousmetrics of the network communication performance inbetween nodes namely latency, reception ratio andtransfer rate.

Figure 13 provides a comprehensive illustration of thetopological configuration used in the test network.

Figure 13: llustration of the topological configuration used in the test

network.

Using the OpenWSN topology.c file it is possible toforce the nodes to only accept packets from the adjacentnodes (in the case of this test), so that packets receivedfrom other nodes are ignored before they reach protocollayers higher than MAC as per Figure 14.

Figure 14: Forced network routing topology.

VI. CONCLUSION

At the beginning of this project the intention was touse and adapt one of the distributed protocol stacksthatcome with the FreeRTOS, but it was quickly realizedthat these protocol stacks did not meet our objectives bynot adapting to communications inside WSN.

The OpenWSN project adapts FreeRTOS to aninnovative protocol stack, IEEE 802.15.4E. Thisprotocol stack is a proposed improvement to the state ofthe art used in WSN, 802.15.4, and has as critical pointsin its improvement the use of TSCH. By allowing theuse of multi-channel in the transmission of informationin the network an increase in the global transfer capacityof the network and the reduction of multipath fading isachieved through the periodic variation of thetransmission channel.

The outstanding differences between the 802.15.4 and802.15.4E protocols are interesting to be explored indepth both in the area of Emergency Detection andResponse and in Industrial Wireless Sensor Networksapplications known as IWSN.

The use of synchronized networks in fact implies theadditional consumption of energy for the maintenanceof the network in the synchronization of thetransmission slots and in the maintenance of the routingmap of the network. In any case it prevents collisionsbetween several nodes that have their state ofemergency activated at the same instant. Since meshnetworks have at least one gateway and where wirelessactivity is higher, multiple portal nodes can be used toextend the network lifespan, which is foreseen in theIEEE 802.15.4E protocol but which is not yet beenimplemented in the OpenStack protocol stack.

To finish the defined protocol IEEE 802.15.4E can besaid that it is not yet mature and many times problemsare encountered in its execution.

In the implementation of FreeRTOS there is still roomfor improvement. By adapting FreeRTOS to theprotocol stack, many of the features provided by the OSsuch as queues, timers and true parallelization, have

8

been deprecated. Instead, OpenWSN adds somehowOpenOS as an overhead to FreeRTOS only takingadvantage of the interruption of tasks, scheduling andreplacement of running tasks with higher priority ones.

In the implementation of the new MRM3 the ease ofloading code in IHEX format is an asset because itallows to use a generic serial communication tool toinstall the application.

In the course of developing this project I contributedwith the implementation of:

• The adaptation of the OpenWSN project to theMoteIST platform.

• The update of the source code of FreeRTOS tobe used in this project, and is also useful infuture projects carried out by the students ofthe group.

• The possibility of compiling code in extendedmode in order to be able to use all the ROMexisting in the msp430f5438a microcontroller.

• The update of the virtual machine used by thegroup with the new build environment installedand configured.

• The modification of MRM to allow loadingcode in IHEX format directly from a serialterminal with data flow control in software,eliminating the need to use specific software tocarry out this operation.

B. Future Work

The original intent of this thesis was to compare theperformance of the new IEEE 802.15.4E protocol withthe original IEEE 802.15.4 version implemented inother existing projects such as TinyOS and Contiki,where the main difference is that the latter do not use anOS of real time.

In the case of MRM3 there is an opportunity toimprove the reliability of this bootloader using amulti-image loading system. Knowing that in theMoteIST platform there is a non-volatile external flashit would be interesting to modify the MRM3 to recordimages and upload images from it. In addition the use ofgeneric channels for loading the image using themicrocontroller's source bootloader is an improvementto take into consideration in the construction anddevelopment of a next platform

REFERENCES

[1] http://openwsn.com/ - Accessed a 07/10/2016[2] J. M. de C. C. Teixeira, “MoteIST ++ A Hardware

Platform for Wireless Sensor Networks,” InstitutoSuperior Técnico – Technical University of Lisbon,2009.

[3] T. X. Furtado, “ActiveTSN - Actuation on theTagus Sensor Net,” Instituto Superior Técnico –Technical University of Lisbon, 2013.

[4] D. Sharma, S. Verma, and K. Sharma, “NetworkTopologies in Wireless Sensor Networks : A Review,”International Journal of Electronics & CommunicationTechnology, vol. 7109, 2013.

[5] A. Bayo, D. Antolín, N. Medrano, B. Calvo, and S.Celma, “Early detection and monitoring of forest firewith a wireless sensor network system,” Procedia Eng.,vol. 5, pp. 248–251, 2010.

[6] R. M. Allen, H. Brown, M. Hellweg, O.Khainovski, P. Lombard, and D. Neuhauser, “Real-timeearthquake detection and hazard assessment by ElarmSacross California,” Geophysical Research Letters, vol.36, pp. 1–6, 2009.

[7] A. S. Tanenbaum, C. Gamage, and B. Crispo,“Taking sensor networks from the lab to the jungle,”Computer (Long. Beach. Calif)., vol. 39, no. 8, pp.98-100, 2006.

[8] A. Somov, A. Baranov, D. Spirjakin, A. Spirjakin,V. Sleptsov, and R. Passerone, “Deployment andevaluation of a wireless sensor network for methaneleak detection,” Sensors Actuators A Phys., vol. 202, pp.217–225, Nov. 2013.

[9] IEEE Computer Society, “802.15.4: Low-RateWireless Personal Area Networks (LR-WPANs),”September. 2011.

[10] R. Valli and P. Dananjayan, “Power Control withQoS constraints in WSN using Game TheoreticApproach,” no. Julho, 2012.

[11] R. M. R. Rocha, “Wireless Sensor Networks -Networks Architecture.” Instituto Superior Técnico –Technical University of Lisbon, 2006.

[12] J. M. D. de A. R. Soares, “CHARON :Convergent Hybrid-Replication Approach to Routing inOpportunistic Networks - Efficient Collection Routingfor Low-Density Mobile WSNs,” Instituto SuperiorTécnico -Technical University of Lisbon, 2009.

[13] E. Baccelli, O. Hahm, W. Matthias, and T. C.Schmidt, “RIOT OS : Towards an OS for the Internet ofThings,” The 32nd IEEE International Conference onComputer Communications, pp. 79–80, 2013.

[14] E. Baccelli and O. Hahm, “RIOT : One OS toRule Them All in the IoT,”, RR-8176, INRIA. 2012.

[15] B. C. Söllner, “Comparison of Operating SystemsTinyOS and Contiki,” no. August, pp. 7–13, 2012.

[16] A. Eswaran, A. Rowe, and R. Rajkumar, “Nano-RK: An Energy-Aware Resource-Centric RTOS forSensor Networks,” 26th IEEE Int. Real-Time Syst.Symp., pp. 256–265, 2005.

[17] S. Raman, “TinyOS – An Operating System forTiny Embedded Networked Sensors,” 2002.

[18] IEEE Computer Society, “IEEE Standard forLocal and metropolitan area networks – Part 15.4:Low-Rate Wireless Personal Area Networks(LR-WPANs) Amendment 1: MAC sublayer”, IEEE Std802.15.4e, Amendment April 2012, pp 17, 2011.

[19] Texas Instruments, "MSP430x5xx andMSP430x6xx Family", Reference SLAU208N, RevMay 2014, June 2008.

9

[20] Intel, “Hexadecimal Object File FormatSpecification.” pp. 1–10, Rev A, January 6, 1988.

10