IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO.
9, NOVEMBER 2009
A Routing Scheme for the IEEE-802.15.4-Enabled
Wireless Sensor Networks
A. Haffiz Shuaib, Student Member, IEEE, and A. Hamid Aghvami, Fellow, IEEE
Abstract—A wireless sensor network (WSN) has features that
fit into several classes of wireless networks (e.g., mesh, ad hoc,
and mobile ad hoc networks) and, at the same time, features that
are unique to it. These exceptional characteristics place many
demands on the WSN routing protocol. For instance, the routing
protocol 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 route
computation metric. All of the aforementioned conditions must
be accomplished in an energy-efficient manner. Although several
routing protocols have been proposed for WSNs, most approaches
are usually focused on energy-efficient operations. The validity of
this case is undeniable; however, one crucial element is generally
assumed or ignored i.e., how one can prevent routing loops in the
network. In addition to achieving the aforementioned routing ob-
jectives, in this paper, we go one step further by expressly defining
and thoroughly evaluating mechanisms for loop prevention and
minimization. Our proposed routing scheme leverages the services
that were offered by the IEEE 802.15.4 specification to satisfy the
requirements of a WSN routing protocol.
Index Terms—IEEE 802.15.4, routing, wireless personal area
networks (WPANs), wireless sensor networks (WSNs).
I. I NTRODUCTION
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, then
the 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 published
July 14, 2009; current version published November 11, 2009. This work was
supported in part by AMYN Investments Limited, Lagos, Nigeria. The review
of this paper was coordinated by Prof. Y. Xiao.
The authors are with the Centre for Telecommunications Research, King’s
College London, WC2R 2LS London, U.K. (e-mail: abdul.shuaib@kcl.ac.uk;
hamid.aghvami@kcl.ac.uk).
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TVT.2009.2027440
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.
5135
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 the
cluster 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 standard
for 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, we
present 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. O BJECTIVES OF A W IRELESS S ENSOR
N ETWORK R OUTING P ROTOCOL
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.
5136
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, two
paths exist from Cluster C to 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 figure
is 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 assume
that the numbers beneath the arrows in (1) and (2), shown
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
below, signify the quality of a link between any two nodes on a
path, i.e.,
P ath 1 = C −−→ −−→ −−→
14 B 14 A 0 Sink S (1)
P ath 2 = C −−7→ D −−8→ E −−→
14 Sink S. (2)
Now, if Cluster C picks the next hop based on its immediate
link quality, it would pick Cluster B as its next hop to the sink.
Notice that Cluster C cannot 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-sink
scenario 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. R ELATED W ORK
The routing protocol in this paper is a proactive vector
routing protocol that relies on a cluster network architecture
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS
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 used
for 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 to
determine 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 cost
computation. As discussed in the last section, this approach is
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.
5137
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 on
the 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 an
optimal 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. O VERVIEW OF THE 802.15.4
N ETWORK A RCHITECTURE
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 discuss
how 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, either
as the coordinator or as a member. Typically, at start up, a
5138
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 accepts
associations. 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) a
reduced 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
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
where SO, SO ≤ BO is referred to as the superframe order.
The SFD of a WPAN begins at the instant that the beacon is
transmitted 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 A–D are within the communication distance of one
another, their SFDs could be arranged as shown in Fig. 2. Note
that to maintain the integrity of the SFD boundaries, WPANs
A–D 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
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
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 industrial–scientific–medical 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 the
CAP of any SFD, WPAN members and the coordinator have
to contend for the medium using a carrier-sense multiple access
with collision avoidance (CSMA–CA) 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
(3) 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 CSMA–CA mechanism and must be ac-
knowledged upon receipt. When a coordinator receives a GTS
(4) request command, it acknowledges the frame and decapsulates
it. The information with regard to the GTS request is then sent
to the coordinator’s next higher layer. The coordinator’s 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
layer of 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-WPAN
communication is achieved, but it gives room for much
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS
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 master–slave
bridging, the coordinators act as the relay nodes or bridges on
behalf of their respective WPANs. Slave–slave 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 B’s 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 CFP
of 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 bridge’s 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 routing
mechanism.
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.
5139
V. P ROTOCOL D ESCRIPTION AND I MPLEMENTATION
In this section, we introduce and describe the operational
mechanism 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 1—Neighbor 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 cardinality
is |Nx |.
Definition 2—Out-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 Nx−s−out , and Nx−s−out ∪
Nx = Nx .
Definition 3—In-Neighbor: Correspondingly, if WPAN A
has a route to a sink through WPAN B, then WPAN A is
an In-neighbor of WPAN B for that sink. We will denote the
set of In-neighbors of WPAN X for sink S as Nx−s−in , and
Nx−s−in ∪ Nx = Nx .
Definition 4: It is possible that an In-Neighbor n ∈ Nx−s−in
for a WPAN X to sink S can also be an Out-neighbor for
WPAN X to sink T, i.e., |Nx−s−in ∩ Nx−t−out | ≥ 0.
Definition 5—Route 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 6—Route Dscrpt List: The incoming route de-
scriptor list (Route Dscrpt List) RDin−list contains all incom-
ing route descriptors, whereas the RDout−list contains all the
outgoing descriptors of a relay node.
5140
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 7—Forwarding Table: The forwarding table Tf d
contains 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 9—LQI: 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 10—Update Interval: The update interval, which
we will denote by Λ, is the length of time that must elapse
before 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., Λ = Λco−ef f ∗ BI,
where Λco−ef f is the update coefficient. Finally, we will denote
the 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 juxtaposing
each 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 distance
of 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 routing
information from the beacon for processing. The frequency of
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
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 node’s 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 A–D 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 also
sets LP L = 255. The sink then transmits this beacon during its
active 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 outgoing
descriptor 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
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS 5141

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 C will 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 route
is 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 Λ, the

forwarding 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 the
transmitted beacon of node C, because they are both
within the communication range of node C. When node
D receives node C’s route descriptor, it rejects it, because
node D can infer from the ONID of node C’s 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 C to its In-Neighbor List ND−in for Sink S.
Node B will also reject node C’s 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 descriptor’s
OID = SID. A descriptor is also rejected by a node X
if OID ∈ NX . The loop prevention process is captured
in 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 will
no 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 side
of caution just in case the validity of the information
Fig. 6. Loop-prevention algorithm. X is the ID of the node that runs the
algorithm, and YRDi is the ID of the source of RDi . HCx−s is the current
hop 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 about Sink 2, although it is no
longer 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 C has
traffic that needs to get to Sink S through node D. The process
of admission control and bandwidth reservation by node D on
behalf of node C is explained as follows. Within every update
interval Λ, along with the inclusion of route descriptors, node D

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.
5142
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 D’s routing process and its higher layer, as shown in Fig. 7.
If node C requires 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 C seeks to route through node D.
Upon receiving this GTS request, node D estimates how much
resources would be required to admit node C’s traffic. If
node D can handle node C’s 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 begins
transmission to node D at the assigned slot times. On the other
hand, if node D cannot admit traffic on behalf of node C, it sim-
ply does not grant node C the second GTS grant. This method
assures that the traffic from node C does 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 do
so. In this case, node B should be the preferred Out-Neighbor
for node C to 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 CSMA–CA/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. The
GTS transaction between a WPAN coordinator and its WPAN
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
member is done using the member’s 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 never
assign 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
(HDij )γ + (LP Lij )ρ
Cij = (5)
2
where Cij ∈ [0.0, 255.0], HDij ∈ [0, 255] is the hop degree
from Sink i to node j, and LP Lij ∈ [0, 255] is the value of the
lowest LQI along the path from Sink i to node j. The hop degree
HDij is a function of the HC HCij from a node to a sink such
that 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 hop
degree 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 how
these exponents are applied, assume that two paths (Paths 1 and
2) exist from node A to Sink S. We have
P ath 1 = A −−→ −−→ −−→ −−→
50 B 60 C 50 D 70 S
P ath 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 metric
for Paths 1 and 2 are 150.2 and 136.0, respectively. Based on
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS
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 of
the HC HCij as follows:
1
ρ= . (6)
HCij
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.4
for 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 F
cannot admit traffic from node A exists. In this case, node A
would turn to the other path for which node B is the Out-
Neighbor. If node B has the resources to admit traffic from
node 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 the
current update interval Λcurr , an Out-Neighbor to a sink grants
the 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 Λcurr
γ= (7)
0.0, otherwise.
Now, based on the assumption that node F does not grant
GTS to node A but node B does within the current interval
Λcurr , γ = 1.0 for Path 1, and γ = 0.0 for Path 2. With ρ =
1/HCij , node A’s route metric CAS for Paths1 and 2 are 126.83
and 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 from
its coordinator’s transmitted beacon and updates its forwarding
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.
5143
TABLE I
SIMULATION PARAMETER VALUES
table with the exact same values. In this paper, the WPAN
coordinator also doubles as the WPAN’s 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 their
beacons.
VI. P ERFORMANCE E VALUATION
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 model
the 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. We
do 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. The
remaining table entries are self explanatory.
5144
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 of WPANs
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, as
shown in Fig. 10(b). The reason for this case is that the two-
hop path from the sink through WPAN 1 to WPAN 2 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 frames
up 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 WPAN 3. 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, WPAN 3 was
set to transmit 300 frames of 100 B each to the sink. Three
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
scenarios were also created, and the energy consumed by the
two Out-Neighbors of WPAN 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 through
WPAN 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 (γ), as
shown 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 WPAN 2. WPAN 2 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 Dynamic
Topology (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 nonsink
nodes, whereas the white nodes are the sinks. Although the
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS 5145

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 for
Update 120.

Fig. 10. Route Dscrpt List and forwarding table for WPAN 2 (γ = 1, and ρ = 1). (a) Incoming Route Dscrpt List for Update 120. (b) Forwarding table for
Update 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. 12. Route Dscrpt List and forwarding table for WPAN 3 (γ = 1, and ρ = 1). (a) Incoming Route Dscrpt List for Update 120. (b) Forwarding table for
Update 120.

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

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 a
connection to Sinks 1 and 4, because they are clearly out of the
number of sinks known per WPAN coordinator was lower for
the OUT Perimeter scenario 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 Λco−ef f defines the duration of the update interval
(see Definition 10). For example, with Λco−ef f = 5 and with
the BO value shown in Table I, the length of the update
interval Λ is 2.5 s (i.e., the route descriptors are propagated
and received, and forwarding tables are purged and updated
every 2.5 s). Correspondingly, if Λco−ef f = 50, then Λ = 25 s.
Note that the routing protocol is disabled if Λco−ef f = 0. With
the 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 Perimeter scenario 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 its
tail pulls outward, with at least one instance where a node had a

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.
5146 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009

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 (Λco−ef f = 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 perimeter scenario 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 question
is 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 topological
changes due to sink mobility. For an unstable routing protocol,

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.
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS 5147

Fig. 17. Energy expended in the network. (a) Network energy consumption. (b) Energy consumed versus the number of sinks (Static scenario; Λco−ef =
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 expended
to 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., Λco−ef f = 0),
the network consumed the least amount of energy. With the
routing protocol enabled (i.e., Λco−ef f > 0), we see that the
higher 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 the
size 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 total
battery capacity in Table I, the nodes can last for ∼ 277 days or
∼0.76 year before running out of energy. As shown in
Fig. 18(a), when the routing protocol is disabled, the nodes
can last for about 4.3 years. We will use this result as the

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.
5148
Fig. 19. Average time to converge and energy expended per WPAN (five sinks; Λco−ef f = 5). (a) Average time to converge (in seconds). (b) Energy expended
per 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 of
one another if we need to prevent inter-WPAN interference.
Therefore, by implication, an increase in |Nx | increases the
update interval, because the BI is one of the two parameters
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
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, and
connected, 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
all Nx 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 without
adversely 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 Sink 4 for WPAN 1 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
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS 5149

the end-to-end delay for the OUT Perimeter scenario was higher It is instructive to restate here that the standard sets the
than that of the other two scenarios when Λco−ef f > 15. This nominal transmit power to 0 dBm and the receiver sensitivity
case is a direct result of the increased HC between the WPANs to −85 dBm.
and Sink 4, because Sink 4 moved out of the deployment Equation (8) meets the first condition, i.e.,
perimeter. In terms of the delivery ratio, the Static and IN
perimeter scenarios performed better than the OUT perimeter L = 255 + 3 ∗ P rxdBm (8)
scenario, as shown in Fig. 20(b). The primary reason for this
where P rxdBm is the power (in decibel–milliwatts) of a re-
result was that, for all scenarios except the OUT perimeter
ceived frame.
scenario, the mobile sink was always within the deployment
For example, if we assign P rxdBm = 0, we see that the equa-
area. For the OUT perimeter scenario, observe a gradual drop
tion gives a value of L = 255; conversely, if we set P rxdBm =
to 0 in the delivery ratio as the update interval increased. This
−85, we get L = 0. With (8), the value of L for every other
case was a direct result of GTSs not being quickly allocated to
received signal power between the receiver sensitivity and
data such that the data will reach the mobile sink before leaving
the nominal transmit power is effectively bounded within the
the deployment perimeter.
interval [0, 255].
In addition, an equation that estimates data traffic delay
To conform with the second mandate, we introduce (9), i.e.,
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
L, otherwise.
derived in Appendix B.
VII. C ONCLUSION
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 can
be 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.
A PPENDIX A
LQI C OMPUTATION
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 uniformly
distributed within this interval.
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.
L, if L − L < 0.5
LQI = (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 might
have to be truncated to meet the requirement. What we did
was to round the L value downward or upward, depending on
whether 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 <5, as shown in (9).
In addition, in the case where P rxdBm = 65.5 and L = 58.5,
the LQI becomes 59.
A PPENDIX B
O PTIMAL E NERGY C ONSUMPTION
V ERSUS A CCEPTABLE D ELAY
In this section, we derive two equations that can be used
to estimate the amount of energy that was consumed in the
network, the delay that was experienced by data traffic, and
the reaction time to topological changes subject to the network
configuration.
There are three components that contribute to the energy E
that was consumed in the network as a result of the proposed
routing mechanism. The first component is the number of route
descriptors S in a beacon. As mentioned in the main body of
this paper, the higher the number of route descriptors in the
beacon is, the larger the beacon becomes, and the more the
energy that is expended to transmit and receive these beacons
[see Fig. 17(b)]. Note that S ≤ 8, as allowed by the Route
Dscrpt Count field (see Fig. 4).
The second component is the number of known neighbor
WPANs, i.e., |Nx |. As shown in Fig. 19(b), the energy that was
consumed by a node partaking in the routing process is directly
proportional to its value of |Nx |.
The third component, which is the length of Λ, magnifies or
minimizes the impact of the other two components on E, as
discussed in Section VI-A.
If we define E as a vector E = (e) and define the vector
C = (S, |Nx |), then a change in the vector C would also cause a
change in the vector E. For instance, C  = (S + s, |Nx | + nx )
will cause the change E  = (e + ε).
5150
Given the linear relationship between E and C, (10) is
derived as follows:
 
1 s
(ε) = (a11 a12 )
Λ nx
where a11 = ∂e/∂S, and a12 = ∂e/∂|Nx |. The elements aij
depend 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 was
consumed under different deployment scenarios. An increase
in S assures that multiple sinks are known to a WPAN, which
increases connectivity, but this case also increases E. Similarly,
an increase in |Nx | increases E while also increasing the
connectivity 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 tolerance
if the coordinator of a WPAN, e.g., WPAN X, periodically
whenever any WPAN n ∈ Nx that
leaves its receiver disabled 
satisfies {n : n ∈ Nx−u−in n ∈ / Nx−t−out , u = t} transmits
its beacon (see Definitions 2–4).
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 by
three components. The first component is the HC H from a data
source 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. The
second component G is the number of GTSs granted to traffic
as 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 of D.1 The third component Λ multiplies the impact
of D on the network, as shown in Fig. 18(b). In essence, the
vector D = (d) is affected by another vector T = (H, G) such
that 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 similar
to (10) is derived as follows:
 
h lib/MultiHopLQI/
Λ (δ) = (b11 b12 )
−g
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
sink U , i.e., with a higher number of elements in Nx−u−out ⊂
Nx , then there is a higher probability of having a high G value
and, hence, a reduction in D. However, an increase in the
cardinality of Nx−u−out also increases the cardinality of Nx ,
which, in turn, increases E.
1 Note that the G component does not affect the reaction time to topological
changes, because the route-propagation mechanism does not rely on GTSs.
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.
IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 9, NOVEMBER 2009
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.
(10)
R EFERENCES
[1] K. Murray, A. Timm-Giel, M. Becker, C. Guo, R. Sokullu, and
D. Marandin, “The European Network of Excellence CRUISE application
framework and network architecture for wireless sensor networks,” in
Proc. IEEE Globecom Workshops, Nov. 2007, pp. 1–6.
[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. 166–170.
[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 a
lifetime constraint,” IEEE Trans. Mobile Comput., vol. 4, no. 1, pp. 4–15,
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. 878–890.
[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. 1735–1746.
[11] A. S. Tanenbaum, Computer Networks. Upper Saddle River, NJ: Pearson
Educ., 2003, pp. 359–360.
[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. 116–138.
[13] K. Akkaya and M. Younis, “Survey of routing protocols in wireless sensor
networks,” Ad Hoc Netw., vol. 3, no. 3, pp. 325–349, May 2005.
[14] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “An application-
specific protocol architecture for wireless microsensor networks,” IEEE
Trans. Wireless Commun., vol. 1, no. 4, pp. 660–670, Oct. 2002.
[15] A. Manjeshwar and D. Agrawal, “TEEN: A routing protocol for enhanced
efficiency in wireless sensor networks,” in Proc. 15th Int. Parallel Distrib.
Process. Symp., Apr. 2001, pp. 2009–2015.
[16] Q. Li, J. Aslam, and D. Rus, “Hierarchical power-aware routing
in sensor networks,” in Proc. DIMACS Pervasive Netw. Workshop,
May 2001.
[17] A. Woo, T. Tong, and D. Culler, “Taming the underlying challenges of
reliable multihop routing in sensor networks,” in Proc. 1st ACM SenSys,
2003, pp. 14–27.
[18] MultiHopLQI. [Online]. Available: http://www.tinyos.net/tinyos-1.x/tos/
(11) [19] R. Fonseca, O. Gnawali, K. Jamieson, S. Kim, P. Levis, and A. Woo, The
collection 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. 2063–2068.
[21] J. Luo, J. Panchard, M. Piorkowski, M. Grossglauser, and J.-P. Hubaux,
“Mobiroute: Routing towards a mobile sink for improving lifetime
in sensor networks,” in Proc. 2nd IEEE/ACM DCOSS, Jun. 2006,
pp. 480–497.
[22] C. Gomez, P. Salvatella, O. Alonso, and J. Paradells, “Adapting AODV for
IEEE 802.15.4 mesh sensor networks: Theoretical discussion and perfor-
mance evaluation in a real environment,” in Proc. Int. Symp. WoWMoM,
2006, pp. 159–170.
[23] H. Cheng and J. Cao, “A design framework and taxonomy for hybrid
routing protocols in mobile ad hoc networks,” Commun. Surveys Tuts.,
vol. 10, no. 3, pp. 62–73, 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. 595–608, Aug. 2004.
[25] Zigbee-Alliance, Zigbee Specifications, 2007. [Online]. Available: www.
zigbee.org
SHUAIB AND AGHVAMI: ROUTING SCHEME FOR IEEE-802.15.4-ENABLED WIRELESS SENSOR NETWORKS
[26] A. Koubaa, A. Cunha, and M. Alves, “A time-division beacon schedul-
ing mechanism for IEEE 802.15.4/Zigbee cluster-tree wireless sensor
networks,” in Proc. 19th ECRTS, Jul. 2007, pp. 125–135.
[27] R. Musaloiu-E and A. Terzis, “Minimizing the effect of Wi-Fi interference
in 802.15.4 wireless sensor networks,” Int. J. Sensor Netw., vol. 3, no. 1,
pp. 43–54, Dec. 2007.
[28] J. Misic, “Analysis of slave–slave bridging in IEEE 802.15.4
beacon-enabled networks,” IEEE Trans. Veh. Technol., vol. 57, no. 3,
pp. 1846–1863, May 2008.
[29] J. Misic, C. Fung, and V. Misic, “On bridge residence times in
master–slave connected 802.15.4 clusters,” in Proc. 20th Int. Conf. AINA,
Apr. 2006, vol. 2, pp. 286–290.
[30] N. Bulusu, J. Heidemann, and D. Estrin, “GPS-less low-cost outdoor
localization for very small devices,” IEEE Pers. Commun., vol. 7, no. 5,
pp. 28–34, Oct. 2000.
[31] N. B. Priyantha, A. Chakraborty, and H. Balakrishnan, “The cricket
location-support system,” in Proc. ACM Mobicom, Boston, MA, 2000,
pp. 32–43.
[32] A. Savvides, C.-C. Han, and M. B. Strivastava, “Dynamic fine-grained
localization in ad hoc networks of sensors,” in Proc. ACM Mobicom, 2001,
pp. 166–179.
[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. 38–42, 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 sensor
networks,” 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 and
enhancements in the IEEE 802.15.4 wireless sensor networks,” in Proc.
GLOBECOM, Nov./Dec. 2, 2005, vol. 3, pp. 1176–1800.
[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.4—Wireless medium access control (MAC) and
physical layer (PHY) specifications for low-rate wireless personal area
networks (WPANs) amendment 1: Add alternate PHYs, 2007.
[39] L. N. Trefethen, The Princeton Companion to Mathematics. Princeton,
NJ: Princeton Univ. Press, 2008, pp. 604–615.
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.
5151
A. Haffiz Shuaib (S’08) received the B.Sc. degree in
computer science from the Ambrose Alli University,
Ekpoma, Nigeria, in 2003 and the M.Sc. (top 5% of
the class) degree in mobile and high-speed telecom-
munications networks from Oxford Brookes Univer-
sity, Oxford, U.K. in 2005. He is currently pursuing
the Ph.D. degree with the Centre for Telecommu-
nications Research (CTR), King’s 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 Ubiquitous
Intelligent Sensing Environments Work Package (CRUISE NoE D113.3) on
future needs, research strategy, and visionary applications for sensor networks.
A. Hamid Aghvami (M’87–SM’91–F’05) received
the 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 King’s
College London, where he was promoted to Reader
in 1989, became a Professor of telecommunications
engineering in 1993, and is currently the Director
of the Centre for Telecommunications Research. He
carries 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 given
invited talks on various aspects of personal and mobile radio communications
and courses on the subject worldwide.
Prof. Aghvami is a Fellow of the Royal Academy of Engineering and the
Institution of Electrical Engineers. From 2001 to 2003, he was a Member of the
Board of Governors of the IEEE Communications Society. He is a distinguished
Lecturer of the IEEE Communications Society and has been a Member, Chair-
man, and Vice Chairman of the technical program and organizing committees
of several international conferences. He is also the Founder of the International
Conference on Personal, Indoor, and Mobile Radio Communications.