Real-time applications in Wireless Sensor Networks

Paolo Pagano, Mangesh Chitnis, and Giuseppe LipariRetis Lab, Scuola Superiore SantAnna, Pisa (I)

December 1, 2007

Abstract

Wireless Sensor Networks (WSNs) technology is used mainly inenvironmental monitoring applications, which require low-frequency

sampling and little computational complexity. Recently, new classes ofapplications with different characteristics are being considered, includingprocess control, industrial automation, surveillance, multimedia streaming.

Such applications may present real-time requirements as boundedend-to-end delay and guaranteed Quality of Service. It becomes thennecessary to use proper resource management policies, and perform a

detailed off-line analysis of the behavior of the system.Simulation can play a key role, together with analytical models, for

validating a system against the parameters ofQuality of Service it must respond of.

In this report, we present RTNS, a publicly available free tool to simulateOperating System aspects in wireless distributed applications; it extendsthe weel-known NS-2 simulator with models of the CPU, the RTOS andthe application tasks, to take into account delays due to the computation.RTNS can be used to effciently co-design the kernel and network profiles

before deployment, especially when the number of nodes is

Contents

1 Motivations 2

1.1 Introduction (da riscrivere) . . . . . . . . . . . . . . . . . . . 21.2 RTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 RTNS and the IEEE802.15.4 standard . . . . . . . . . . . . . 51.4 Messaging constructs in RTNS . . . . . . . . . . . . . . . . . 7

2 Installation 9

2.1 Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Sample scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Fetch and Forward . . . . . . . . . . . . . . . . . . . . 122.3.3 Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Work in progress . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Limits 15

3.1 Scaling properties . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Case study 17

4.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Reliability of RTNS and test suite 19

5.1 The Operating System . . . . . . . . . . . . . . . . . . . . . . 195.2 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . 205.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3.1 Simulated data . . . . . . . . . . . . . . . . . . . . . . 225.3.2 Real data . . . . . . . . . . . . . . . . . . . . . . . . . 23

Bibliography 25

1

Chapter 1

Motivations

1.1 Introduction

Wireless Sensor Networks (WSNs) were initially proposed in domains whereordinary networks (not necessarily wired) are not convenient, either becauseof the missing infrastuctures, or when numerous nodes (in the order of hun-dreds) are needed to achieve the assigned task. Examples of such domainsare military applications (like quickly sensorizing a large un-known area)and environmental monitoring.

These early systems (which we might call first generation) consist of aset of battery-powered nodes, typically programmed in a homogeneous way(they run the same program), having self-organizing capabilities to achievethe communication and cooperation interactions required by distributed ap-plications of monitoring and control. Sensor nodes are manufactured withextremely low-cost a small size technology. They integrate a microcontroller,a radiofrequency transmitting device, a set of sensors and a limited amountof memory (static and dynamic).

The main stream of the research has focused on MAC optimizationto minimize energy consumption, generally dominated by communicationtasks, so to improve on the lifetime of the devices between battery replace-ments; on the other hand, research topics related to resource managementand CPU scheduling have been marginally discussed.

Today a second generation of WSNs are being considered for indus-trial automation (e.g. process control in assembly areas), multimedia (e.g.telemedicine, intrusion detection systems), health care (e.g. emergency pro-tocols, disaster response, and stroke patient rehabilitation), etc.

On the nodes manufacturers side, richer devices embedding 16 and 32-bits CPUs and larger sets of programmable and dynamic memories to sup-port more complex applications are today on the market. In such applica-tions a robust Real-Time Operating System (RTOS) providing customizablescheduling policies (for multi-tasking operation) and reliable services, rang-

2

ing from networking to peripheral management, is needed.Large industrial and academic collaborations, such as the RI-MACS

project (RIM, n.d.), focus on increasing reconfigurability and adaptivenessof industrial automation platforms by using WSNs in selected cases.

The profile of these networked distributed systems is substantially dif-ferent from those of other domains of WSNs: in addition to requirements forincreased robustness and fault tolerance, each node is expected to performa substantial amount of computation such that related to data filtering,actuation, diagnostic, logging, communication, etc. In practice, the compu-tational load on each node (in terms of amount of processing time needed bythe application tasks) may become relevant. In addition, such applicationsexhibit real-time constraints, sometimes hard real-time ones. Late sensormessages may not be considered acceptable. Many activities, like samplingand actuation, must be triggered periodically and executed within boundeddelays, otherwise the system may not work properly.

Figure 1.1: Activities, like sampling and actuation, are triggered periodicallyand executed within bounded delays. An event-triggered activity may delaythem causing a system malfunction.

A real-time schedulability analysis must be performed to guarantee thatthe system will work properly under worst-case load conditions.

1.2 RTNS

Together with off-line mathematical tools assessing the schedulability issue,simulation plays a crucial role especially for large and complex systems withhundreds of nodes.

To the authors knowledge, the packages providing a joint model of thenode (including the Operating System mechanisms) and of the network arerare examples (Cervin et al., 2007).

We wanted to bridge the gap between the network and Operating System

3

simulators proposing a software package permitting a more reliable devel-opment of distributed sensor systems (e.g. supporting the IEEE 802.15.4standard) for rapid prototyping.

Thus we propose the Real Time Network Simulator (RTNS), a sim-ulation suite to model operating system mechanisms for distributed net-worked applications, built by integrating the popular NS-2 (Network Sim-ulator (NS2, n.d.)) and RTSim (Real Time operating system SIMulator)packages.

In discrete event simulation, the operation of a system is represented asa chronological sequence of events. Each event occurs at an instant in timeand marks a change of state in the system(Robinson, 2004).

Discrete event simulators are usually implemented making use of a re-sizeable event queue where to post and pop events for appropriate process-ing. For instance time-triggered activities regularly post expiration eventsinto the queue to produce a periodic sequence of actions.

The queue is re-ordered at every post to always keep the closest event infront; the physical notion of time is discretized and increases by the intervalbetween the two latest expirations at every pop.

Both NS-2 and RTSim are discrete event simulators, thus they use theirown queues to ensure a chronological sequence of events.

We decided to keep the NS-2 event scheduler as the main engine, andmake the RTSim engine as its sub-engine. We defined a special event inNS-2 called the synchro event, that takes care of processing all events ofRTSim that happen at a single point in time as shown in Figure 1.2.

Figure 1.2: Synchronization of the NS-2 and RTSim schedulers. In theRTSim scheduler there are events at time 5, 11, 15; the co-simulator enginepushes into the NS-2 scheduler synchro events at these time instants toprocess all corresponding RTSim events at appropriate NS-2 time.

4

This design solution:

allows to consume time for the intra-node activities not related tothe network stack operations and ignored by the standalone NS-2 pack-age;

makes RTNS be seen by the end users as an extension of the NS-2platform, allowing full compatibility with existing functionalities.

In Figure 1.3, an example for the usage of the NS-2 API to configurea wireless sensor node is shown, remarking the correspondance with theISO/OSI model of the network stack.

Figure 1.3: An example for the configuration of a wireless sensor node com-pliant to the IEEE 802.15.4 standard. The parameters of the NS-2 API (inTCL scripting language) follow the color scheme of the figure on the right:in Orange the Radio Propagation Model, Channel, and Antenna specifica-tions, in Blue the Physical layer, in Green the MAC layer, in Purple the ifQtype and dimensioning, in Red the Routing protocol.

To enrich the simulation by all the mechanisms induced by the OS, inRTNS the node is equipped by a scheduler that, following a (real-time)policy, interleaves the tasks related to computation (intra-node activities)with those related to networking (extra-node activities).

NS-2 front-end (the TCL scripting) has been extended providing a set ofAPIs permitting to set the CPU clock, the number of running tasks, and theutilization factor; the tasks execute a customizable instruction set bookingthe CPU for a fixed or random (statistically distributed) number of clockticks.

1.3 RTNS and the IEEE802.15.4 standard

RTNS has been tested in simple and complex topologies both in beacon

5

The most popular protocol for MAC andPhysical layers for communications in WSNis IEEE 802.15.4. It has been standardizedby IEEE in year 2003 and provides an easy-to-implement, low cost, energy aware suiteof protocols for short range and low ratecommunications.It comprises:

diversified topologies ranging fromsimple star to multi-hop scenarios astrees and connected clusters;

two profiles of nodes (Reduced andFull Functional Devices), dependingon their resource sets;

two types of nodes (Coordinatorsand Devices) dependent on the rolethey play in the network;

pure CSMA/CA or beacon struc-tured communication frame;

different frame formats depending onthe communication subject.

Figure 1.4: The IEEE802.15.4 standard for Wireless Personal Networks.

and in non-beacon mode of IEEE802.15.4 standard, briefly described inFigure 1.4.

Unfortunately the NS-2 support for WSNs does not include the simula-tion of the Collision Free Period (CFP), a portion of the superframe com-posed by Granted Time Slots (GTS) assigned by the WPAN coordinatorto individual nodes for exclusive use; the simulated access to the mediumhas thus followed the CSMA/CA mechanism foreseen in the standard fornon-exclusive access and is in general not suited for real-time applications.

Though, by definition, this limits the impact of RTNS in the domain ofthe second generation WSNs, it follows the attitude of vendors who usu-ally dont implement such functionalities in the commercial network stackprovided with micro-controllers equipped with radio transceivers.

Because of the above limitation, RTNS can be efficiently used for mea-suring selected parameters of Quality of Service (e.g. mean and maximumlatency in sending and receiving messages, packet loss yield, etc.) ratherthan for proving the hard real-time reliability of a distributed system.

RTNS can be used to test a possible layout or to validate a design choice,i.e.:

its possible to calculate the Quality Of Service reachable with a givenset-up, kernel structure, network and load conditions;

6

its possible to select a working profile for the node (setting the pa-rameters related to OS and Network activities) depending on the QoSrequested by the application.

Figure 1.5: An example for setting up a 8 MHz CPU running an OS withFCFS scheduling policy and a task set generating a computational load of0.2. The parameters of the RTNS API (in TCL scripting language) follow thecolor scheme of the figure on the left: in Green the RTSim scheduler instancecustomed for the CPU speed, in Purple the NS-2 networking protocol, inBlue the OS abstraction with the scheduler in Red, in Orange the Task Setgenerating the load.

1.4 Messaging constructs in RTNS

Whenever it is requested from the TCL script, the simulator creates aninstance of RT-App which is attached to an NS-2 Agent (RT-Agent) to sendand receive data packets (see Figure 1.5). The RT-App creates aperiodictasks for Send, Receive, and for Routing purposes and schedules themadopting one of the policies implemented in RTSim (as FCFS, EDF, FP,etc.).

These tasks get blocked as soon as they are spawned and remain inthe block state waiting for an event corresponding to send or receive of adata packet. Whenever they are activated by means of external interruptsthey enter the ready queue together with already existing computational(dummy) tasks introduced to create a tunable load within the CPU. TheOperating System puts these tasks into the Running status following theadopted scheduling policy selected at the time when RT-App is instantiated.

Because of the adopted scheduling algorithm, the tasks can be delayedby some time from the activation. In a scheduler based on activation times,the tasks are queued up and executed in FCFS order (as shown in Figure

7

1.6 for the Receive task); in such a case, the user is not asked to specify apriority and the delays are strongly dependent on the load of the node.

R

start timer stop timer

trace the delayin the log file

packet arrivalnotification by MAC

T

T

activationreceive blocked

Figure 1.6: Concurrent execution of computational () and receive (R)tasks in case of FCFS policy.

In case of a priority-based scheduler the preemption of the CPU dependson the difference in priority between the running task and the one which hasbeen suddenly activated. In our studies, we will adopt FP scheduling andassign to network tasks (Send and Receive) higher priority with respect tothe others (as shown in Figure 1.7 for the Receive task). This solution worksonly as matter of example (of a case limit) since in the real world there maybe computational tasks more important than networking and a finer tuningto set the priorities is required.

R

T

stop timerstart timer

trace the delayin the log file

packet arrivalnotification by MAC

T

activationreceive blocked

preemption

Figure 1.7: Concurrent execution of computational () and receive (R)tasks in case of FP policy, assigning to R a priority higher than to .

8

Chapter 2

Installation

2.1 Download

The packages needed for the complete installation are provided in the tar-balls you can download from the WEB and consist of:

NS-2 version 2.29 (slightly modified);

RTNS realtime package in NS-2;

RTSim version 1.0 (slightly modified);

ROOT version 5.11 (for Cygwin) or 5.12 (for Linux).

The Cygwin environment does not require any add-up.For the Linux installation, we do not validate every distribution and we referto the latest (7.04) Ubuntu. The standard CD installation you find on theweb (http://www.ubuntu.com/getubuntu/download) requires a few morepackages listed hereby:

tcl8.4 (8.4.14-0ubuntu1)

tcl8.4-dev (8.4.14-0ubuntu1)

tk8.4 (8.4.14-0ubuntu2)

tk8.4-dev (8.4.14-0ubuntu2)

x-dev (7.0.10-1)

libxpm-dev (1:3.5.6-1)

xlibs-dev (1:7.2-0ubuntu11)

9

2.2 Validation

Follow the instructions you find on the Web in Section Installation. If installscript succeeded, you can check if RTNS properly works going to /tcl/ex/realtime/base and typing:

$ ns forRTApp.tclThis process will produce the following output in the filesystem:

forRTApp.trc (NS-2 tracefile);

forRTApp.res (RTNS tracefile);

forRTApp.nam (NAM tracefile);

forRTApp.root (ROOT histogram collection);

and the printouts on the standard error shown in Figure 2.1.

Figure 2.1: NS-2 output of base script.

10

2.3 Sample scripts

In table 2.1, a list of sample scripts for RTNS is reported. Each exampleis based on a script you can find in the subdirectories of /tcl/ex/realtime/. The examples will be discussed in the next sessions.

Directory name Synopsis MultiHop Comments

cluster ns cluster.tcl -load N Star Topology,Tunable load on the sink

fetch and forward ns fetch and forward.tcl Y Clustered Topology,-load Tunable load on the gateway

tree ns tree.tcl -load1 Y Tree Topology,-load2 effect of node failure

Table 2.1: Sample scenarios for RTNS.

2.3.1 Cluster

In Cluster the simulation is about a start topology. Namely four nodeslocated at the edges of a square concurrently communicate with a sink,placed in the center of mass as shown in Figure 2.2. Its possible to simulatecomputational activity (generating tasks running on each CPU) to delayend-to-end communications.

0

4

2

1

3

Figure 2.2: Cluster scenario. Concurrent communications directed to thesink.

In the end of the tcl script, ROOT analysis platform is spawned execut-ing cluster.C script and producing (as an example of selected metric) thedistribution of time delay introduced by OS to message reception in the sink(see Figure 2.3, displaying the content of cluster.pdf).

11

MessageID200 400 600 800 1000 1200 1400 1600 1800

T

(s)

0

0.01

0.02

0.03

0.04

0.05

0.06

Time delay jitter in message reception recEntries 2000Mean 1025RMS 562.5

Time delay jitter in message reception

Figure 2.3: Cluster scenario. OS-induced delay in message reception in-fluenced by computational load. In this example the load on the sink is0.7.

2.3.2 Fetch and Forward

In Fetch and Forward the simulation is about a connected-cluster topology.Namely two nodes want to deliver data messages upwards making use of therouting service offered by the gateway as shown in Figure 2.4. Its possibleto simulate computational activity (generating tasks running on the CPUof the gateway) to delay message routing.

0 1

2

3

Figure 2.4: fetch and forward scenario. Communications are routed by thegateway.

In the end of the tcl script, ROOT analysis platform is spawned ex-ecuting fetch and forward.C script and producing (as an example of se-lected metric) the distribution of network propagation time delay intro-duced by the load in the gateway (see Figure 2.5, displaying the content offetch and forward.pdf).

12

MessageID200 400 600 800 1000 1200 1400 1600 1800

T

(s)

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2Network propagation time recnet

Entries 998Mean 450.4RMS 317

Network propagation time

Figure 2.5: Fetch and Forward scenario. Network propagation time is influ-enced by the computational load in the gateway. In this example the loadon the gateway is 0.7.

2.3.3 Tree

In Tree the simulation is about a tree topology. The CBR traffic is directedfrom node 1 to node 10 as shown in Figure 2.6. Its possible to simulate abreakdown and follow what happens if an alternate route is computed byAODV protocol.

0

1

3

2

4 5

6 7 8 9 10

Figure 2.6: Tree scenario. Effect of node failures.

In the end of the tcl script, ROOT analysis platform is spawned exe-cuting tree.C script and producing (as an example of selected metric) thedistribution of network propagation time delay. This delay is influenced bythe load along the two routing paths followed by the packets before andafter the link between node 1 and nodes 0 and 2 break down. Figure 2.7displays a superimposition of histograms (as the content of tree.pdf) relatedto a load jump of 0.5, 0.6, 0.9, 0.99.

13

message ID0 200 400 600 800 1000 1200 1400 1600 1800

T

(s)

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

Network propagation time

0.99 (red)

0.90 (green)

0.60 (yellow)

0.50 (purple)

Figure 2.7: Tree scenario. Network propagation time is influenced by thecomputational load found along the routing path. In this example, after afailure, the load jump assumes the values of 0.5, 0.6, 0.9, 0.99 and thepropagation time correspondly increases.

2.4 Work in progress

AODV-Aware is a modified implementation of AODV routing protocol be-ing developed at Scuola Superiore SantAnna. The modified protocol buildsthe routes up in order to minimize the end to end delay suffered in packettransmission in multi-hop scenarios. In order to take into account the com-putational load in the network, the protocol makes use of such informationstored in a distributed DB let be available through a middleware service. Bymeans of AODV-Aware, we can minimize the step due to the failure shownin Figure 2.7, by selecting the path with minimum cumulated load in theintermediate nodes.AODV-Aware will be distributed with the forthcoming releases of RTNS.

14

Chapter 3

Limits

3.1 Scaling properties

The usage of RTNS of course requires more resources concerning disk space,memory, and time overhead with respect to NS-2. The tarball size is ofthe order of 150 MBytes and includes the components required by the tool:ROOT(Brun and Rademakers, n.d.), Metasim and RTlib(Palopoli, L. et al.,2002) are external packages (free sources) which must be linked at compiletime.

The NS-2 package is widely adopted in the telecommunication worldbecause of its remarkable scalability; this virtue and the recent support ofIEEE802.15.4 wireless communication standard permit to simulate denseWireless Sensor Networks where hundreds of nodes are interconnected.

The overhead induced by the Operating System simulation on one handenlarges the time needed to simulate the network operations, on the otherhand may limit in number the nodes composing the network.

N

NColomns

RowsRoutingPathCommRange

Figure 3.1: Lattice like scenario with the two opposite nodes on the diagonalwilling to exchange data. The total number of nodes, figure relevant for thescalability of the package is a parameter in the simulation.

15

Referring to the scenario in Figure 3.1 where the two furthest nodes alongthe diagonal in a rectangular lattice are exchanging data, we measured thesimulation time supposing a uniform CPU occupancy in the nodes equalto 50%. The network is operated in non-beacon mode as defined in theIEEE802.15.4 standard for a peer-to-peer communication paradigm.

# of nodes0 50 100 150 200 250 300 350 400 450

exec

utio

n tim

e [s]

1

10

210

With RTSim OS

Without RTSim OS

Figure 3.2: Execution time as a function of the total number of nodes forstandalone NS-2 and RTNS.

As shown in Figure 3.2, NS-2 and RTNS show a similar trend in thesimulation time as a function of the total number of nodes in the lattice, thetwo curves being displaced along Y by a fixed amount.

# of Nodes0 500 1000 1500 2000 2500

%

of M

emor

y Ut

iliza

tion

10

20

30

40

50

60

70

80

90

RTNS

standalone NS-2

Memory Utilization vs Number of Nodes

Figure 3.3: RAM maximum usage of NS-2 and RTNS as a function of thetotal number of nodes.

The RAM footprint increases linerarly as a function of the number ofnodes as it is expected from the linear increase in the RTNS objects (kernels,schedulers, tasks, etc.). The plot in Figure 3.3 demonstrates this lineardependence showing that the difference with standalone NS-2 relies only inthe slope of the two lines with no big memory leak detected.

16

Chapter 4

Case study

4.1 Scenario

To evaluate the performances related to the Operating System in the contextof fire monitoring we refer to wide, square shaped (2500 m side) network asthe one depicted in Figure 4.1.

50 Colomns

T

fire position

Rows

RoutingPathCommRange

5070 m

Figure 4.1: A 2500 nodes WSN, the value of the temperature (exponentiallydistributed) is related to the computational load in the devices. The routingpath is calculated by AODV agent and the red line is shown only as a matterof example.

We imagine to relate computing activity to the value of the sensed phys-ical observable (e.g. temperature) and distribute it following an exponentialcurve. The exponential factor is such that the temperature sharply dropsin a few hops from the location of the maximum. This model can representthe extension of the fire in an early stage.

In our envisioning the nodes might be equipped by cameras and imageacquisition is triggered whenever the temperature crosses some threshold inorder to detect human presence in the area.

17

We locate the sink at the bottom-right edge of the square and we simulatethe end-to-end communication displacing the center of the fire along thediagonal.

We make use of the RTNS capabilities and take into account the effectof computational load in the forwarding activity of the intermediate nodes.

We demonstrate that a correct scheduling policy must be implementedin order to have a prompt reaction of the safety system.

4.2 Results

We measured the end-to-end transmission time of a fire-detected messageas a function of the position of the fire along the diagonal of the square.

Obviously, the longer the distance, the longer the delay either adoptingFCFS or FP schedulers as shown in 4.2.

Distance (# of hops)0 500 1000 1500 2000 2500

Del

ay (s

)

0

1

2

3

4

5

FCFS scheduling

FP scheduling

End to End Transmission Time vs Distance from Fire Center

Figure 4.2: Simulated end-to-end transmission time as a function of the fireposition along the diagonal.

Nevetherless the overhead induced by the Operating System to route thealarm packet along the diagonal is kept under control using a real-timescheduling policy such as FP whereas in case of FCFS scheduling the meanvalue can approach several seconds.

The maximum delay has a less monotonic trend, being more affected byoccasional collisions: figures up to 20 s have been extracted from simulationat the maximum extension of the routing path.

Apart from numerical evaluation (which is actually very dependent onAd-hoc Routing settings), the trend demonstrates the reliability of a real-time kernel to trigger a prompt reaction in the safety system.

18

Chapter 5

Reliability of RTNS and test

suite

To demonstrate the reliability of our simulator we compare simulated andreal data coming from a simple star shaped WSN.

Of course the test bed is very far from the case study proposed in chapter4, but the results are encouraging and we plan to perform a large scaleexperiment soon.

5.1 The Operating System

We adopted a real-time kernel especially suited for micro-controllers: ERIKAEnterprise (EE) commercialized by Evidence srl.

EE consists of a single and multi-processor real-time OS kernel imple-menting a collection of APIs similar to those of OSEK/VDX standard forautomotive embedded controllers. It implements a shared memory modelfor a layered architecture composed by a substrate Kernel acting on a Hard-ware Abstraction Layer (HAL) dependent on the specific platform. A setof software modules implements the task management and the schedulingpolicy.

It is well suited to respond to the stringent pre-requisites of WirelessSensor Networks, because of:

the minimal footprint in terms of RAM (about 3 KBytes), partiallydependent on the hardware platform and the adopted configuration;

the hard real-time compliance, because it complements FP schedul-ing providing support for Immediate Priority Ceiling and PreemptionThresholds on single CPU systems;

19

the supported Atmel AVR 5 architecture1, very popular in WSN con-texts;

the application layer customizable to fit diversified scenarios whereWSN are deployed.

To implement the Network Stack substrate we adapted the libraries pro-vided by Atmel(ATM, n.d.) and compliant with the IEEE 802.15.4 standard.The Atmel set of functions, organized as a network library, have been linkedto ERIKA core.

Conditional compilation is used to customize the cases of ordinary de-vices and Personal Area Network (PAN) coordinator.

The network initialization is organized by means of an aperiodic task:on the coordinator side, such a task establishes a new network, sets thecommunication mode (peer-to-peer or beacon mode, single or multiple clus-ter, etc.), and runs the negotiation for device association (until the devicesare registered in the PAN Information Base, PIB); on the device side, thetask activity goes through the association negotiation stage, ending whenthe device is registered in the PIB.

Following the fixed priority scheduling policy implemented in EE, theconcurrent execution of computational and network tasks is dependent onthe priority assigned at configuration time to each of them. Flattening thepriorities of all the tasks, the scheduling policy reduces to FCFS (the oneadopted in the popular TinyOS operating system).

5.2 Experimental setup

In our set-up we used the Atmel STK-500/501 development board equippedwith Atmega 128 CPU platform and AT86RF230 2.4 GHz transceiver.

We program the micro-controller through a JTag ICE mkII debuggermaking use of the facilities offered by the AVR-STUDIO IDE.

We want to measure the OS-induced delays in packet reception in anexperimental setup matching the one in Figure 2.2. The resulting real hard-ware network is depicted in Figure 5.2.

Four clients generate CBR traffic towards the WPAN coordinator at 15Hz rate; the latter is connected to a PC through a serial line. On the PC aserver is running the Data AcQuisition (DAQ).

In the initiating devices, two tasks are managed by ERIKA in FP: thenet task taking care of the operations related to the Network Stack and thesend task (with maximum priority) assuring a coherent trigger of periodictransmissions.

1To the best of the authors knowledge, in so far only a few Operating Systems have

been ported to AVR 5 architecture; namely Nano-RK, TinyOS and recently ERIKA.

20

Figure 5.1: The testing kit for Atmel ATMEGA 128 used in the experiment.The micro-controller is mounted on the STK-500/501 development boardand use the AT86RF230 2.4 GHz transceiver peripheral.

In the recipient device, we modeled the activity of the WPAN coordinatorwith two tasks managed either using FCFS or FP: the net task and the loadtask modeling the computational activity.

In the Atmega 128 microcontroller, the hardware interrupts raisen by theAT86RF230 transceiver are mapped to the entry 11 of the interrupt vector.The Interrupt Service Routine (ISR) installed at that address in memory isthe one of the Physical layer of the network library. The micro-controllerexecutes such code at the arrival of a data frame.

For the recipient node, we modified the ISR introducing some lines ofcode to get the packet arrival time. Whenever the net task goes into execu-tion, it receives the packet, calculates the delay induced by the OS activity,merge these information into a message sent to the serial line by means ofthe Universal Asynchronous Receiver/Transmitter (UART).

As already mentioned, the computational activity task is modeled by theload task; its periodic (activated every 70 ms) and is tuned keeping fixedthe period (T) and varying the Execution Time (ET). Variations in ET areobtained enlarging or reducing the body code of the thread.

Assuming a limited impact of the net (for to the limited number of nodesand the absence of transmissions triggered by the application layer) task, agood estimator for the Utilization Factor is:

21

Figure 5.2: The experimental setup used for real hardware testing.

U = Uload + Unet Uload =ETload

Tload

The delay is measured through a hardware timer whose values are takenat the arrival of a data frame during the immediate execution of the ISRand at the end of the MAC call-back function ending the receive procedure.

During the communication between the nodes, the DAQ is taking traceof the incoming messages in a file-oriented fashion where each file is relatedto a specific load and priority setting for the tasks in the recipient node.

5.3 Results

5.3.1 Simulated data

We collected simulated data as in the example shown for the receive taskwithin the sink in Figure 5.3. The figure refers to a node adopting FCFSscheduling policy and having Utilization Factor (U) equal to 0.7: the delayin reception is plotted as a function of the transmission number. The globaldelay and the components coming from the 4 transmitting nodes are in thesame figure.

The average value is usually small (at moderate load) and refers to thearrival of the packet during the execution of the net task.

The peaks refer to the arrivals of data packets immediately after theactivation of the load task. Having set the CBR interval to 70 ms (slightlymore than 65 ms, period of the load task), the packet arrival intersect theload task later and later thus being delayed less and less.

We let U vary from 0 (empty body of the load thread) to 1 (ETload =Tload). At every value of U we performed 10 runs (different in the simulationseeds) composed by 500 messages.

22

Message ID0 10 20 30 40 50 60 70

Del

ay (s

)

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045 Node 0Node 1Node 2Node 3

Figure 5.3: Delay as a function of message number.

In Figure 5.4 the maximum delay (quoted in seconds) is shown as afunction of U. A linear dependence of the delay on the load adopting theFCFS module is observed. As expected the delay is insensitive to the loadin case of FP.

Utilization Factor0.2 0.4 0.6 0.8 1

Del

ay (s

)

-0.01

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

Message Delay in Packet Reception

FCFS

FP

Figure 5.4: Simulated delay in Packet reception as a function of the Com-putational Load in the sink.

5.3.2 Real data

We used the real hardware setup described in Section 5.2. Intervening onthe load task ET we did a scan in the Utilization Factor ranging from 0 to1 getting the maximum delay observed in data exchange.

The trends of the delays for the cases of FCFS and FP scheduling policiesare conform to the simulated data.

The results in Figure 5.5 show that FCFS is inadequate to medium-high

23

computational activity whenever the network is required to provide certainparameters of QoS.

Utilization Factor

0 0.2 0.4 0.6 0.8 1

Dela

y (s)

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

Message Delay in Packet Reception

Figure 5.5: Measured delay in Packet reception as a function of the Com-putational Load in the sink.

24

Bibliography

ATM (n.d.). Atmel Corporation.. http://www.atmel.com.

Brun, Rene and Fons Rademakers (n.d.). ROOT. An Object Oriented DataAnalysis Framework.. http://root.cern.ch.

Cervin, Anton, Martin Ohlin and Dan Henriksson (2007). Simulation ofnetworked control systems using TrueTime. In: Proc. 3rd InternationalWorkshop on Networked Control Systems: Tolerant to Faults. Nancy,France. Invited talk.

NS2 (n.d.). Information Sciences Institute (University of Southern Cali-fornia, Los Angeles CA, USA), The Network Simulator NS-2.. http://www.isi.edu/nsnam/ns/.

Palopoli, L. et al. (2002). An object oriented tool for simulating distributedreal-time control systems. Software: Practice and Experience.

RIM (n.d.). The RI-MACS EU project (NMP2-CT-2005-016938). http://www.rimacs.org.

Robinson, Stewart (2004). Simulation - The practice of model developmentand use.. Wiley.

25