Computing, March 2015, Vol. 97, Issue 3, pp 205-236

LINKORD: Link Ordering-Based Data Gathering Protocolfor Wireless Sensor Networks

Marjan Radi1,∗, Behnam Dezfouli1, K. A. Bakar1, S. A. Razak1, Malrey Lee2

1Department of Computer Science, Faculty of Computing, Universiti Teknologi Malaysia (UTM), Malaysia2School of Electronics and Information Engineering, ChonBuk National University, Korea

Abstract

With respect to the multi-hop communication pattern of wireless sensor networks, all the nodes should establish multi-hoppaths towards a common data gathering point to provide a data gathering service for the underlying applications.Although data gathering protocols provide a simple service, these protocols suffer from poor performance in practice dueto the power constraints of low-power sensor nodes and unreliability of wireless links. Existing data gathering protocolsrely on the ETX metric to find high-throughput paths through assuming there is an infinite number of transmissionattempts at the link layer for delivering a single packet over every link. However, in practice the link layer provides abounded number of transmissions per packet over individual links. Therefore, employing existing data gathering protocolsin these situations may result in the construction of the paths that require more than maximum number of provided linklayer transmissions for delivering a single packet over each link. In this regard, we propose a path cost function whichconsiders the limitation on the number of provided link layer transmissions and relative position of the links along thepaths according to their data transmission probability. Furthermore, we introduce a data gathering protocol which usesthe proposed path cost function to construct high-throughput paths. Moreover, this protocol employs a newly designedcongestion control mechanism during the data transmission process to provide energy-efficient and high-throughput datadelivery. The simulation results show that, the proposed protocol improves data delivery ratio by 70% and networkgoodput by 80%, while it reduces the consumed energy for data delivery by 50% compared to the default data gatheringprotocol of TinyOS.

Keywords: Wireless Sensor Networks, Data Gathering, Link Ordering, Link Quality, Energy-Efficiency

1. Introduction

Since wireless sensor networks offer new opportunitiesto observe the physical environments and interact withinaccessible areas (e.g., jungles, earthquake disaster area,battlefield target area, or inside a nuclear reactor), thesenetworks are being used in a wide range of applications[1, 2]. The main observable traffic pattern in wirelesssensor networks is many-to-one, in which data flows frommany sensor nodes towards a single base station [3–6]. Dueto the limited radio range of the sensor nodes, intermedi-ate nodes require to perform data relaying to forward thecollected data from source nodes towards the sink node[7–9]. Therefore data gathering service is one of the keybuilding blocks of different wireless sensor networks proto-cols to support multi-hop data transmission pattern [10].The main aim of data gathering protocols is to constructthe network routing topology, which allows the collecteddata from source nodes to be delivered to the network datagathering point [10, 11].

∗Corresponding author:Email address: radi@ieee.org (Marjan Radi)

Due to the importance of providing efficient data gath-ering capability in wireless sensor networks, several datagathering protocols have been developed over the pastdecade. The utilized path cost function is the main fac-tor that differentiates these protocols [12]. Experimentalstudies on the performance of the existing data gatheringprotocols show that, while the existing data gathering pro-tocols provide a basic service for many applications, theysuffer from poor performance in practice (in terms of re-liable and energy-efficient data delivery) due to the highdynamics of low-power wireless links [13–15]. According tothese studies, the required number of link layer transmis-sions (including retransmissions) for successful packet de-livery from a given source node to the sink over unreliablelinks influences the network-wide contentions, throughputand network energy consumption [16, 17]. Therefore, re-ducing the required number of link layer transmissions iscritical to provide efficient data gathering in wireless sensornetworks [18, 19]. In this context, the Expected Transmis-sion count metric (ETX), is widely utilized by the existingdata gathering protocols to provide efficient and reliabledata gathering in wireless sensor networks [12]. The ETXvalue of a given link is defined as 1

p×q , where p and q are

ComputingArchives for Scientific ComputingDOI: http://link.springer.com/article/10.1007/s00607-014-0414-9

1

M. Radi et al. — Springer : Link

Figure 1: The influence of link positions on the data transmissioncost of paths.

probabilities that a packet is successfully transmitted andacknowledged respectively [20]. Based on the definitionof this metric, it assumes the link layer provides an infi-nite number of transmissions at each link to deliver everytransmitted data packet to the destination [12, 21]. Sinceby this assumption the link layer never drops a packet,the ETX value of each path only depends on the ETXof its constructed links, while the location of the links onthe path is not important. Therefore, this unrealistic as-sumption allows a commutative path cost computation,which simplifies the calculation of the expected numberof transmissions over each path for successful packet de-livery. However, these protocols may construct paths in-cluding links which cause a higher number of transmis-sions than the maximum number of provided link layertransmissions. Since in practice the link layer provides afinite number of transmission attempts at each link, ex-isting data gathering protocols expose low performancein the real-world implementations. The main reason isthat, packet drops due to the limited number of trans-missions at the link layer on the links near the destina-tion are very costly, as the packets have traversed severallinks before they are dropped. Figure 1 presents this is-sue through a simple example. Based on this figure theETX summation of the links along both paths are equalto 4. Assume the link layer provides at most 2 transmis-sion attempts at each link. Consequently, the probabilitythat a packet passes the link with an ETX value equal to3 is 1

3 + (1 − 13 ) × 1

3 = 0.55. Therefore, the probability ofpacket drop due to the limited number of link layer trans-missions on the last link of path1 is higher than path2.Since packet drops near the destination are very costly,the data transmission cost of path1 is higher than path2.However, simple summation of the link ETX values alongthe paths does not capture this issue. Expected number ofTransmissions On a Path (ETOP) is a recently proposedpath cost function as a part of Dynamic Source Routing(DSR) protocol for wireless mesh networks, which esti-mates the data transmission cost of individual paths withrespect to the limited number of offered link layer trans-missions at each link [22]. Since, through this cost func-tion each source node should determine the entire pathtowards the destination node by a Dijkstra algorithm, itcannot be used in wireless sensor networks. The reason is

that, in wireless sensor networks data gathering tree con-struction process should be initiated by the sink node anddata transmission cost of every path from a given sensornode towards the sink should be estimated based on thecalculated cost in the reverse direction (from sink towardsthe sensor nodes) [23]. However, designing a distributeddata gathering protocols which considers the order of thelinks along the paths from sensor nodes towards the sinkis a non-trivial task.

From the discussion given above, it is obvious that ex-isting data gathering protocols cannot provide an efficientdata gathering service when the link layer provides a finitenumber of transmission attempts at individual links. Thereason is that packet drops due to the bounded number oflink layer transmissions on the links close to the sink nodeimpose a significant packet delivery cost to the network.Therefore, in order to construct a minimum cost data gath-ering tree in term of the required number of packet trans-missions for every single packet delivery, it is required todevelop data gathering protocols which consider the fol-lowing issues: (1) the maximum number of offered linklayer transmission attempts for delivering a single packetover each link, (2) relative position of the links along thepaths, and (3) packet delivery probability of individuallinks. In this regard the main contributions of this paperare:

Firstly, we propose a path cost function which considersthe limitation on the number of provided link layer trans-mission attempts at individual links, relative position ofthe links along the paths and packet delivery probabilityof every link in order to construct the paths which mini-mize the required number of transmissions for a successfulpacket delivery. The proposed path cost function, calledSuccessful or Failed packet Transmission Cost (SFTC),enables every node to estimate data transmission costthrough its neighboring nodes with respect to the relativeposition of the links from that particular node towards thesink based on the calculated cost in the reverse direction(from sink towards the sensor nodes).

Secondly, we propose a LINK ORDering based datagathering protocol (LINKORD) which is composed of twophases: 1) Data gathering tree construction phase, and2) Data transmission phase. The aim of this protocol isto provide a high performance data gathering in termsof data delivery ratio, network goodput, and energy con-sumption. During the data gathering tree constructionphase every node identifies cost of data transmission to-wards the sink node through its neighboring nodes usingthe proposed SFTC path cost function. Therefore, at theend of this phase each node has identified several pathsthrough its neighboring nodes towards the sink in the con-structed network data gathering tree. The data trans-mission phase takes care of data forwarding from sourcenodes towards the sink during network operation. Fur-thermore, this phase also handles network congestion andpath failures during the data transmission process. To thisend, a Congestion Control with Parent Change capability

2

M. Radi et al. — Springer : Link

(CCPC) approach is developed which enables every childnode to change its congested parent node in order to re-duce the network congestion level.

Thirdly, we implement the proposed data gatheringprotocol and evaluate its performance compared to theTinyOS’s Collection Tree Protocol (CTP) under two differ-ent scenarios. Comprehensive simulation studies confirmthat LINKORD improves data delivery ratio by 70%, end-to-end network goodput by 80%, and energy consumptionby 50% compared to the TinyOS’s CTP.

The rest of this paper is organized as follows: Section?? provides an overview on the existing data gatheringprotocols in wireless sensor networks. We introduce theproposed SFTC path cost function and LINKORD in Sec-tion 3 and Section 4 respectively. Performance evaluationand comparison of LINKORD against TinyOS’s CTP isperformed in Section 5. We conclude in Section 6.

2. Related Work

Due to the importance of sensor data gathering, therehas been a huge amount of research over the past decadeto provide efficient data gathering in wireless sensor net-works [12, 21, 23]. The major difference of these proto-cols is in their employed cost functions for parent selec-tion during the network data gathering tree constructionprocess. Based on the empirical studies on the characteri-zation of wireless links, data transmission quality of wire-less links fluctuates highly over time due to the effects ofwireless propagation such as multipath fading, shadowing,and path loss [24–26]. These studies suggest that employ-ing link quality-based routing metrics can provide stablenetwork performance by selecting high-quality links whichreduce the number of packet losses and retransmissions[16, 27–29]. Therefore, the majority of existing data gath-ering protocols utilize link-quality based routing metricsto construct a stable tree routing structure which includeshigh-quality paths.

MintRoute was the first proposed data gathering pro-tocol for wireless sensor networks. This protocol uses adistance vector routing approach to advertise global rout-ing state [13]. Furthermore, it uses the ETX [20] as therouting cost metric to compute the data transmission costof available paths. To this aim, MintRoute utilizes rout-ing tables to preserve the neighborhood information atindividual nodes along with their respective data trans-mission cost towards the sink node. In MintRoute, theentire nodes periodically broadcast routing messages toshare their achieved routing information towards the sinknode and update the preserved routing information at in-dividual nodes.

MultihopLQI is a variation of MintRoute which uses ahardware-based link quality estimation metric for com-puting the data transmission cost of different paths [30].Unlike MintRoute, MultihopLQI uses the link quality in-dicator (LQI) metric as its routing cost metric which is

provided by 802.15.4 RF transceivers [27]. This proto-col avoids keeping routing tables through maintaining thestate of the best parent at a given time. Although LQIcan provide immediate approximations regarding to thebit error rate of the successfully received packets, this in-formation can be only provided by the CC2420 radio chip[31]. This limitation causes the MultiHopLQI protocolto be hardware dependent. Moreover, as this approachestimates the quality of links based on the successfullyreceived packets, it cannot differentiate between packetlosses due to the poor link quality or those due to thecollisions [32, 33]. These inaccurate link quality estima-tions result in frequent network tree reconstruction andunstable routing topology.

The Collection Tree Protocol (CTP) is the default datagathering protocol of TinyOS [21]. The main aim of thisprotocol is to benefit from integration of the data and con-trol plans in order to provide quick response against rout-ing failures during the data transmission process and re-pair the broken paths with a minimum interruption in thedata gathering performance. As with MintRoute, CTPalso uses a distance vector routing algorithm with ETXcost metric to establish the paths that minimize the ex-pected number of transmissions for data delivery. In addi-tion, this protocol uses the network active traffic to probethe topology and detect routing problems, while it alsoemploys the Trickle algorithm [34] to control the beacon-ing exchange rate of the network nodes. In this protocolthe routing framework consists of three main components:Routing Engine (RE) that determines the best next-hopneighboring node towards the sink node as well as up-dating the routing tables; the Forwarding Engine (FE),that takes care of forwarding data packets to the deter-mined nodes by the RE; and the Link Estimator (LE)that periodically determines the data transmission qualityof available links using the four-bit link quality estima-tion approach [35]. Furthermore, TinyOS’ CTP is capableof detecting network congestion during the data transmis-sion process through setting the congestion flag of the datapackets [12]. In this context, whenever the packet bufferof a node is at least half full, it sets the congestion flagof its outgoing packets to 1 in order to notify the childnodes about its congestion status. If a node identifies itsparent is congested, it stops its packet transmission untilthe congestion status of its parent changes or it finds analternative path towards the sink. In this protocol a nodewill change its current congested parent to another parentwhose multi-hop ETX value is lower than the other avail-able neighbors.

Hyper is a data gathering protocol which enables mobileusers to access the sensor network data during their envi-ronmental evaluations or maintenance work. This protocoluses a distance vector routing strategy for relaying datapackets to the mobile sinks [36]. To support a low-latencyaccess to the sensor data by mobile users, Hyper providesfast neighborhood assessment and multiple data gatheringtrees for simultaneous utilization by several users. Since

3

M. Radi et al. — Springer : Link

Hyper uses ETX as the routing cost metric to constructreliable routing trees, it can initialize the tree constructionprocess whenever the neighborhood connectivity is evalu-ated. Consequently, each node periodically exchanges bea-con messages with its neighboring nodes to obtain the re-quired link quality information for tree construction. Sincethe root of each constructed tree is a mobile sink, whenevera mobile sink arrives to a new location it should initiatesthe link estimation process for evaluating its connectionstowards its new neighbors by broadcasting a series of bea-con messages. When each node evaluates its neighborhoodconnectivity, sink node initiates the routing tree construc-tion process by flooding a tree update message into thenetwork. Since mobile users are practically delay sensitiveand the neighborhood connectivity assessment should beperformed in a short period by the network nodes, thisprotocol cannot provide an efficient data gathering ser-vice in large-scale dense wireless sensor networks. This isdue to the fact that fast neighborhood assessment in high-density networks intensifies contentions for channel accessand causes a huge number of packet losses which in turnreduces the accuracy of the collected neighborhood infor-mation by individual nodes.

CentRoute is another data gathering protocol whichcombines a source routing approach with a centralizedroute computation mechanism (in a microserver) to res-cue the nodes from making routing decisions [37]. As withseveral other routing protocols, CentRoute uses ETX costmetric for parent selection. The main idea behind design-ing this routing framework is that the resource limitationsof sensor nodes influence the correctness and accuracy ofthe decision which is made at each mote based on its lim-ited local information. Therefore, this protocol aims toemploy microservers to make routing decisions based onthe combination of the achieved information from multi-ple motes. In order to construct a tree topology which isrooted at a microserver, each node periodically broadcastsa join request message. If a node that is already joined tothe tree receives this message, it forwards the message toa microserver via its parent. Then upon reception of thismessage at a microserver, it generates a join reply messageand forwards this message towards the sender node usingsource routing.

Dozer is another data gathering framework which aimsto fulfill the performance demands of periodic data gath-ering in monitoring applications [38]. This protocol inte-grates a tree routing protocol with a TDMA-based MAClayer to support energy-efficient data delivery by reducingidle listening and overhearing periods. To this aim, Dozerconstructs a network routing tree in which the entire com-munications between all the nodes and their parents to-wards the sink node are coordinated by a TDMA-basedMAC protocol. In order to construct this data gatheringframework, whenever a node joins to the network routingtree during the data gathering tree construction process, itbroadcasts beacon messages at the start of its time sched-ule to assign time slots for connection-requests from dis-

connected nodes and enables them to join to the networktree. Furthermore, each node preserves a list of prospec-tive parents for fast recovery from route failures during thedata transmission process.

3. Successful or Failed Packet Transmission CostFunction Design

This section dedicated to describe the proposed pathcost function in this paper. In this regard, the considerednetwork and packet transmission models for calculatingpacket transmission cost of multi-hop paths are given inthe first part of this section. Finally, the last part presentsthe design of the proposed SFTC cost function in detail.

3.1. Network Model and NotationsA wireless sensor network can be considered as a di-

rected graph G(N, E, P), where N is the set of sensornodes, E is the set of links between nodes, and P is the setof packet delivery probabilities over the links in set E. LetNi be the set of neighboring nodes of node ni. Therefore,set E should be represented as E={ex,y|x ∈ N and y ∈ Nx}and each link ex,y∈E has a packet delivery probability0 < px,y ≤ 1 with a single transmission effort.

The packet transmission process is modelled as follows.At the start of the data transmission phase, a given sourcenode n0 starts to transmit its data packets towards the sinknode over a path with n hops through node n1, n2, ..., nn.Therefore, node n0 will pass its packet to the link layerwhich is responsible for transmitting this packet to noden1. The transmitted packet by node n0 will be received bynode n1 with probability p0,1 after 1 transmission attempt.If node n1 does not receive the packet transmitted by noden0, this packet will be transmitted again by the link layerof node n0. Link layer of node n0 repeats this processuntil the maximum number of link layer transmissions (rtransmissions) is reached or the packet is successfully re-ceived by node n1. If after the rth retry the packet dosenot reach to the receiver node n1, the sender node willdrop the packet. While, if node n1 receives the transmit-ted packet successfully, it will transmit the packet to noden2. This process will be repeated between all the nodes onthe selected path, until node nn receives the transmittedpacket from node n0 or the packet drops at an intermedi-ate node along the path. Let hs be the number of succes-sive hops that a packet passed successfully from a sourcenode before it is dropped. Thus, hs=i means that thetransmitted packet from node ni failed to reach to nodeni+1. Therefore, if tx,y signifies the required number oflink layer transmissions for a single packet delivery overlink ex,y, hs=i denotes that ti,i+1 was more than r. Sincethe link layer offers a bounded number of transmission at-tempts at individual links, some packets may be droppedduring the data transmission process somewhere along theselected paths. By considering this possibility the relativeposition of the links highly influences the data delivery cost

4

M. Radi et al. — Springer : Link

of different paths. Therefore, the data transmission costof every path cannot be calculated through a simple sum-mation of the data transmission quality of its constructedlinks which has been employed in the existing data gath-ering protocols [12, 21].

Consider the case where the link layer provides an infi-nite number of transmissions for packet delivery over indi-vidual links. By this assumption, every node can calculatethe required number of packet transmissions for successfulpacket delivery to its neighboring nodes as:

E[ex,y] =∞∑

i=1i(1 − px,y)i−1px,y = 1

px,y(1)

where E [ex,y] is the expected number of required trans-missions for successful packet transmission over link ex,y,and px,y is the probability of successful packet transmis-sion from node nx towards node ny. With respect tothe Equation 1, the expected number of required packettransmissions for successful packet delivery over a path(n0,n1, ...,nn) can be calculated as:

E[e0,n] =n−1∑i=0

1pi,i+1

(2)

Now assume that link layer performs at most r trans-mission attempts over each link for a single packet delivery.In this case the expected number of packet transmissionattempts for transmitting a single packet over link ei,i+1is:

E[ei,i+1] = (r∑

k=1

k(1 − pi,i+1)k−1pi,i+1) + r(1 − pi,i+1)r (3)

where (1 − pi,i+1)k−1pi,i+1 is the probability that thetransmitted packet from node ni have been successfully de-livered to node ni+1 at kth transmission attempt. There-fore, the expected number of transmissions for successfulpacket delivery over link ei,i+1 after performing k trans-mission attempts is calculated through multiplying thisterm by k. Moreover, term r(1 − pi,i+1)r denotes theexpected number of transmission attempts performed bynode ni while node ni+1 could not receive the transmittedpacket. With respect to Equation 3, the expected numberof packet transmissions over a path (n0,n1, ...,nn) in termsof packet delivery probability of the links and the maxi-mum number of link layer transmissions over each link can

11

][

1,01,0

peE

21

][2,1

2,1 p

eE

7

1]

[

3,2

3,2

p

eE

1

1][

1,0

1,0

p

eE

71

][2,1

2,1 p

eE

21

][

3,2

3,2

p

eE

Path1

Path2

Figure 2: A sample scenario to evaluate data transmission cost overtwo different paths from a source node towards a given destinationnode.

be expressed as:

E[e0,n] = Ppath(Es[e0,n]) + (1 − Ppath)(Ef [e0,n])where

Ppath =n−1∏i=0

(1 − (1 − pi,i+1)r)

Es[e0,n] =n−1∑i=0

E[ei,i+1]

Ef [e0,n] =n−1∑i=0

(1 − pi,i+1)r(i−1∏j=0

(1 − (1 − pj,j+1)r))(i∑

l=0

E[el,l+1])

(4)where

∏−1j=0=1, Ppath signifies the probability of success-

ful reception of the transmitted packet by source node n0at the sink node (i.e., node nn), 1-Ppath is the probabilityof packet drop over a path from source node n0 towardsthe sink node, Es[e0,n] is the expected number of packettransmissions for packet delivery over path n0, ...,nn, andEf [e0,n] is the expected number of packet transmissionsover path n0, ...,nn, while the packet fails to reach the sinknode. Furthermore, term (1 − (1 − pi,i+1)r) indicates theprobability of successfully packet delivery over link ei,i+1and term (1 − pi,i+1)r represents the probability that apacket fails to pass the link ei,i+1 after performing r trans-mission attempts.

Figure 2 illustrates two different paths from node n0towards node n3 to clarify the differences between datatransmission cost of multi-hop paths when the link layerprovides a limited or an infinite number of transmission at-tempts. In the case that the link layer provides an infinitenumber of packet transmissions for a successful packet de-livery, the data transmission cost of both paths is equal to10 (according to Equation 2). Consider the scenario wherethe link layer provides at most 2 transmission attempts ateach link (i.e., r=2). First assume node n0 wants to trans-mit a packet to node n3 through path1. The probabilitythat the transmitted data packet from node n0 passes linke0,1, link e1,2 and link e2,3 with at most 2 transmissionattempts is 1, 0.75, and 0.26 respectively. Therefore, theprobability of packet drop after performing r transmission

5

M. Radi et al. — Springer : Link

attempts at each link is equal to 0, 0.25 and 0.73 respec-tively. Based on Equation 4, data transmission cost ofpath1 in the case where the link layer provides at most 2transmission attempts is equal to 5. While, if node n0 se-lects path2 to transmit a data packet towards node n3, theexpected number of packet transmissions over this path isequal to 4.19. The higher data transmission cost of path1compared to path2 is due to the fact, that in the firstpath, the low-quality links with high probability of packetdrop after performing 2 transmission attempts are locatednear the destination node. With respect to this examplein the cases where the link layer offers a bounded numberof transmission attempts, packet delivery cost of a multi-hop path is highly related to the maximum number of linklayer transmissions and relative position of the links alongthe path. However, assuming an infinite number of linklayer transmissions over individual links simplifies the cal-culation of the required number of packet transmissions forsuccessful packet delivery from a source node towards thedestination node. The reason is that, by this assumptionthe link layer never drops a packet over the links alonga path. Therefore, the expected number of packet trans-missions over a path only depends on the packet deliveryprobability of the links along the path, while their arrange-ment is not important.

3.2. Successful or Failed Packet Transmission Cost ofMulti-Hop Paths

In data gathering protocols the sink node initiates theconstruction process of the network data gathering treethrough broadcasting a routing packet to the network. Tothis aim, the utilized path cost function in these proto-cols should be able to estimate the data transmission costfrom each node toward the sink based on the calculatedcost in the reverse direction (from sink towards the sensornodes). In this context, the SFTC is designed in such away that it can estimate cost of data delivery from everynode to the sink node through the transmitted packet fromthe sink node which traverses the backward links towardsthe nodes. However, as the proposed routing cost functionconsiders the relative position of the links along the paths,estimating the transmission cost from every node towardsthe sink based on the calculated cost in the reverse direc-tion is non-trivial.

According to the given network model and variables inSection 3.1, SFTC of a path (n0, n1,...,nn) with n hopsfrom sink node nn towards source node n0 can be repre-sented as follows:

SF T C = (1∑

i=n

E[ei−1,i]Ψ(ei,n)) (5)

where Ψ(ei,n) is a the weighting function that scales therequired number of transmission attempts at each link inorder to reflect the influence of link positions and theirrespective data transmission quality on the data transmis-sion cost of a path. The insight behind using this weighting

function is that, it scales the expected number of link layertransmissions on a given link ei−1,i based on the ratio ofthe required number of packet transmissions for success-ful data delivery over the traversed links from sink nodenn till node ni to the maximum number of offered linklayer transmission attempts. In order to have a success-ful packet delivery over a given link through performingat most r transmission attempts, the ratio of the requirednumber of packet transmissions over that link for success-ful packet delivery to the r value should be less or equalto 1. If this ratio is higher than 1, there is a probabilityof packet drop after performing r transmission attempts.Therefore, to calculate the data transmission cost of differ-ent paths based on the maximum number of provided linklayer transmission attempts at individual links (i.e., r),weighting function Ψ(ei,n) can take the following values:

Ψ(ei,n) ={ 1 if n = i∏i+1

j=n Ψ(ej,j−1) if n , i

where

Ψ(ej,j−1) ={

1 if (1/pj−1,j)r ≤ 1

(1/pj−1,j)r if (1/pj−1,j)

r > 1

(6)

Furthermore, the expected number of packet transmissionsover link ei−1,i in terms of packet delivery probability overthe links and maximum number of link layer transmissionattempts in the cases where the link layer provides at mostr transmission attempts has been shown through Equa-tion 3. By substituting Equation 3 in Equation 5, theestimated cost for a single packet transmission over a path(n0, n1,...,nn) with n hops in term of number of packettransmissions can be calculated as:

SF T C = (1∑

i=n

((r∑

k=1

k(1 − pi−1,i)k−1pi−1,i) + r(1 − pi−1,i)r)Ψ(ei,n))

(7)

In order to clarify the differences between∑n−1i=0 E[ei,i+1] and SFTC in the situations where

the link layer provides a bounded number of transmissionattempts at individual links, Table 1 shows the data trans-mission cost of different paths through these path costfunctions. As can be seen from this table,

∑n−1i=0 E[ei,i+1]

provides similar data transmission cost for the pathswith equal number of hops. For instance, path (1,1,0.25)and path (0.25,1,1) have an equal

∑n−1i=0 E[ei,i+1] value

regardless of the number of link layer transmissions (i.e., 1or 3 transmission attempts) and position of the links alongthe paths. While employing the SFTC path cost functionto calculate the data transmission cost of different pathswith equal

∑n−1i=0 E[ei,i+1] values results in dissimilar

values. For instance, through SFTC, path (0.25,1,1) haslower data transmission cost compared to path (1,1,0.25).This is due to the fact, that SFTC prefers the pathswith high-quality links near the destination. In fact, ifthe low-quality links are located near the destination,

6

M. Radi et al. — Springer : Link

Table 1: Comparison of the data transmission cost of multi-hop pathswith assuming a limited and an infinite number of transmission at-tempts at individual links.

Paths r SFTC∑n−1

i=0 E[ei,i+1]

Path1=(1,1,0.25) 1 9 6Path2=(0.25,1,1) 1 3 6Path3=(0.25,1,1,1) 1 4 7Path4=(1,1,0.25) 3 9.66 6Path5=(0.25,1,1) 3 9 6Path6=(0.25,1,1,1) 3 10 7

high probability of packet loss over these links results inthe waste of network resources to forward data packetsover the previous links along a path before those packetsare dropped. Therefore, although path (0.25,1,1,1) hasmore hops and higher

∑n−1i=0 E[ei,i+1] value compared

to path (1,1,0.25), but in the cases where the link layerprovides 1 transmission attempt SFTC assigns a lowercost to the first path in comparison with the secondone. However, if the link layer provides 3 transmissionattempts, SFTC prefers path (1,1,0.25) compared to thepath (0.25,1,1,1). The reason is that, in this situationthe required number of transmission attempts over a linkwith a p value equal to 0.25 is close to the number ofprovided link layer transmission attempts. Therefore, inthis case SFTC gives chance to the packets to reach thedestination with lower network resource utilization byselecting path (1,1,0.25) with 3 hops instead of selectingpath (0.25,1,1,1) with 4 hops.

4. Link Ordering-Based Data Gathering Protocol

After network initialization, every node should iden-tify at least one path towards the network data gatheringpoint (i.e., sink node) [39]. Therefore, LINKORD aims toconstruct the minimum cost network data gathering treewhich is rooted at the sink node and provides efficient datagathering during network operation through two differentphases. The first phase establishes minimum cost pathsfrom every sensor node towards the sink through the pro-posed SFTC path cost function. After construction of thenetwork data gathering tree, the second phase is responsi-ble for transmitting the collected data by the source nodestowards the sink. This section provides the detailed oper-ation of each phase.

4.1. Data Gathering Tree Construction PhaseIn the proposed LINKORD protocol every nodes uses

the SFTC path cost function to identify the data trans-mission cost towards the sink node through its neighbor-ing nodes. Therefore, each node should be aware about thedata transmission quality of its links towards its neighbor-ing nodes. We assume a link quality estimation process isperformed at the network initialization phase before thedata gathering tree construction process [20, 40]. So, dur-ing the data gathering tree construction process all the

nodes can utilize their achieved link quality informationto calculate the data transmission cost of different pathstowards the sink node.

At the start of data gathering tree construction processthrough LINKORD protocol, all the nodes initialize theirdata transmission cost towards the sink node to an in-valid value (i.e., -1) to show that they have not identifiedany path towards the sink so far. In LINKORD, the sinknode initializes the data gathering tree construction pro-cess by broadcasting a routing packet towards its neighbor-ing nodes with Minimum path cost, and Ψ(e) fields whichare initialized to 0 and 1 respectively (Lines 9-14 of Algo-rithm 1). The main format of this routing packet is illus-trated in Figure 3. During the path construction process,whenever node ni receives a routing packet from node nj , itfirst searches its neighborhood table to find the preservedlink quality information towards node nj . Node ni utilizesthe preserved neighborhood information regarding neigh-bor nj and included information in the received routingpacket to calculate the data transmission cost towards thesink node through node nj (Line 22 of Algorithm 1). Whennode ni calculates the data transmission cast towards thesink node through node nj , it preserves the routing infor-mation through this node in its routing table (i.e., pathcost, and Ψ(e) value towards the sink node). Further-more, if node ni has not identified any path towards thesink so far, (i.e., its preserved minCosti,sink variable isequal to -1), it records node nj (i.e., the node which hassent the routing packet) as its parent node. In this case,node ni also updates the Minimum path cost, and Ψ(e)fields of the received routing packet according to the lines18-31 of Algorithm 1 and rebroadcasts this packet again.While, if node ni has a parent node with minimum pathcost towards the sink, it checks whether node nj offers alower cost path compared to its selected parent node be-fore it decides to rebroadcast the received routing packet.Node ni will change its parent to node nj , if it providesa lower cost path towards the sink node compared to thecurrently selected path. Since node ni has changed itsparent and it has found a new path with lower cost com-pared to its previously announced path, it should updatethe Minimum path cost towards sink, and Ψ(e) fields ofthe received routing packet based on the newly calculatedvalues and rebroadcasts this packet again (lines 33-46 ofAlgorithm 1). While, if the data transmission cost of theidentified path through node nj is higher than the mini-mum data transmission cost which has been identified bynode ni so far, node ni only preserves the related routingcost information of node nj (lines 47-49 of Algorithm 1).This process will be repeated between all the nodes duringthe data gathering tree construction process, until all thenodes identify the data transmission cost towards the sinknode through their entire neighboring nodes.

4.2. Data Transmission PhaseWhen the network data gathering tree is established,

network nodes can start to forward their collected data

7

M. Radi et al. — Springer : Link

Algorithm 1 Data gathering tree construction algorithm.1: Notations:2: RoutingPkt: Transmitted routing packet by sink for constructing the network data gathering tree3: RecRtPacketj,i: Received routing packet by node ni which has been transmitted by node nj

4: RecRtP acketj,i → minCost: Included value in the Minimum path cost towards sink field of the received routing packet bynode ni which has been transmitted by node nj

5: RecRtP acketj,i → Ψ(ej,sink): Included value in the Ψ(e) field of the received routing packet by node ni which has beentransmitted by node nj

6: minCosti,sink: The minimum data transmission cost towards sink node which have been identified so far by nodes ni

7: P arenti: Current parent of node ni towards the sink node8: LastSFTC : The last calculated SFTC value9: if (it is sink node) then

10: create a RoutingP kt11: RoutingP kt → minCost=012: RoutingP kt → Ψ(e)=113: broadcast the RoutingP kt14: end if15: if (a RoutingP kt is received by node ni from node nj) then16: search the neighborhood table to find the corresponding entry for node nj

17: fetch pi,j

18: if (minCosti,sink==-1) then19: for (k=1;1;r) do20: E[ei,j ] = k(1 − pi,j)k−1pi,j + r(1 − pi,j)r

21: end for22: SF T C=RecRtP acketj,i → minCost+(E[ei,j ] × RecRtP acketji → Ψ(ej,sink) )23: RecRtP acketj,i → minCost = SF T C

24: if ( 1/pi,j

r ≤ 1) then25: RecRtP acketj,i → Ψ(ei,sink) = RecRtPacket j,i → Ψ(ej,sink) × 126: else27: RecRtPacket j,i → Ψ(ei,sink) = RecRtPacket j,i → Ψ(ej,sink)×( 1/pi,j

r )28: end if29: P arenti = node nj

30: LastSF T C = SF T C31: broadcast the RoutingP kt with the updated fields32: else33: for (k=1;1;r) do34: E[ei,j ] = k(1 − pi,j)k−1pi,j + r(1 − pi,j)r

35: end for36: SF T C=RecRtP acketj,i → minCost+(E[ei,j ] × RecRtP acketj,i → Ψ(ej,sink))37: if (SF T C < LastSF T C) then38: RecRtP acketj,i → minCost = SF T C

39: if ( 1/pi,j

r ≤ 1) then40: RecRtP acketj,i → Ψ(ei,sink) = RecRtP acketj,i → Ψ(ej,sink) × 141: else42: RecRtP acketj,i → Ψ(ei,sink) = RecRtP acketj,i → Ψ(ej,sink) × ( 1/pi,j

r )43: end if44: P arenti = node nj

45: LastSF T C = SF T C46: broadcast the RoutingP kt with the updated fields47: else48: preserve the calculated SFTC value and Ψ(ej,sink) for neighbor nj in the

routing table49: end if50: end if51: end if

8

M. Radi et al. — Springer : Link

Preamble SFD MAC header CRC

8 Bytes 2 Bytes

Destination

address Type

Sequence

number

Source

address Length

1 Byte 1 Byte 1 Byte 1 Byte 1 Byte

5 Bytes

Ψ(e) value

towards sink

Minimum path

cost towards sink

2 Bytes 2 Bytes 2 Bytes

Physical header MAC payload

Figure 3: Routing packet format.

towards the sink node through the identified paths. Inthis context, whenever a node collects some informationfrom environment or receives a data packet from one ofits child nodes, it forwards these data packets towards thesink node through its selected parent node during the datagathering tree construction process. Consequently, uponreception of a data packet by a given node it first checkswhether the received packet has been received previously.If it realizes that the received packet is a duplicate packet,it will discard the packet to avoid waste of network re-sources. While if the received packet is not duplicated andthe receiver node has a free space in its packet buffer, itstores the received packet into the packet queue to forwardthe packet towards the sink node. Otherwise it drops thepacket because of buffer overflow.

Due to the high dynamics of low-power wireless com-munications, limited resources of sensor nodes, and sharedwireless communication medium, many-to-one data gath-ering pattern in wireless sensor networks can easily causenetwork congestion and a huge number of packet drops asthe result of packet buffer overflow [41, 42]. Therefore, toreduce the effects of network congestion on the data gath-ering performance, the CCPC mechanism is proposed inconjunction with the developed data gathering protocol.The proposed technique exploits the incoming and outgo-ing rates of individual nodes to measure the congestiondegree of nodes based on their data packet reception, datapacket generation and packet transmission rates. To thisaim every node ni calculates the incoming rate from itsindividual child nodes (e.g., node nj) as follows:

Rj = 1Tj

(8)

where Tj is the packet reception interval from node nj .Furthermore, every node calculates its packet forward-

ing rate by inverting the time period from when a packetarrives at its MAC layer until the last bit of that packet istransmitted successfully.

In order to eliminate the overhead of transmitting con-trol packets for congestion control purpose, CCPC ap-proach adds some control bits to the data packets duringthe data transmission process in order to provide valuableinformation for congestion control and route maintenancepurposes. As demonstrated in Figure 4, the required in-formation to perform the proposed CCPC mechanism isadded to each data packet as a CCPC control frame. As

with routing packet, in this packet 2 bytes are used to in-clude the data transmission cost from every sender nodetowards the sink for path maintenance purpose. The In-coming rate and Outgoing rate fields share the congestiondegree of every node among its neighboring nodes, whichallows the child nodes of a congested node to change theircurrent parent to the best potential parent that may re-duce the network congestion level. Selected child field de-termines the identity of the child node that should changeits current congested parent node. Finally, the PC bitshows the parent change eligibility of the sender node, andCF bit identifies that the sender of the packet is congested.

As can be seen from Figure 5, network nodes can be indifferent states during the data transmission phase in or-der to perform the proposed CCPC approach. Initially anode ni is in the no-Congestion state. During this stage,whenever node ni receives a newly generated data packetfrom the application layer or a non-duplicated data packetfrom one of its child nodes, it checks the filled percentageof its buffer space. If at the packet reception time thefilled space in its packet buffer is equal or higher than theuser specified threshold value (i.e., TQc), it moves to theCongestion-Detected state which means that it deals withcongestion.

In the Congestion-Detected state, node ni notifies itsneighbors that its buffer will be overflowed in the near fu-ture by setting the CF bit of its outgoing data packets to1. Moreover, node ni waits for a period to find a childnode which is eligible to change its current parent (i.e.,node ni) through setting a timer as:

Tcs = ρ × 1Ravg

where

Ravg = Rci

ρ

(9)

where Ravg is the average packet reception rate at nodeni from its child nodes, Rc

i is the packet reception rate atnode ni from all of its child nodes, and ρ is the number ofactive child nodes of a given node.

When node nj overhears a transmitted packet from itscurrent parent (i.e., node ni) with the CF bit equal to1, it identifies that the packet buffer of its current parentis being overflowed. Therefore, it starts to find anotherparent node among its identified potential parent nodes tochange its current parent. To this aim, node nj retrieves

9

M. Radi et al. — Springer : Link

1 Byte 1 Byte 1 Byte 1 Byte 1 Byte

2 Bytes 1 Byte 1 Byte 1 Byte

2 Bytes29 Bytes48 Bytes 2 Bytes

Preamble SFD MAC header MAC payload

Destination

address Type

Sequence

number

Source

address Length

Incoming

rate

Minimum

path cost

towards sink

1 Bit

CRC

Outgoing

rate

Selected

childPC CF

CCPC control

frame

Physical header

Figure 4: Data packet format.

no-Congestion Congestion-Detected

Wait-for-Parent-Change-

Confirmation

Wait-for-Stabilization

Condition:

Buffer Size ≥ MaxBuffer Size × TQc

Action:

Set the CF field of data packet to 1

Set the child selection timer

Condition:

child selection timer is over and at least one

eligible child for parent change is found

Action:

Select the best child node to change its

parent

Set the Selected child field of data packet to

the address of the identified best child node

Condition:

overhear a data packet from the

selected child for parent change and

Condition:

and Buffer Size < MaxBuffer Size × TQc

Action:

Set the CF field of data packet to 0

Condition:

Condition:

overhear a data packet from the

selected child for parent change and

1

oi

gi

ci

R

RR

1

oi

gi

ci

R

RR

1

o

i

g

i

c

i

R

RR

1

o

i

g

i

c

i

R

RR

Figure 5: The state diagram of CCPC.

10

M. Radi et al. — Springer : Link

the preserved incoming and outgoing rates for its potentialneighboring nodes from its neigborhood table to find thebest parent node nk as follows:

∆R =Rok − (Rc

k + Rgk + Ro

j ) (10)

where ∆R indicates the difference between packet recep-tion rate and packet transmission rate of a node, Ro

k is thepacket transmission rate of node nk, Rc

k is the packet re-ception rate of node nk from its child nodes, and Rg

k is thepacket generation rate at the application layer of node nk.Notice that, a potential parent node nk for node nj is anode which holds the inequality CostToSinkk ≤ MinCost-Val+ β× MinCostVal. In this inequality, CostToSinkk isthe data transmission cost from node nk towards the sinknode, MinCostVal is the minimum data transmission costthat node ni have been calculated so far, 0 ≤ β ≤ 1 is athreshold value to select a neighboring node towards thesink as a potential parent.

If node nj finds a potential parent node to change its cur-rent parent, it sets the PC bit of its outgoing data packetsto 1. When node ni which is in the Congestion-Detectedstate receives a data packet from a child node nj with PCbit equal to 1, it updates the related information regard-ing the parent change eligibility of this child node in itsneighborhood table. If the waiting time for child selection(i.e., Tcs) is over, node ni searches its neighborhood ta-ble to find a child node with maximum data transmissionrate which is eligible to change node ni to another parentnode. Afterwards, node ni sets the Selected child field ofits outgoing data packets to the address of the selectedchild node and changes its current state to the Wait-for-Parent-Change-Confirmation.

If node nj overhears a data packet from its current par-ent (i.e., node ni) with the Selected child field equal to itsaddress (i.e., node nj), it should change its current parentfrom node ni to its identified best potential parent nk.

Whenever node ni which is in the Wait-for-Parent-Change-Confirmation state overhears a transmitted datapacket from its selected child (i.e., node nj) for parentchange process, it realizes that child node nj has changedits current parent to another node. Therefore, node ni up-dates the preserved packet reception rate information inits neighborhood table regarding to this child node to 0.Furthermore, it checks its current congestion status as:

CD =Rc

i + Rgi

Roi

(11)

If Rci + Rg

i exceeds the Roi , there still some backlogged

packets in node ni’s packet buffer. Thus, node ni shouldchange it state to the Congestion-Detected state againto balance its packet reception and transmission rates.While, if packet arrival rate of node ni’s buffer is smalleror equal to its outgoing rate, ni realizes that congestion isabated and it can move to the Wait-for-Stabilization state.

During the Wait-for-Stabilization state, whenever nodeni receives a data packet, it checks the ratio of its packet

incoming rate plus its packet generation rate to its packetoutgoing rate. If this ratio is lower than 1, node ni recog-nizes that the congestion is alleviated. So it can move tothe no-Congestion state when the filled space in its packetbuffer is lower than the user specified threshold value. Oth-erwise, it should enter the Congestion-Detected state againto equalize its packet reception and transmission rates.

LINKORD also utilizes the network traffic to updatethe preserved link quality information at individual nodesand detects routing problems during the data transmissionprocess. In this context, every node updates the preservedinformation regarding the data transmission quality of itslinks towards its potential parents nodes based on num-ber of acknowledged, unacknowledged and overheard datapackets from them. Moreover, every node updates the pre-served neighborhood information in its neighboring tableduring the data transmission process using the Minimumpath cost towards sink field of the transmitted packets. Inaddition, whenever a node receives a data packet, it com-pares the included path cost in the packet with its ownpath cost towards the sink to identify if there exists anyrouting inconstancy. If the data transmission cost of thereceiver node is higher than the included cost in the datapacket, the receiver node starts to update the routing stateof its neighboring nodes.

5. Performance Evaluation

This section analyzes and compares performance ofLINKORD against default CTP of TinyOS [12, 21]. Firstwe describe the considered simulation framework, simu-lation scenarios and performance parameters for perfor-mance evaluation. Then we analyze and discuss the simu-lation results.

5.1. Simulation SetupWe have performed our performance evaluations using

the OMNeT ++ framework. In order to provide an accu-rate wireless channel model and improve the accuracy ofthe simulation results, we have developed a physical layermodule that considers path loss, multipath effect, trans-mission power variations, noise floor variations and thecapture effect based on the presented models in [43–46].The radio parameters are chosen based on the Mica2 motespecifications. Furthermore, we have implemented B-MAC[47] as the underlying MAC protocol in our simulationsoftware. In all of the figures, each result point shows themedian of 20 simulation runs, while the error bars repre-sent the upper and lower quartiles. Table 2 represents thedefault simulation parameters of this paper in detail.

Since LINKORD lies in the similar subset of the designspace as the default CTP of TinyOS [12, 21], this protocolis selected as the benchmark for performance evaluationsunder two different simulation scenarios as follows:

i. First Simulation Scenario: This scenario aims toevaluate the efficiency of LINKORD and TinyOS’s

11

M. Radi et al. — Springer : Link

Table 2: Simulation parameters.Radio

Average noise power [dBm] -106Noise figure [dB] 13Switch to TX/RX [µs] 250Radio sampling [µs] 350Evaluate radio sample [µs] 100Noise bandwidth [Hz] 30000Modulation NC-FSKEncoding ManchesterBaud rate [Bauds per second] 38400Transmission power [dBm] 0Standard deviation of transmission power heterogeneity 1.2Standard deviation of noise floor heterogeneity 0.9Number of settling bits 49Radio speed after encoding [bits per second] 19200Reference distance [m] 1PL (d0) [dB] 55

Environment

Ambient temperature [C◦] 27Path loss exponent (outdoor) 4.7Multipath channel variations (outdoor) 3.2

B-MAC

Initial backoff [slots] 32Congestion backoff [slots] 16Sampling interval [ms] 20

Other parameters

Network topology RandomNumber of nodes 400Area size 40mX40m, 60mX60mPacket buffer size [packets] 12TQc 0.5β 0.1

CTP to discover high performance paths from sensornodes towards the sink. Since the position of the linksalong the paths with small number of hops has littleor no impact on the network data gathering perfor-mance, the location of source and sink nodes should beadjusted in a way, that results in construction of longdistance paths. Therefore, source nodes should be atthe farthest distance from the sink node to maximizethe length of established paths from source nodes to-wards the sink. To achieve this goal, in this scenarioonly 20 nodes with the largest distance from sink nodeare considered as the source nodes and each one gener-ates 20 data packets destined to the sink node. Thissetting provides a framework to evaluate the effec-tiveness of considering link positions during the datagathering tree construction process to achieve an ef-ficient data transmission over long paths in wirelesssensor networks. Furthermore, to study the influenceof number of offered link layer transmission attemptsper packet delivery, different performance parameters

are evaluated under situations where the link layerprovides 1 and 3 transmission attempts at individuallinks.

ii. Second Simulation Scenario: The second simu-lation scenario is intended to study the proficiencyof different protocols to reduce the effects of networkcongestion on the data gathering performance in theapplications where all the nodes generate data at asame rate. Therefore, in all the experiments un-der this scenario, the congestion control capabilityof TinyOS’s CTP is enabled [12], and the proposedCCPC approach is used during the data transmis-sion phase of LINKORD. Furthermore, every sensornode generates 30 data packets destined to the sinknode. As with the first simulation scenario, all theperformance parameters are evaluated under situa-tions where the link layer provides 1 and 3 transmis-sion attempts at individual links to study the effectsof the number of provided transmission attempts perpacket at the link layer on the network data gathering

12

M. Radi et al. — Springer : Link

performance. In order to be sure that different proto-cols are compared in the situation where the networkgets congested, various performance metrics are eval-uated against packet generation interval of the sensornodes ranges from 1 to 64 seconds. Since the linklevel throughput in the developed simulation frame-work is approximately 28 packets per second and theconsidered network topology has 399 sensor nodes, sothe network should become congested when each nodegenerates a data packet every 14 seconds.

5.2. Performance ParametersWe have evaluated and compared the performance of

the LINKORD and TinyOS’s CTP using following param-eters:

i. Data delivery ratio: This metric measures the ratioof successfully received data packets by the sink nodeto the total number of transmitted data packets bythe source nodes. Therefore, it indicates the abilityof different protocols to enhance the data transmissionreliability.

ii. End-to-end network goodput: This metric is mea-sured as the ratio of the total number of successfullyreceived data bits by the sink node to the data trans-mission duration. In other words, this metric showshow different data gathering protocols influence therate of successful packet delivery to the sink node.

iii. Average Consumed Energy for Packet Trans-missions: This metric reveals the average consumedenergy by individual sensor nodes for transmittingdata packets towards the sink node which is presentedas the percentage of total battery capacity of a sensornode.

iv. Packet delivery overhead: This metric indicatesthe overhead cost of running different data gatheringprotocols to provide data gathering service in wirelesssensor networks through measuring the ratio of allthe transmitted packets during the data transmissionprocess to the number of successfully received datapackets at the sink node.

5.3. Performance Evaluation Under First Simulation Sce-nario

This section compares the performance of LINKORDwith default data gathering protocol of TinyOS in orderto validate the effects of link positions along the paths onthe network data gathering performance in the cases wherethe link layer provides a bounded number of transmissions.

5.3.1. Data Delivery RatioFigure 6 shows the ratio of the received data packets at

the sink node to the transmitted data packets by the sourcenodes through employing LINKORD and TinyOS’s CTP.As can be seen from this figure, in the cases where the link

Figure 6: Data delivery ratios achieved by LINKORD and TinyOS’sCTP versus network traffic load under the first simulation scenario.

layer provides 1 and 3 transmission attempts at each linkLINKORD improves data delivery ratio about 70% and33% compared to the TinyOS’s CTP respectively. The rea-son behind this trend is that, LINKORD constructs morereliable paths compared to the TinyOS’s CTP which calcu-lates the data transmission cost of different paths througha simple summation of the ETX values of the links alongthe paths. According to the LINKORD design, this pro-tocol calculates the data transmission cost of each pathbased on the required number of transmission attemptsfor successful packet delivery over individual links of thatpath and the maximum number of offered link layer trans-missions. Therefore, LINKORD assigns higher data trans-mission cost to the paths with links where the expectednumber of transmission attempts for successful packet de-livery is higher than the maximum number of offered linklayer transmissions. However, as TinyOS’s CTP assumesthere is an infinite number of transmission attempts at in-dividual links, in the cases where the link layer providesa limited number of transmissions, it selects paths thatare more unreliable compared to the selected paths by theLINKORD. Consequently, as the number of offered linklayer transmission attempts increases the achieved datadelivery ratio through both approaches is getting close toeach other. In both approaches by increasing the neighbor-hood density of nodes from 20 to 40 nodes, the data deliverratio elevates about 33%. The reason for this incrementaltrend is that, elevating the neighborhood density decreasesthe number of packet drops due to the hidden node ter-minal problem. Furthermore, raising the network densityresults in the paths with a lower number of hops. Con-sequently, data transmission over shorter paths reducesthe channel access contentions and wireless interferencebetween network nodes which in turn improves the datadelivery ratio.

13

M. Radi et al. — Springer : Link

Figure 7: The end-to-end network goodput achieved by LINKORDand TinyOS’s CTP versus network traffic load under the first simu-lation scenario.

5.3.2. End-to-End Network Goodput

Figure 7 depicts the measured end-to-end goodput forLINKORD and CTP of TinyOS against packet genera-tion rate of the source nodes. As it can be observed, ininsensitive traffic loads LINKORD improves the end-to-end network goodput about 80% and 70% compared tothe TinyOS’s CTP in the situations where the link layerprovides 1 and 3 transmission attempts. By reducing thenetwork traffic load, still LINKORD provides higher end-to-end network goodput relative to the TinyOS’s CTP.This behavior is mainly due the fact that LINKORD con-siders the relative position of the links along the pathswith respect to their packet delivery probability and thenumber of offered link layer transmission attempts. Sincethe network traffic is convergecast, the traffic load of thenodes near the sink node is always higher than the othernodes. Therefore, as LINKORD prefers the paths withhigh-quality links near the sink node and low-quality linksnear the source nodes, it can help to reduce the traffic loadof the nodes near the sink node and improves the end-to-end network goodput. Another observation that can bedrawn from this figure is that, as the neighborhood size ofnodes raises from 20 to 40 the provided end-to-end networkgoodput by both approaches elevates. This observationcan be described as follows: Firstly, as discussed in theprevious section, increasing the neighborhood size of indi-vidual nodes reduces the number of packet drops due tothe hidden node terminal problem which in turn improvesthe network goodput. Secondly, increasing the neighbor-hood density results in the paths with a lower number ofhops from every sensor node towards the sink. Therefore,data transmission over paths with lower number of hopsreduces the channel contention level among the networknodes which in turn elevates the network goodput.

Figure 8: Percentage of average consumed energy for packet trans-mission towards the sink node by LINKORD and TinyOS’s CTPversus network traffic load under the first simulation scenario.

5.3.3. Average Consumed Energy for Packet Transmis-sions

Figure 8 demonstrates the percentage of average con-sumed energy for packet delivery to the sink nodeagainst network traffic load through using LINKORD andTinyOS’s CTP. As expected, LINKORD reduces the per-centage of average consumed energy for transmitting datapackets towards the sink node about 50% and 30% com-pared to the TinyOS’s CTP in the cases where the linklayer provides 1 and 3 transmission attempts respectively.This is mainly due to the utilized path cost function inLINKORD. In fact, LINKORD assigns higher data trans-mission cost to the paths with low-quality links near thesink node by using the SFTC path cost function. Thus,it significantly reduces the number of packet drops due tothe limited number of link layer transmissions on the linksnear the sink node. As a consequence, LINKORD highlyreduces the network energy waste due to transmitting datapackets over a large number of hops which will be droppedsomewhere close to the sink node.

5.3.4. Packet Delivery OverheadIn order to study the overhead caused by different pro-

tocols to transmit data packets towards the sink node, thissection analyzes the packet delivery overhead of differentprotocols which is defined as the total number of transmit-ted packets during the data transmission phase to the num-ber of received packets at the sink node. Figure 9 presentsthe packet delivery overhead caused by employing differ-ent protocols as a fraction of the network traffic load. Asexpected LINKORD reduces the packet delivery overheadby 41% and 30% compared to the TinyOS’s CTP whenthe link layer provides 1 and 3 transmission attempts ateach link. This is a direct result of considering the relativeposition of the links along the paths with respect to their

14

M. Radi et al. — Springer : Link

Figure 9: Packet delivery overhead of LINKORD and TinyOS’s CTPvarious network traffic load under the first simulation scenario.

packet delivery probability and maximum number of pro-vided link layer transmissions. In fact, LINKORD reducespacket delivery overhead through selecting paths which in-cur a lower number of transmissions while they providehigher data delivery ratio. Furthermore, increasing theneighborhood size from 20 to 40, reduces the packet deliv-ery overhead of both protocols. This decreasing trend canbe explained as: Raising the neighborhood size of nodesresults in the paths with lower number of hops which inturn reduces the total number of packet transmissions fora single packet delivery over each path.

5.4. Performance Evaluation Under Second SimulationScenario

This section studies the network data gathering perfor-mance through employing LINKORD, and TinyOS’s CTPin the cases where all the nodes generate data at a samerate and both protocols utilize congestion control mecha-nism during the data transmission process.

5.4.1. Data Delivery RatioFigure 10 presents the achieved data delivery ratio

through different protocols as a function of packet gen-eration rate of sensor nodes under the second simulationscenario. This figure reveals that LINKORD provides upto 60% and 50% higher data delivery ratio compared to theTinyOS’s CTP in the cases where the link layer provides1 and 3 transmission attempts at each link respectively.This performance improvement is mainly due to two rea-sons. The first reason is that, LINKORD considers theposition of the links along the paths based on their packetdelivery probability and the number of offered link layertransmissions at each link. Thus, these results confirm theinefficiency of calculating data transmission cost of multi-hop paths through summation of their link ETX values in

Figure 10: Data delivery ratios achieved by LINKORD, andTinyOS’s CTP versus network traffic load under the second simu-lation scenario.

the cases where the link layer provides a limited numberof transmission attempts at every link. The second rea-son is that by employing the CCPC approach during thedata transmission phase, whenever a given child node re-alizes its current parent may face packet drop in the nearfuture due to buffer overflow, it starts to forward its pack-ets towards the sink node through another eligible parentnode. In CCPC approach, every node which conceives itshould change its current parent, considers the packet re-ception and transmission rate of its potential parents toselect the best potential parent node instead of makinga blind parent selection (e.g., in TinyOS’s CTP a childselects a new parent based on its offered data transmis-sion cost). Through the CCPC approach, each node firstperceives how much would be the ratio of packet inputrate to the output rate of a potential parent node, if itselects that node as its parent. In other words, throughthe CCPC approach each child node can choose a parentwhich has less probability of being congested compared tothe other potential parents when this child node switchesto that newly selected parent. In TinyOS’s CTP, everynode which realizes its current parent is congested, blindlychanges its parent to another one which provides lowermulti-hop ETX towards the sink node compared to otherneighbors. Therefore, since in TinyOS’s CTP nodes do notconsider the incoming and outgoing rates of their neigh-bors to change their congested parent node, the achieveddata delivery ratio through this protocol is significantlylower than LINKORD.

5.4.2. End-to-End Network GoodputFigure 11 shows the achieved end-to-end goodput by

LINKORD compared to the TinyOS’s CTP under the sec-

15

M. Radi et al. — Springer : Link

Figure 11: The end-to-end network goodput achieved by LINKORDand TinyOS’s CTP versus network traffic load under the second sim-ulation scenario

ond simulation scenario. As with the achieved resultsunder the first simulation scenario, the goodput of bothprotocols increases as the network traffic load intensifies.Again in this scenario, LINKORD improves the end-to-end network goodput compared to the TinyOS’s CTP.The first reason behind this behavior is that, TinyOS’sCTP assumes the link layer offers an infinite number oftransmissions per packet and it does not consider the po-sition of the links along the paths. Therefore, when thelink layer provides a bounded number of transmissions, theselected paths through TinyOS’s CTP may include linkswhich require a higher number of transmissions for success-ful packet delivery than the maximum number of offeredlink layer transmissions. While, LINKORD arranges thelinks along the paths based on their packet delivery prob-ability and maximum number of achievable transmissionsat the link layer. Moreover, these results confirm that un-der high traffic loads where the probability of congestionis very high, balancing the incoming and outgoing trafficrates of network nodes results in efficient network band-width utilization. Since the proposed CCPC approach ad-justs the data reception rate of very node based on its ser-vice rate, it allows the nodes to efficiently use the networkresources for delivering the collected data from environ-ment to the sink node.

5.4.3. Average Consumed Energy for Packet Transmis-sions

Figure 12 plots the percentage of average consumed en-ergy for packet transmission towards the sink node throughdifferent protocols under the second simulation scenario.As can be seen from this figure LINKORD reduces theconsumed energy for packet transmission up to 30% and20% compared to the TinyOS’s CTP when the link layer

Figure 12: Percentage of average consumed energy for packet trans-mission towards the sink node by LINKORD and TinyOS’s CTPversus network traffic load under the second simulation scenario.

provides 1 and 3 transmission attempts at every link re-spectively. This performance improvement is a direct con-sequence of using SFTC path cost function during the datagathering tree construction phase of LINKORD. Anotherreason is that CCPC enables every child node of a con-gested parent to change its current parent to another nodewhich can handle the outgoing rate of this child node with-out any congestion. In fact, this approach helps each con-gested node to reduce the number of packet drops due tothe buffer overflow through adjusting its packet incomingrate according to its packet outgoing rate. Consequently,by reducing the probability of packet drops due to thebuffer overflow, the consumed energy for packet transmis-sion is reduced.

5.4.4. Packet Delivery OverheadFigure 13 depicts the ratio of the total number of trans-

mitted packets during the data transmission phase to thenumber of received packets at the sink node as a functionof network traffic load for different protocols. This fig-ure shows that under this new scenario the delivery costof LINKORD is still 43% and 30% lower than TinyOS’sCTP when the link layer provides 1 and 3 transmissionattempts at each link respectively. This is because of theutilized route selection mechanism in LINKORD which al-lows the nodes to select paths that cause a lower numberof transmissions and higher data delivery ratio comparedto the TinyOS’s CTP. Furthermore, as the required infor-mation to perform CCPC approach is added to the datapackets as a CCPC control frame, employing this approachin conjunction with LINKORD has not increased the datadelivery overhead compared to TinyOS’s CTP. Moreover,as CCPC approach enables every node to adjust its packetincoming rate based on its packet outgoing rate, it signifi-

16

M. Radi et al. — Springer : Link

Figure 13: Packet delivery overhead of LINKORD and TinyOS’sCTP versus network traffic load under the second simulation sce-nario.

cantly reduces the total number of transmission attemptsfor a successful packet delivery.

6. Conclusion

This paper proposed a data gathering protocol calledLINKORD to provide efficient data gathering with respectto the bounded number of link layer transmissions andpacket delivery probability of network links. In the sit-uations where the link layer provides a limited numberof transmissions attempts at each link, the reliability andcost of data delivery is not only related to the number ofhops along the paths or their respective data transmissionquality. In fact, since packet drops near the sink node dueto the bounded number of link layer transmissions is verycostly, the relative position of the links along each pathplays an important role in computing the data transmis-sion cost of individual paths. Therefore, the main aimof LINKORD is to calculate the data transmission costof every path based on the relative position of the linksalong that path. In this context, this paper also proposesa SFTC path cost function which is a non-commutativefunction of the packet delivery probability of the links.The proposed path cost function is utilized by the net-work nodes during the data collection tree constructionprocess to identify low-cost paths towards the sink. Fur-thermore, a CCPC approach is developed in conjunctionwith LINKORD in order to provide efficient data deliveryduring the data transmission phase. This approach allowsevery node to adjust its packet incoming rate based onits packet outgoing rate whenever it identifies its packetbuffer will be overflowed in the near future, through noti-fying the child nodes to change their congested parent.

The simulation results show the higher performance ofLINKORD compared to the TinyOS’s CTP in terms ofdata delivery ratio, end-to-end network goodput, energyconsumption and packet delivery overhead. The achievedresults reveal that, by taking into consideration the rela-tive order of the links along the paths and controlling theincoming rate of the nodes during the data transmissionphase, data gathering performance improves significantlywhen the link layer provides a bounded number of trans-mission attempts per packet delivery.

References

[1] J. Yick, B. Mukherjee, D. Ghosal, Wireless Sensor NetworkSurvey, Computer Networks 52 (2008) 2292–2330.

[2] C. F. García-hernández, P. H. Ibargüengoytia-gonzález,J. García-hernández, J. A. Pérez-díaz, Wireless Sensor Net-works and Applications: A Survey, International Journal ofComputer Science and Network Security 7 (2007) 264–273.

[3] E. E. P. K. Gilbert, K. Baskaran, E. B. Elijah Blessing, ResearchIssues in Wireless Sensor Network Applications: A Survey, In-ternational Journal of Information and Electronics Engineering2 (2012) 702–706.

[4] T. Arampatzis, J. Lygeros, S. Manesis, A Survey of Applicationsof Wireless Sensors and Wireless Sensor Networks, in: Proceed-ings of the 2005 IEEE International Symposium on Control andAutomation Intelligent Control, IEEE, Limassol, Cyprus, 2005,pp. 719–724.

[5] D. England, B. Veeravalli, A Robust Spanning Tree Topologyfor Data Collection and Dissemination in Distributed Environ-ments, IEEE Transactions on Parallel and Distributed Systems18 (2007) 608–620.

[6] B. Dezfouli, M. Radi, S. A. Razak, K. Whitehouse, K. A. Bakar,T. Hwee-pink, Improving Broadcast Reliability for NeighborDiscovery , Link Estimation and Collection Tree Constructionin Wireless Sensor Networks, Computer Networks 62 (2014)101–121.

[7] M. Radi, B. Dezfouli, K. A. Bakar, M. Lee, Multipath Routingin Wireless Sensor Networks: Survey and Research Challenges,Sensors 12 (2012) 650–685.

[8] M. Radi, B. Dezfouli, K. A. Bakar, S. A. Razak, M. A. Ne-matbakhsh, Interference-Aware Multipath Routing Protocol forQoS Improvement in Event-Driven Wireless Sensor Networks,Tsinghua Science & Technology 16 (2011) 475–490.

[9] M. Radi, B. Dezfouli, K. A. Bakar, S. A. Razak, T. Hwee-Pink,IM2PR: interference-minimized multipath routing protocol forwireless sensor networks, Wireless Networks (2014).

[10] S. Moeller, A. Sridharan, B. Krishnamachari, Routing WithoutRoutes: The Backpressure Collection Protocol, in: Proceedingsof the 9th ACM/IEEE International Conference on InformationProcessing in Sensor Networks (IPSN ’10), Stockholm, Sweden,pp. 279–290.

[11] R. Fonseca, O. Gnawali, K. Jamieson, S. Kim, P. Levis, A. Woo,The Collection Tree Protocol (CTP), Technical Report, TEP123, TinyOS Network Working Group, 2006.

[12] U. Colesanti, S. Santini, The Collection Tree Protocol for theCastalia Wireless Sensor Networks Simulator, Technical Re-port, No 729, Department of Computer Science, ETH Zurich,Switzerland, 2011.

[13] A. Woo, T. Tong, D. Culler, Taming the Underlying Chal-lenges of Reliable Multihop Routing in Sensor Networks, in:Proceedings of the 1st International Conference on EmbeddedNetworked Sensor Systems, ACM, Los Angeles, CA, USA, 2003,pp. 14–27.

[14] K. Srinivasan, P. Dutta, A. Tavakoli, An Empirical Study ofLow Power Wireless, ACM Transactions on Sensor Networks 6(2010) 1–49.

17

M. Radi et al. — Springer : Link

[15] S. Das, H. Pucha, K. Papagiannaki, Studying Wireless Rout-ing Link Metric Dynamics, in: Proceedings of the 7th ACMSIGCOMM conference on Internet measurement (IMC ’07), pp.327–332.

[16] N. Baccour, M. B. Jamaa, A Comparative Simulation Studyof Link Quality Estimators in Wireless Sensor Networks, in:Proceedings of 17th IEEE/ACM International Symposium onModeling, Analysis and Simulation of Computer and Telecom-munication Systems (MASCOTS ’09), London, pp. 301–310.

[17] A. Vlavianos, L. K. Law, I. Broustis, S. V. Krishnamurthy,M. Faloutsos, L. Kong, Assessing Link Quality in IEEE 802.11Wireless Networks: Which is the Right Metric?, in: Proceedingsof the 19th International Symposium on Personal, Indoor andMobile Radio Communications (PIMRC ’08), Cannes, FrenchRiviera, France, pp. 1–6.

[18] K.-H. Kim, K. G. Shin, On Accurate Measurement of LinkQuality in Multi-Hop Wireless Mesh Networks, in: Proceedingsof the 12th Annual International Conference on Mobile Com-puting and Networking (MobiCom ’06), Los Angeles, CA, USA,pp. 38–49.

[19] R. Draves, B. Zill, J. Padhye, Comparison of Routing Met-rics for Static Multi-Hop Wireless Networks, ACM SIGCOMMComputer Communication Review 34 (2004) 133–144.

[20] D. S. J. D. Couto, D. Aguayo, J. Bicket, R. Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing, in:ACM Mobicom Conference, ACM, San Diego, CA, USA, 2003,pp. 134–146.

[21] O. Gnawali, R. Fonseca, K. Jamieson, Collection Tree Proto-col, in: Proceedings of the 7th ACM Conference on EmbeddedNetworked Sensor Systems (SenSys ’09), Berkeley, California,pp. 1–14.

[22] G. Jakllari, S. Eidenbenz, Link Positions Matter : A Noncom-mutative Routing Metric for Wireless Mesh Networks, IEEETransactions on Mobile Computing 11 (2012) 61–72.

[23] F. Wang, J. Liu, Networked Wireless Sensor Data Collection:Issues, Challenges, and Approaches, IEEE CommunicationsSurveys and Tutorials 13 (2011) 673 – 687.

[24] A. Cerpa, J. L. Wong, M. Potkonjak, D. Estrin, TemporalProperties of Low Power Wireless Links: Modeling and Im-plications on Multi-Hop Routing, in: Proceedings of the 6thACM International Symposium on Mobile Ad Hoc Networkingand Computing (MobiHoc ’05), Urbana-Champaign, IL, USA,pp. 414–425.

[25] D. Ganesan, B. Krishnamachari, A. Woo, D. Culler, Com-plex Behavior at Scale: An Experimental Study of Low-PowerWireless Sensor Networks, Technical Report, UCLA/CSD-TR02-0013, Computer Science Department, UCLA, 2002.

[26] A. Meier, T. Rein, J. Beutel, L. Thiele, Coping with UnreliableChannels: Efficient Link Estimation for Low-Power WirelessSensor Networks, in: Proceedings of the 5th International Con-ference on Networked Sensing Systems, Kanazawa, pp. 19–26.

[27] N. Baccour, A. Kouba, L. Mottola, M. A. Zuniga, H. Youssef,C. A. Boano, M. Alves, Radio Link Quality Estimation in Wire-less Sensor Networks : A Survey, ACM Transactions on SensorNetworks 8 (2012) 183–217.

[28] S. Lin, G. Zhou, K. Whitehouse, Y. Wu, Towards Stable Net-work Performance in Wireless Sensor Networks, in: Proceedingsof the 30th IEEE Real-Time Systems Symposium (RTSS ’09 ),Washington, DC, USA, pp. 227 – 237.

[29] V. C. Borges, M. Curado, E. Monteiro, Cross-Layer RoutingMetrics for Mesh Networks: Current Status and Research Di-rections, Computer Communications 34 (2011) 681–703.

[30] TinyOS Network working group, The MultihopLQI Protocol,2009.

[31] K. Srinivasan, P. Levis, RSSI is Under Appreciated, in: Pro-ceedings of the 3th ACM Workshop on Embedded NetworkedSensors (EmNets ’06), Boston, MA, USA, pp. 1–5.

[32] D. Puccinelli, M. Haenggi, Duchy: Double Cost Field HybridLink Estimation for Low-Power Wireless Sensor Networks, in:Proceedings of the 5th Workshop on Embedded Networked Sen-sors (HotEmNets’08), Charlottesville, Virginia, USA, pp. 1–5.

[33] C. A. Boano, M. A. Zuniga, T. Voigt, A. Willig, K. Romer,The Triangle Metric: Fast Link Quality Estimation for MobileWireless Sensor Networks, in: Proceedings of 19th Interna-tional Conference on Computer Communications and Networks(ICCCN’10), Zurich, Switzerland, pp. 1–7.

[34] P. Levis, N. Patel, D. Culler, S. Shenker, Trickle : A Self-Regulating Algorithm for Code Propagation and Maintenancein Wireless Sensor Networks, in: Proceddings of the FirstSymposium on Networked System Design and Implementation(NSDI ’04), San Francisco, CA.

[35] O. Gnawali, K. Jamieson, P. Levis, R. Fonseca, Four-Bit Wire-less Link Estimation, in: Proceedings of the 6th Workshop onHot Topics in Networks (HotNets ’06), Atlanta, GA, USA, pp.1–7.

[36] T. Schoellhammer, B. Greenstein, Hyper: A Routing Protocolto Support Mobile Users of Sensor Networks, Tech Report,Center for Embedded Network Sensing (CENS) (2006).

[37] J. Heidemann, D. Estrin, Centralized Routing for Resource-Constrained Wireless Sensor Networks, Technical Report Au-gust, UCLA, Los Angeles, CA, USA, 2007.

[38] N. Burri, P. V. Rickenbach, Dozer: Ultra-Low Power DataGathering in Sensor Networks, in: Proceedings of the 6thInternational Conference on Information Processing in SensorNetworks (IPSN ’07), Cambridge, Massachusetts, USA, pp.450–459.

[39] M. Radi, B. Dezfouli, K. A. Bakar, S. A. Razak, M. Lee, Net-work Initialization in Low-Power Wireless Networks: A Com-prehensive Study, The Computer Journal In Press (2013) 1–24.

[40] M. Radi, B. Dezfouli, K. A. Bakar, S. A. Razak, Integration andAnalysis of Neighbor Discovery and Link Quality Estimation inWireless Sensor Networks, The Scientific World Journal 2014(2014) 1–23.

[41] W.-w. Fang, J.-m. Chen, L. Shu, T.-s. Chu, D.-p. Qian, Con-gestion Avoidance, Detection and Alleviation in Wireless SensorNetworks, Journal of Zhejiang University Science C 11 (2009)63–73.

[42] V. Deshpande, P. Sarode, S. Sarode, Root Cause Analysis ofCongestion in Wireless Sensor Network, International Journalof Computer Applications 1 (2010) 31–34.

[43] K. Whitehouse, A. Woo, F. Jiang, J. Polastre, D. Culler, Ex-ploiting the Capture Effect for Collision Detection and Recov-ery, in: Proceedings of The 2nd IEEE Workshop on EmbeddedNetworked Sensors, Sydney, Australia, pp. 45–52.

[44] M. Z. n. Zamalloa, B. Krishnamachari, An Analysis of Unre-liability and Asymmetry in Low-Power Wireless Links, ACMTransactions on Sensor Networks 3 (2007) 165–199.

[45] G. Zhou, T. He, S. Krishnamurthy, Models and Solutions forRadio Irregularity in Wireless Sensor Networks, ACM Transac-tions on Sensor Networks 2 (2006) 221–262.

[46] B. Dezfouli, M. Radi, S. A. Razak, K. A. Bakar, T. Hwee-pink,Modeling Low-Power Wireless Communications, Computer net-works and its Applications (2014) 1–31.

[47] J. Polastre, J. Hill, D. Culler, Versatile Low Power Media Accessfor Wireless Sensor Networks, in: Proceedings of the 2nd Inter-national Conference on Embedded Networked Sensor Systems(SenSys ’04), Maryland, USA, pp. 95–107.

18