A Routing Scheme for the IEEE-802.15.4-Enabled

8/7/2019 A Routing Scheme for the IEEE-802.15.4-Enabled

1/17

IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009 5135

A Routing Scheme for the IEEE-802.15.4-EnabledWireless Sensor Networks

A. Haffiz Shuaib, Student Member, IEEE, and A. Hamid Aghvami, Fellow, IEEE

AbstractA wireless sensor network (WSN) has features thatfit into several classes of wireless networks (e.g., mesh, ad hoc,and mobile ad hoc networks) and, at the same time, features thatare unique to it. These exceptional characteristics place manydemands on the WSN routing protocol. For instance, the routingprotocol must assure uniform dissipation of energy across the net-work, quickly converge irrespective of the network node density,and be flexible in terms of the routing framework and the routecomputation metric. All of the aforementioned conditions mustbe accomplished in an energy-efficient manner. Although severalrouting protocols have been proposed for WSNs, most approachesare usually focused on energy-efficient operations. The validity ofthis case is undeniable; however, one crucial element is generally

assumed or ignored i.e., how one can prevent routing loops in thenetwork. In addition to achieving the aforementioned routing ob-jectives, in this paper, we go one step further by expressly definingand thoroughly evaluating mechanisms for loop prevention andminimization. Our proposed routing scheme leverages the servicesthat were offered by the IEEE 802.15.4 specification to satisfy therequirements of a WSN routing protocol.

Index TermsIEEE 802.15.4, routing, wireless personal areanetworks (WPANs), wireless sensor networks (WSNs).

I. INTRODUCTION

W

IRELESS sensor network (WSN) applications can be

grouped into two broad categories: 1) event based and

2) periodic monitoring [1]. Although these application cate-

gories may differ in terms of traffic characteristics and quality-

of-service requirements, both categories essentially place the

same communication architecture on the underlying network.

This architecture is such that communication is generally be-

tween WSN nodes and their neighbors or between WSN nodes

and the sink nodes. Communication between neighbor nodes is

primarily one that allows for efficient data gathering. For exam-

ple, data with regard to sensed phenomena can be aggregated or

pruned to eliminate duplicates if nodes within the same vicinity

cooperatively work with one another. These data are then

transmitted to the sinks, where they are consumed. If these sink

nodes reside one hop away from the data-gathering nodes, thenthe task of the data source to sink transmission is simple. How-

ever, these sinks may sometimes be located multiple hops away

from the source of the data, thus requiring a routing protocol.

Manuscript received March 1, 2009; revised May 18, 2009. First publishedJuly 14, 2009; current version published November 11, 2009. This work wassupported in part by AMYN Investments Limited, Lagos, Nigeria. The reviewof this paper was coordinated by Prof. Y. Xiao.

The authors are with the Centre for Telecommunications Research, KingsCollege London, WC2R 2LS London, U.K. (e-mail: [email protected];[email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TVT.2009.2027440

Aside from the traditional qualities that have been desired of

a routing protocol, e.g., the ability to quickly converge, be loop

free, be correct, be stable, and be reliable, a routing protocol

that has been targeted toward WSNs must also ensure that it is

scalable, that the overhead is minimized, and that it supports

uniform depletion of energy across the network. In terms of

scalability, the sheer density of nodes in a WSN mandates that

the network is administered at the level of the cluster, and

as a result, routing is better served at the granularity of that

administrative unit. In this case, clusters along the path from the

data source to the sink must be willing to relay traffic to the sink

node. To achieve this case, mechanisms must exist within thecluster that allow for bandwidth reservation, admission control,

and cross-cluster communication.

Coincidentally, the IEEE 802.15.4 specification [2], which is

implemented on the bulk of the hardware that was targeted at

WSNs (e.g., Sun Spots [3], IP-Sensor [4], small autonomous

network device (SAND) [5], NanoSensor [6], MicaZ, and IRIS

[7]), provides the bare mechanisms for cluster formation and

maintenance, admission control, and bandwidth reservation,

all of which can be harnessed to achieve the objectives of a

WSN routing protocol. If we will extrapolate from previous

trends, then it is likely that the IEEE 802.15.4 specification

will become the de facto physical- and MAC-layer standardfor WSNs, just as the IEEE 802.3 and 802.11 standards are for

local area networks. With this case, it will be unwise to design

higher layer protocols that are transparent to the services that

were offered by the specification. To that end, in this paper, we

propose a routing framework and mechanism that interacts with

the IEEE 802.15.4 protocol to assure connectivity in a WSN in

an energy-efficient manner.

The remainder of this paper is organized as follows. In

Section II, we discuss the challenges that were placed by

the WSN communication architecture on routing protocols. In

Section III, we discuss some of the routing protocols that have

been proposed for WSNs. Section IV gives an operational

overview of the IEEE 802.15.4 specification. In Section V, wepresent the technical details of the proposed routing mecha-

nism. Section VI contains an evaluation of the mechanisms

in Section V. We use the OPNET network simulation tool for

this purpose. The Appendices follow the conclusion, which is

contained in Section VII.

II. OBJECTIVES OF A WIRELESS SENSOR

NETWORK ROUTING PROTOCOL

In this section, we describe the challenges and itemize the

objectives of a WSN routing protocol/mechanism/framework.

The discussion in this section is illustrated in Fig. 1.

0018-9545/$26.00 2009 IEEE

Authorized licensed use limited to: PSN College of Engineering and Technology. Downloaded on July 28,2010 at 12:02:34 UTC from IEEE Xplore. Restrictions apply.


2/17

5136 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009

Fig. 1. Cluster-to-sink communication.

A cluster is typically made up of a cluster head, cluster

members, and a cluster gateway. The cluster head is the ad-

ministrative node for the cluster, and the gateway is the primary

relay node for the cluster. Sometimes, the cluster head acts as

the cluster gateway, whereas at other times, a member of the

cluster is designated as the gateway. For illustration, we will

assume that the data that were generated in Cluster C needs to

be transmitted to a sink, i.e., Sink S in Fig. 1. In the figure, twopaths exist from Cluster Cto Sink S. The first path, i.e., Path 1,

goes through Clusters B and A, and the other path, i.e., Path 2,

goes through Clusters D and E.

The first challenge of a WSN routing protocol is how it

can achieve efficient route propagation i.e., how sinks are

announced to the network clusters, how routes to the sinks are

maintained, and how nodes that are not gateway nodes or cluster

heads can be shielded from taking part in the route discovery

and update processes.

The second challenge deals with the twin problem of admis-

sion control and bandwidth reservation by the relay clusters on

behalf of other clusters. For instance, if Path 1 in the figureis the preferred path from Cluster C to Sink S, Cluster B

should grant Cluster C access by reserving bandwidth for and

admitting traffic from Cluster C if it can manage it. If a cluster

is unwilling or cannot admit traffic from another cluster en

route to a sink, then this information must be reflected in the

route metric, even before the first data packet is transmitted.

The idea here is to prevent other clusters from interfering

with the internal activities of a relay cluster without its

permission.

A WSN routing protocol must infer the quality of all links

on a path from a source to a destination with minimal overhead,

and this condition should be reflected in the route metric that

qualifies that path. To illustrate this challenge, let us assumethat the numbers beneath the arrows in (1) and (2), shown

below, signify the quality of a link between any two nodes on a

path, i.e.,

Path 1 = C14 B 14 A 0 Sink S (1)

Path 2 = C7 D 8 E14 Sink S. (2)

Now, ifCluster Cpicks the next hop based on its immediatelink quality, it would pickCluster B as its next hop to the sink.

Notice that Cluster Ccannot infer that the link quality between

Cluster A and the sink is 0. This case is not ideal, because a

route is only as good as its lowest quality hop. The additive-cost

approach, which uses the sum of the link metric along the path,

and the averaging approach, which takes the mean cost on a

path, are also not ideal. Observe that, although Path 1 has a link

with quality 0, it would still sum or average higher than Path 2.

Another challenge deals with dissipation of energy. It has

been shown in [8] and [9] that the lifetime of a WSN is extended

if the rate of energy dissipation across the network is uniform.

For instance, if Path 2 is the preferred path and all routed data

consistently go through this path, the clusters along Path 2 will

die out quicker than those on Path 1. The routing framework

should recognize and appropriately adapt this case. Note that

uniform energy dissipation also somewhat translates to load

balancing.

Another solution to the aforementioned uniform energy-

dissipation problem is to have mobile sinks in the network. The

main idea here is to have the mobile sink visit multiple locations

within the network to collect data, thus saving the energy that

would have been used to relay data if the sink was remotely

located and multiple hops away. In [10], the authors showed

that the network lifetime can theoretically be extended by up to

500% when mobile sinks are used. However, this mobile-sinkscenario will constitute a major challenge for any WSN routing

protocol. For example, let us assume that Cluster D announces

to the network that it is one hop away from the mobile sink.

Cluster C hears this announcement and accordingly updates

its routing table. When the mobile sink moves away from

Cluster D toward Cluster E, Cluster D purges the entries for

the mobile sink soon after. At the next announcement interval,

Cluster C announces that it is two hops away from the mobile

sink. Cluster D hears this announcement and updates its routing

table, assuming that it is three hops away from the mobile sink

through Cluster C. Aside from the obvious issue of loop in the

path that was introduced here, this scenario easily leads to the

count-to-infinity problem that plagued the Routing Information

Protocol (RIP) [11].

Requirements also exist for the support of routing that is

geographically oriented and secure. In addition, of course, the

traditional routing challenges (e.g., scalability, flexibility, loop

prevention, fault tolerance, minimal overhead, adaptability to

link and topology changes, and how the shortest most reli-

able most energy-efficient path can be chosen) must also be

dealt with.

III. RELATED WOR K

The routing protocol in this paper is a proactive vectorrouting protocol that relies on a cluster network architecture



3/17

SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS 5137

to achieve its objectives. Thus, the discussion in this section

will be restricted to a representative set of WSN protocols that

share similar features with our proposed routing protocol. The

interested reader should consult [12] and [13] for an exhaustive

survey of routing protocols that were targeted at WSNs.

The first group of protocols are cluster routing protocols.

Examples of such protocols are the low-energy adaptive cluster-ing hierarchy (LEACH) protocol [14], the threshold-sensitive

energy-efficient (TEEN) protocol [15], and the hierarchical

power-aware routing (HPAR) protocol [16].

LEACH is an adaptive clustering routing protocol that elects

a cluster head from a group of homogenous node to act as the

relay node for the cluster for a given time interval. After this

interval, the cluster head is replaced by one of its peers. As soon

as a node is replaced, its elective eligibility diminishes in subse-

quent election rounds. The idea is to spread the energy that was

utilized for relaying data for the cluster among the nodes. Each

cluster head gathers data from the cluster and directly transmits

these data to the sink. LEACH was designed for scenarios in

which data are always available to be sent at a fixed rate. TEEN,

which has a similar mechanism to LEACH, was designed for

reactive networks, i.e., networks that immediately transmit data

upon sensing a phenomenon. The implicit assumption in both

LEACH and TEEN that all cluster heads (and by extension all

nodes) can directly reach the sink prevents the network from

expanding, and therefore, it cannot cover large regions.

The HPAR protocol groups each node into a geographical

zone or cluster. A single node in each zone is periodically

selected to estimate the power levels of each node in its zone.

This estimate is used to compute the amount of energy that

was expended to transmit data out of each corner of the zone.

This information is then broadcast to other zones and is usedfor future routing decisions. The idea here is that nodes from

other zones can infer the path that can reliably relay information

using the minimum amount of energy.

MintRoute [17], MultiHopLQI [18], the Collection Tree Pro-

tocol (CTP) [19], Arbutus [20], and MobiRoute [21] are a set of

routing protocols that, as a group, are referred to as collection

protocols. The primary difference in each of these protocols lie

in how the path cost is computed. For example, in MintRoute,

the computed cost of a path is a function of the ratio of the

number of expected packets and the number of packets that

were received on the immediate link. CTP attempts to improve

upon MintRoute by summing the link costs across all hops todetermine the cost of a path. The MultiHopLQI protocol uses

the same principle of additive cost for path cost computation

but differs from CTP in the sense that the cost is a function of

the received signal strength compared to using the ratio of the

expected number of received packets and the number of packets

that were received.

None of the aforementioned collection protocols explicitly

implements a form of load balancing. Achieving load balancing

is the primary motivation of the Arbutus collection protocol. It

achieves its objective by using the traffic load on the immediate

links of a relay node as an input to the cost computation

algorithm. Observe that the collection routing protocols use

either an additive or an immediate cost approach for path costcomputation. As discussed in the last section, this approach is

not ideal. In addition, these protocols do not deal with the issue

of mobility; however, an extension of the MintRoute protocol

called MobiRoute has been proposed for this very purpose.

One common feature of the collection protocols is the use

of network-layer beacons to propagate route information in the

network. As will be discussed in this paper, we adopt a similar

approach to route propagation, except that this time, we rely onthe beacon mechanism that has already been provided for by

the IEEE 802.15.4 specification.

The aforementioned protocols in this section can be classed

as proactive distance vector routing protocols. The ad hoc on-

demand distance vector protocol, which is a reactive distance

vector routing protocol, was originally designed for ad hoc

networks, but it has been discussed within the context of

WSNs in [12] and [22]. The advantages and disadvantages of

reactive routing protocols are well known. For example, nodes

do not need to maintain path entries to every destination in the

network, because route paths are requested on demand, thus

saving memory space. Associated with this benefit are some

disadvantages, including the fact that route request messages

are sent into the network using a broadcast mechanism, which

can easily lead to a broadcast storm. The possibility of selecting

a suboptimal path due to limited topological information that

is available to the node [23] and the delay that was incurred

when trying to acquire a route [24] are factors that should

be considered when using a reactive protocol. The unique

communication architecture of the WSNs makes some of the

concerns that were addressed by reactive routing protocols

redundant. For example, the only significant multihop com-

munication in a WSN is the communication between the sink

and the data source; thus, the gateway/relay node need not

hold route information to all nodes in a network but to anoptimal number of sinks. To that end, our routing mechanism,

as will be detailed in this paper, adopts a flexible approach that

combines some of the advantages of the proactive and reactive

protocols.

IV. OVERVIEW OF THE 802.15.4

NETWORK ARCHITECTURE

In this section, we discuss the network architecture of the

IEEE 802.15.4 specification and its operational overview in

terms of how the clusters are formed and how the shared chan-

nel is accessed in the beacon-enabled mode. We also discusshow intercluster communications can be achieved using a

combination of the mechanisms that were provided by the

specification.

Within the specification, a cluster is referred to as a wireless

personal area network (WPAN), and the cluster heads are

referred to as the WPAN coordinators. In the remainder of this

paper, we will use the terms WPAN and WPAN coordinator

when referring to a cluster and a cluster head, respectively.

A. WPAN Formation Process and the Active/Inactive Periods

Based on a communications perspective, an IEEE 802.15.4

node is functional only if it is associated with a WPAN, eitheras the coordinator or as a member. Typically, at start up, a



4/17


Fig. 2. SFD interleaving.

node scans the channel looking to receive beacons from WPAN

coordinators within its surrounding areas. At the end of a scan,

the node looks for the best beacon in the beacon scan list,

which is usually the beacon from a WPAN that is within its

personal operating space ( 10-m radius) and currently acceptsassociations. The node proceeds to associate with a WPAN if it

is deemed to be suitable. As a part of this process, the WPAN

coordinator assigns a 16-b short address to the associating node.

All future communications between the WPAN coordinator

and a member are done using this short address. On the other

hand, if none of the beacons is suitable, the node does one of

the following two approaches, depending on the type of the

IEEE 802.15.4 node: 1) a full function device (FFD) or 2) areduced function device (RFD). An RFD, which is relatively

resource constrained, might shut down its radio and later try

again to locate a suitable WPAN. An FFD, upon failing to

find a suitable WPAN, can proceed to form its own. The

newly created WPAN identifies itself using a 16-b WPAN ID

and begins beacon transmission. Two consecutive transmitted

beacons from a single WPAN will be separated by a beacon

interval (BI). If the network operates on the 2.4-GHz frequency

band with a bit rate of 250 Kb/s, then the duration of the BI (in

seconds) is shown as follows:

BI = 0.01536 2BO (3)

where BO, 0 BO 15 is referred to as the beacon order.As soon as beacon transmission commences, other unassoci-

ated nodes within the vicinity of the WPAN coordinator can

elect to join the newly formed WPAN. WPAN members are

only active for a certain period within the BI. This active period

is referred to as the superframe duration (SFD). The length of

the SFD is given as

SFD = 0.01536 2SO (4)

where SO, SO BO is referred to as the superframe order.

The SFD of a WPAN begins at the instant that the beacon istransmitted by the WPAN coordinator. The difference between

the SFD and the BI is the time interval in which WPAN nodes

need to be inactive and can probably go to sleep.

If multiple WPANs operate on the same frequency band or

frequency channel and are within the communication range of

one another, it is mandatory that their SFDs are separated in

time. The idea is to prevent one WPAN from interfering with

the active period of another. For instance, if we assume that

WPANs AD are within the communication distance of oneanother, their SFDs could be arranged as shown in Fig. 2. Note

that to maintain the integrity of the SFD boundaries, WPANs

AD must be synchronized with one another. Several solutions

exist to ensure the aforementioned condition, including [25]and [26]. It should be apparent in Fig. 2 that as the number

of WPANs within the communication distance of one another

increases, the length of the BI also increases if each SFD will

be separated in time.

Although outside the scope of this paper, it is worth noting

that mechanisms exist to mitigate the interference that was

caused by other networks, e.g., 802.11, which operates on

the industrialscientificmedical band as the IEEE 802.15.4

network [27].

B. Channel Access Mechanisms

The SFD can be divided into the contention access period

(CAP) and an optional contention-free period (CFP). In theCAP of any SFD, WPAN members and the coordinator have

to contend for the medium using a carrier-sense multiple access

with collision avoidance (CSMACA) mechanism. To transmit

during the CFP, WPAN members must have been granted

some guaranteed time slots (GTSs) in the SFD by the WPAN

coordinator. These grants are either unsolicited or a result of an

explicit GTS request that was transmitted by a WPAN member.

In this paper, the CFP is the most pertinent and, as such, will

further be discussed in detail using Fig. 3.

According to the standard, the activities of the IEEE 802.15.4

MAC layer are coordinated by an abstract entity known as the

next higher layer. This entity receives and processes MAC-layer commands on behalf of a node. For instance, if a node

requires for GTSs, the higher layer computes the number of

slots required and sends this information to the MAC layer. The

MAC layer appropriately frames this GTS request command,

setting all the required fields, and transmits it on the wireless

medium. According to the specification, all command frames

will be sent using the CSMACA mechanism and must be ac-

knowledged upon receipt. When a coordinator receives a GTS

request command, it acknowledges the frame and decapsulates

it. The information with regard to the GTS request is then sent

to the coordinators next higher layer. The coordinators next

higher layer reserves slots in the subsequent SFD based on

the request and as it deems fit. The information with regard

to GTS grants are included in the next outgoing beacon. Upon

the receipt of a GTS grant from the coordinator, the next higher

layerof a node instructs the CFP process to begin transmissions

as soon as its reserved slot time begins and stops the process

when it ends. If the number of allocated GTSs is not sufficient,

the GTS request process is repeated as aforementioned and as

depicted in the message sequence in Fig. 3. Note that only a

maximum of seven nodes can be granted GTSs in any SFD.

C. Inter-WPAN Communication

The standard does not expressly define how inter-WPANcommunication is achieved, but it gives room for much



5/17


Fig. 3. Default GTS message sequence.

flexibility. In [28] and [29], the authors attempt to exploit

this flexibility to achieve inter-WPAN communication. Two

mechanisms with similar underlying principles were proposed.

In the first solution [28], which was referred to as masterslave

bridging, the coordinators act as the relay nodes or bridges on

behalf of their respective WPANs. Slaveslave bridging [29],

on the other hand, shifts the responsibility of relaying data for

a WPAN to a node other than the coordinator. To illustrate the

operation of the bridge, we will assume that two WPANs A and

B exist such that traffic from WPAN A needs to go through

WPAN B en route to the sink. A bridge will typically accept

data from WPAN A during its SFD and deliver these data to

WPAN B during WPAN Bs SFD. Another bridge will deliver

the data from WPAN B to the sink using the same mechanism.

The bridge can accept and deliver data using the CAP or CFPof the WPANs. If the bridge operates during the CAP, then it

will have to compete for the channel like any other member of

the WPAN. As noted in [28], depending on the internal state

of a receiving WPAN, the bridges operation during the CAP

can negatively impact the activities of the WPAN members, or

the other WPAN members could do the same to the bridge.

Although the CFP portion is used for bridge activities, this

negative impact is still possible, because the GTS request

command is only transmitted during the CAP. In addition, the

fact that the bridge can compete for the channel across multiple

WPANs suggests that the bridge is a member of each of those

WPANs.

In this paper, we adopt a different approach to inter-WPAN

communication by slightly extending the GTS message se-

quence in Fig. 3. Here, a relay node, whether it is a coordi-

nator or another designated node, need not be a member of

multiple WPANs. The communication across WPANs is strictly

done using the CFP, because it aids admission control and

bandwidth reservation, which, in turn, provides a mechanism

for insulating a WPAN from outside activities, if need be. If

a WPAN is saturated and cannot handle traffic that needs to

be relayed, this information is reflected in the route metric

that qualifies the path through that WPAN. The details of

how we achieve the aforementioned approach are discussed in

Section V-B, because it is an integral component of our routingmechanism.

V. PROTOCOL DESCRIPTION AND IMPLEMENTATION

In this section, we introduce and describe the operationalmechanism of our routing scheme within the context of what

is expected of a WSN routing protocol. In addition, contained

within this discussion is how our mechanism interacts with

the IEEE 802.15.4 MAC layer to achieve the WSN routing

objectives. However, before going into the discussion, a few

definitions are given in order.

A. Definitions and Notations

The definitions that follow will act as an aid to understanding

the various components of our routing mechanism, which is

described in the next section. Definition 1Neighbor WPAN: If WPANs A and B are

within the communication range of one another, then WPAN

A is a neighbor of WPAN B, and vice versa. We will denote the

set of neighbor WPANs of WPAN X as Nx, and its cardinalityis |Nx|.

Definition 2Out-Neighbor: If WPAN A has a route to a

sink through WPAN B, then WPAN B is an Out-neighbor

of WPAN A for that sink. We will denote the set of Out-

neighbors of WPAN X for sink S as Nxsout, and Nxsout Nx = Nx.

Definition 3In-Neighbor: Correspondingly, if WPAN A

has a route to a sink through WPAN B, then WPAN A isan In-neighbor of WPAN B for that sink. We will denote the

set of In-neighbors of WPAN X for sink S as Nxsin, andNxsin Nx = Nx.

Definition 4: It is possible that an In-Neighbor n Nxsinfor a WPAN X to sink S can also be an Out-neighbor for

WPAN X to sink T, i.e., |Nxsin Nxtout| 0.Definition 5Route Descriptor: A route descriptor contains

information with regard to a single route to a sink, and this

information will include the hop count (HC), the Out-neighbor,

and the quality of the path to that sink.

Definition 6Route Dscrpt List: The incoming route de-

scriptor list (Route Dscrpt List) RDinlist contains all incom-

ing route descriptors, whereas the RDoutlist contains all theoutgoing descriptors of a relay node.



6/17


Fig. 4. Route packet structure. (a) Beacon payload format. (b) Route descriptor format.

Fig. 5. WPANs and one sink. (a) Network structure. (b) Outgoing route descriptor.

Definition 7Forwarding Table: The forwarding table Tfdcontains the routes to the sinks and the associated computed

route cost.

Definition 8: The inputs to the process that produces

the forwarding table are the entries of the incoming Route

Dscrpt List.

Definition 9LQI: The IEEE 802.15.4 specification man-

dates that each incoming frame must be stamped with a link

quality indicator (LQI) value. This value indicates the quality

of the link at the time of frame reception. According to the

standard, the LQI value must be an integer that is uniformly

distributed between 0 and 255, with 255 indicating the highest

signal quality. Details about how this value is computed are

contained in Appendix A.

Definition 10Update Interval: The update interval, which

we will denote by , is the length of time that must elapsebefore a relay node completes the following three tasks:

1) purges its forwarding table; 2) updates the forwarding table if

new information is available; and 3) announces its best routes to

sinks to its surrounding WPAN neighbors. The update interval

is in multiples of the BI [see (3)], i.e., = coeff BI,where coeff is the update coefficient. Finally, we will denotethe current update interval by curr.

B. Mechanisms for Achieving WSN Routing Objectives

The purpose of this section is to give a technical description

of our proposed routing mechanism. We do this by juxtaposingeach of its components with the objectives of the WSN routing

protocols in Section II.

1) Route propagation: Route propagation is achieved

through the insertion of route information into the payload

section of an outgoing IEEE 802.15.4 beacon once in every

update interval . WPANs within the communication distanceof one another know when a neighbor WPAN transmits its

beacon, because they all have to be synchronized to prevent

SFD boundary encroachment (see Section IV-A). A WPAN

coordinator simply enables its receiver when any neighbor

WPAN n Nx transmits a beacon that contains route infor-mation. The receiver is immediately disabled once the beacon

is received. The coordinator then proceeds to extract the routinginformation from the beacon for processing. The frequency of

the neighborhood beacon reception also depends on the update

interval .The structure of the beacon payload is shown in Fig. 4(a).

The protocol ID (Proto ID) field tells the MAC layer which

higher layer owns the content of the beacon payload. The route

descriptor count (Route Dscrpt Count) indicates the number of

route descriptors in the payload. The maximum number of route

descriptors in any beacon payload is eight. The Route Dscrpt

List field contains the route descriptors to the known sinks.

The formal structure of a route descriptor is shown in

Fig. 4(b). The sink WPAN ID (SID) contains the WPAN ID

of the sink. The Out-Neighbor ID (ONID) field contains the

WPAN ID of the Out-Neighbor. The HC contains the nodes HC

from the sink. Finally, the Lowest Path LQI (LPL) field holds

the value of the lowest link LQI on the path from the sink to

the node.To describe the route-propagation mechanism, consider

Fig. 5(a), in which nodes S and AD are the coordinators for

their respective WPANs, and the numbers by the bidirectional

arcs that connect the nodes are the LQI values of the links. At

time 1 [see Fig. 5(b)], node S, which is the sink for the network,

inserts a payload into the beacon payload section. The beacon

payload Proto ID is set to1 to indicate to the MAC layer that

the payload is for the network/routing layer, and the value of

the Route Dscrpt Count field is set to1 to indicate that only

one route descriptor is contained in the Route Dscrpt List. The

contents of this single route descriptor are shown in the first

row in Fig. 5(b). Notice that the sink puts its address in the

SID and ONID fields of the descriptor and sets HC = 0. It alsosets LP L = 255. The sink then transmits this beacon during itsactive period or SFD. Node A enables its receiver and gets the

beacon from the wireless stream. It extracts the payload and

adds the route descriptor to its incoming Route Dscrpt List.

At time 2, node A fills an outgoing route descriptor with the

values shown in row 2 in Fig. 5(b). This time, the LPL is set

to 20, because the link between Sink S and Node A had an LQI

value of 20, as indicated in Fig. 5(a). HC = 1. This outgoingdescriptor is inserted into the beacon payload, and the beacon

is transmitted. Nodes B and D will receive the beacon that was

transmitted by node A. Both nodes will process the incoming

descriptor similar to process previously undertaken by node A.For their outgoing route descriptors, nodes B and D both update



7/17


the HC to 2, and the ONID is set to the address of node A. Node

B updates the LPL in its outgoing descriptor to 10, whereas

node D leaves the LPL as 20, although the LQI of the link that

connects nodes A and D has a value of 50. Node Cwill receive

two descriptors to Sink S: one descriptor from node B and

another from node D. We designed the routing protocol such

that, if a node has multiple routes to a sink, only the best routeis included in the outgoing Route Dscrpt List. If other things are

equal, node C will include only the path through node D in its

outgoing Route Dscrpt List, primarily because the LPL on the

path to the sink through D is higher than that of the path through

B. In other words, the routing mechanism takes cognizance of

the quality of all the links on a path to a sink, because the quality

of a path is only as good as the hop on that path with the lowest

link quality. At time 4, node C creates an outgoing descriptor,

with the values shown in the fifth row in Fig. 5(b). This

descriptor is inserted into the next outgoing beacon from C.2) Loop Avoidance: We use four mechanisms to prevent

or minimize the occurrence of loops in the network. These

mechanisms are itemized and discussed as follows.

1) Lists and table purge. In every update interval , theforwarding table and the outgoing descriptor list are

purged. If new information is available in the form of new

descriptors in the incoming descriptor list, the forwarding

table is populated with this information; otherwise, it is

left empty. The idea here is to prevent the utilization and

propagation of stale information, which minimizes loops

within the network.

2) Descriptor Reject 1. In Fig. 5, at time 4, node C sends

out its descriptor, as shown in the last row in Fig. 5(b).

Nodes B and D will receive the route descriptor in thetransmitted beacon of node C, because they are both

within the communication range of node C. When node

D receives node Cs route descriptor, it rejects it, because

node D can infer from the ONID of node Cs route

descriptor that it is the Out-Neighbor or the next hop for

node C to Sink S. This approach effectively deals with

the count-to-infinity problem. During this process, node

D adds node Cto its In-Neighbor List NDin for SinkS.Node B will also reject node Cs route descriptor, because

it can infer from the HC field of the descriptor that it is

closer to the sink than node C and that the descriptors

OI D = SI D. A descriptor is also rejected by a node Xif OI D NX . The loop prevention process is capturedin the algorithm in Fig. 6.

3) Descriptor Reject 2. Consider another scenario where

Sink S in Fig. 5(a) is mobile and moves away from node A

toward node B. At the next update interval , node A willno longer have a direct path to Sink S, but node B will.

Now, node A receives a route descriptor from node B,

announcing that it is one hop away from the sink. Node A

rejects this descriptor and removes Node B from its In-

Neighbor list for that sink. At the next update interval

, node A will accept the route descriptor from node B,because node B is no longer an In-Neighbor of node A

for Sink S. The idea here is for A to err on the sideof caution just in case the validity of the information

Fig. 6. Loop-prevention algorithm. X is the ID of the node that runs thealgorithm, and YRDi is the ID of the source ofRDi. HCxs is the currenthop count of node X to Sink S.

that was propagated by node B is temporal. This loop-

prevention mechanism was added to the routing protocol,

because we found out that, in practice, the speed and

the dwelling time of the mobile sinks can sometimes

negatively impact route convergence.4) Descriptor TX limit. For the last loop avoidance mech-

anism, sinks are only allowed to propagate route descrip-

tors about themselves, i.e., the Route Dscrpt Count is

always 1 for a sink. For example, consider a mobile sink

scenario with two sinks: one mobile sink and one static

sink. Let us further assume that each sink is within the

communication distance of the other one such that Sink 1

knows about Sink 2, and vice versa. Sink 1 propagates

route information about Sink 2, and sink 2 does the

same for Sink 1. Now, if Sink 1 becomes mobile and

moves away from Sink 2, the possibility exists that Sink 1

might transmit information aboutSink 2

, although it is nolonger within the communication range of Sink 2, thus

propagating incorrect information. The descriptor TX

limit mechanism prevents this instance.

3) Admission Control and Bandwidth Reservation: Band-

width reservation and admission control across multiple

WPANs is accomplished using the modified GTS message

sequence in Fig. 7.

Based on Fig. 5, node C had chosen node D as its Out-

Neighbor WPAN to Sink S. Let us now assume that node Chas

traffic that needs to get to Sink S through node D. The processof admission control and bandwidth reservation by node D on

behalf of node C is explained as follows. Within every updateinterval , along with the inclusion of route descriptors, node D



8/17


Fig. 7. Modified GTS message sequence.

includes GTS grants in its beacon for each of its In-Neighbors

(a maximum of 7 In-Neighbors). This method is coordinated by

node Ds routing process and its higher layer, as shown in Fig. 7.

Ifnode Crequires traffic to be sent through node D en route to

Sink S, it uses this first unsolicited GTS grant to send a GTS

request to node D. This GTS request would contain information

about how much traffic node Cseeks to route through node D.

Upon receiving this GTS request, node D estimates how much

resources would be required to admit node Cs traffic. If

node D can handle node Cs traffic, node D, in its next active

period/SFD, grants node C the required number of GTSs. The

second grant is depicted as Grant 2 in Fig. 7. Node C beginstransmission to node D at the assigned slot times. On the other

hand, ifnode D cannot admit traffic on behalf ofnode C, it sim-

ply does not grant node C the second GTS grant. This method

assures that the traffic from node Cdoes not interfere with the

activities of the WPAN in which node D is the coordinator

without the permission of node D. In general, if the internal

state of a WPAN is such that it cannot route traffic on behalf

of any of its WPAN neighbors, it simply does not include GTS

grants (either Grant 1 or 2 in Fig. 7) in its outgoing beacons. If

node D cannot admit traffic for node C, then node B might doso. In this case, node B should be the preferred Out-Neighbor

for node Cto Sink S, and this approach should be reflected in the

route metric. How this approach is incorporated into the route

metric computation is discussed in the next section.

If we will contrast the modified message sequence in Fig. 7

with the default in Fig. 3, we would find that the difference

lies in how the GTS requests are sent. The default message

sequence uses the CSMACA/CAP channel-access mechanism

to transmit a request, whereas the modified version uses the

CFP. If the first GTS is not granted (i.e., Grant 1), then there is

no way that a GTS request can be placed across WPANs; hence,

bandwidth cannot be reserved, and traffic will not be admitted

from outside the WPAN.

Based on the discussions so far, we see that a coordinator

can assign GTSs to nodes within and outside its WPAN. TheGTS transaction between a WPAN coordinator and its WPAN

member is done using the members assigned 16-b short ad-

dress. To allow for consistency, GTS transactions outside a

WPAN should be carried out using the 16-b WPAN ID. The

only provision is that the coordinator of WPAN X should neverassign a 16-b address that is already in use by any WPAN

n Nx to any of its WPAN members.4) Route Metric Computation: The relative preference of

one path over another is based on the computed metric on those

paths. Our route metric computation formula is a function of

the link quality of the path and the hop distance from a sink,

as shown in (5). The higher the metric Cij, the better the route.

We have

Cij =(HDij)

+ (LP Lij)

2(5)

where Cij [0.0, 255.0], HDij [0, 255] is the hop degreefrom Sinki to node j, and LP Lij [0, 255] is the value of thelowest LQI along the path from Sinki to nodej. The hop degreeHDij is a function of the HC HCij from a node to a sink suchthat HDij = 255 HCij , i.e., the closer a node is to a sink,the higher the hop degree becomes. Based the aforementioned

condition, we can infer that the HC between a node and a sink

can never exceed 255.

In (5), [0.0, 1.0] and [0.0, 1.0] are the LQI and hopdegree exponents, respectively. These exponents are weights

that define the relative importance of the hop degree/HC and

the lowest LQI on a path when computing Cij. To show howthese exponents are applied, assume that two paths (Paths 1 and

2) exist from node A to Sink S. We have

Path 1 = A 50 B 60 C50 D 70 S

Path 2 = A 30 F 20 G 40 S.

In addition, assume that the numbers underneath the arrows

represent the quality of the hop/link.

Using (5) and setting = 1.0 and = 1.0, the route metricfor Paths 1 and 2 are 150.2 and 136.0, respectively. Based on



9/17


the computed route metric, Path 1 will be the preferred route

for node A to Sink S. However, Path 1 will also consume more

energy for transmission than Path 2, because it consists of more

hops to the sink than the other path. This case might not be ideal

for all scenarios. To remedy this case, we make a function ofthe HC HCij as follows:

=1

HCij. (6)

If we recomputed the route metric for both paths while taking

cognizance of (6) and = 1, we get 126.83 for Path 1 and 127.4for Path 2, with Path 2 becoming the preferred path.

Given that Path 2 is the current preferred path, the Out-

Neighbor for node A is node F. The possibility that node Fcannot admit traffic from node A exists. In this case, node Awould turn to the other path for which node B is the Out-Neighbor. If node B has the resources to admit traffic fromnode A, then the path through node B should be the preferred

path, because the path through node F is as good as useless.Basically, the inability of an Out-Neighbor to admit traffic en

route to a sink should be reflected in the metric that qualifies

that path through that Out-Neighbor. This condition is precisely

what the HD exponent in (5) ensures. For instance, if, in thecurrent update interval curr , an Out-Neighbor to a sink grantsthe first GTS (i.e., Grant 1 in Fig. 7) to an In-Neighbor, then is set to 1, but if it does not, then is set to 0, i.e.,

=

1.0, if first GTS allocated in curr0.0, otherwise.

(7)

Now, based on the assumption that node F does not grant

GTS to node A but node B does within the current intervalcurr , = 1.0 for Path 1, and = 0.0 for Path 2. With =1/HCij, node As route metric CAS for Paths1 and 2 are 126.83and 3.71, respectively, with Path1 becoming the preferred path.

5) Support for Other WSN Routing Objectives: Certain

WSN applications, e.g., agricultural and environmental mon-

itoring applications, require that the underlying network can

retrieve and transmit data in a geographically oriented form. For

this case to be possible, the WSN nodes must have some form

of onboard location positioning component, e.g., the GPS-less

solutions in [30][32]. If this component is present, our routing

mechanism can be turned into a geographically oriented proto-

col simply by choosing the 16-b WPAN ID based on the geo-graphical location of the coordinator. Note that efficient routing

for WSN is done at the granularity of the cluster/WPAN.

With regard to communication security within the context of

the IEEE 802.15.4 specification, see [33][35].

Given the relative limitations of WSN nodes, particularly

in terms of onboard memory, it is ideal that the size of the

forwarding table is bounded and kept to a minimum. To prevent

forwarding table explosion, we limit the number of entries into

the forwarding table to 16, i.e., two of the best paths each for a

maximum of eight distinct sinks.

Note that, if a WPAN coordinator designates one of its

WPAN member as the relay node for that WPAN, the desig-

nated relay node simply extracts the route information fromits coordinators transmitted beacon and updates its forwarding

TABLE ISIMULATION PARAMETER VALUES

table with the exact same values. In this paper, the WPAN

coordinator also doubles as the WPANs gateway or relay node.

Finally, a WPAN, through its coordinator, can choose not

to participate in the routing process by having the coordinator

disable its receiver when its neighbor WPANs transmit theirbeacons.

VI. PERFORMANCE EVALUATION

Cross-layer interactions do not lend themselves well to

mathematical or analytical modeling, primarily because the

multivariate parameters of the interacting layers must be con-

sidered if the performance characteristics should accurately be

captured. To that end, the routing mechanism in the previous

section was built atop an IEEE 802.15.4 model, which was

implemented using the OPNET network simulation tool [36].

We chose this simulation tool, because it enables us to modelthe wireless channel in detail and with a relatively high fidelity.

We carried out two sets of evaluations to assess how the rout-

ing mechanism in conjunction with the IEEE 802.15.4 MAC

and physical layers deliver on the objectives expected of a WSN

routing protocol. In the first set of evaluations, we studied how

the routing scheme achieves load balancing, uniform energy

dissipation, bandwidth reservation, and admission control. We

also look at the contents of the incoming descriptor lists and

the forwarding tables of each of the nodes. In the second set of

evaluations, we look at how the mechanism performs on scale,

particularly in terms of loop control, sink mobility, energy

consumption, and its adaptability to topological changes. Wedo this approach under three different scenarios.

The plots in the next two sections are average values that

were collected with a 95% confidence interval over multiple

simulation runs, each with a different random number seed that

is uniformly distributed between 0 and 250.

The entries in Table I are the simulation parameters that

are common to both sets of evaluations. The table shows the

nominal transmit power and receiver sensitivity, as set by the

IEEE 802.15.4 specification for compliant nodes. Our energy-

consumption model follows that of Texas Instrument (TI)s

CC2430 chip [37], which is currently deployed on the latest

hardware platforms targeted at WSNs. This TI chip expends

24.7 mA for transmission and 27 mA for reception at 3 V. Theremaining table entries are self explanatory.



10/17


Fig. 8. Three WPANs and one sink.

A. Evaluation 1

Our first network scenario consisted of four WPANs, as

shown in Fig. 8. One of these WPANs was the network sink. In

the scenario, we placed WPAN 3 far enough so that it is outside

the communication range of the sink but within range ofWPANs

1 and 2. The idea was to have WPANs 1 and 2 act as the Out-

Neighbors for WPAN 3 to Sink 1. Note that, with the nominal

transmit power and receiver sensitivity and under a free-space

path loss model, the maximum communication distance of a

node is 170 m or less if we factor in the other radio attributes.In Figs. 9 and 10, we show the content of the incoming Route

Dscrpt List and the resulting forwarding table for WPANs 1

and 2 for the 120th update interval. We can see in Fig. 9 that

WPAN 1 has a direct route to the sink and an alternate indirect

route through WPAN 2. A similar deduction about the number

of available routes to WPAN 2 can be made in Fig. 10. In

Fig. 9(b), the direct route is the preferred route to SINK 1 for

WPAN 1 as expected, but notice that the preferred route for

WPAN 2 to SINK 1 is the indirect route through WPAN 1, asshown in Fig. 10(b). The reason for this case is that the two-

hop path from the sink through WPAN1 to WPAN2 had a better

link quality than the one-hop path from the sink to WPAN 2, as

indicated in the low-LQI entries in Figs. 9(a) and 10(a). Such

a scenario allows for data to transverse the best quality path,

if longer, at the expense of consuming twice the amount of

energy required for transmission and reception. If the forward

error-correction option, as provided for in [38], is set for the

radios of the deployed IEEE 802.15.4 WSN nodes, then these

nodes can receive and improve on low-quality frames. In this

case, there is no reason that the shortest path should not be

the preferred option. Our nodes can receive low-quality framesup to a certain degree, given the error correction threshold in

Table I, i.e., the nodes can recover frames that with 20% or

fewer errors. To align the route metric with this result, we set

the LQI exponent = 1/HCij as discussed in Section V-B-4.The new forwarding table of WPAN 2 is shown in Fig. 11(a),

with the direct path set as the best path to the sink.

Fig. 12 shows the incoming Route Dscrpt List and the

forwarding table for WPAN3. The path through WPANs 1 and 2

tie in terms of the HC to the sink; thus, WPAN 3 chose WPAN 1

as its Out-Neighbor to SINK 1 based on the link quality of the

path through WPAN 1.

To demonstrate the load balancing, admission control, and

bandwidth reservation capabilities of the protocol, WPAN3 wasset to transmit 300 frames of 100 B each to the sink. Three

scenarios were also created, and the energy consumed by the

two Out-Neighbors ofWPAN 3 in each of the three scenarios is

shown in Fig. 13.

In the first scenario in Fig. 13, no data were transmitted by

WPAN 3, and the energy that was consumed by WPANs 1 and 2

was mainly due to beacon transmission and reception. In

the second scenario, WPAN 3 routed the 300 frames throughWPAN 1, because WPAN 1 was the preferred Out-Neighbor,

as shown in Fig. 12(b). Thus, the energy that was consumed

by WPAN 1 is higher than what was consumed by WPAN 2.

In the third scenario, WPAN 1 was set to reserve bandwidth

and admit traffic for half of what WPAN 3 requested, after

which, WPAN 1 denied all GTS grants to all its In-Neighbors.

As a result of this non-GTS grant, the route through WPAN 1

was downgraded based on the hop degree exponent (), asshown in the forwarding table in Fig. 11(b), causing WPAN 2

to become the preferred Out-Neighbor for WPAN 3. This case

caused WPAN 3 to request bandwidth reservation and traffic

admittance from WPAN2. WPAN2 granted this request, and the

remainder of the data frames was transmitted through WPAN 2

to SINK 1. Both Out-Neighbors were utilized by WPAN 3 for

routing traffic; thus, the energy consumed by WPANs 1 and 2

evened out, as shown in Scenario 3 in Fig. 13.

A few points to remember from the aforementioned example

are given as follows: 1) A WPAN can choose to admit all,

some, or none of the traffic from an In-Neighbor; 2) if traffic

is not admitted by an Out-Neighbor, it is reflected in the route

metric of the route that goes through that Out-Neighbor; and

3) Points 1 and 2 allow for load balancing and graceful degra-

dation of the network, which has been shown to increase the life

time of the network [8], [9].

B. Evaluation 2

For the set of evaluations within this section, we created three

different scenarios. Each scenario consisted of 20 randomly

deployed WPAN coordinators, five of which were set to be

sinks. These nodes were deployed in a 250 m 250 m area.In the first scenario, which we refer to as the Static Topology

scenario, all coordinators were static. In the other two scenarios,

two of the five sinks were set to be mobile. In the Dynamic

Topology (IN Perimeter) scenario, the trajectories of the mobile

sink nodes were confined to the perimeter of the deployment

area. In the third scenario, which we refer to as the DynamicTopology (OUT Perimeter) scenario, the trajectories of the

mobile sinks were set such that they went out of the deployment

area and, ultimately, out of the communication range of the

other 18 coordinators. The whole idea was to study the impact

of sink mobility on the routing protocol. For both scenarios with

mobility enabled, the mobile sinks moved at a ground speed

of 10 m/s. There were four stops along the trajectories of the

mobile sinks; the dwell time for the mobile sinks at each stop

was 3 min. For the dynamic scenarios, sink mobility started 3

min into the simulation.

The connectivity graphs, which are based on the contents

of the forwarding tables of the nodes, are shown in Figs. 14

and 15(a). The black nodes in the figures represent the nonsinknodes, whereas the white nodes are the sinks. Although the



11/17


Fig. 9. Route Dscrpt List and forwarding table for WPAN 1 (= 1, and = 1). (a) Incoming Route Dscrpt List for Update 120. (b) Forwarding table forUpdate 120.


Fig. 11. New forwarding tables for Update 120 for WPANs 2 and 3. (a) Forwarding table for WPAN 2 (= 1, and = 1). (b) Forwarding table for WPAN 3( = 1).


Fig. 13. Energy consumption for WPANs 1 and 2.

nodes had multiple routes to each sink (6.4 on the average),

the plots in the figures only show the routes with the lowest HC

to the sinks.

For the static scenario, we can see that the network is fully

connected. For both Dynamic Topology scenarios, Sinks 1 and

4 were the mobile sinks. The initial and final positions of the

mobile sinks for the Dynamic Topology scenarios can visually

be inferred by comparing Figs. 14(b) and 15(a) with Fig. 14(a).

In the IN Perimeter scenario, the links with the dotted lines

were the new links formed as a result of sink mobility. For the

OUT Perimeter scenario, notice that none of the nodes had aconnection to Sinks 1 and 4, because they are clearly out of the

communication range (i.e., >170 m). As a result, the average

number of sinks known per WPAN coordinator was lower forthe OUT Perimeterscenario than for the other two scenarios, as

shown in Fig. 15(b), which is a plot of the average number of

known sinks versus the update coefficient. Note that the update

coefficient coeff defines the duration of the update interval(see Definition 10). For example, with coeff = 5 and withthe BO value shown in Table I, the length of the updateinterval is 2.5 s (i.e., the route descriptors are propagatedand received, and forwarding tables are purged and updated

every 2.5 s). Correspondingly, ifcoeff = 50, then = 25 s.Note that the routing protocol is disabled if coeff = 0. Withthe routing protocol disabled, WPAN coordinators cannot reach

the sinks, because the network would not be connected. The

average number of known sinks, as shown in Fig. 15(b), is con-

sistent with what was expected for each of the three scenarios.

Note that consistency is the first of the two indicators of route

convergence (the second indicator will be discussed shortly).

In the OUT perimeter scenario, as the sinks steadily moved

away from the deployment area, WPAN coordinators at one

edge of the deployment area had to increasingly depend on

the coordinators at the opposite edge to reach the mobile sinks.

Thus, the mean HC from WPAN coordinators to the sinks was

higher for the OUT Perimeterscenario compared with the other

two scenarios, as shown in Fig. 16(a). This increased HC for

the OUT perimeter scenario is more clearly shown in the HC

frequency distribution of the network in Fig. 16(b), where itstail pulls outward, with at least one instance where a node had a



12/17


Fig. 14. Connectivity graphs. (a) Static scenario. (b) IN Perimeter scenario.

Fig. 15. Connectivity graph and average number of known sinks. (a) OUT Perimeter scenario. (b) Average number of known sinks.

Fig. 16. Hop counts to sinks. (a) Mean hop count to sinks. (b) Hop count frequency frequency distribution (coeff = 5).

path with eight hops to a sink. In addition, based on the figure,

the coordinators in the Static scenario were a maximum of three

hops away from any sink at any time. This maximum HC for the

IN perimeterscenario was 4.

A system is said to be stable if it has properties that assure

that errors introduced into the system at one time do not

unboundedly grow at later times [39]. If the system in questionis a routing protocol, then a stable routing protocol is one that

assures that a loop introduced into the network at any time does

not unboundedly grow during the operation of the network. The

stability of a routing protocol is the second indicator of route

convergence. Fig. 16(a) and (b) implicitly convey the stability

of our routing protocol. For instance, the fact that the mode

for all three plots is 2 in Fig. 16(b) indicates that there are no

perpetual loops in the network, irrespective of the topologicalchanges due to sink mobility. For an unstable routing protocol,



13/17


Fig. 17. Energy expended in the network. (a) Network energy consumption. (b) Energy consumed versus the number of sinks (Static scenario; coef =10, 20 WPANs).

Fig. 18. Network life time and average time to converge. (a) Network life time (in years). (b) Average time to converge (in seconds).

the frequency of the higher HCs would have been much higher,

which is generally an indication of loops in the network, similar

to the case with the count-to-infinity problem associated with

RIP [11].

The following two cost metrics are associated with route

convergence (consistency + stability): 1) the energy expendedto achieve convergence and 2) the time taken to converge. In

Figs. 17 and 18, we present the energy that was consumed in the

network for the simulation duration, the estimated life time of

the network, and the average time to converge as a function of

the update coefficient. Based on the plots in Fig. 17(a), we see

that when the routing protocol was disabled (i.e., coeff = 0),the network consumed the least amount of energy. With the

routing protocol enabled (i.e., coeff > 0), we see that thehigher the update coefficient is, the lower the energy consumed

becomes. Fig. 17(a) expresses that the less frequent the route

updates, the lower the energy consumed. As shown in the

figure, the energy that was consumed in the OUT perimeter

scenario was slightly lower than those of the other two

scenarios. The reason for this case is that the higher the number

of deployed sinks [see Fig. 15(b)], the higher the number of

route descriptors in the beacon payload, which increases thesize of the overall beacon itself, hence, a slight increase in

the amount of energy required for reception and transmission

of beacons, as depicted in Fig. 17(b). The plot in Fig. 17(b)

reaches its asymptotic level when the number of deployed sinks

is greater than or equal to 8. This case is a result of the length

of the Route Dscrpt Count field in Fig. 4(a), which restricts the

number of descriptors in any beacon to a maximum of 8.

The lifetime of a wireless network is generally defined as

the length of time for which the network functions as expected

before becoming unusable. For the energy-constrained WSN,

the network becomes unusable when all or a subset of the

nodes, particularly those tasked with relaying data, run out of

energy. To that end, based on the rate of energy consumption in

Fig. 17(a), we estimated the network lifetime as a function of

the update coefficient. For instance, when the update coefficient

was 10 in Fig. 17(a), the energy that was consumed in the

network was 10.84 J (Static scenario). This result translates to

0.54 J apiece for each of the 15 WPAN coordinators and the

five sinks for a simulation duration of 20 min. At that rate,

the daily consumption is 39 J per node. Based on the totalbattery capacity in Table I, the nodes can last for 277 days or0.76 year before running out of energy. As shown in

Fig. 18(a), when the routing protocol is disabled, the nodescan last for about 4.3 years. We will use this result as the



14/17


Fig. 19. Average time to converge and energy expended per WPAN (five sinks; coeff = 5). (a) Average time to converge (in seconds). (b) Energy expendedper WPAN.

Fig. 20. Average end-to-end delay and delivery ratio. (a) Average end-to-end Delay (in seconds). (b) Average delivery ratio.

upper bound for the lifetime of the network. With the update

coefficient set to 5, the nodes only last for about half a year,

but as we increased the update coefficient, the lifetime of the

network steadily inched toward the lifetime upper bound.

It might seem like a good idea to extend the lifetime of the

network by simply having a larger update interval or coefficient,

but having a larger update interval also means that the network

would be less reactive to topological changes, because the

frequency of route propagation and route updates are defined

by the update interval (see Definition 10). For instance, notice

that the average time to converge is higher for larger values of

the update coefficient, as shown in Fig. 18(b). It suffices to say

that, if a WSN topology is one that frequently changes, then a

lower update coefficient should be chosen for that network, and

the converse should be the case if the topology is expected to

be generally less dynamic.

Another factor that indirectly affects the convergence time

of the routing protocol is the number of WPANs deployed in

the network, assuming that the size of the deployment area is

kept constant. In Section IV-A, we mentioned that the length

of the BI should be directly proportional to the number of

deployed WPANs |Nx| within the communication distance ofone another if we need to prevent inter-WPAN interference.

Therefore, by implication, an increase in |Nx| increases theupdate interval, because the BI is one of the two parameters

used in its computation. In Fig. 19(a), we show that increasing

the number of deployed WPANs has the same impact on the

convergence time as an increase in the update interval, as

shown in Fig. 18(b). One immediate benefit of having a high

|Nx| value is that the network is robust, fault tolerant, andconnected, because a single WPAN will typically have multiple

routes through its neighbor WPANs to any number of sinks.

However, this benefit comes at the cost of an increase in energy

consumption [see Fig. 19(b)], because a WPAN, e.g., WPAN

X, will have to enable its radio to receive route beacons from

allNx

in every update interval to maintain high connectivity.

In Appendix B, we derive an equation that optimizes the

energy consumption in the network as |N x| increases withoutadversely affecting connectivity.

To study the impact of the update coefficient on the delivery

ratio and the data end-to-end delay for all three scenarios, we

sent 300 data frames of 100 B each from WPAN 1 [circled

black node in Figs. 14 and 15(a)] to mobile Sink 4. The Out-

Neighbors to Sink4 for WPAN1 were set to only assign enough

GTSs to transmit 50 frames in every update interval. This condi-

tion meant that the more frequent the update interval becomes,

the more the GTSs allocated per unit time are, and therefore, the

faster the traffic travels. The impact of this result is captured in

Fig. 20(a), where we see a steady increase in the average end-to-end delay as we increase the update coefficient. Notice that



15/17


the end-to-end delay for the OUT Perimeterscenario was higher

than that of the other two scenarios when coeff > 15. Thiscase is a direct result of the increased HC between the WPANs

and Sink 4, because Sink 4 moved out of the deployment

perimeter. In terms of the delivery ratio, the Static and IN

perimeter scenarios performed better than the OUT perimeter

scenario, as shown in Fig. 20(b). The primary reason for thisresult was that, for all scenarios except the OUT perimeter

scenario, the mobile sink was always within the deployment

area. For the OUT perimeter scenario, observe a gradual drop

to 0 in the delivery ratio as the update interval increased. This

case was a direct result of GTSs not being quickly allocated to

data such that the data will reach the mobile sink before leaving

the deployment perimeter.

In addition, an equation that estimates data traffic delay

and the reaction time to topological changes subject to the

protocol configuration (e.g., the number of GTSs allocated

to data traffic) and the network deployment configuration is

derived in Appendix B.

VII. CONCLUSION

In this paper, we have proposed a routing scheme that

interacts with the IEEE 802.15.4 MAC- and physical-layer

specification to achieve the objectives of a WSN routing

protocol.

So far, we have technically demonstrated the following

five cases:

1) how the route information is propagated through the

use of route descriptors, which are contained within the

IEEE 802.15.4 beacons;

2) how admission control and bandwidth reservation canbe achieved across clusters/WPANs by simply extend-

ing the GTS message sequence of the IEEE 802.15.4

specification;

3) how loops can be prevented or minimized using route

descriptor rejects and descriptor transmission limitation;

4) how the routing metric can be used to reflect the highest

quality path, the shortest path, or a combination of both

by simply manipulating the LQI and the hop degree

exponents;

5) how support for uniform energy dissipation in the net-

work is achieved.

We have shown through thorough evaluation that the pro-posed routing scheme is flexible, adapts to topological changes,

is stable, and can achieve a high degree of sink connectivity.

APPENDIX A

LQI COMPUTATION

The IEEE 802.15.4 specification states that the LQI com-

putation algorithm should use the received signal power of a

frame, its signal-to-noise ratio, or a combination of both as

input. The standard mandates the following two conditions:

1) The LQI value must be bounded within the interval [0, 255],

with 255 being the highest quality signal and 0 being the lowest,

and 2) the LQI value must be an integer value that is uniformlydistributed within this interval.

It is instructive to restate here that the standard sets the

nominal transmit power to 0 dBm and the receiver sensitivity

to 85 dBm.Equation (8) meets the first condition, i.e.,

L = 255 + 3 P rxdBm (8)

where P rxdBm is the power (in decibelmilliwatts) of a re-ceived frame.

For example, if we assign P rxdBm = 0, we see that the equa-tion gives a value ofL = 255; conversely, if we set P rxdBm =85, we get L = 0. With (8), the value of L for every otherreceived signal power between the receiver sensitivity and

the nominal transmit power is effectively bounded within the

interval [0, 255].

To conform with the second mandate, we introduce (9), i.e.,

LQI =

L, ifL L < 0.5L, otherwise.

(9)

To explain this case, let us assume that P rxdBm = 65.5,which gives L = 58.5. This value of L is invalid and mighthave to be truncated to meet the requirement. What we did

was to round the L value downward or upward, depending onwhether the number after the decimal point was 5 or < 5.If the number after the decimal point is 5, we round upward,and we did the opposite when the value was


16/17


Given the linear relationship between E and C, (10) isderived as follows:

1

() = (a11 a12)

s

nx

(10)

where a11 = e/S, and a12 = e/|Nx|. The elements aijdepend on the energy consumption model of the hardware

platform and can empirically be derived. Equation (10) can

be used by the network implementer to estimate how much

a chosen value of |Nx| or S affects the energy that wasconsumed under different deployment scenarios. An increase

in S assures that multiple sinks are known to a WPAN, whichincreases connectivity, but this case also increases E. Similarly,an increase in |Nx| increases E while also increasing theconnectivity and fault tolerance of the network. Although the

effects of the S component on the E value is bounded (i.e.,S 8), |Nx| is not. However, the impact of |Nx| on E can

be reduced without affecting connectivity and fault toleranceif the coordinator of a WPAN, e.g., WPAN X, periodically

leaves its receiver disabled whenever any WPAN n Nx thatsatisfies {n : n Nxuin

n / Nxtout, u = t} transmits

its beacon (see Definitions 24).

The delay that was experienced by data traffic on the path

to a sink and the time delay to react to topological changes

can be represented by a vector D = (d), which is affected bythree components. The first component is the HC Hfrom a datasource to a sink. The closer a data source is to a sink, the lower

the value of H, and therefore, the lower the value of D. Thesecond component G is the number of GTSs granted to trafficas it transverses the path from the source to the destination.

The more the GTSs G granted by Out-Neighbors along a path,the faster the traffic travels, and hence, there is a reduction

in the value ofD.1 The third component multiplies the impactof D on the network, as shown in Fig. 18(b). In essence, thevector D = (d) is affected by another vector T = (H, G) suchthat a change in T will cause a change in D, i.e., T = (H + h,G g) will cause a change D = (d + ). One equation similarto (10) is derived as follows:

() = (b11 b12)

h

g

(11)

where b11 = d/H, and b12 = d/G. The elements bij in(11) can empirically be derived based on the WSN deployment

configuration and the traffic characteristics.

Aside from , there are several subtle relationships between(10) and (11). For instance, if WPAN X has multiple paths to a

sinkU, i.e., with a higher number of elements in Nxuout Nx, then there is a higher probability of having a high G valueand, hence, a reduction in D. However, an increase in thecardinality of Nxuout also increases the cardinality of Nx,which, in turn, increases E.

1Note that the G component does not affect the reaction time to topologicalchanges, because the route-propagation mechanism does not rely on GTSs.

The task of the network implementer is to find that the

network configuration, among other things, meets the required

objective in terms of the energy budget and delay constraints.

Both equations help in this task.

REFERENCES

[1] K. Murray, A. Timm-Giel, M. Becker, C. Guo, R. Sokullu, andD. Marandin, The European Network of Excellence CRUISE applicationframework and network architecture for wireless sensor networks, inProc. IEEE Globecom Workshops, Nov. 2007, pp. 16.

[2] LR-WPAN, Wireless medium access control (MAC) and physical layer(PHY) specifications for low-rate wireless personal area networks(WPANs), 2006, IEEE Tech. Rep.

[3] Sun-Spots, 2009. [Online]. Available: http://www.sunspotworld.com/docs/general-faq.php

[4] IPsensor, 2009. [Online]. Available: http://www.archrock.com/[5] M. Ouwerkerk, F. Pasveer, and N. Engin, SAND: A modular applica-

tion development platform for miniature wireless sensors, in Proc. Int.Workshop Wearable Implantable BSN, Apr. 2006, pp. 166170.

[6] NanoSensor, 2009. [Online]. Available: http://www.sensinode.com[7] Xbow, 2009. [Online]. Available: http://www.xbow.com/[8] V. Mhatre, C. Rosenberg, D. Kofman, R. Mazumdar, and

N. Shroff, A minimum-cost heterogeneous sensor network with alifetime constraint, IEEE Trans. Mobile Comput., vol. 4, no. 1, pp. 415,Jan./Feb. 2005.

[9] M. Yarvis, N. Kushalnagar, H. Singh, A. Rangarajan, Y. Liu, and S. Singh,Exploiting heterogeneity in sensor networks, in Proc. IEEE 24th Annu.

Joint Conf. INFOCOM, Mar. 2005, vol. 2, pp. 878890.[10] J. Luo and J.-P. Hubaux, Joint mobility and routing for lifetime elonga-

tion in wireless sensor networks, in Proc. IEEE 24th Annu. Joint Conf.INFOCOM, Mar. 2005, vol. 3, pp. 17351746.

[11] A. S. Tanenbaum, Computer Networks. Upper SaddleRiver, NJ:PearsonEduc., 2003, pp. 359360.

[12] J. N. Al-Karaki and A. E. Kamal, Handbook of Sensor Networks: Com-pact Wireless and Wired Sensing Systems. Boca Raton, FL: CRC, 2005,pp. 116138.

[13] K. Akkaya and M. Younis, Survey of routing protocols in wireless sensornetworks, Ad Hoc Netw., vol. 3, no. 3, pp. 325349, May 2005.

[14] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, An application-specific protocol architecture for wireless microsensor networks, IEEETrans. Wireless Commun., vol. 1, no. 4, pp. 660670, Oct. 2002.

[15] A. Manjeshwar and D. Agrawal, TEEN: A routing protocol for enhancedefficiency in wireless sensor networks, in Proc. 15th Int. Parallel Distrib.Process. Symp., Apr. 2001, pp. 20092015.

[16] Q. Li, J. Aslam, and D. Rus, Hierarchical power-aware routingin sensor networks, in Proc. DIMACS Pervasive Netw. Workshop,May 2001.

[17] A. Woo, T. Tong, and D. Culler, Taming the underlying challenges ofreliable multihop routing in sensor networks, in Proc. 1st ACM SenSys,2003, pp. 1427.

[18] MultiHopLQI. [Online]. Available: http://www.tinyos.net/tinyos-1.x/tos/lib/MultiHopLQI/

[19] R. Fonseca, O. Gnawali, K. Jamieson, S. Kim, P. Levis, and A. Woo, Thecollection tree protocol (CTP). [Online]. Available: http://www.tinyos.net/tinyos-2.x/doc/txt/tep123.txt

[20] D. Puccinelli and M. Haenggi, Arbutus: Network-layer load balanc-ing for wireless sensor networks, in Proc. IEEE WCNC, Apr. 2008,pp. 20632068.

[21] J. Luo, J. Panchard, M. Piorkowski, M. Grossglauser, and J.-P. Hubaux,Mobiroute: Routing towards a mobile sink for improving lifetimein sensor networks, in Proc. 2nd IEEE/ACM DCOSS, Jun. 2006,pp. 480497.

[22] C. Gomez, P. Salvatella, O. Alonso, and J. Paradells, Adapting AODV forIEEE 802.15.4 mesh sensor networks: Theoretical discussion and perfor-mance evaluation in a real environment, in Proc. Int. Symp. WoWMoM,2006, pp. 159170.

[23] H. Cheng and J. Cao, A design framework and taxonomy for hybridrouting protocols in mobile ad hoc networks, Commun. Surveys Tuts.,vol. 10, no. 3, pp. 6273, Quarter 2008.

[24] P. Samar, M. R. Pearlman, and Z. J. Haas, Independent zone routing:an adaptive hybrid routing framework for ad hoc wireless networks,

IEEE/ACM Trans. Netw., vol. 12, no. 4, pp. 595608, Aug. 2004.[25] Zigbee-Alliance, Zigbee Specifications, 2007. [Online]. Available: www.zigbee.org



17/17


[26] A. Koubaa, A. Cunha, and M. Alves, A time-division beacon schedul-ing mechanism for IEEE 802.15.4/Zigbee cluster-tree wireless sensornetworks, in Proc. 19th ECRTS, Jul. 2007, pp. 125135.

[27] R. Musaloiu-E and A. Terzis, Minimizing the effect of Wi-Fi interferencein 802.15.4 wireless sensor networks, Int. J. Sensor Netw., vol. 3, no. 1,pp. 4354, Dec. 2007.

[28] J. Misic, Analysis of slaveslave bridging in IEEE 802.15.4beacon-enabled networks, IEEE Trans. Veh. Technol., vol. 57, no. 3,

pp. 18461863, May 2008.[29] J. Misic, C. Fung, and V. Misic, On bridge residence times inmasterslave connected 802.15.4 clusters, in Proc. 20th Int. Conf. AINA,Apr. 2006, vol. 2, pp. 286290.

[30] N. Bulusu, J. Heidemann, and D. Estrin, GPS-less low-cost outdoorlocalization for very small devices, IEEE Pers. Commun., vol. 7, no. 5,pp. 2834, Oct. 2000.

[31] N. B. Priyantha, A. Chakraborty, and H. Balakrishnan, The cricketlocation-support system, in Proc. ACM Mobicom, Boston, MA, 2000,pp. 3243.

[32] A. Savvides, C.-C. Han, and M. B. Strivastava, Dynamic fine-grainedlocalizationin ad hoc networks of sensors,in Proc. ACM Mobicom, 2001,pp. 166179.

[33] J. Misic, F. Amini, and M. Khan, Performance implications of peri-odic key exchanges and packet integrity overhead in an 802.15.4-beacon-enabled cluster, Int. J. Sensor Netw., vol. 3, no. 1, pp. 3842, Dec. 2007.

[34] Y. Xiao, H.-H. Chen, B. Sun, R. Wang, and S. Sethi, MAC security

and security overhead analysis in the IEEE 802.15.4 wireless sensornetworks, EURASIP J. Wireless Commun. Netw., vol. 2006, no. 2, p. 81,Apr. 2006.

[35] Y. Xiao, S. Sethi, H.-H. Chen, and B. Sun, Security services andenhancements in the IEEE 802.15.4 wireless sensor networks, in Proc.GLOBECOM, Nov./Dec. 2, 2005, vol. 3, pp. 11761800.

[36] OPNET, 2009. [Online]. Available: www.opnet.com[37] A true system-on-chip solution for 2.4 GHz IEEE 802.15.4/Zigbee

(Rev. F), Chipcon Products From Texas Instruments, 2008. [Online].Available: http://focus.ti.com/lit/ds/symlink/cc2430.pdf

[38] LR-WPAN, Part 15.4Wireless medium access control (MAC) and physical layer (PHY) specifications for low-rate wireless personal areanetworks (WPANs) amendment 1: Add alternate PHYs, 2007.

[39] L. N. Trefethen, The Princeton Companion to Mathematics. Princeton,NJ: Princeton Univ. Press, 2008, pp. 604615.

A. Haffiz Shuaib (S08) received the B.Sc. degree incomputer science from the Ambrose Alli University,Ekpoma, Nigeria, in 2003 and the M.Sc. (top 5% ofthe class) degree in mobile and high-speed telecom-munications networks from Oxford Brookes Univer-sity, Oxford, U.K. in 2005. He is currently pursuingthe Ph.D. degree with the Centre for Telecommu-nications Research (CTR), Kings College London,

London, U.K.Prior to joining the CTR in 2006, he was a Soft-ware Developer with the Nigerian financial sector.

In 2007, he led the European Network of Excellence Creating UbiquitousIntelligent Sensing Environments Work Package (CRUISE NoE D113.3) onfuture needs, research strategy, and visionary applications for sensor networks.

A. Hamid Aghvami (M87SM91F05) receivedthe M.Sc. and Ph.D. degrees from the Univer-sity of London, London, U.K., in 1978 and 1981,respectively.

In 1984, he joined the academic staff of KingsCollege London, where he was promoted to Reader

in 1989, became a Professor of telecommunicationsengineering in 1993, and is currently the Directorof the Centre for Telecommunications Research. Hecarries out consulting work on digital radio commu-nications systems for both British and international

companies. He is the author of more than 500 technical papers and has giveninvited talks on various aspects of personal and mobile radio communicationsand courses on the subject worldwide.

Prof. Aghvami is a Fellow of the Royal Academy of Engineering and theInstitution of Electrical Engineers. From 2001 to 2003, he was a Member of

Date post:	09-Apr-2018
Category:	Documents
Upload:	mpsmoorthy
View:	214 times
Download:	0 times

A Routing Scheme for the IEEE-802.15.4-Enabled

Documents