23

J. Parallel Distrib. Comput. 67 (2007) 922 – 934
www.elsevier.com/locate/jpdc

Reliable and efficient communications in sensor networks
Peter Kok Keong Loh a,∗ , Wen Jing Hsu a , Yi Pan b
a School of Computer Engineering, Nanyang Technological University, Singapore
b Department of Computer Science, Georgia State University, USA

Received 17 April 2006; received in revised form 27 March 2007; accepted 5 April 2007
Available online 25 April 2007

Abstract
Wireless sensor networks are inherently plagued by problems of node failure, interference to communications from environmental noise
and energy-limited sensor motes. These problems pose conflicting issues in the design of suitable routing protocols. Several existing reliable
routing protocols exploit message broadcast redundancy and hop count as routing metrics and their performance trade-offs are revealed during
simulation. In this paper, we study and analyse related design issues in proposed efficient and reliable routing protocols that attempt to achieve
reliable and efficient communication performance in both single- and multi-hub sensor networks. Simulation results of four such routing
protocols show that routing performance depends more on optimal (near-optimal) routing in single hub than in multi-hub networks. Our work
also shows that optimal (near-optimal) routing is better achieved when historical metrics like packet distance traversed and transmission success
are also considered in the routing protocol design.
© 2007 Elsevier Inc. All rights reserved.
Keywords: Routing protocol design; Reliable and efficient routing; Deadlock-freedom; Livelock-freedom; Wireless sensor network; Single hub network; Multihub network

1. Introduction
Small size of sensor motes wireless sensor networks (WSNs)
facilitates easy deployment and allows unobtrusive and inconspicuous detection and monitoring. Applications such as
tactical sentinels, smart buildings and intelligent monitoring
systems are made possible by deploying large number of nodes
that are small in size and cost-effective. Low cost allows more
nodes to be deployed and also to be deployed in a use-anddiscard fashion. With more nodes being deployed, the area of
coverage can be increased or, keeping the area unchanged, the
increase in node density gives a more accurate and precise result and also provides a degree of inherent fault tolerance in
the network via mote redundancy.
In a WSN setup, the nodes may be deployed in an ad hoc
manner with no pre-defined topology. The nodes automatically
set up a network by communicating with one another in a multihop fashion. New nodes can malfunction, be added or removed
∗ Corresponding author. Fax: +65 67926559.

E-mail addresses: askkloh@ntu.edu.sg, pmbdf27@hotmail.com (P.K.K.
Loh), hsu@ntu.edu.sg (W.J. Hsu), pan@cs.gsu.edu (Y. Pan).
0743-7315/$ - see front matter © 2007 Elsevier Inc. All rights reserved.
doi:10.1016/j.jpdc.2007.04.008

from the network at any time. Newly added nodes must integrate into the network seamlessly and the network must detect
and react quickly when nodes are removed to avoid affecting
the reliability of message delivery services. The RF links between any two nodes are also subjected to noise interference
and other environmental factors. The links may be unavailable
periodically and this implies that the network has a dynamic
topology changing with time. A routing protocol design must
therefore ensure that a network can achieve self-configurability,
adaptivity and resilient to failure with low energy consumption
[2,6,12,13,15,17].
A WSN can have one or more hubs as shown in Fig. 1. A
hub is a special mote equipped with additional longer-range
radio or satellite transceiver for communication with the base
station. The hub receives messages from nodes for processing
before further disseminating them to users located at the base
station. There can be multiple hubs to provide for redundancy
in case of hub failure and also to achieve higher efficiency as
messages can be routed to any one of the hubs depending on
connectivity, which reduces latency and energy consumption.
Typically, a node will forward messages to the nearest hub,
requiring least number of hops.

P.K.K. Loh et al. / J. Parallel Distrib. Comput. 67 (2007) 922 – 934

Sensor Mesh

Legend
Node
Hub

Base Station
Fig. 1. Diagram of a WSN setup.

Wireless networks include several other families such as Cellular networks, Bluetooth, IEEE 802.11 and Mobile Adhoc Network (MANET). WSN is the latest family of wireless network
that has some distinct characteristics. These distinct characteristics introduce additional requirements on its routing protocols.
While conventional routing protocols for wireless networks are
typically only concerned with data throughput and network
latency [4,5,10,11], efficient and reliable routing protocols in
WSNs have to satisfy the following performance criteria:
Minimise energy consumption: Nodes are battery-operated
and network lifetime depends on battery lifetime. Batteries contain a limited amount of energy that is not automatically replenished. In many situations, after nodes are deployed, they
are expected to operate independently without human intervention. Therefore, the routing protocol must be energy-efficient
by minimising energy consumption to maximise network lifetime [7].
Tolerate node failures: Nodes deployed in harsh or inhospitable environments may be prone to hardware failure that
could render them useless in some situations. The routing protocol must react to the change in topology quickly when nodes
fail and reduce the impact on network performance to a minimum by discarding the invalid route and obtaining a new route
quickly [21].
Tolerate unreliable RF links: Cheap and low-powered
transceivers used by WSN nodes exacerbate the inherently
unreliable RF medium. Consequences are high packet loss
and error rates and intermittent disruptions to communications
when RF links become non-existent. The routing protocol must
operate under such conditions to achieve efficient and reliable
message delivery.
Exhibit scalability: One prominent feature of WSNs is the
deployment of large number of nodes, in the order of tens to
hundreds. Routing protocols must therefore be scalable by having low routing overheads and maintaining consistent performance when the network size increases [14].
With these objectives in mind, we propose and analyse an
efficient and reliable routing protocol design that seeks to
route messages to hubs reliably. The design approach of this

923

light-weight protocol requires low-control message overheads
to handle a changing topology caused by unreliable RF links
and node failures.
The remainder of this paper is organised as follows. Section 2
surveys the designs of some existing efficient and reliable routing protocols proposed for WSNs. Section 3 lists the contributions of our work. Section 4 describes and analyses the detailed
design of the proposed light-weight routing protocol. Simulation results for single- and multi-hub sensor networks are presented and discussed in Section 5. Finally, Section 6 concludes
this paper followed by the references and acknowledgments.
2. Related work
In this section, we present and evaluate the designs of four
efficient and reliable routing protocols designed for many-toone routing in WSNs. They are Gradient-Based Routing (GBR)
[20], Gradient Broadcast (GRAB) [21], Dynamic Source Routing (DSR) [16] and Adhoc On-demand Distance Vector Routing (AODV) [9,19]. The designs of these protocols are similar
in that they either use some energy metric such as a neighbouring mote’s remaining power and/or path length metric, e.g. hop
count or distance costs for routing decisions.
The GBR protocol distributes traffic load evenly among all
nodes to prevent overloading a portion of the nodes by using
stochastic measure. A gradient is set up from the nodes to the
hub and all messages will flow in that direction towards the
hub. The hub will broadcast an interest message that is flooded
throughout the network. Each node upon receiving the interest
message will record the number of hops taken by the interest
message. Each node then knows the number of hops it needs to
reach the hub. A node will forward a message to a neighbour
nearer to the hub than itself. When there are multiple neighbours
with the same hop count to the hub, one is randomly chosen.
Random choice of the next hop has a good effect of spreading
traffic over time but in WSNs where RF transmission varies
from one pair of nodes to the next even on an optimal route,
the routing protocol design may require the incorporation of a
means to measure link quality.
GRAB is designed for reliability by routing duplicate messages in a mesh from a source node to a hub in the sensor
network. A cost field is set up in the network and the value of
a node in the field is the minimum cost to reach the hub from
that node. The cost field has a value of 0 starting from the hub
and the value at each node increases with the distance from
the hub. Messages will flow through the cost field in the direction of decreasing cost, that is, towards the hub. Messages
travel from the originating nodes to the hub using the minimum cost path. When a node generates a message, it initialises
a message header field with its cost to the hub and assigns
a credit value to that message before broadcasting it. When
neighbouring nodes receive the message, only those nodes that
have a lower cost (nearer to the hub) enter a decision process
to route or drop that message. Routing design involves the concept of credit consumption by nodes during routing. When a
message has enough credit, the node will route the message else
the message will be discarded. A message’s credit is therefore

924


consumed at each intermediate node on the path to the hub.
When a message has insufficient credit, it can only be forwarded
on a single path—the minimum cost path. By assigning an
appropriate amount of credit to each message, duplicate copies
of that message can travel in multiple paths from the source
node to the hub in a mesh. This mechanism provides good
reliability at the expense of higher energy consumption and
message latency.
The DSR protocol is a reliable and fairly efficient routing
protocol designed to enable the sensor network to be completely
self-organising and self-configuring. No existing network infrastructure or administration is required. Network nodes collaborate to forward packets for each other to allow communication over multiple “hops” between nodes not directly within
wireless transmission range of one another. As nodes in the network fail, or wireless transmission conditions change, all routing is automatically determined and maintained by the DSR
routing protocol. Since the number or sequence of intermediate
hops needed to reach any destination may change at any time,
the resulting network topology may be quite dynamic. The DSR
protocol allows nodes to dynamically discover a source route
across multiple hops to any destination in the network. The
header format in a data packet comprises the complete, ordered
list of nodes through which the packet must pass, avoiding the
need for periodic maintenance of routing information in the intermediate nodes through which the packet is forwarded. By including this source route in the header of each data packet, other
nodes forwarding or overhearing any of these packets may also
easily cache this routing information for future use. DSR makes
use of promiscuous mode to constantly obtain the most current
routing information. Although operating in promiscuous mode
costs additional energy, nodes are able to obtain the latest routing information quickly and therefore packets are routed on
valid paths. This reduces energy consumption during routing
because less re-transmissions and control packets are needed.
DSR also keeps multiple paths in the routing table for increased
reliability. This gives DSR good fault- and noise-tolerance.
The AODV routing protocol is designed to be a reactive one
that can scale to larger networks. AODV builds routes between
nodes and establishes a path to the hub by exchanging distancevector information. A node will, however, only maintain a single path in its routing table to the hub. When the single path
fails, a route discovery mechanism has to be invoked. Route
re-establishment relies on flooding the whole network with requests to recover the lost path. A simple flooding scheme is
employed in AODV, where every node rebroadcasts these route
request (RREQ) packets even if some of its neighbours have
already received the requests, and thus the rebroadcasts may
reach no additional nodes. The efficiency of the local repair
algorithm depends on how fast a node can find an up-to-date
route in its neighbourhood. AODV uses multi-round discovery,
exploring alterative paths to establish a route.
3. Contributions
WSNs have practical benefits that will improve the quality of life and also productivity and efficiency in a specified

environment. To realise this, the nodes in the network must
have an efficient and reliable communication system for them
to interact and achieve their objectives. In the heart of this
communication system is the routing protocol responsible for
the dissemination of messages in the network. The challenge
is then to have a routing protocol that can achieve conflicting
requirements of reliable routing while minimising communications and energy overheads. Our paper has four contributions
to the field of WSNs:
(1) We identified the key performance measures of a WSN
that reflects operational requirements. This allows a routing protocol designer to come up with solutions that have
practical benefits.
(2) We proposed a light-weight routing protocol design for a
multi-hop WSN, which meets the above conflicting operational requirements. Our routing protocol is named EAR.
(3) We analysed and evaluated the performance of our protocol
design against four other existing approaches using simulation. The results reveal useful, design-related behavioural
characteristics and anomalies of existing protocols under
adverse operating scenarios.
(4) Our work could serve as a framework for further research
and study into the design of high performance, reliable
routing protocols.
4. Protocol design details
4.1. MAC protocol
EAR requires a Medium Access Control (MAC) protocol
that provides reliable link-to-link transmission. One example
is IEEE 802.11 [10] MAC protocol that provides reliable linkto-link transmission by using Request-To-Send (RTS), ClearTo-Send (CTS) and Acknowledgement (ACK) handshaking
mechanism. Using such MAC protocol is necessary in a wireless environment because RF links are unreliable and message
collisions occur frequently which results in messages being
lost. Explicit control messages are therefore needed to detect
lost messages.
4.2. Algorithm
EAR supports single or multiple hubs in the network. Nodes
generate Report (RPT) packets that contain information of interest to the network users. The RPT packet can be routed to
any hub in the network. At each intermediate node, routing ensures that the packet will be forwarded on a path to a hub that
offers the best connectivity at the point of time. This effectively
reduces energy consumption and packet latency as packets are
always routed to a hub using the best path available.
4.2.1. Setup phase
Fig. 2 illustrates the setup phase. Each hub on powering up,
broadcasts an Advertisement (ADV) packet to request for RPT
packets generated by other nodes. When neighbouring nodes
around the hub receive this ADV packet, it will store this route


Hub broadcasts ADV

925

Node broadcasts RREQ

Nodes receives ADV

Legend
Hub
Nodes with no route

Node broadcasts RREP

Nodes with at least one
route to hub

Nodes receives RREP
Fig. 2. Illustration of setup phase.

to the hub in their respective routing tables. This is shown in
steps (a) and (b) in Fig. 2, where the three coloured nodes
nearest to the hub have received the ADV packets and stored
the routes. These nodes will not propagate the ADV packet
received.
When a node is powered on, it will back off for a random
interval of time before beginning an initialisation process. A
node begins the initialisation process by broadcasting an RREQ
packet asking for a route to any hub. When a hub receives an
RREQ packet, it will broadcast a Route Reply (RREP) packet.
Similarly, when a node receives an RREQ packet, it will broadcast an RREP packet if it has a route to a hub. This is illustrated by steps (c) and (d) in Fig. 2. Otherwise, it will ignore
the RREQ packet. Nodes do not propagate RREQ packets.
When a node receives an RREP packet, it will store the
route in its routing table. When it has at least a route to the
hub it skips the initialisation process. Therefore, by introducing
random delay for each node to begin initialisation process, a
portion of nodes will receive RREP packets before they have
begun their initialisation process. This is shown in step (e) of
Fig. 2. This enables fast propagation of routes and also saves
on the amount of control packets generated in the setup phase.
A node can store one or more routes to the hub for enhanced
reliability. A route in the routing table is indexed using the next
hop node’s ID—that is the ID of the neighbour to this node. A
node n will only keep one route entry for a neighbour that has
a route to the hub. That neighbour could have multiple routes
to the hub but it is of no concern to node n because all it needs
to know is that this neighbour has a route to the hub so it
can forward RPT packets to this neighbour. In the route table,
every entry is uniquely identiﬁed by the neighbour’s ID and for
each entry, only the best route of that neighbour is stored. The
selection of best routes is described next.
4.2.2. Route management
As nodes have very limited memory, the size of the routing
table has to be restricted. This leads to the question of how
to select the best routes and only keep the best routes in the

Tree affects the link quality
between node 1 and hub
1
Hub
2
Fig. 3. Illustration of RF link quality.

routing table at all times. In EAR, two metrics are used to admit
a route into the routing table. The primary metric is the number
of hops a route needs to reach the hub, which we call the length
of a route. The reason for using this metric is that the best route
is always the shortest and incurs the lowest packet latency and
least energy to transmit the packet from source to destination.
But the RF link between a node and each of its neighbours will
not be the same because of the difference in physical distance
and the type of terrain between them (e.g. two nodes might be
obstructed by a tree that attenuates RF signals). In this situation,
the best route is not the shortest as trying to forward a packet
to a neighbour with a shorter path but bad RF link quality
may expend more energy in re-transmissions and also increases
packet latency than forwarding to a neighbour with a longer
path but with good RF link. In Fig. 3, path 1 → 2 → Hub is
better than 1 → Hub although it takes an additional hop.
In our design, we use a concept known as route blacklisting to manage this. Initial routes are admitted to the routing
table based on length as admission criteria to ensure that only
shortest routes are chosen. During operation, RPT packets are
relayed through these routes. To reduce route management overhead, routing table updates are piggy-backed on corresponding
control packets in the MAC layer and occur with the same frequency as MAC layer handshakes. Eventually, less desirable
routes start to exhibit high packet loss rates, are blacklisted and
omitted from the routing table. Routes that are omitted from
the routing table will not be admitted again until after a period of time. This design approach limits routing table storage
requirements and accounts for temporary disruptions as well.
The mechanism uses a sliding window that keeps track of the

926


outcome of the last N attempts to forward packets on a route.
If a route fails to forward all packets in the last N consecutive
attempts, then it will be blacklisted and omitted from the routing table. Route blacklisting is used to determine transmission
success rate in EAR’s second route selection metric known as
RouteScore defined as follows:
RouteScore = (PE ×WE +PT ×WT ), where PE is the energy
level of the next hop node (0.0–100.0), WE the assigned weight
for PE (0.0–1.0), PT the transmission success rate (0.0–100.0),
WT the assigned weight for PT (0.0–1.0).
The sum of the weights, WE and WT , is set to 1. RouteScore
then takes on a value from 0 to 100 and a higher value indicates
a better route. RouteScore is used only when there are two
routes with the same length competing to be admitted to the
routing table. When a new route is received and the routing
table is full, route replacement is carried out. Routes that are
blacklisted are ignored. In the replacement algorithm, the first
step is to search for the route with the lowest RouteScore in
the routing table. In the event of a tie in score, the route with
a longer length is chosen. In the second step, the worst route
is compared against the incoming route and the shorter path is
admitted into the routing table. If there is a tie in length, the
route with the higher RouteScore is admitted. To calculate the
RouteScore for the incoming route, an arbitrary value is initially
assigned to PT as the link quality is unknown. PT will rise (or
drop) when subsequent packet transmissions succeed (or fail)
via the associated path. Assume that PE of the worst route and
the incoming route is the same. The factor that decides if the
incoming route is to be admitted will then depend on PT for
that route.
This route management scheme stores the best routes in the
routing table. Packets are guaranteed to travel on the best route
from a node to the hub. This provides reliable packet delivery
because the RF links are of better quality resulting in less packet
loss. This in turn reduces the number of retransmissions needed,
thus reducing packet latency and energy consumption.
4.2.3. Data dissemination
After the setup phase, every node in the network will have
at least one route to the hub. Nodes will then start generating
RPT packets at periodic intervals or go into idle mode waiting
for some event to happen before generating RPT packets. This
depends on the application of the network. When an RPT packet
is generated at a source node, it carries two fields in its header;
ExpPathLen and NumHopTraversed. The first field defines the
expected number of hops this packet will have to traverse before
it reaches the hub. It is defined as
ExpPathLen = NH × .
NH is the number of hops from this node to the hub for the
route selected to forward this packet. is some assigned weight
from 0.0 to 1.0. is always greater than 0 because the minimum
number of hops to reach the hub is at least 1. NumHopTraversed
records the number of hops a packet has traversed so far and is
initialised as 0. The packet is then forwarded to the next node
in the route. When the next node receives the packet, it will

F

D
A

B

E

G
Hub

C
Fig. 4. Illustration of forwarding based on RouteScore metric.

increment NumHopTraversed by one and then compare it with
ExpPathLen that is never altered after initialisation. If ExpPathLen is larger than NumHopTraversed, the routing mechanism will choose a route with a higher RouteScore. Should there
be a tie in the RouteScore, the route with the shorter length is
chosen. By assigning > 0, a packet can take a longer route
with better link quality, assuming RouteScore is determined by
link quality alone. The value of ExpPathLen will determine the
number of times a packet can take a longer route when making
a routing decision at an intermediate node.
Fig. 4 shows that at node B, the packet goes to node C and
then to node D instead of going directly to node D because
the link quality between node B and D is lower than the link
quality between node B and C and node C and D. Similarly,
the packet makes the same decision at node E.
If ExpPathLen is smaller than or equal to NumHopTraversed,
a simple route selection mechanism requiring only two comparisons is used. Firstly, select route with the shortest length. If
there is a tie, select the route with the highest RouteScore. The
logic is that if the number of hops a packet has traversed exceeds the expected number of hops, there must be some changes
in the network topology due to node failure or environmental
noise affecting the RF communication. During this period of
instability, the packet will take the shortest route to the hub.
The same routing mechanism is used at each intermediate node
until the packet reaches a hub.
To prevent potential deadlocks from occurring, we define at
each node a variable BufUtilLvl that stores the current utilisation
level of the packet output buffer. We then define a threshold
value BLThreshold , where BLThreshold < Bmax (max size of
buffer). If BufUtilLvl is greater than BLThreshold , the packet will
be forwarded on the shortest route to the hub. Fig. 5 shows
the buffering algorithm and an illustration of how a temporary
deadlock involving nodes A and B is freed.
A node will not forward a packet to a neighbour that has
a higher hop count to the hub than itself. This is to ensure
no livelock occurs in the routing process. Referring to Fig. 6,
node A can forward packet to node B which then forwards it
to the hub if the direct link between node A and the hub is
disrupted. Similarly, node B can also forward to node A instead
of forwarding directly to the hub. Both node A and node B have
a minimum hop count of 1 to the hub. When node B receives
the packet from node A, it can forward the packet to node C for


If (Num Hop Traversed Exp Path Len AND Buf Util Lvl BL Threshold)
{
Forward packet on a route with the highest Route Score;
If ( a tie occurs )
Forward packet on the shortest route;
}
Else
{
Forward packet on the shortest route;
If (a tie occurs)
Forward packet on the route with highest Route Score;
}

C

927

A

Hub
B

Fig. 5. Pseudo code of buffering algorithm.

Proof. We prove by induction. Consider the sequence of nodes,
Ak → · · · → Ai → · · · → A1 → H , where Ai (1 i k)
denotes an arbitrary node and H denotes the hub. The subscript
k denotes the number of hops needed to reach the hub from
node Ak . Basic step, when the neighbouring nodes of the hub
receive the ADV packet, they have a hop count value of 1.
Inductive step, when nodes with hop count of 1 propagate the
route information, their neighbour nodes that are not within
communication range of the hub will take on a hop count with
value of 2, which is the least possible number of hops to the
hub. This carries on until the farthest node from the hub in the
network.

because the minimum number of hops to reach the hub is at
least 1.
Case 1: ExpPathLen h: In this case, the routing mechanism
will always select the shortest route in the routing table for
forwarding. In the case of a tie, the route with the highest
RouteScore is selected. Thus, according to Lemma 1, selecting
the shortest route at every intermediate node will lead the packet
to a hub and no node is revisited.
Case 2: ExpPathLen > h: In this case, the routing mechanism will select the route with the highest RouteScore in
the routing table for forwarding. Should there be a tie in the
RouteScore, the route with the shorter length is chosen. In this
case, the neighbouring node with the highest RouteScore may
have the same hop count to the hub as the sender node and this
can possibly result in the packet being re-transmitted back to
the sender. Although a temporary loop is formed, a deadlock
can never occur since BLThreshold < Bmax and buffers will
never be full. According to the buffering algorithm in Fig. 5,
a packet will be forwarded on the shortest route if the packet
output buffer exceeds the predefined threshold, thus breaking
the loop. Since ExpPathLen is bounded by the diameter of the
network, it is a finite value. If h becomes equal or greater than
ExpPathLen, the packet will travel on the shortest route to hub,
as in case 1. For example, buffers at nodes A and B in Fig. 5
show a temporary cycle (potential deadlock) due to their similar
route scores computed from each node to the hub. Eventually,
when the node buffer at B exceeds the specified threshold, the
packet is forwarded on the shortest route to the hub, effectively
breaking the cycle.
Since case 1 shows that no loop will ever occur and case 2
shows that any loop formed will be broken up in finite time,
EAR is deadlock-free.

For example, Fig. 6 shows that nodes D, E and F are, respectively, 2, 3 and 4 hops away from the hub while nodes A
and B are only 1 hop away.

Corollary 1. In a connected network, EAR will deliver all
packets generated by the nodes to the hubs successfully in a
noiseless and fault-free environment.

Theorem 1. The routing algorithm of EAR is deadlock-free as
long as the hub is not disconnected.

Proof. The proof can be inferred from Lemma 1. Since every
node will have a route with the minimum hop count from that
node to the hub, the packet is simply forwarded on that route
and it will reach the hub eventually.

A
E

Hub
D
B

F

C
Fig. 6. Illustration of route topology.

similar reasons. Node A and Node B will never forward packet
to node D because the minimum hop count to the hub from
node D is 2. The proof of livelock-freedom may be found in
Corollary 2.
Lemma 1. In a connected network with at least one hub, every
node in the network will have at least one route that leads to
the hub. The sequence of such a route is in decreasing order of
the number of hops to hub.

Proof. We recall that ExpPathLen = NH × (NH is the actual
route length in hops and 0 <
1). Let h be the number of hops
traversed by a packet. Then, there are two cases to consider.
The first case is when ExpPathLen h. The second case is when
ExpPathLen > h, where > 0. NH is always greater than 0

Theorem 2. The number of hops a packet will traverse before
reaching a hub is bounded by H C +R, where HC is the number
of hops the packet generating node needs to reach the hub and

928


R is the diameter of the network in terms of hop count. We
assume, without loss of generality, that a hub is in the centre
of the network. Hence, the farthest node in the network from
the hub has a hop count of R.
Proof. Consider a packet generated at node A. When is set
to 1, which is the maximum value, ExpPathLen = H C. From
Fig. 5, when ExpPathLen > NumHopTraversed, the packet
is forwarded to neighbour node B which has the highest
RouteScore. Node B may not be the shortest route in the
routing table and in the worst case, the packet will be forwarded on the longest route at every intermediate node and the
packet will traverse HC number of hops until ExpPathLen =
NumHopTraversed. Now, the packet will be forwarded on the
shortest route according to the routing algorithm and the packet
will need only a maximum of R number of hops to reach the
hub. Therefore, the maximum number of hops a packet may
traverse before reaching the hub is bounded by H C + R.
Corollary 2. The routing algorithm of EAR is livelock-free.
Proof. In an ideal (noise- and fault-free) environment, EAR
is guaranteed to deliver all packets successfully by Corollary
1. For non-ideal environment, a packet will eventually arrive
at a destination, i.e. a hub after travelling for a maximum of
H C + R hops by Theorem 2. This implies routing by EAR
does not result in a livelock.
4.2.4. Route update
Nodes in WSN are prone to failure and the unpredictable RF
link quality between neighbouring nodes changes frequently
causing the network topology to change with time. Also, node
energy levels may decrease according to the amount of data
packets they transmit and receive during routing. Nodes need
to maintain updated and fresh routes in the routing table at
all times. EAR uses a novel solution that is based on the
handshaking messages used by IEEE 802.11 MAC protocol.
Fig. 7 illustrates this. When node 1 wants to send a data packet
to node 2, node 1 first sends an RTS packet. When node 2
receives the RTS packet, it will send a CTS packet to node
1. Route information is piggy-backed on both RTS and CTS
packet. This enables the neighbours of both nodes 1 and 2 to
obtain the latest route information of the two nodes. Nodes in
blue have received updated route information from either node
1 or node 2 or both.
RTS and CTS packets have to be received and processed by
all nodes as part of the collision avoidance mechanism employed by the MAC protocol. On the other hand, DATA and
ACK packets need not be received by all nodes and to conserve
energy, other neighbouring nodes except for the sender and
receiver can go into sleep mode. Hence, utilising RTS–CTS
handshaking instead of DATA–ACK would result in more current route information for a node. As an example, EAR can use
S-MAC (Sensor MAC) [18,22], which is an MAC protocol designed specifically for WSNs that have various energy-saving
mechanisms. S-MAC uses the same four-way handshaking
mechanism as in IEEE 802.11 to achieve reliable link-to-link

1

2

Node 1 sends RTS

1

2

1

2

Node 2 sends CTS

Legend
Nodes without latest
route info
Nodes with latest
route info

Node 1 sends data packet
Fig. 7. Piggybacking on RTS/CTS packet.

transmission. One of the energy-saving mechanisms known as
Overhearing Avoidance specifies that nodes upon hearing an
RTS or a CTS packet that is not addressed to them will go into
sleep mode.
An alternative method of route update is to periodically exchange control messages between nodes. But such a method is
costly in terms of energy consumption and bandwidth usage. To
send a routing control packet, a node needs to contend for the
medium, which increases bandwidth usage, and energy is expended to transmit and receive the packet. Piggybacking route
information on RTS and CTS packets incurs additional energy
consumption as the packet size increases. But this cost is negligible compared to the cost incurred in sending an additional
routing control packet.
Cost analysis of route update: We compare the energy and latency costs in piggybacking route information on the RTS/CTS
packet to that of sending an explicit routing control packet.
Since the energy consumed is proportional to the packet size,
we assume the energy cost to transmit 1 bit is 1 m-J without
loss of generality. Let K be the size of the route information in
bits, W be the size of a routing control packet in bits and the
bandwidth be B bits per second. Then, we have:
Energy cost of piggybacking = K J, Latency cost of
piggybacking = K/B s, Energy cost of explicit control =
SRTS +SCTS +K +W +SACK J, Latency cost of explicit control
= (SRTS /B) + (SCTS /B) + [(K + W )/B] + (SACK /B) s, where
SRTS —size of MAC layer RTS packet in bits, SCT S —size of
MAC layer CTS packet in bits, SACK —size of MAC layer
ACK packet in bits.
5. Simulation
To evaluate the performance of the different protocol design
approaches, we made use of GloMoSim [1]. We simulated a
WSN where the nodes are modelled after the crossbow MICA2
mote [8]. The specification together with other settings for the
simulator are shown in Table 1.
In the simulation, all nodes generate data packets that are
routed to the hub in the centre of the WSN. The average number
of neighbours per node was 10. This ensures a balance so that


Table 1
Simulator settings
Frequency
Bandwidth
Radio range
Radio model
Propagation model
MAC protocol
Data packet size
Simulation duration

929

environments where the latter is compounded with noise and
node failures.
433 MHz
76 800 bps
56 m
Signal-to-noise (SNR) bounded
Ground reflection (two-ray)
IEEE 802.11 (DCF)
24 bytes
60 min

nodes would have sufficient neighbours to elect a good one to
forward packets and also prevent overcrowding of nodes, which
may lead to unusually high packet loss due to collisions.
We use the following metrics to measure the performance of
the routing protocols under test.
Packet delivery ratio (PDR): This measures the percentage
of data packets generated by the nodes that are successfully
routed to the hubs. It is expressed as
Total number of data packets successfully delivered
× 100%.
Total number of data packets sent
This is an essential parameter because a core function of any
routing protocol is to route and deliver data packets. A good
routing protocol should ideally deliver all data packets generated by the nodes to the hub.
Packet latency: This measures the average time it takes to
route a data packet from the source node to the hub. It is expressed as
Individual data packet latency
.
Total number of data packets delivered
In most applications, it is desirable for data packets to be delivered to the hub in the fastest time. Timely arrival of data
packets at the hub is critical in ensuring that the network users
are informed of any important events that have happened in the
network.
Energy consumption: This measures the energy expended per
delivered data packet. It is expressed as
Total energy expended by nodes
.
Total number of data packets delivered
We calculate energy expended in transmission and reception
by the nodes’ RF transceiver. Energy-efficient routing protocols are essential in a WSN where nodes have limited energy.
This directly affects the lifespan of a network. This metric also
indirectly measures the amount of control packet overhead of
a routing protocol. A routing protocol that generates a large
amount of control packets will consume more energy while a
routing protocol that incurs low control message overhead will
consume less energy.
5.1. Simulation results
The routing protocols are subject to a series of tests to
evaluate their performances in both ideal and realistic WSN

5.1.1. Ideal conditions
The first test deploys the routing protocols in a noise-free and
fault-free environment. The objective is to evaluate the performances of the routing protocols operating in ideal conditions
to analyse the degradation, if any, due to the incorporation of
reliability enhancement features and mechanisms in the basic
routing protocol. This will also allow a later comparison to
show that the decline in performance in non-ideal conditions is
due to the protocol’s ability or inability to cope with noise and
fault rather than other reasons like network overcrowding.
We want to study the scalability of the routing protocols in
terms of both the number of nodes in the network and also the
amount of traffic volume in the network. As such, we simulated
network sizes of 50 nodes to 400 nodes with 10% and 50%
active source nodes. A source node will generate data packets
that are to be routed to the hub. The total packet generated per
source node is 120 at a rate of 1 packet every 30 s. Each test is
run 20 times each with a different seed and the average result
is obtained.
The results are shown in Fig. 8 for 50% source nodes only
because for 10% source nodes, the performance of every routing
protocol is much better than with 50% source nodes since there
is less traffic volume. AODV, DSR and GBR have PDR of
close to 100% on average. EAR has achieved 100% PDR at
all network sizes from 50 to 400. This is expected as we have
proved earlier on in Section 4.2.3 that EAR will deliver all
packets under a noise-free and fault-free environment. This has
shown that most of the routing protocols can operate effectively
in ideal conditions with the reliability enhancement designs
contributing negligible or no overheads. We shall see later that
the performance of some of these routing protocols will drop
drastically because they are not suitably reliable in a noisy
environment coupled with node failures.
PDR for GRAB decreases exponentially because it is designed for operation in a noisy environment where packet loss
is high. In ideal conditions, however, GRAB maintains the use
of broadcasting message packets over redundant paths. As a
result, the number of packets generated is significant resulting
in over-utilisation of bandwidth. This is especially so for 50%
active source nodes in larger size sensor networks with only
a single hub each to absorb the redundant messages. Packet
losses are due to packet collisions and the large amount of packets generated causes packet latency and energy consumption
to be considerably higher than the rest and are off the graph
scales. For comparisons, the performance results for GRAB
have been included in Table 2. The average packet latency is
1061 s and the average energy consumption is 2135 mJ. Similar observations concerning the behavioural characteristics and
performance anomalies of GRAB may be found in an independent research work [3].
EAR has the best performance in PDR, packet latency and
consumes the least amount of energy. GBR comes close taking the second position. AODV and DSR have similar packet

930


Packet Delivery Ratio (PDR)
with50% Source Nodes
% of packets delivered
successfully

100
90
80
70

AODV
DSR
EAR
GBR
GRAB

60
50
40
30
0

50

100 150 200 250 300 350 400
Number of nodes
Packet Latency with
50% Source Nodes

Energy Consumption with
50% Source Nodes
0.25
Latency per packet (s)

Energy expended
per packet (mJ)

30
AODV
DSR
EAR
GBR
GRAB

25
20
15
10
5
0

AODV
DSR
EAR
GBR
GRAB

0.2
0.15
0.1
0.05
0

0

50

100 150 200 250 300 350 400

0

50

Number of nodes

100 150 200 250 300 350 400
Number of nodes

Fig. 8. Results in ideal conditions.

Table 2
Performance results for GRAB under ideal conditions
50

100

150

200

250

300

350

400

Packet delivery ratio (%)
GRAB
87.6

60.8

37.7

26.7

24.2

21.9

18.6

14.9

Packet latency (s)
GRAB
109.8

470.2

937.0

1042.5

1159.3

1302.2

1571.4

1895.7

Energy expended per packet (mJ)
GRAB
625.1

881.1

1443.8

1966.5

2509.3

2877.4

3199.2

3576.3

latencies and are higher than EAR because of the slower route
setup mechanism employed. DSR has higher energy consumption than AODV because it operates in promiscuous mode.

5.1.2. Fault and noise tolerance
In this test, we subject the routing protocols to a realistic operating environment where the wireless medium is affected by
noise interference compounded with node failures. The routing
protocols must be able to select a suitable neighbour for routing
and avoid neighbours with bad RF link quality. Also, network
“holes” may be created due to node failure and routing protocols must route packets around these “holes” and adapt quickly
to a change in network topology.

We use the ideal condition test setup described in Section
5.1.1 with an injected noise and fault models. In the noise
model, every node in the network except a hub takes on a
random noise factor between 10% and 50%. The noise factor
of a node indicates the probability that packets to be received
by that node are corrupted or lost in transmission. In the fault
model, 50% of randomly selected network nodes fail at random
times within the simulation duration. The results are averaged
over 20 runs each with a different seed and shown in Fig. 9.
DSR makes use of promiscuous mode to constantly obtain
the most up-to-date route information. Although operating in
promiscuous mode costs additional energy, nodes are able to
obtain the latest routing information quickly and therefore packets are routed on valid paths, which increases PDR and reduces


100
90
80
70
60
50
40
30
20
10
0

AODV
DSR
EAR
GBR
GRAB

0

50

Packet Delivery Ratio (PDR) with
50% Source Nodes
successfully

successfully

Packet Delivery Ratio (PDR) with
10% Source Nodes

100 150 200 250 300 350 400
Number of nodes

100
90
80
70
60
50
40
30
20
10
0

AODV
DSR
EAR
GBR
GRAB

0

AODV
DSR
EAR
GBR
GRAB

2
1.5
1
0.5

6
5
4
3
2
1
0

0

50

100 150 200 250 300 350 400
Number of nodes

AODV
DSR
EAR
GBR
GRAB

7

0

50

10% Source Nodes
250

100
90
80
70
60
50
40
30
20
10
0

AODV
DSR
EAR
GBR
GRAB

50

100 150 200 250 300 350 400

150 200 250 300
Number of nodes

350

400

AODV
DSR
EAR
GBR
GRAB

200
150
100
50
0

0

100

50% Source Nodes
Energy expendedper
packet (mJ)

Energy expended per
packet (mJ)

100 150 200 250 300 350 400
Number of nodes

8


50

Packet Latency with 50% Source Nodes

Packet Latency with 10% Source Nodes
2.5

0

931

0

50

Number of nodes

100 150 200 250 300 350 400
Number of nodes

Fig. 9. Fault and noise tolerance results.

packet latency. This also reduces total energy consumption because less re-transmissions and control packets are needed.
DSR also keeps multiple paths in the routing table for increased
reliability. This gives DSR better fault and noise tolerance than
AODV although both have similar performances in ideal conditions.
GBR uses stochastic measure to distribute the traffic load
evenly among all nodes to prevent overloading. This approach
is fast and simple thus allowing GBR to achieve low packet
latency and energy consumption. But random selection of next
hop node does not account for the quality of RF links that may
differ from node to node.
GRAB has the second highest PDR on average but incurs
large packet latency and energy consumption because it floods
packets in a mesh to the hub. With 50% active source nodes, the

packet latency increases exponentially and the average energy
consumption with 10% and 50% source nodes are 207 and
172 mJ, respectively. In addition to noise and node failures,
packet loss is also contributed by packet collision as flooding
generates a large amount of redundant packets. Also, a packet
broadcasted by the originating node can be lost in transmission
for good because the node will not know that the packet is lost
as broadcast does not provide for link-to-link transmission and
acknowledgement.
With 10% source nodes, the energy consumption of EAR
is the lowest and its packet latency is the second lowest after
GBR and is only 0.05 s higher than GBR on average. However, EAR has achieved the highest PDR of 98.4% on average compared to GRAB which has the second highest at only
81.9%. Using “route blacklisting”, EAR has the capability to

5.1.3. Multiple hubs
Operating with a single hub limits the size of the WSN and
also do not provide for fault tolerance in the event of hub failure. Using multiple hubs in a network overcomes the above
problems and also allows packets to be forwarded to an alternative hub that has a good path connecting the originating node
thus resulting in higher PDR. Packet latency and energy consumption are also reduced because packets may be routed on
good paths with higher probability so less re-transmission is
needed for lost packets or packet errors.
To evaluate the routing protocols’ ability to support multiple
hubs, we conducted the test using the same noise and fault
conditions with 50% source nodes. The test is conducted for 4
hubs and 9 hubs that are uniformly distributed in the WSN. The
results are averaged over 20 runs each with a different seed.
Fig. 10 shows the results. AODV and DSR are not simulated
because they do not support routing to multiple hubs.
GBR has slightly better PDR than GRAB and the difference
could be due to less packet collision, as GBR does not use
broadcast mechanism.
GRAB incurs the least packet latency on average because by
broadcasting several copies of packets in a mesh means that
the best path would be taken by one of these packet copies
and that copy can arrive at a hub faster resulting in a lower
latency. However, this slight reduction in latency compared to
EAR is compromised by the amount of energy expended in

Packet Delivery Ratio (PDR) with 50% Source Nodes
100
95
90
85

EAR-4
EAR-9

80

GBR-4
GBR-9

75

GRAB-4
GRAB-9

70
0

50

100

150
200
250
Number of nodes

300

350

400

PacketLatency with 50% Source Nodes
0.14
EAR-4


quickly detect those RF links with bad quality and discard them
from the routing table. By piggybacking route information on
RTS/CTS packets, the newest route information is disseminated
very quickly with little energy and latency cost. As shown in the
cost analysis part of Section 4.2.4, the energy cost of a single
route update is much lower when using piggybacking than using explicit routing control packets. The low energy consumption values may also be attributed in part to the ability of EAR
to dynamically account for variable link quality and forwarding
packets only on “best” routes.
With 50% source nodes, EAR manages to achieve 98% PDR
on average compared to the second highest of 70% for GBR and
also consumes the least amount of energy per packet delivered.
The packet latency is only 0.4 s higher than GBR on average
contributed mainly by the larger network sizes at 350 nodes
and 400 nodes. The higher latency is due to the need to route
packets through longer paths with better RF link quality and
also to route packets around failed nodes in a larger network
with higher traffic volume. However, this is good compromise
for the additional packet latency and energy that would have
to be incurred and expended to re-transmit those lost packets
at the transport or application layer, which is an end-to-end
transmission. As an example, at 400 nodes, the PDR of EAR
is 96% while GBR manages only 50%. The packet latency of
EAR is 2 s higher than GBR. But re-transmitting the 46% lost
packet, equivalent to about 10,000 packets will definitely cost
more than the mere 2 s. These results show that the performance
of the EAR routing protocol in a realistic wireless medium is
efficient, reliable and scales well with the size of the WSN.

% of packets delivered successfully


0.12

EAR-9
GBR-4

0.1

GBR-9
GRAB-4

0.08

GRAB-9

0.06
0.04
0.02
0
0

50

100

150 200 250
Number of nodes

300

350

400

Energy Consumption with 50% Source Nodes
Energy expended per packet (mJ)

932

10
9
8
7
6

EAR-4
EAR-9
GBR-4
GBR-9
GRAB-4
GRAB-9

5
4
3
2
1
0
0

50

100

150
200
250
Number of nodes

300

350

400

Fig. 10. Results with multiple hubs.

broadcasting and forwarding redundant packets in a mesh to
the hub. The average energy consumption of GRAB for 4 hubs
and 9 hubs are 52 and 41 mJ, respectively, and therefore, not
within the energy consumption ranges exhibited by the other
routing protocols.
EAR has achieved the highest PDR while consuming the
least amount of energy. The packet latency is the second lowest
after GRAB on average with the difference at about 6 ms. The
good performance is attributed to the ability of EAR to make
a decision at every intermediate node to choose the next best
hop at the point of time. Every packet is always routed to a


hub that offers the best path to the node where the packet is
currently in transit.
5.2. Open issues
We have not investigated the optimal nodes-to-hubs ratio.
When the number of hubs are increased, network performance
increases. But in practical deployment, the number of hubs will
be restricted due to their cost. A cost vs. performance-gain study
will be useful to network designers.
In our proposed network setup, the nodes will forward all
data packets to the hubs. This inevitably causes the nodes nearer
to the hubs to route more packets than other nodes. This implies
those nodes nearer to the hub will drain their energy-reserve
at a much faster rate. One could solve this problem simply by
adopting differentiated node placement strategy where the node
density increases as we move nearer to a hub.
In a sensor network, the network user might want to send
commands to a section of the nodes in the network. We have
not addressed the problem of how to route packets reliably and
efficiently to a node or a group of nodes from the hubs. As such
traffic flow is infrequent, a direct broadcast could probably be
used.
6. Conclusions
This paper has proposed EAR; an efficient and reliable routing protocol for WSNs. Using simulations results, we have
shown that it performs competitively against four existing routing protocols in PDR, packet latency and energy consumption
when operating in a noisy wireless environment where node
failure rate is high. EAR is a viable light-weight and efficient
routing protocol for any sensor network application that requires efficient and reliable routing from nodes to hubs. Possible future work includes studying the open issues in Section
5.2 and fine-tuning the various routing mechanisms to enhance
the performance of EAR.
Acknowledgments
We would like to thank the Nanyang Technological University and Georgia State University for supporting our research
efforts. Yi Pan’s research was supported in part by the National Science Foundation (NSF) under Grants ECS-0196569,
and ECS-0334813, and the National Natural Science Foundation of China (NSFC) under Grant No. 60440420451 (“two
base” project). We acknowledge Mr. Long Say Huan’s help in
the development of EAR and the conduct of the performance
simulations. We also thank the editor and anonymous reviewers for their valuable critique and advice that have significantly
improved the content and organisation of this paper.
References
[1] R. Ahuja, R. Bagrodia, L. Bajaj, M. Gerla, M. Takai, GloMoSim:
a scalable network simulation environment, Technical Report 990027,
UCLA, Computer Science Department.

933

[2] I.F. Akyildiz, E. Cayirci, Y. Sankarasubramaniam, W. Su, A survey on
sensor networks, IEEE Commun. Mag. (2002) 102–114.
[3] T. Bokareva, N. Bulusu and S. Jha, A performance comparison of data
dissemination protocols for wireless sensor networks, Proceedings of
Globecom 2004, IEEE Press, 2004, pp. 85–89.
[4] A. Bourkerche, Performance evaluation of routing protocols for ad hoc
wireless networks, Mobile Networks Appl. 9 (4) (2004) 333–342.
[5] J. Broch, D.A. Maltz, D.B. Johnson, Y.-C. Hu, J. Jetcheva, A performance
comparison of multi-hop wireless ad hoc network routing protocols,
in: Proceedings of the ACM/IEEE International, Conference on Mobile
Computing and Networking, October 1998, pp. 85–97.
[6] N. Bulusu, D. Estrin, L. Girod, J. Heidemann, Scalable coordination
for wireless sensor networks: self-configuring localization systems, in:
Proceedings of the 6th International Symposium on Communication
Theory and Applications (ISCTA’01), July 2001.
[7] A. Chandrakasan, S.-H. Cho, N. Ickes, R. Min, E. Shih, A. Sinha, A.
Wang, Physical layer driven protocol and algorithm design for energyefficient wireless sensor networks, in: Proceedings of the 7th Annual
International Conference on Mobile Computing and Networking, Rome,
Italy, 2001, pp. 272–287.
[8] CrossBow MICA 2 motes specification. http://www.xbow.com .
[9] S. Das, C.E. Perkins, E.M. Royer, Ad hoc on-demand distance vector
(AODV) routing, IETF Internet Draft, draft-ietf-manet-aodv-13.txt,
February 2003, work in progress.
[10] S.R. Das, C.E. Perkins, E.M. Royer, Performance comparison of two
on-demand routing protocols for ad hoc networks, in: Proceedings of
the IEEE Infocom, 2000, pp. 3–12.
[11] M. Degermark, N. Hedman, P. Johansson, T. Larsson, B. Mielczarek,
Scenario-based performance analysis of routing protocols for mobile ad
hoc networks, in: Proceedings of the 5th Annual ACM/IEEE International
Conference on Mobile Computing and Networking, Seattle, Washington,
USA, 1999, pp. 195–206.
[12] D. Estrin, L. Girod, G. Pottie, M. Srivastava, Instrumenting the world
with wireless sensor networks, in: Proceedings of the International
Conference on Acoustics, Speech and Signal Processing (ICASSP 2001),
Salt Lake City, Utah, USA, May 2001.
[13] D. Estrin, R. Govindan, J. Heidemann, S. Kumar, Next century
challenges: scalable coordination in sensor networks, in: International
Conference on Mobile Computing and Networks (MobiCOM’99),
Seattle, Washington, USA, August 1999.
[14] D. Estrin, R. Govindan, C. Intanagonwiwat, Directed diffusion: a
scalable and reliable communication paradigm for sensor networks,
in: Proceedings of the 6th International ACM Conference on Mobile
Computing and Networking (MOBICOM), 2000, pp. 56–67.
[15] Y.C. Hu, J.G. Jetcheva, D.B. Johnson, D.A. Maltz, The dynamic source
routing protocol for mobile ad hoc networks, Internet-Draft, draft-ietfmanet-dsr-09.txt, April 2003.
[16] D. B Johnson, et al., Dynamic source routing in ad hoc wireless
networks, in: T. Imielinski, H. Korth (Eds.), Mobile Computing, Kluwer
Academic Publishers, Dordrecht, 1996, pp. 153–181, (Chapter 5) ISBN:
0792396979.
[17] J.M. Kahn, R.H. Katz, K.S.J. Pister, Next century challenges:
mobile networking for “smart dust”, in: Proceedings of the 5th
Annual ACM/IEEE International Conference on Mobile Computing and
Networking, Seattle, Washington, USA, 1999, pp. 271–278.
[18] LAN MAN Standards Committee of the IEEE Computer Society,
Wireless LAN medium access control (MAC) and physical layer (PHY)
specification, IEEE, New York, NY, USA, IEEE Std 802.11-1997 edition,
1997.
[19] C.E. Perkins, E.M. Belding-Royer, S. Das. Ad hoc on demand distance
vector (AODV) routing, IETF Internet draft, draft-ietf-manet-aodv-12.txt,
November 2002.
[20] C. Schurgers, M.B. Srivastava, Energy efficient routing in wireless sensor
networks, in: MILCOM Proceedings on Communications for NetworkCentric Operations: Creating the Information Force, McLean, VA, 2001.
[21] F. Ye, G. Zhong, S. Lu, L. Zhang, GRAdient Broadcast: a robust
data delivery protocol for large scale sensor networks, ACM Wireless
Networks 11 (2) (2005).

934


[22] W. Ye, J. Heidemann, D. Estrin, An energy-efﬁcient MAC protocol
for wireless sensor networks, in: Proceedings of the 21st International
Annual Joint Conference of the IEEE Computer and Communications
Societies (INFOCOM 2002).
Peter K.K. Loh is currently an Associate Professor of the School of Computer Engineering,
Nanyang Technological University of Singapore.
He has authored and co-authored several papers
in parallel and distributed systems and computer gaming. He has previously held positions
as Manager of Software Cluster Labs and Parallel Processing Lab. He obtained his Ph.D. from
the Nanyang Technological University, M.Sc.
(Comp.Sc.) from Manchester University, M.Sc.
(Elect.Engg.) & B.Eng. from the National University of Singapore. He is also a registered
Professional Engineer (Singapore) and Chartered Engineer (UK) and a Senior
Member of IEEE.
Wen Jing Hsu is currently an Associate Professor of the School of Computer Engineering,
Nanyang Technological University. He is also
a Faculty Fellow of the Singapore-MIT Alliance Computer Science Program since 2002.
He has authored and co-authored many papers in parallel and distributed processing,
among them three were nominated for Best
Paper Award. He is Deputy Director of the
Maritime Research Center, NTU. He also held
positions in the Faculty of Michigan State
University, USA, and was a Visiting Scientist to IBM T.J. Watson Research Center
Yorktown Heights and IBM Palo Alto Scientiﬁc Center. He obtained his Ph.D.,
M.Sc. & B.Eng. from the National Chiao Tung University, Taiwan ROC.

Yi Pan received his B.Eng. and M.Eng. degrees
in computer engineering from Tsinghua University, China, in 1982 and 1984, respectively, and
his Ph.D. degree in computer science from the
University of Pittsburgh, USA, in 1991. Currently, he is a full professor in the Department
of Computer Science at Georgia State University. Dr. Pan’s research interests include parallel and distributed computing, optical networks,
wireless networks, and bioinformatics. Dr. Pan
has published more than 80 journal papers with
28 papers published in various IEEE journals.
In addition, he has published over 90 papers in refereed conferences. He
has also co-edited 13 books (including proceedings) and contributed several
book chapters. He is a co-inventor of three U.S. patents (pending) and 5
provisional patents. His recent research has been supported by NSF, NIH,
NSFC, AFOSR, AFRL, JSPS, IISF and the states of Georgia and Ohio. Dr.
Pan has served as an editor-in-chief or editorial board member for 8 journals
including 3 IEEE Transactions and a guest editor for 7 special issues.

23

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to 23 (20)

23