Tree-Based Routing Protocol for Wireless Sensor NetworksLuca Borsani, Sergio Guglielmi, Alessandro Redondi, Matteo Cesana

Dipartimento di Elettronica e Informazione,Politecnico di Milano,

P.zza Leonardo da Vinci, 32Milano, Italy

{borsani, guglielmi, redondi, cesana}@elet.polimi.it

Abstract—The issue of supporting mobility in Wireless Sensor Net-works is recently attracting increasing attention within the researchcommunity as new-born application scenarios require the deploymentof hybrid network architectures composed of fixed and mobile sensornodes.

In this work, we address the problem of mobility management inWSNs by proposing a tree-based routing protocol able to support mobilesensor nodes. Distinctive features of the proposed routing solution are theprovision of bi-directional uplink/dowlink connectivity to mobile sensornodes, the use of proactive procedures to speed up the association/re-association phase, a reduced impact of the signalling overhead to managenode mobility by resorting to ”local” handover management procedures.The routing protocol has been implemented on commercial hardwareand thoroughly evaluated in terms of reactiveness and overhead throughtestbed experiments, as well as detailed simulations.

I. INTRODUCTION

Wireless Sensor Networks (WSNs) represent nowadays a powerfultransmission commodity to support a vast range of applications andservices with heterogeneous goals and deployment scenarios [1].Classical application arenas of WSNs range form the environmentalmonitoring for the periodic reporting of remote measures on physicalparameters (e.g., humidity, temperature, light, etc. . . ), to safety andsecurity-oriented applications to detect and react to rare events(intrusion detection, natural disaster detection, etc.).

Even if WSNs were originally thought to have static network in-frastructure, recent applications require sensing nodes to be mountedon mobile entities (human beings, mobile robots, etc. . . ). Think of thecase of Wireless Body Area Networks (WBANs) [2] consisting of aset of wearable or implanted sensing devices which can communicateamong themselves and/or transmit data from the body to externaltraffic sinks. WBANs can be indeed useful whenever there is theneed to monitor/track nomadic people, e.g., to monitor soldiers inthe battle field (military applications), patients in nursing institutes(e-health applications), fire brigades and policemen (security/safetyapplications). Whatever application environment, the use of WBANsand mobile sensors in general, brings into the world of WSNs theproblem of effectively supporting the mobility of single nodes and/orgroups of nodes. Namely, the mobile sensors need to be continuouslyconnected to the external network to deliver their sensed data, andviceversa, an external control point may need to seamlessly ”contact”the mobile sensors.

Managing and supporting mobility in WSNs bear similar re-quirements and challenges of other wireless systems (e.g., WLANmobility). Indeed, mobility support should always be seamless fromthe mobile node’s perspective, fast enough to track the mobilenodes’ movements, and robust in all its procedures. Yet, the designof effective mobility support strategies within mobile WSNs posesadditional challenges with respect to other wireless systems. In fact,

the mobile sensors (and often also the infrastructure ones) are batteryoperated, thus all the procedure to provide seamless uplink/downlinkmobile connectivity to mobile sensors must be highly energy efficient.To this extent, the mobility support must feature a limited overheadin terms of processing and required communication messages tobe exchanged among sensor nodes. Moreover, the specific mobilitysupport ”utility” should be fully integrated in a cross-layer fashionwith the specific routing solution adopted by the WSN.

In this work, we propose a solution to support seamless mobilitywithin a multi-hop WSNs featuring both mobile and statically de-ployed nodes. The reference network scenario is the one consideredby project LAURA (LocAlization and Ubiquitous monitoRing ofpAtients for health care support) whose final goal is the design andthe implementation of a lightweight system based on Wireless SensorNetworks (WSNs) for the automatic localization and supervisionof nomadic patients within a nursing institute [3]. Mobile nodes(sensors) mounted on patients connect to a multi-hop infrastructurestatically deployed to finally reach the control center; both uplink anddownlink traffic must be supported in the reference scenario. Indeed,sensor nodes mounted on nomadic patients must be able to deliverremotely locally-collected information (uplink), and, dually, receivingconfiguration information from the control center (downlink).

Within this scenario, we take a cross-layer approach and designa mobility-aware tree-based routing protocol which is able to buildup and maintain a tree routing topology with mobile leaves (mo-bile sensor nodes). The proposed solution provides bi-directionalconnectivity from the root(s) of the tree (traffic gateways) to themobile nodes and viceversa and features proactive procedures tospeed up the association/re-association procedures of the mobilenodes, while limiting the impact of the signalling overhead to managenode mobility. We implemented the proposed scheme on commercialhardware and thoroughly evaluated in terms of reactiveness andoverhead through testbed experiments.

The paper is organized as follows: Section II overviews the relatedwork in the field of mobile WSNs. we take then a constructiveapproach by introducing first the procedure to set up a static routingtree (Section III), further showing how to extend it to the case ofmobile sensor nodes (Section IV). Section V reports and commentson the numerical results derived from the experimental evaluation ofthe mobility management procedures, whereas section VI gives ourconcluding remarks.

II. RELATED WORK

Applications for localization, tracking and monitoring of objectsand people in indoor environments, usually resort to hybrid sensor

networks composed of fixed and mobile nodes [4]. Hence, mobility-aware routing protocols are required to support seamless communi-cation from/to the mobile nodes and the data sinks.

The most common approach in the literature to handle mobilityin WSNs ([5], [6], [7], [8], and [9]) consists in modifications of theLow Energy Adaptive Cluster Hierarchy (LEACH) protocol [10]. InLEACH, sensor nodes are organized into local clusters, with one nodeacting as Cluster-Head (CH). The CH is responsible to deliver all thedata coming from non-cluster-head nodes to the PAN coordinator(traffic sink). Since non-cluster-head nodes have a TDMA schedulecomputed from their CH, they can be switched on only in their timeslot, thus reducing energy consumption. On the contrary, since clusterheads must be always active in order to receive data from the clusterand forward it to the PAN coordinator, their lifetime is limited. Toavoid the death of a fixed set of sensor nodes, LEACH introducesa randomized rotation of the cluster heads in order to distribute theenergy consumption among all nodes in the network.

LEACH-Mobile, in short LEACH-M [5], is a modified versionof LEACH that introduces support for mobile nodes. In LEACH-M the data transmission phase is modified with an explicit request-response paradigm. The cluster head broadcasts a call for data to allthe nodes in his cluster and waits for responses: mobile nodes thatdo not answer are marked as possible lost nodes and deleted fromthe TDMA schedule. Conversely non-cluster-head nodes that do notreceive data requests in their TDMA slot because of their mobility,start a procedure to join a new cluster and deliver their data.

LEACH-Mobile-Enhanced (LEACH-ME) [6] and Distributed Clus-tering Algorithm (DCA) [9] introduce modifications in cluster headelection to generate steady and balanced clusters that are disturbedminimally by cluster heads movement while other mobility protocolssuch as CBR-Mobile [8] and M-LEACH [7] try to increase datatransfer success rate and energy saving modifying LEACH datatransmission phase.

In general, LEACH and its modified versions supporting mobilenodes are based on single hop communication, so they work underthe assumption that all the nodes in the network can reach directly thePAN coordinator when it’s their cluster-head turn. This assumptionis seldom realistic, especially in indoor environments where walls,furniture and people limit the radio range of wireless devices andmulti-hop routing is unquestionably necessary.

A partially different approach to mobility in WSN that considersmulti-hop routing is given in [11]. Here pseudo-cluster are formed,with their cluster heads organized in a multi-hop tree that acts asrouting path for mobile nodes. When a moving node needs to transmitits data, it broadcasts an explicit request and analyzes received repliesto identify the cluster head which has minimal hop count toward thePAN coordinator. This solution also provides down-link data queryfrom PAN.

The distinctive features of the present work compared with theliterature can be thus summarized in the two following aspects: (i) theproposed approach addresses mobility in multi-hop WSNs, which, tothe best of our knowledge, is still an unresolved issue; (ii) whilst mostof the literature in the field resort to simulation-based performanceevaluation, the proposed approach has been actually implemented oncommercial hardware and experimentally tested in realistic scenarios.

III. HIERARCHICAL ADDRESSING TREE (HAT) ROUTING

PROTOCOL

In this section we start off by presenting the static HAT routingprotocol which builds up a tree-like routing/forwarding topology

among the network nodes. In the next section, we then show howHAT can be modified enhanced to effectively support mobile nodes.

The routing tree is rooted at a Personal Area Network (PAN)coordinator which collects the traffic of the entire tree. The hi-erarchical routing tree is created and maintained through dynamicassociation (de-association) policies, which allow sensors to retrieve(release) network addresses and join (leave) the routing tree. Theassigned addresses feature a hierarchical structure which reflects thetree topology. Referring to Figure 1 which shows an example ofaddress format and management, the network addresses are composedof ordered fields in the form A.B.C.D. Each field is used to addressall the nodes at a given depth in the tree (distance in hop from theroot). The first field, A, addresses the nodes directly connected to theroot of tree (PAN coordinator), the second field the nodes two hopsaway the root, and so on. The number of fields in the network address(tree depth), and the number of nodes which can be addressed in eachfield (tree width), obviously depend on the number of bytes availableto represent the network address. In this work, unless differentlyspecified, we have considered addresses of 2 bytes, with a maximumnumber of fields (tree depth) of 5, and each node has a maximumnumber of sons equal to 8.

AssociationVisibility

PAN Coordinator

2.0.0.0.0

2.1.0.0.0

1.0.0.0.0

1.1.0.0.0

1.2.0.0.0

1.2.1.0.0

Fig. 1. Example of Address Format and Tree Topology.

A. Association Phase

Upon activation, a sensor node starts in the Initialization state.After having initialized all the internal components and variables, asshown in Figure 2(a), the node switches to the Scanning state andstarts collecting beacons (BCN) sent by the surrounding nodes.

PAN Coordinator

2.0.0.0.0

1.0.0.0.0

New node

BCNBCN

(a)

PAN Coordinator

2.0.0.0.0

1.0.0.0.0

New node

CFR

REQRES

(b)

Fig. 2. Procedure of Network Association. (a) A new node approaching thenetwork senses the channel through the reception of beacons from neighbournodes. (b) The new node joins the network using a three-way handshake withthe node having best characteristics.

Then, the node, hereafter denoted as associating node, choosesthe parent node to be associated to among the elements of a set P ,which includes the nodes having received a beacon message from.Association proceeds by maximizing the following utility function J :

J(i) = αRSSIi + βNi + γHCi, (1)

which depends on three factors: i) the Received Signal StrengthIndicator from node i (RSSIi); ii) the current number of children ofthe i-th candidate parent (Ni) and iii) the distance of the candidateparent from the PAN coordinator (Hop Count, HCi). The associatingnode consequently chooses the parent node i∗ which maximizes theutility function J(i), that is:

i∗ = arg.maxi∈P

(J(i)) (2)

The RSSI gives an estimate of the quality of the link and it is usedto prevent nodes from associating with a parent through unstablelinks. The last two factors impact on the target network topology.Intuitively, the larger is the weight β (γ), the deeper (wider) is theresulting tree. The weights of the three factors have been empiricallyset to α = 1, β = −3, and γ = −6.

Upon selection a three-way handshake is made (Figure 2(b)):the associating node sends an explicit association request (REQ) tothe selected parent node, which, in turn, responds with a messagecontaining the proposed network address (RES). This response isbroadcasted since the requesting node does not have a networkaddress yet. Hence, the requesting node must confirm the associationwith a confirm message (CFR) to the parent and can then switchto the Associated With Network (AWN) state. At this point theassociated node generates a Mote Announcement message (MA) thatis forwarded through the whole tree to the PAN coordinator. This isnecessary to keep updated the list of connected mote at the root of thetree (that is generally connected to a PC or other gateway devices).A specular message called Mote Loss message (ML) is also providedin case of death of nodes. In this case, when a node recognizes thatone of his children is dead, a Mote Loss message is sent to the PANcoordinator, so the list of connected motes can be updated.

In the AWN state, the association is maintained by means ofperiodic beacon messages sent by parent nodes which carry all theinformation needed to manage and maintain the association. Namely,each beacon message contains a sequence number (that can beused for synchronization purposes), the current route cost (used byassociating nodes to compute the association utility function), and aCHILD MASK used to inform associating nodes about the currentnumber of children associated to a given parent.

The CHILD MASK is also used to prevent inconsistencies in theassociation due to asymmetries in the wireless links between parentsand children. Indeed, the aforementioned association phase leveragesinformation obtained through downlink beacons, and it consequentlyaccounts only for the downlink quality of the parent-to-node link; thusan associating node could select a parent with a ”good” downlinkchannel quality but with an actual ”poor” uplink channel quality.This may lead to situations where the parent node does not receivethe beacons from its child, and consequently deletes it from therouting table, while the child remains associated to the parent. Toprevent this problems, the CHILD MASK reports the identities ofall the associated nodes, such that a node receiving a beacon fromits parent can crosscheck if it is still in the parent’s routing table. Ifthis test fails, the node goes back to the Initialization state and a newassociation procedure is triggered.

B. Routing

HAT is responsible for end-to-end (source to destination) packetdelivery including routing through intermediate hosts. This isachieved through the use of routing tables stored on each node anda network header inserted in every message. HAT network headeris shown in Fig. 3. It contains four fields, namely Packet Scope,Broadcast Sequence Number, Network Source Address and NetworkDestination Address.

Network Destination

Address

Network Source Address

Broadcast Sequence Number

Packet Scope

Fig. 3. Network Header Structure

The routing table contains in each row a node id (MAC address)and the corresponding network address (in the form A.B.C.D.).MAC address is necessary for one hop communication, while networkaddress is used for routing purposes. Upon association, each nodestores his parent node addresses in the first row of the table andpossibly the addresses of its children nodes.

Whenever a node receives a message to forward, it checks thePacket Scope field in the network header. Depending on the value ofthe packet scope, different routing strategies are adopted:• LOCAL BROADCAST: in this case the message is simply sent

to all reachable nodes;• BROADCAST: in this case the message must be delivered to

all nodes in the network. To ensure this condition every nodethat receives a broadcast message forward it again to the radio.To prevent traffic explosion over the channel every node checksfor duplicate messages through the Broadcast Sequence Numberand discards those who were already received and forwarded;

• UNICAST: The forwarding node searches for the next hop inhis routing table: if the network destination address is in therouting table, the message is sent using the corresponding MACaddress. Else, a comparison operation is performed to forwardthe message in the proper subtree, using only the first K + 1fields of the destination address, being K the current hop counttowards the PAN coordinator. Referring to Figure 1, assumethat node with address 1.0.0.0.0 (K = 1) receives a messagedestined to 1.2.1.0.0: the forwarding node checks his routingtable and select as next hop the child whose first K = 2 fieldsare 1.2 (i.e. node 1.2.0.0.0). This operation is recursively doneperformed in each level of the tree, providing correct deliveryof packets.

• TO PAN COORD: in this case the message is destined to theroot of the tree, so every node simply forwards it to its parent;

HAT protocol inherently supports node mobility since changes innetwork topology caused by death of nodes or variations in RF pathsthat can occur in presence of moving obstacles, but it is not reactiveto frequent changes due to mobile nodes. To avoid several data lossesin downlink traffic when the receiving node is mobile, we introduceprotocol modifications in order to handle high mobility of nodes.

IV. ENABLING MOBILITY: HAT-MOBILE

In this section we present HAT-Mobile, a modification of HATprotocol that allows nodes to move throughout a specific coveragearea without losing connection with network. In HAT-Mobile, nodesare divided in two categories: fixed and mobile nodes. Fixed nodeshave no mobility and create the routing tree, while mobile nodes can

move freely within the coverage area. We impose that mobile nodescan join the routing tree only as leaves.

In order to maintain connection with network, mobile nodesperiodically check their routing tables to evaluate the quality of linkwith their current parent node and neighbors nodes. If the receivedsignal strength from the current parent node becomes lower than adefined threshold τ1 (equal to -70 dB in our experiments), the nodecan set up a new association with a neighbor node k∗ among the setP of surrounding nodes with better characteristics, according to thefollowing equation:

k∗ = arg.maxk∈P

(J(k))

s.t. J(k∗) > J(p) + τ2(3)

where J is the utility function defined in section III-A, J(p) is thecost function of the current parent node and τ2 is a power thresholdthat forces the new association to have better characteristics thanthe previous one (equal to 10 dB in our experiments). Moreoverτ2 prevents the mobile nodes to frequently start new associationprocedures.

If a mobile node decides to set up a new association, it starts anhandover process that cause a de-association with parent node andan association with the chosen neighbor node k∗.

A. Handover Procedure

A mobile node that needs an handover procedure switches to theHandover state and sends an explicit handover request (H REQ) tothe selected neighbor node, which in turn responds with a messagecontaining a new network address (H RES). Then the requestingmobile node sends an update message to his old parent node tocommunicate his de-association and then switches to AWN state.Figure 4(a) shows an example of handover process.

B. Local management of handover process

In order to limit signaling traffic involved in the handover proce-dure thus saving energy, we propose an approach to handle handoverinformation locally by leveraging handover tables and exchange ofmessages in sub-tree of the topology tree.

Upon handover phase, the old parent of the mobile node involved inthe process sends an handover table update message (H UPD) to theRoot Node of the two fixed node that have implemented the handoverprocess (namely the old and the new parent of the mobile node). TheH UPD message contains the old and new network address of themobile node, together with its MAC address. These information arestored by the Root Node in an handover table and are used for routingpurposes.

The structure of handover table is:• MAC Address: MAC Address of mobile node;• Old Network Address: Network address of mobile node before

handover procedure;• New network address: Network address of mobile node after

handover procedure;Figure 4(b) shows an example of local management of handover

process. A Root Node, that receives an H UPD with handoverinformation, can perform different actions:• The MAC address contained in the H UPD it’s not in its

handover table; the Root Node stores the three addresses in thefirst free entry of the table.

• The MAC address contained in the H UPD is in its han-dover table and the value of New network address stored inthe handover table is equal to the field Old network address

contained in H UPD. This situation happens when a mobilenode perform two handovers with nodes that have the sameRoot Node. In this case the Root Node overwrites the value ofNew network address.

• The MAC address contained in the H UPD is in its handovertable and the value of Old network address stored in the han-dover table is equal to the field New network address containedin H UPD. This situation happens when a mobile node performsan handover with a node that was its parent node previously. Inthis case the Root Node delete the entry.

PAN Coordinator

2.0.0.0.0

2.1.0.0.0

1.0.0.0.0

1.1.0.0.0

1.2.0.0.0

M

Mobile Node1.2.1.0.0

H_REQ

H_RES

M

1.2.1.0.0

Root Node

(a)

2.0.0.0.0

2.1.0.0.0

1.0.0.0.0

1.1.0.0.0

1.2.0.0.0

M

H_UPD

H_UPD

1.1.1.0.0

1.2.1.0.0 1.1.1.0.0 M

H_Table PAN Coordinator

Root Node

(b)

Fig. 4. Handover process. (a) Mobile node M starts an handover procedures.(b) The H UPD message is sent to the Root Node of the two fixed nodesinvolved in the handover process and the handover table is updated.

C. Routing

Whenever a node receives a message to forward, it checksits handover table. If the destination address is contained in theOld network address column of the table, the destination node hasperformed an handover. In this case is necessary to overwrite thedestination address of the message to forward with the new networkaddress contained in the handover table. Successively, the routingprocedure described in III-B can be performed as it is.

D. Addresses Management

During the handover procedure new network addresses are assignedto mobile nodes, and the handover information is stored locally.Whenever a new network address is required, it stands to reasonthat no one of the addresses present in the handover tables of thefixed nodes can be assigned. Doing the contrary would cause errorsin the forwarding of messages, since the same network address wouldpoint to two different mobile nodes (one assigned directly, and theother pointed through a handover table). For this reason it is ofprimary importance to lock network addresses involved in handoverprocedures. Moreover, since the number of assignable addresses islimited, it is necessary to implement specific procedures in order tounlock network addresses for further assignment.

1) Address release: This procedure is linked to the case of doublehandover described in IV-B, where a Root Node overwrites the valuecontained in the New network address field of the handover table.In this case is possible to unlock the overwritten network address,because it becomes out of date. So the Root Node sends an addressrelease message (A R) to advice the old parent node that the specifiednetwork address can be unlocked (Figure 5).

2) Address release request: This is an on-demand procedure thata fixed node implements when only 25% of its address subspace isunlocked. When a fixed node is in this situation, it sends an addressrelease request message A R R to its parent node containing a locked

A

B C

%

&

(a)

H_UPD

x y M

H_Table

A

B C

D

M

(b)

A

B C

D

M

x z

H_UPD

H_Table

M

(c)

A

A_R(y) B C

D

M

(d)

Fig. 5. Procedure of Address Release. (a) Mobile node M with networkaddress x switches from B to C and receives address y. (b) B sends an updateto node A, Root of B and C. A stores handover information in its handovertable. (c) M switches from C to D and receives address z, node C sendsan update to A. Handover information are updated. (d) Node A recognize adouble handover and network address y can be released.

network address that is required to unlock. When a node receive anA R R performs two actions:• If the network address is contained in old network address

column of its handover table, it inserts in the A R R messagethe value of new network address;

• It forwards the A R R message to its parent node.When the PAN Coordinator receives the A R R message,

it sends an announce handover message (A HAN) with thenew network address of the mobile node to the gateway that updatesthe actual network address of mobile node. In this way, all the entriesregarding the locked address in the handover tables are useless andthe address can be unlocked. Then, the PAN Coordinator sends anA R message (described in IV-D1) to advice the requesting node thatit can unlock the specified network address.

3) Address reset: A fixed node must implement this procedurewhen the association with a mobile node is lost. In fact it isnecessary to delete all the entries in the handover tables that containsinformation about the disconnected mobile node. The fixed nodesends an address reset message (A RESET) that contains networkaddress of mobile node to his parent node.

A node that receive an A RESET message, deletes the entryrelevant to the specified network address and forward the message tothe parent node, so that all the entries relative to the lost node aredeleted recursively.

V. PERFORMANCE EVALUATION

In order to evaluate the performance of the proposed protocol, wecarried out different experiments using MEMSIC IRIS sensor nodesoperated by TinyOS. In the first experiment we evaluate the latencyof handover procedures. This delay refers to the interval between thetransmission of the H REQ message from a mobile node to a fixednode and the update of the handover table of the Root Node involvedin the handover procedure (Figure 4). This latency can be computedas sum of two contributes:• Handover message time: interval between the transmission of

a H REQ message and the reception of the ACK of H UPD

A B

C

M

PAN Coordinator

A_R_R(x)

(a)

A B

C

M

PAN Coordinator x y M

H_Table

(b)

A B

C

M

A_HANPAN Coordinator

(c)

A B

C

M

PAN Coordinator x y M

H_Table

A_R(x)

(d)

Fig. 6. Procedure of Address Release Request. (a) Node A requires to unlocknetwork address x. A R R message is sent uplink. (b) PAN coordinatorrecognize address x in its handover table. (c) PAN coordinator sends aA HAN to the gateway in order to update node list. (d) PAN coordinatorinforms node A to unlock address x.

message from a mobile nodes requesting a handover. Note thatthis contribute is constant and does not depend on the currenttree topology. It results from our experiments that the handovermessage time is on average 60 ms.

• Tables update time: time spent to update the handover tablesof the nodes involved in the procedure. As explained in sectionIV-B the H UPD message sent by the mobile node must reachthe Root of the fixed nodes involved in the process. So thisinterval does depend on the topology of the tree, in particularon the number of hops between the mobile node and the RootNode.

To evaluate this delay, we implemented a testbed that generates aconstant traffic at a rate of 20 Hz from the PAN coordinator towards amobile node. Since the mobile nodes is unreachable before the updateof the handover table, the interval of packet mis-reception providesan estimate of the handover latency. We implemented a timer on themobile node that starts when the ACK of the H UPD message isreceived and stops when a new message is received (this means thatthe handover table was updated at the Root Node).

We tried different topologies, varying the hop count between themobile node and the Root of the old and new parent to estimate thehandover latency. Table I shows the total latency obtained from ourexperiments (including the Handover Message time).

Hops count Total Latency [ms]2 1723 2664 374

TABLE IHANDOVER LATENCY

In the second experiment we set up a network composed of 8 fixednode distributed in an area of about 120 m2, setting up a routing treeas the one showed in Figure 7. We transmitted test packets withdifferent rates from the PAN coordinator to a mobile node, movingwith a speed of 1 m/s within the coverage area, following a fixed path(the dotted red line in Figure 7). We evaluated the performance of the

proposed protocol through the estimation of Packet Error Rate underdifferent conditions, varying both data transfer rate and transmissionpower levels. In order to emphasize the improvement of HAT-Mobileover HAT, we carried out an experiment with two mobile nodesoperating the two version of the proposed protocols.

PAN Coordinator Fixed Nodes Start Stop Trajectory Association

Fig. 7. Test with a realistic scenery. The dotted line represents thetrajectory of the mobile node during the experiments. The network topologyis represented with black lines, and the fixed nodes composing the sensornetworks are displayed with blue dots.

Figure 8 shows the Packet Error Rate of HAT-Mobile, varying thedata rate and for different transmission output powers. We observethat when the transmission power is set to higher values, the PERdecreases. This is due to the larger coverage area of fixed nodes, thatallow the mobile node to start less handover procedures.

1 2 3 4 5 6 7 80

1

2

3

4

5

6

Data Rate [Kbit/s]

Pack

et E

rror R

ate

[%]

!3.2 dBm!12.2 dBm

Fig. 8. Packet Error Rate of HAT-Mobile with different data rates andtransmission powers. The mobile node is moving at 1 m/s in an area of about120 m2.

Figure 9 shows the comparison between HAT and HAT-Mobilewith different data rates and with the same experiment settings ofFigure 7. The transmission power of both fixed and mobile nodes wasset to -12.2 dBm. Expectedly, the Packet Error Rate increases with theoffered data rate for both routing solutions. We further observe thatHAT-Mobile protocol achieved clear improvements in Packet ErrorRate compared to HAT protocol.

Besides reducing the PER, HAT-Mobile protocol allows also toreduce the total energy consumption due to the local management ofthe handover information. In other words, the local management ofhandovers allows to reduce the total number of signalling messagesto be exchanged to support mobility, thus reducing the overall energyconsumption. In order to quantify the reduced energy consumption,

1 2 # $ % & ' (0

%

10

1%

20

2%

*ata .ate 012it456

Pa89

et :

rror .

ate

0=6

>A@!Ao2iBe>A@

Fig. 9. Packet Error Rate of HAT and HAT-MOBILE protocol with differentdata rate.

we implemented a simulator for HAT and HAT-Mobile in MATLAB.The simulator deploys random network topologies with variablenumber of sensor nodes, and sets up the routing tree according tothe procedures described in Section III. A sample network topologywith 100 fixed nodes in reported in Figure 10. An increasing numberof mobile nodes moving according to a Random Waypoint model isthen added to the topology. Handovers are triggered according to therules of HAT (Sec. III) and HAT-Mobile (Sec. IV).

The simulator then computes the total energy consumption relatedto handovers. To this extent, we used a reference energy model basedon MEMSIC IRIS datasheet, in which the radio dissipates 200 nJ perbit. We assumed that both H UPD message and MA message haveequal size (176 bit in our implementation).

100 50 0 50 100

100

80

60

40

20

0

20

40

60

80

100

Fig. 10. 100-nodes random network used in our experiments. The red crossin [0,0] is the PAN coordinator, while the blue dots are the fixed nodes.Associations are represented with black lines.

Figure 11 reports the total energy consumption when varying thenumber of mobile sensor nodes. Notably, HAT-Mobile improves theenergy savings of the updating procedure, achieving between 2x and3x reduction in energy compared to HAT.

0 10 20 30 40 500

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Number of mobile nodes

Tota

l Ene

rgy

Dis

sipa

ted

in s

yste

m (J

oule

)

HATHAT Mobile

Fig. 11. Energy efficiency of HAT-Mobile over HAT

VI. CONCLUSIONS

In this paper, we have addressed the issue of supporting nodemobility in hybrid Wireless Sensor Networks composed of staticand mobile nodes. Namely, we have proposed a a tree-based routingprotocol able dynamically construct routing topologies as the mobilenodes move throughout the network arena.

The proposed approach, named HAT-Mobile, includes proactivetechniques to speed up the handover procedures of mobile sensornodes among different access points, while preserving bi-directionalconnectivity to/from the root node of the tree (PAN coordinator).HAT-Mobile further features solutions to limit the impact of the sig-nalling overhead required to support the handover procedures, whichconsequently reduces the energy consumption for the overall processof mobility support. The experiment carried out with commercialhardware have demonstrated the potentials of HAT-Mobile in termsof energy efficiency, handover latency reduction, and reduced PacketError Rate.

ACKNOWLEDGMENTS

This work has been partially supported by project LAURA, Local-ization and Ubiquitous Monitoring of Patients for Health care supportfinanced by the Politecnico di Milano.

REFERENCES

[1] I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “A surveyon sensor networks,” Communications Magazine, IEEE, vol. 40, no. 8,pp. 102 – 114, aug. 2002.

[2] M. Quwaider, J. Rao, and S. Biswas, “Body-posture-based dynamic linkpower control in wearable sensor networks,” Comm. Mag., vol. 48, no. 7,pp. 134–142, 2010.

[3] “http://laura.como.polimi.it.”[4] A. Redondi, M. Tagliasacchi, M. Cesana, L. Borsani, P. Tarrio, and

F. Salice, “LAURA - LocAlization and Ubiquitous monitoRing of pA-tients for health care support,” in Advances in Positioning and Location-Enabled Communications, 2010. APLEC ’10., IEEE International Work-shop on, 2010.

[5] D.-S. Kim and Y.-J. Chung, “Self-Organization Routing Protocol Sup-porting Mobile Nodes for Wireless Sensor Networks,” in Computer andComputational Sciences, 2006. IMSCCS ’06. First International Multi-Symposiums on, 2006.

[6] G. Santhosh Kumar, M. V. Vinu Paul, and K. Poulose Jacob, “MobilityMetric based LEACH-Mobile Protocol,” in Advanced Computing andCommunications, 2008. ADCOM 2008. 16th International Conferenceon, 2008.

[7] L. Nguyen, X. Defago, R. Beuran, and Y. Shinoda, “An Energy EfficientRouting Scheme for Mobile Wireless Sensor Networks,” in WirelessCommunication Systems. 2008. ISWCS ’08. IEEE International Sym-posium on, 2008.

[8] S. A. B. Awwad, C. K. Ng, N. K. Noordin, and M. F. A. Rasid, “ClusterBased Routing Protocol for Mobile Nodes in Wireless Sensor Network,”in Collaborative Technologies and Systems, 2009. CTS ’09. InternationalSymposium on, Volume: 2, 2009.

[9] A. Koucheryavy and A. Salim, “Prediction-based clustering algorithmfor mobile wireless sensor networks,” in Advanced CommunicationTechnology (ICACT), 2010 The 12th International Conference on, 2010.

[10] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “Energy ef-ficient communication protocol for wireless microsensor networks,” inSystem Sciences. Proceedings of the 33rd Annual Hawaii InternationalConference on, 2000.

[11] J. Y. Choi, J. H. Lee, and Y. J. Chung, “Minimal Hop Count PathRouting Algorithm for Mobile Sensor Networks,” in Computer andComputational Sciences, 2006. IMSCCS ’06. First International Multi-Symposiums on, 2006.