EAI Endorsed Transactions - EUDL

MobiLab: A Testbed for Evaluating MobilityManagement Protocols in Wireless Sensor NetworksJianjun Wen, Zeeshan Ansar, Waltenegus Dargie∗

Chair for Computer Networks, Faculty of Computer Science, Technical University of Dresden, 01062 Dresden,Germany

Abstract

Wireless sensor networks that support the mobility of nodes are finding applications in different areas such ashealthcare, elderly care, and rehabilitation from total knee and hip replacement. However, these applicationareas also require reliable and high throughput networks. Considering the high fluctuation of link qualityduring mobility, protocols supporting mobile wireless sensor nodes should be rigorously tested to ensure thatthey produce predictable outcomes. In this paper we present a wireless sensor network testbed for carryingout repeated and reproducible experiments, independent of the application or protocol types which shouldbe tested. The testbed consists of, among others, a server side control station and a client side traffic flowcontroller which coordinate inter- and intra-experiment activities. We fully implemented the testbed for theTinyOS and TelosB platforms. We employed Diddyborg robots for emulating different types of movement inindoor and outdoor environments. The paper includes also an extensive evaluation of the testbed and theperformance of two mobility-aware MAC protocols.

Received on 17 November 2016; accepted on 6 July 2017; published on 21 December 2017Keywords: Testbed, handover, mobility management, wireless sensor networks, mobile

Copyright © 2016 Jianjun Wen et al., licensed to EAI. This is an open access article distributed under the terms of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/), which permits unlimited use, distribution and reproduction in any medium so long as the original work is properly cited.

doi:10.4108/eai.21-12-2017.153504

1. IntroductionWireless sensor networks which support the mobility ofnodes are useful for different applications. For example,in the healthcare domain, they have been proposed tomonitor patients with Parkinson Disease[1], gastropare-sis [2], epilepsy [3], and asthma [4]. As a result, thereis an endeavour to integrate medical devices and makethem interact with existing wireless sensor platforms.For instance, the wireless mobility capsule integratingpH, pressure, and temperature sensors for the diagnosisof gastroparesis1 has officially been approved by theUS drug and food administration since 2006; it has

*Corresponding author. Email: [email protected] is a condition in which the contraction of muscles

in the stomach or intestine do not function properly, preventing thenormal emptying of food in these organs. There can be many causesto gastroparesis such as uncontrolled diabetes, Parkinson Disease,multiple sclerosis, deposits of protein fibres in tissues and organs,and medicaments involving narcotics and antidepressants, but theprimary cause is a damage to the vagus nerve, which regulates thedigestive system. Its typical symptoms are nausea, vomiting, andconstipation.

produced promising results and may replace existinginvasive and painful procedures (such as endoscopy)[5]. Similarly, there are commercially available wirelesselectrocardiograms which can be integrated with exist-ing sensor platforms.

There are, however, some challenges associatedwith mobility, one of the most significant challengesbeing the difficulty of maintaining link quality duringmobility. Independent experiments show that linkquality quickly deteriorates when nodes are mobilewhile communicating, resulting in high packet loss,drift, and jitter. This aspect particularly affectsapplications which require relatively high throughput.Devices such as wireless electrocardiograms typicallygenerate data at tens of kilobits per second rate. Whilethis in itself may not be high, if other sensors such as3D accelerometers and gyroscopes have to be sampledat comparatively the same rate, then the aggregatedata rate from a single node can be high. Whereasthe effect of mobility on link quality fluctuation hasbeen extensively studied in the context of cellularcommunications (owing, luckily, to the ability of

1

EAI Endorsed Transactionson Future Internet Research Article

EAI Endorsed Transactions on

Future Internet 12 2016 - 12 2017 | Volume 4 | Issue 12 | e1

http://creativecommons.org/licenses/by/3.0/

mailto:<[email protected]>

Jianjun Wen et al.

collecting ample statistics from a large number of usersin different settings and locations), investigation of linkquality fluctuation in mobile wireless sensor networksis a work in progress.

In this paper we propose a testbed for evaluatingthe effect of mobility in wireless sensor networks.The testbed separates the concern of applicationdevelopment from the evaluation of the applicationin different mobile scenarios. By doing so, complexand reproducible experiments can be carried out toensure that the behaviours of applications are bothreproducible and predictable. We fully implementedthe testbed for the TinyOS and TelosB platforms. Ourmobile nodes are carried by Diddyborg robots [6], eachof which is controlled by 6 powerful gear motors, so thatthe robots can be tasked to emulate different types ofmovements in indoor as well as outdoor environments.We used our testbed to evaluate the performance of twoproposed mobility management MAC protocols.

The remaining part of this paper is organized asfollows: In Section 2, we review related work andposition our own work. In Section 3, we present thesystem architecture of our testbed and in Section 4, wediscuss its implementation. In Section 5, we employour testbed to evaluate the performance of threeindependently developed mobility managing MACprotocols. Finally, in Section 6, we give concludingremarks and outline future work.

2. Related workTestbeds are intended to efficiently test wirelesssensor networks before they are actually deployed inreal-world environments. Compared to the area orvolume an actual deployment occupies, testbeds areconsiderably compact, so that they can be installedin labs or in areas which are easily accessible.This means, some communication parameters areintentionally scaled and events can be deliberatelyinjected into the network to suit the test setting andto emulate actual events. There are online testbedswhich are available to the WSN research community,most of them establishing two types of networks.One of the networks is the actual wireless linkthe characteristic of which is investigated and theother network serves as a backbone, reliable networkfor collecting performance indicator metrics. Thisnetwork can be wireless (for example, a WLAN)or wired (using USB hubs or serial interfaces). Asfar as the software architecture is concerned, theexisting testbeds also share similar aspects such as: (a)provision of web-based infrastructure and experimentmanagement services; and (b) functionalities fordynamic reprogramming, specification, configuration,and execution of experiments. Some of the testbedsemploy robots [7–9] while others employ toy trains [10]

as mobile platforms, to which wireless sensor nodesare attached. Besides providing mobility, the mobileplatforms also serve as power suppliers and nodemanagers, through which new program images can beinstalled and experiment procedures are controlled andmanaged.

Emulab [7] is perhaps the first publicly reachablemobility-enabled testbed for WSNs experimentation.The testbed is deployed in an L-shaped area andconsists of (1) 25 Mica2 static nodes installed onthe walls and ceiling of a building to form agrid-like topology, (2) 6 mobile nodes attached torobotic platforms, which can perform user-specific andaccurate way-point walking models (according to theauthors, the position of the robots can be determinedwithin 1 cm error, the worst-case), (3) 6 cameras whichare installed on the ceiling to track the robots, and(4) additional 3 web-cams to provide live-monitoring.One of the limitations of the testbed is the difficultyof influencing the movements of the robots duringexperiment execution, because their movement patternis predetermined and is not accessible at runtime.

Kansei [11] is a testbed employing the same typesof robots like Emulab to support mobility, but it doesnot provide any positioning system. The testbed usesfive robots integrating TMote Sky nodes and ExtremeScale Mote (XSM). These robots are deployed on topof a Plexiglas plane in which 210 XSMs and TMoteSky nodes are arranged in a 15 × 14 grid bench-work.In addition to the common functionalities the previoustestbed provides, Kansei provides a mechanism to injectevents into individual nodes and gateways. Sensei-UU [8] employs a Lego NXT robot as the mobileplatform, on which a TelosB node and a smartphoneare attached. Its unique feature is employing WL-500GP wireless access point as a control station toprovide programming, experiment monitoring, anddata logging functionality via a wireless channel. Whileit is relatively easy to reproduce and repeat experimentswith this testbed, it has some drawbacks: (1) the robotrequires the installation of tapes on the floor, whichlimits the types of movement that can be emitated bythe mobile platform (i.e., undertaking different randommovements is difficult); and 2) it is difficult to supportmultiple mobile nodes at the same time.

SensLAB [9] and TrainSense [10] are two recentlyproposed testbeds for mobile platforms. Both utilizetoy trains as mobile platforms. Since the trains run ontracks, which physically limit their motion, the testbedsare difficult to extend. It is also difficult to introducerandom walks into experiments. One of the merits ofthese testbeds is their ability to provide better accuracyof localization and control of mobility compared withthe other mobile platforms.

2EAI Endorsed Transactions on


MobiLab: A Testbed for Evaluating Mobility Management Protocols

3. Architecture of MobiLabThe main purpose and, therefore, contribution of ourtestbed is the flexible but reproducible execution ofcomplex experiments with wireless sensor networksin which some of the nodes are mobile. The testbedenables users to upload their own program imageonto individual nodes and to specify experimentprocedures and the movement pattern of mobile robotsindependent of the types of applications the wirelesssensor networks are supporting. To achieve thesegoals, our testbed separates resource management intodifferent concerns.

3.1. HardwareArchitectureThe hardware architecture (displayed in Fig. 1) consistsof four modules: a control station, a wireless sensornetwork, a node manager, and a backbone wirelesschannel. The control station serves as the main interfacebetween the user and the testbed. A group of dedicatedsoftware services run in the control station to managethe testbed resources and to control experiments. In thenext subsection we provide a detail description of thesoftware architecture of the control station.

The wireless sensor network consists of three typesof nodes: static relay nodes, mobile nodes, and sniffernodes. The sniffer nodes are special stationary nodesthat are not involved in any experiment, but are usefulfor monitoring the state of the wireless channel toobtain complementary information about experimentexecution during debugging. By changing the firmware,the sniffer nodes can also produce interference intothe network. A node manager interfaces a nodewith the control station. Each node manager (forour implementation we used a raspberry board) isconnected to a wireless sensor node via a USB port.The node managers and the control station establishthe backbone network to exchange management andexperiment information at runtime. We use a Wi-Fiad hoc network as our backbone network because ofits scalability and flexibility. A node manager enablesto easily program and control a node as well as tocollect useful performance related data from it. Thenode manager connected to a mobile node has theadditional task of controlling the motion of the robotand collecting location information.

3.2. Software ArchitectureThe control station is the most important modulein MobiLab. It ensures that the testbed as a wholefunctions as a unified system. It is through thecontrol station every program image or command ispropagated to the wireless sensor network. Fig. 2displays its software architecture, which consists ofa user interface, a resource management service, an

>_

control station

WSN PLANE

stationary node

sniffer node

mobile node

node manager (static)

communiation agent

programminglogging

node manager (mobile)

communication agent

programminglogging

wireless control channel (wifi)

USB

user

Figure 1. The hardware architecture of MobiLab.

experiment management service, a data managementservice, and a data analysis service.

User Interface. MobiLab provides both a web-basedand a command-line-interface through which users canaccess the testbed and conduct experiments remotely.Users can browse active nodes and their status, uploadprogram images into the wireless sensor network,and specify and manage experiment procedures usingexperiment execution primitives we defined (to bediscussed below).

Rsource Management. MobiLab does not require a fixedinfrastructure (a specific network size or topology)to run experiments. As to which specific pair ofnodes should communicate with one another atany given time and for how long can be specifiedin experiment procedures to evaluate, for example,link quality fluctuation between them. The resourcemanagement service is responsible for authorizingnodes to join the network and users to access individualnodes; for managing binary images, and for ensuringproper program installation. Moreover, the resourcemanagement service uploads and deletes programimages to and from nodes and controls versions. In it,a synchronization daemon runs in the background toensure that program images in the control station andthe node managers are consistent.

Experiment Management Service. The experiment man-agement service enables users to define and manageinter- and intra-experiment activities. As regards man-agement, users can initiate, interrupt, suspend, mod-ify, and end experiments at runtime by using exper-iment execution primitives (see Table 1). The primi-tives enable users to configure interaction (transmissionpower, channel, partner nodes) and to specify commu-nication durations, among others. When an experimentprocedure is submitted to it, the experiment manage-ment service validates the procedure to ensure that it isexecutable, parse the procedure to extract experiment



Jianjun Wen et al.

web-based user interface

auto detection

programming

Resource Management

image manager

command line tool set

component interface internal logic

link trigger metrics

handover metrics

Data Analysis

analysis

data logging

EXP

experiment specification

PAR

parameter specification

Experiment Management

execution agent manager

exe agent exe agent

cmd distributor cmd interpreter

script parser

validator

virtualization

comm agent CA

virtual node VN

Data Management retrieve

start experiment

Figure 2. The software architecture of the control station.

MBL

mobility specification

Robot Controller

loc tracking motion execution

recorder

generator

Resource Management

power control(on/off)

firmware update

node probe

Traffic Flow Controller

message adapter serial comm

agent

socket comm agent

Local Server

experiment control

node manage

crea

tede

stro

y

TFCP Middleware

configuration traffic flow control

command distributor

Application

confi

gure

star

t

paus

e

cont

inue

term

inat

est

op

data report

session management

traffic flow control protocol stack

Mobility Management Protocol

link trigger mechanism

handover mechanism probe

probe

probe

data sampler

serial communication driver layer radio driver layer

send

rece

ive

Node Manager Sensor Node

Figure 3. An overview of the software architecture of the testbed from a single node perspective: (Left) The software architecture ofthe node manager. (Right) The software architecture of a sensor node.

parameters, translates the parameters into binary, cre-ates a control flow (execution sequence), and passes thecontrol flow to the execution manager. The executionmanager is responsible for coordinating the executionof an experiment procedure until it terminates. A vir-tual node manager within the control station’s archi-tecture creates a virtual representation for each phys-ical node. The aim is to hide differences in hardwarearchitecture between nodes from users and to providecommon interfaces for accessing and interacting withthem.

Table 1. traffic flow control primitives.

primitive descriptionconfigure setup the application dependent parametersstart initiate the test roundstop notify finish of test roundpause suspend executioncontinue resume executionterminate stop execution permanently

Data Management and Analysis. Data management orlogging is one of the useful features of testbedframeworks. The data in question are typically not




sensed data; rather they are performance indicatorssuch as RSSI, Link Quality Indicator (LQI), SNR,timestamps, etc. which are useful for analyzing thefluctuation of link quality, the reliability of links,the adaptivity of routing protocols, etc. When anexperiment is launched, MobiLab creates an instanceof a data logging module which is then associated withthe communication agents of the corresponding virtualnodes. During experiment execution, the physicalnodes log the desired data locally and forward themto their virtual node managers at the control station,which then stores the data in a database. Alternativelyperformance indicators can be directly streamed tovirtual node managers as they are generated.

3.3. Node ManagerA node manager is a physical device which isphysically connected with a wireless sensor node viaa USB interface. The idea is to facilitate the dynamicreprogramming of nodes, the replacement of modules,and the collection of relevant performance indicatorsduring experiments. The software aspect of a nodemanager has three components, which are the localserver, a resource manager, and a traffic flow controller.A robot node manager includes an extra module formanaging mobility.

Local Server. It is a socket-based server that receivescommands and messages destined to the physicalnode from the control station. Its main responsibilityis managing the physical node and controlling theproper execution of experiments. The server is logicallyconnected with the resource management service atthe control station, thus it is able to provide thefunctionalities for probing the sensor node, updatingfirmware and physically powering on and off thenode; it is also responsible for coordinating experimentcontrol flows and commands pertaining to the motionof a robot.

Traffic Flow Controller. The procedure of an experimentis first encoded using the traffic primitives we specifiedin Table 1. By the time it reaches the traffic flowcontroller at the node manager, it is translated intoa sequence of commands and parameters. The trafficflow controller is responsible for creating a channelbetween the node manager and the physical node andfor transmitting the commands and parameters in theirsequence and appropriate delay to the physical node. Italso channels the logged data from the physical nodeto the node manager. The node managers are timesynchronized with the control station at the beginningof each run of an experiment.

Robot Controller. The motion of a robot is controlled bya robot controller. The controller is instantiated by itsnode manager before an experiment is launched and

destroyed after the experiment is completed. Differentmobility models can be implemented and integratedinto the node manager a priori and an instance ofa model can be loaded when the robot controlleris first instantiated. The parameters of this modelcan be modified at runtime by using the experimentprimitives in Table 1. Currently, we are experimentingwith straight line walking and the random waypointmodel [12].

3.4. Sensor NodeFig. 3 (right side) illustrates the software architectureof a wireless sensor node. Most relevant to this paperis the traffic flow control protocol middleware (TFCP),which we shall discuss in some detail. The TFCPmiddleware is an application independent layer formanaging inter and intra-experiment activities. It isloosely coupled with the OS layer, interacting withcommunication drivers by send and receive interfacesand exposing six interfaces to the higher layers (MAC,network and application layers), so that users cansetup experiment and application specific parametersand control the execution steps of experiments. Thedata sampler and report module locally collects andaggregates performance indicator metrics from relevantlayers and communicates them with the control stationvia the TFCP middleware.

The mobility management protocol does not belongto the MobilLab testbed. We integrated it to investigatethe performance of different mobility managementprotocols under the same setting. We shall explain thisin more detail in Section 5.

4. ImplementationWe established a wireless sensor network with TelosBnodes; its size varied between 10 and 20 stationarynodes and three mobile nodes. We implemented thecontrol station on a laptop computer, in a Linuxenvironment. Each TelosB node is physically attachedto a Pi 2 model B raspberry board [13], which servesas a node manager. The raspberry board has 4 USBports, a 900 MHz quad-core ARM Cortex-A7 CPU, 1 GBRAM, and 8 GB micro SD card. The mobile TelosB nodesare carried by Diddyborg robots [6] and controlled bytheir own onboard raspberry boards. The raspberryboards established a background ad-hoc network usingUSB-WiFi adapters and the ap-hotspot2. Several studiesconfirm that IEEE 802.11 and IEEE 802.15.4 radios cancoexist with each other without obvious interference ifnon-overlapping channels can be selected carefully [14][15], which we did.

2https://github.com/hotice/AP-Hotspot



Jianjun Wen et al.

Figure 4. A wireless sensor network deployed in a long corridorat our faculty. One mobile node travels from one end of thecorridor to the other end while communicating with a single relaynode with which it establishes a link with the best link quality.

All the software components running inside thecontrol station and the node managers are developedwith Python, which can easily be ported to otherplatforms. The web application is based on DjangoFramework and Apache server. The TFCP middlewarerunning on each sensor node is built on top of TinyOSand has a footprint of 1058 bytes of ROM and 84 bytesof RAM.

We re-implemented two mobility-aware MAC pro-tocols, which we previously developed for MicaZ andImote2 platforms [16–18] and integrated them into ourtestbed to evaluate both the testbed and the proto-cols. Both protocols are essentially the same and areintended to support burst transmission and seamlesshandover. Their main difference lies in their evalua-tion of link quality fluctuation and handover triggeringmechanisms. The motivation for the protocols is that inresidential or rehabilitation centers where mobile nodescan be employed to monitor patients, elderly people, orchildren, establishing reliable links is vital. Moreover,(1) the number of mobile nodes in these environmentsis small compared to the stationary relay nodes that canbe deployed, (2) a significant portion of the networktraffic is generated by the mobile nodes, and (3) theflow of traffic is predominantly one directional, namely,from the mobile nodes to the basestation. Consequently,these protocols forego contention for each packet toavoid unnecessary packet transmission delay; instead,

as soon as a mobile node realizes that the channel is free,it transmits packets in burst, but each packet shouldbe acknowledged to ensure reliable transmission. Whenthe mobile node detects that the quality of an existinglink is deteriorating, it searches for a more reliable relaynode in its surrounding without breaking the existinglink. Upon detecting a reliable relay node, the mobilenode transfers communication to it. The key aspectof a handover is that a mobile node switches packettransmission from a unicast to a multicast mode duringhandover, so that neighbor relay nodes can intercept thepacket it transmits and candidate themselves to becomeits relay nodes. From candidate relay nodes, the mobilenode chooses one of them and switches communicationback to a unicast mode.

The link quality evaluation mechanisms and whethera deterioration in a link quality eventually leads toa disconnection require the evaluation of incomingacknowledgement packets. A simpler mechanism leadsto a quicker decision, introducing a small processingoverhead but the decision may also lead to frequenthandover oscillation; a more complex mechanismrequires a sizable amount of received acknowledgementpackets and a more advanced estimation technique.The first protocol can be configured as single-thresholdor dual-threshold. In the first case, when the RSSIvalues of a set number of incoming acknowledgementpackets consistently drops below a set threshold, ahandover is initiated. In the second case, two typesof thresholds are defined. The first threshold serversto initiate a handover request whereas the secondthreshold servers to select and bind to a new relay node.The second protocol, on the other hand employs anadaptive filter (least mean square) to determine linkquality deterioration as a consistent phenomenon andto initiate a handover.

5. EvaluationAs we already point out, we used our setup to evaluateboth the testbed as an experiment supporting tooland the mobility-aware MAC protocols. As regards thetestbed, our aim was to evaluate the variance in theexperiment dissemination and completion time, thescalability of the testbed both as a function of thenumber of nodes involved in an experiment and asa function of the complexity of an experiment. Asregards the MAC protocols, our aim was to evaluatethe cost of handover, in terms of the expected delayin transferring a communication as a function ofnode density (distance between relay nodes) and theduplication of packets during a search for a relay node(the mobile node communicates with multiple relaynodes during a handover request or neighbor discoveryphase).




5.1. Evaluation of MobiLabIn order to carry out reproducible experiments, thedetail of the experiment procedures are scripted, i.e.,the beginning, end, and duration of every activityis specified. When the control station dispatchesexperiment procedures, they may not be executedby the individual nodes at precisely the same time.Consequently, nodes may not begin and end theexecution of experiments at the same time. Thisphenomenon is an aspect of both the size of the networkand the complexity of the experiments.

To investigate this phenomenon, we launched a set ofsimple experiments with variable number of physicalnodes (from 5 to 20) and emulated nodes (up to500). We recorded the starting time of each nodeand calculated the maximum variance (time differencebetween the earliest starting node and the latest staringnode). We observed that the maximum variance ofexperiment beginning time was 200 ms. Secondly, weinserted arbitrary number of control commands (pauseand continue commands) in the experiments lastingup to 600 seconds, and varied the number of nodesfrom 1 to 10. We did not observe significant incrementsof experiment completion times when the numberof commands increased (shown in Fig. 5b). To showthe repeatability of an experiment using MobiLab, weevaluated the RSSI fluctuation and packet receptionrate under different configurations. We conducted aseries of experiments and repeated each one threetimes. As Fig. 5c and 5d shown, the CDF of RSSIvalues are almost the same for the experiment withthe same configuration (transmission power, motionpattern, walking path etc.) and the packet receptionrates are consistent for each repetition.

5.2. Evaluation of Mobility-Aware ProtocolsWe carried out repeated experiments to evaluate theperformance of the two mobility-aware protocols interms of overall packet transmission success rate andthe number of duplicate packets relay nodes shouldforward to the basestation during a handover phase.Our experiments involved two different separationdistances between relay nodes that make up thewireless sensor network we deployed in one of thecorridors of our faculty: 5 m and 10 m (see Fig. 4). Amobile robot carrying one of the mobile nodes moved ata speed of 0.13 m/s from one end of the corridor to theother end while transmitting packets in burst. It neededabout 200 seconds to cover the entire distance. For eachconfiguration we repeated the experiment three times.Table 2 lists the physical and MAC layer parameters forout experiments.

Success Rate. Fig. 6a displays the packet transmissionsuccess rate of the thee handover schemes. As can

Table 2. experiment parameters: upper) link trigger independentparameters; lower) link trigger dependent parameters

parameter valuedeployment (spacing) 5, 10 mchannel 26transmission power -25 dBmIPI 200, 500 msduration 200 slink trigger parameter valueSingle threshold threshold -60, -65 dBm

Dual threshold threshold -60, -65 dBmmargin 5 dBm

LMS partitions 5trigger level 2

be seen, all of them have a success rate of greaterthan 98% when the distance of separation betweenthe relay nodes was 5 m, for the overlapping in theradio coverage of the relay nodes becomes larger whenthe separation distance becomes smaller, as a result, ahandover request is most likely successful. In contrast,when the separation distance between the relay nodeswas 10 m, the packet transmission success rate ofall the three schemes was reduced; nevertheless, theLMS scheme outperformed the other two schemes bya narrow margin (98.33% compared with 94.92% and96.67%).

Handover Cost. In order for a mobile node to searchfor an alternative relay node in its surrounding withoutinterrupting communication with the old relay node, ithas to transmit outgoing packets in a broadcast mode.These packets will be intercepted by participating relaynodes and forwarded to the basestation, which leads topacket duplication. The faster the handover phase, thefewer the duplication packets. The slower the handoverphase, the larger the duplication packets. We definedthe term duplication ratio to quantify the networkschannel utilization efficiency. Thus,

δ =pδpu

(1)

where Pδ and Pu are the number of duplicated andunique packets the basestation receives, respectively,and δ is a measure of channel utilization efficiency(a larger δ signifying a lower channel utilization).Fig. 6b displays the network’s channel utilizationefficiency in terms of δ. As can be seen, when thedistance of separation between the relay nodes was5 m, the duplication ratio of the single threshold andthe dual threshold handover strategies was significantlyhigher. This is the trade-off between a higher handoversuccess rate and a larger amount of duplication. Asthe separation distance between relay nodes decreases,the chance of nearby relay nodes intercepting the



Jianjun Wen et al.

0 100 200 300 400 500number of nodes (#)

0.00

0.05

0.10

0.15

0.20

0.25

tim

e v

ari

ance

(s)

(a) (b)

tx-power=-25 dBm

tx-power=-10 dBm

tx-power=0 dBm

(c)

-25 dBm -10 dBm 0 dBmrepeated experiment

0

20

40

60

80

100

pack

et

succ

ess

rate

(%

)

repeat 1repeat 2repeat 3

(d)

Figure 5. Performance analysis of MobiLab as an experiment management tool: (a) The time variance of synchronized starting timefor networks of different sizes; (b) The deviation in the duration of arbitrary control commands in a single experiment. (c) cdf of RSSIfluctuation of repeated experiments; (d) packet success rate of repeated experiments

5 m 10 mspacing (m)

0

20

40

60

80

100

120

succ

ess

rate

(%

)

single threshold dual threshold LMS

(a)

5 m 10 mspacing (m)

0

20

40

60

80

100

duplic

ati

on r

ati

o (

%)

single threshold dual threshold LMS

(b)

Figure 6. The efficiency of handover mechanisms for different deployment scenarios (when the spacing between stationary relay nodeswas 5 m and 10 m). (a) Packet transmission success rate; (b) The duplication ratio of the whole network.

multicast handover packets increases. The relay nodesintercepting the handover request packets (the payload

of which contains a useful data) will forward the packetto the basestation (in order to reduce packet loss due




to the deteriorating link quality). At a longer distanceof separation, the chance of intercepting a handoverrequest decreases, but with it, the possibility of findingan alternative relay node decreases as well. As can beseen in the figure, there is an exception to this for thedual threshold scheme; this is because, this scheme forcesthe mobile node to wait until it discovers a link, thequality of which is above the second threshold, beforeit finalized a handover process.

Handover Oscillation. Fig. 7 shows how the threehandover schemes enabled a seamless handover as aresult of fluctuation in the RSSI values of receivedacknowledgement packets (as regarded from the mobilenode, which initiates a handover). The left-side ofeach figure indicates the RSSI values in dBm andthe right-side indicates in which of the two states –a normal transmission state (unicast transmission) ora handover state (multicast transmission state) – themobile node was while moving along the corridor.The dual-threshold scheme spent much of the time insearching for reliable relay nodes whereas the singlethreshold and the LMS schemes spent comparativelymuch of the time in a normal transmission state(signifying a quick handover phase). However, the LSMscheme is the one with the highest successful packettransmission rate.

6. Conclusion and Future WorkIn this paper we introduced MobiLab, a testbedwe developed to experiment with wireless sensornetworks which support mobile nodes. MobiLabseparates the concerns of application and protocoldevelopments from their testing phase. Our mainmotivation was performing repeated and reproducibleexperiments independent of the types of networktopology, communication protocols, communicationparameters, and sensors involved in the experiments.We presented both the conceptual architecture andthe implementation of our testbed and illustrated howwe used the testbed to evaluate two mobility-awareMAC protocols. The hardware architecture of MobiLabconsists of a control station, node managers, sensornodes and mobile robots as mobile platforms. The nodemanagers establish a wi-fi backbone network to providemanagement and data collection functionalities duringthe execution of experiments. The wireless networkenables flexible deployment and scalability. Thehardware components of MobiLab are commercialoff-the-shelf (COTS) products, which makes MobiLabaffordable and easy to reproduce. From the softwareperspective, besides sharing the same design principleswith existing testbeds, MobiLab provides several novelcontributions such as supporting both inter- and intra-experiment management, TFCP middleware in a sensornode, and a robot motion management. Except for the

sensor node architecture, which is implemented in Cfor the TelosB platform, all the remaining softwarecomponents are implemented in python, which isrelatively easy to port to other platforms. Our futuregoal is to use the testbed for testing different mobileapplications and routing and MAC protocols, to enlargethe wireless sensor network, and to deploy the testbedin different environments.

Acknowledgement. This work has been partially fundedby the German Research Foundation (DFG) under projectagreement: DA 1211/5-2.

References[1] Sha, D.L., Xie, W.C., Fan, X.L. and Li, Y. (2015) Based

on wireless sensor network (nwk) of non-contact tremormonitoring equipment improvement for parkinson’sdisease. In Applied Mechanics and Materials (Trans TechPubl), 713: 491–494.

[2] Grimes, C.A., Ong, K.G., Varghese, O.K., Yang, X., Mor,

G., Paulose, M., Dickey, E.C. et al. (2003) A sentinelsensor network for hydrogen sensing. Sensors 3(3): 69–82.

[3] Lay-Ekuakille, A., Vergallo, P., Griffo, G., Kanoun, O.,Angelillo, F. and Trabacca, A. (2013) Wireless networkacquisition of joint eeg-ecg-ergospirometric signals forepilepsy detection. In Measurements and NetworkingProceedings (M&N), 2013 IEEE International Workshop on(IEEE): 41–45.

[4] Seto, E.Y., Giani, A., Shia, V., Wang, C., Yan, P., Yang,A.Y., Jerrett, M. et al. (2009) A wireless body sensornetwork for the prevention and management of asthma.In Industrial Embedded Systems, 2009. SIES’09. IEEEInternational Symposium on (IEEE): 120–123.

[5] Farmer, A.D., Scott, S.M. and Hobson, A.R. (2013)Gastrointestinal motility revisited: the wireless motilitycapsule. United European gastroenterology journal :2050640613510161.

[6] Diddyborg robot, https://www.piborg.org/diddyborg.[7] Fish, R., Flickinger, M. and Lepreau, J. (2006) Mobile

emulab: A robotic wireless and sensor network testbed.In IEEE INFOCOM.

[8] Rensfelt, O., Hermans, F., Larzon, L.Å. and Gunning-

berg, P. (2010) Sensei-uu: A relocatable sensor networktestbed. In Proceedings of the fifth ACM international work-shop on Wireless network testbeds, experimental evaluationand characterization (ACM): 63–70.

[9] Des Rosiers, C.B., Chelius, G., Fleury, E., Fraboulet,A., Gallais, A., Mitton, N. and Noël, T. (2011) Senslabvery large scale open wireless sensor network testbed. InProc. 7th International ICST Conference on Testbeds andResearch Infrastructures for the Development of Networksand Communities (TridentCOM).

[10] Smeets, H., Shih, C.Y., Zuniga, M., Hagemeier, T. andMarrón, P.J. (2013) Trainsense: a novel infrastructure tosupport mobility in wireless sensor networks. In WirelessSensor Networks (Springer), 18–33.

[11] Ertin, E., Arora, A., Ramnath, R., Naik, V., Bapat, S.,Kulathumani, V., Sridharan, M. et al. (2006) Kansei:



Jianjun Wen et al.

0 50 100 150 200timestamp (s)

70

60

50

40

30

20

RSSI (d

Bm

)

N

H

handover

state

(a)

handover phase

normal transmission phase

(b)

0 50 100 150 200timestamp (s)

70

60

50

40

30

20

RSSI (d

Bm

)

N

H

handover

state

(c)

Figure 7. RSSI fluctuation of incoming acknowledgement packets and handover oscillation. (a) Single threshold scheme. (b) Dualthreshold scheme. (c) LMS.

a testbed for sensing at scale. In Proceedings of the 5thinternational conference on Information processing in sensornetworks (ACM): 399–406.

[12] Camp, T., Boleng, J. and Davies, V. (2002) A survey ofmobility models for ad hoc network research. Wirelesscommunications and mobile computing 2(5): 483–502.

[13] Raspberry pi 2 model b,https://www.raspberrypi.org/products/raspberry-pi-2-model-b/.

[14] Srinivasan, K., Dutta, P., Tavakoli, A. and Levis, P.

(2010) An empirical study of low-power wireless. ACMTransactions on Sensor Networks (TOSN) 6(2): 16.

[15] Baccour, N., Koubaa, A., Mottola, L., Zuniga, M.A.,Youssef, H., Boano, C.A. and Alves, M. (2012) Radio

link quality estimation in wireless sensor networks: asurvey. ACM Transactions on Sensor Networks (TOSN)8(4): 34.

[16] Dargie, W. and Wen, J. (2014) A seamless handover forwsn using lms filter. In Local Computer Networks (LCN),2014 IEEE 39th Conference on (IEEE): 442–445.

[17] Dong, Q. and Dargie, W. (2013) A survey on mobilityand mobility-aware mac protocols in wireless sensornetworks. Communications surveys & tutorials, IEEE15(1): 88–100.

[18] Zhiyong, T. and Dargie, W. (2010) A mobility-awaremedium access control protocol for wireless sensornetworks. In GLOBECOM Workshops (GC Wkshps), 2010IEEE (IEEE): 109–114.



EAI Endorsed Transactions - EUDL

Documents

Transcript of EAI Endorsed Transactions - EUDL