RMAC: A Routing-Enhanced Duty-Cycle MAC Protocol for Wireless Sensor Networks

Abstract

Duty-cycle MAC protocols have been proposed to meet the demanding energy requirements of wireless sensor networks. Although existing duty-cycle MAC protocols such as S-MAC are power efficient, they introduce significant end-to-end delivery latency and provide poor traffic contention handling. In this paper, we present a new duty-cycle MAC protocol, called RMAC (the routing enhanced MAC protocol), that exploits cross-layer routing information in order to avoid these problems without sacrificing energy efficiency. In RMAC, a setup control frame can travel across multiple hops and schedule the upcoming data packet delivery along that route. Each intermediate relaying node for the data packet along these hops sleeps and intelligently wakes up at a scheduled time, so that its upstream node can send the data packet to it and it can immediately forward the data packet to its downstream node. When wireless medium contention occurs, RMAC moves contention traffic away from the busy area by delivering data packets over multiple hops in a single cycle, helping to reduce the contention in the area quickly. Our simulation results in ns-2 show that RMAC achieves significant improvement in end-to-end delivery latency over S-MAC and can handle traffic contention much more efficiently than S-MAC, without sacrificing energy efficiency or network throughput.

Full text

Page 1

RMAC: A Routing-Enhanced Duty-Cycle MAC
Protocol for Wireless Sensor Networks
Shu DuAmit Kumar SahaDavid B. Johnson
Department of Computer Science, Rice University, Houston, TX, USA
Abstract—Duty-cycle MAC protocols have been proposed to
meet the demanding energy requirements of wireless sensor
networks. Although existing duty-cycle MAC protocols such as
S-MAC are power efficient, they introduce significant end-to-end
delivery latency and provide poor traffic contention handling. In
this paper, we present a new duty-cycle MAC protocol, called
RMAC (the Routing enhanced MAC protocol), that exploits cross-
layer routing information in order to avoid these problems without
sacrificing energy efficiency. In RMAC, a setup control frame can
travel across multiple hops and schedule the upcoming data packet
delivery along that route. Each intermediate relaying node for the
data packet along these hops sleeps and intelligently wakes up at
a scheduled time, so that its upstream node can send the data
packet to it and it can immediately forward the data packet to
its downstream node. When wireless medium contention occurs,
RMAC moves contention traffic away from the busy area by
delivering data packets over multiple hops in a single cycle, helping
to reduce the contention in the area quickly. Our simulation results
in ns-2 show that RMAC achieves significant improvement in
end-to-end delivery latency over S-MAC and can handle traffic
contention much more efficiently than S-MAC, without sacrificing
energy efficiency or network throughput.
I. INTRODUCTION
Large-scale wireless sensor networks have a significant po-
tential in applications such as monitoring of natural and man-
made environmental phenomena and events, but this potential
may be limited due to the limited battery capacity of sensor
nodes. Many traditional wireless MAC protocols used in wire-
less ad hoc networks, such as IEEE 802.11, require a wireless
device to remain awake to monitor the medium, even when the
node is not transmitting or receiving a packet. Since a typical
sensor network application usually generates very light traffic
on the network, this idle-listening mechanism is very inefficient
and wastes significant energy.
To mitigate this energy consumption of idle listening, duty-
cycling mechanisms have been introduced in sensor network
MAC protocols. For example, in S-MAC [1], each sensor
node follows a periodic synchronized listen/sleep schedule. An
overview of the operation of S-MAC is shown in Figure 1, in
which a node S sends a packet to a node D. The listening
period, in which the node’s radio is enabled, is divided into a
SYNC period and a DATA period. During the SYNC period,
an independent synchronization protocol is used to synchronize
the clocks of the sensor nodes, so that they can be awake
simultaneously with their neighbors. During the DATA period,
packets from applications can be sent. Similar to IEEE 802.11,
S-MAC uses the RTS/CTS mechanism to avoid collisions
between multiple transmitting nodes, and when a node receives
a data packet, it returns an ACK to the sender.
At the start of a SLEEP period, a node turns off its radio
and goes to sleep to save energy, unless it is still in the middle
of data transmission, in which case, the sender and the receiver
go to sleep after the transmission completes. In the example in
Figure 1, neither node S nor D will go to sleep until the ACK
frame is received by S. The above S-MAC operational cycle is
repeated endlessly during the life of the nodes.
As in IEEE 802.11, nodes in S-MAC maintain a Network
Allocation Vector (NAV) for virtual carrier sensing. For exam-
ple, node X in Figure 1 is a neighbor of node D and overhears
the CTS sent by D. Node X will set its NAV to indicate this
virtual carrier and will not send any traffic while its NAV is
nonzero. Inter-frame spacing, such as SIFS (Short Inter-Frame
Spacing) and DIFS (Distributed Inter-Frame Spacing), are also
used in S-MAC, as in IEEE 802.11. Before a node transmits an
RTS, it waits a random time in its contention windows (CW)
in order to decrease the possibility of collision when multiple
nodes try to send data in the same DATA period.
Duty-cycle MAC protocols are more energy efficient than
traditional MAC protocols, but they have some limitations.
Most importantly, end-to-end delivery latency may be increased
substantially; for example, with S-MAC, in each operational
cycle, a packet can be forwarded over a single hop only,
since an intermediate relaying node has to wait for its next
downstream node to wake up to receive the packet.
In addition, because a sensor node using a duty-cycle MAC
protocol is synchronized to be awake during the same short
period as its neighbors, the probability of network contention
increases. Although sensor network applications usually gener-
ates very light traffic, decreasing the importance of this concern,
in some applications such as event monitoring, communication
demands may suddenly increase in a burst in a small neigh-
borhood. For example, when a fire starts, several temperature
monitoring sensors in the area will report to the sink node
at the same time. If the transmission contention among these
sensors is not handled well, the emergent data may be lost or
will experience a long delivery latency.
Finally, existing duty-cycle MAC protocols significantly limit
network throughput, since nodes can be active only during a
small fraction of the time. Although network throughput in
sensor networks is not as important as in traditional networks,
throughput is still an important factor, for example to support
high throughput during a temporary traffic burst, such as in
event-monitoring applications.
Motivated by the above problems, in this paper, we present
the design and evaluation of a new duty-cycle MAC protocol,
called RMAC (the Routing enhanced MAC protocol), that

0743-166X/07/$25.00 ©2007 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2007 proceedings.

1478

Page 2

DIFS
CW
RTS
D
SYNC
CTS
SIFS
DATA
ACK
SIFSSIFS
X
S
DATASLEEP
Wake Up
Go To Sleep
NAV
Radio SleepNAV
Fig. 1.S-MAC: A typical duty-cycle MAC protocol for sensor networks
exploits cross-layer routing information in order to avoid these
problems without sacrificing energy efficiency. Most impor-
tantly, RMAC can deliver a data packet multiple hops in a
single operational cycle. During the SLEEP period in RMAC,
a relaying node for a data packet goes to sleep first and then
intelligently wake up when its upstream node has the data
packet ready to transmit to it. After the data packet is received
by this relaying node, it can also immediately forward the
packet to its next downstream node, as that node has also just
woken up and is ready to receive the data packet.
RMAC can thus deliver a data packet much faster without
sacrificing the energy efficiency achieved by the duty-cycle
mechanism. RMAC can also efficiently handle traffic con-
tention by moving the contention traffic quickly away from the
contention area. Also, when a burst of traffic occurs, RMAC is
able to make multiple transmissions in a single SLEEP period,
thus taking better advantage of the SLEEP period than previous
duty-cycle MAC protocols.
The organization of the rest of this paper is as follows. In
Section II, we describe the basic ideas behind RMAC and give
an introduction to the protocol. We then present the details of
RMAC in Section III, including the control and data forwarding
algorithms and the exception handling methods. Simulation-
based performance evaluation is presented and discussed in
Section IV. In Section V, we discuss the related work in the
area of sensor network MAC designs. Finally, Section VI draws
conclusion and discusses future work.
II. RMAC OVERVIEW
In order to reduce end-to-end delivery latency with a duty-
cycle MAC protocol, the protocol should be able to forward
a data packet multiple hops within a single operational cycle.
The design of RMAC is guided by the fact that to achieve this,
nodes along the data forwarding path need to be awake only
when actually transmitting or receiving the packet. RMAC thus
sends a small control frame along the data forwarding path to
allow all nodes along the path learn when to be awake in order
to receive the data packet from the immediate upstream node
and forward it to the immediate downstream node.
Figure 2 shows an overview of the operation of RMAC. An
operational cycle of a sensor node in RMAC can be divided
into three stages: SYNC, DATA, and SLEEP. Similar to prior
work, RMAC assumes that a separate protocol (e.g., [2], [3]),
SYNCDATASLEEP
CW
PION
DIFS
A
B
S
C
PION
PION
PION
DATA
ACK DATA
ACK DATA
ACK
SIFS
SIFS
SIFS
SIFS
SIFS
SIFS
SIFS
SIFS
Wake UpGo To Sleep
Radio Sleep
Fig. 2.RMAC overview
operating during the SYNC period, synchronizes the clocks on
sensor nodes with the required precision.
When a data packet is to be sent to a destination node that is
multiple hops away, a control frame is sent during the DATA
period to initiate the communication with the downstream
nodes. Instead of using a pair of RTS and CTS frames between
just two nodes, RMAC uses a series of control frames, named
PIONs (Pioneer frames), across multiple hops. A PION is used
to request communication, like an RTS frame, and to confirm a
request, like a CTS frame. Most importantly, a node transmits
a single PION to confirm receipt of a PION from its upstream
node and to simultaneously request communication from a
downstream node. This dual function makes the multihop
relaying of PIONs very efficient. We will present the PION
mechanism in detail in Section III.
During a SLEEP period, nodes go to sleep except for those
that have communication tasks, as set up by the PIONs. Every
node that has sent or relayed a PION must wake up at some
specific time to transmit or forward the data frames; each node
goes back to sleep after completing its communication task.
III. RMAC PROTOCOL DETAILS
A. Pioneer Control Frame (PION)
When a node has data to send, the node initiates its request
at the start of a DATA period. For example, if a source node
S has data to send to some destination (Figure 2), node S first
picks a random period from the contention window and waits
for the medium to be quiet for that period and an additional
DIFS period (as in IEEE 802.11) before sending a PION to
the next-hop node A.
This PION includes all fields as in an RTS, such as current
node’s address, the next-hop address, and the duration of
the transmission. More importantly, the PION also includes
some cross-layer information: the final destination address
of the current flow and the number of hops the PION has
traveled. This final destination address is passed down by the
networking layer, and the hop count is set to zero when the
data packet is generated by the source node.
When A receives S’s PION, unless A is the final destination
of this flow, A gets the next-hop address for this destination
from its own network layer. A then waits a SIFS period
(as in IEEE 802.11) before transmitting its own PION. The
PION contains three addresses, apart from the final destination
address: its own address, the previous-hop address (S), and the
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2007 proceedings.

1479

Page 3

DATASLEEP
CW
PION
DIFS
A
B
S
PION
PION
DATA
ACK
SIFS
SIFS
SIFS
Wake Up
Go To Sleep
Radio Sleep
DATA
ACK
SIFS
SIFS
Fig. 3.Data transmission example
new next-hop address (e.g., B). Additionally, the hop count in
this new PION is set to 1 more than that in the received PION;
the use of the hop count will be explained in Section III-B.
This PION from A serves both as a CTS to S and as an RTS
to B. Unlike other protocols, when S receives A’s PION, S
does not send its data frame immediately but waits for the
start of the SLEEP period to transmit the data frame; the
DATA period of the operation cycle is used only to send and
receive PION frames, setting up the schedule for the actual
data transmission. Data frames are transmitted and received
only during the SLEEP period. Upon receiving A’s PION, B
performs the same steps as A. This process of receiving a
PION and immediately transmitting another PION continues
until either the final destination has received the PION or the
end of the current DATA period is reached.
B. Data Transmission
As mentioned in Section III-A, all data frames are
transmitted in the SLEEP period. In the example in Figure 3,
when the first node S receives the PION confirmation from
node A, it waits until the start of the SLEEP period to transmit
the data frame. Node A stays awake to receive the data frame
at the start of the SLEEP period, and after node A receives
the data frame, it sends an ACK frame to S. After receiving
the ACK, node S goes to sleep mode.
If node A earlier received the confirmation PION from its
next hop B in the DATA period, A immediately relays the
data frame to B. This data frame relaying process continues at
each hop until the final destination is reached or the data frame
reaches some node that did not receive a confirmation PION
from its next hop, in which case the node just holds the data
frame until the DATA period of the next operational cycle. At
that time, this node sends a fresh PION to the next hop with
the hop count reset to zero. This entire process is repeated until
the final destination is reached.
In the above case, when the SLEEP period starts, nodes S
and A start their data frame sending/receiving immediately.
Other nodes in the multihop path that took part in the PION
transmission in the current DATA period go to sleep to save
energy. Each node later wakes up at the right time to receive
the data frame from the upstream node and send it to the
downstream node. For example, node B can go to sleep when
the SLEEP period begins, but it wakes up at the scheduled
time when A is ready to forward the data frame to B.
The data relaying process is very much like a pipeline
process; the correct wake up time of a node can be calculated
DATASLEEP
CW
PION
DIFS
A
B
S
PION
PION
DATA
ACK
SIFS
SIFS
SIFS
Wake UpGo To SleepRadio Sleep
DATA
ACK
SIFS
SIFS
A’
123
NAV
Fig. 4.Network Allocation Vector (NAV) example
from the hop count from in the PION frame. Suppose a node
is the ith hop during the PION transmission. Its wake up time
Twakeup(i) should be
Twakeup(i) = (i − 1) · (durDATA + SIFS + durACK + SIFS)
where durDATA and durACK are the times to send a single data
frame and an ACK frame, respectively. If all data frames in the
sensor network are the same size, durDATA could be a preset
value; otherwise, durDATA can be included in the PION, to let
every node along the path calculate the correct wake up time.
(1)
C. Setting the Network Allocation Vector (NAV)
The Network Allocation Vector (NAV) at each node is
used in IEEE 802.11-style MAC protocols for virtual carrier
sense, to avoid packet collisions. A non-zero NAV implies a
busy medium and hence prevents a node from transmitting.
Unlike existing sensor network MAC protocols, the control
sequence is different in RMAC, since the PIONs schedule data
transmissions expected in the future. Thus, the NAV in RMAC
records segments of time, rather than a single duration, during
which the medium is considered busy. All nodes that overhear
a PION set a segment in their NAV based on the durDATA and
the hop count i in the PION. For example, in Figure 4, if node
A?is a neighbor of node A, in order to avoid collision at node
A, A?should not transmit if node A is potentially receiving
anything. Therefore, if node A?overhears a PION from A to
B, it should set its own NAV to reserve the following three
segments of time (in the format [starttime,endtime]):
Confirmation PION Segment (1): [now,now+durPION],
where durPION is the transmission duration of a PION frame.
This segment ensures that A?will not transmit when A is
receiving the confirmation PION from B.
Data Segment (2): [tdatastart,tdataend], where tdatastartcan be
calculated by A?based on the next sleep time and Twakeupof A.
The value tdataendcan then be further calculated by adding a
durDATA to tdatastart. This segment ensures that A?will not
transmit when A is receiving the data frame from the previous
hop.
ACK Segment (3): [tackstart,tackend], where tackstartcan be
calculated by adding durDATA plus durACK plus 3 × SIFS
to tdataend. The value tackend is tackstart plus durACK, the
transmission time of an ACK frame. This segment ensures that
A?will not transmit when A is receiving the ACK frame from
its next hop.
After setting the above NAV segments, if node A?receives
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2007 proceedings.

1480

Page 4

another PION destined to itself that requests A?to do data
relaying, then A?only transmits a confirmation PION, thereby
agreeing to relay the data frame, if the relaying assignment
does not conflict with its current NAV settings. This relaying
assignment involves an immediate PION and future ACK and
data transmissions. If any of these assignments conflict with
the current NAV at A?, then A?does not transmit a PION, thus
rejecting the future relaying of the corresponding data frame;
the previous hop will have to request A?in the DATA period
of the next operational cycle.
D. Handling Frame Losses
If a PION is lost, the upstream node of the PION’s sender
will not get a confirmation and so will not try to send the
data frame to the downstream node. The upstream node will
initiate a new PION in the next DATA period. Unfortunately,
the downstream node does not know that the upstream node did
not get its confirmation, so it will wake up and receive nothing.
After a predefined timeout, it will go back to sleep. Therefore,
the downstream node wastes some energy on the unnecessary
wakeup and the data packet cannot travel as many hops as it
could have. In the worst case, the upstream node may lose
the PION from the next downstream node, but that PION may
successfully traverse several hops further along the downstream.
In this worst case, every node along the downstream will wake
up at the scheduled time, wait, receive nothing, and then go
back to sleep after time out.
If a data or a ACK frame gets lost, no retries are made in the
current operational cycle, since the next hop is not scheduled
to be awake to receive the retransmitted packet. Consequently,
the upstream node goes back to sleep and tries again in the next
DATA period, starting with a fresh PION. In summary, RMAC
does not require any retry effort in a single operational cycle.
The node that identifies a loss will start with a fresh PION in
the next operational cycle.
E. Synchronization and Data Fusion
In sensor networks, multiple duty-cycle schedules may co-
exist due to the limitation of the synchronization algorithms or
hardware. Irrespective of the duty-cycle based MAC protocol
being used, if a node has neighbors of different duty-cycle
schedules, the node needs to keep track of all these different
schedules. In RMAC, if a node receives a PION and the next
hop has a different duty-cycle schedule, the PION relaying
stops; the relaying node will first receive the data and then
try to deliver the packet to the next hop following the next
hop’s duty-cycle schedule.
Since the clock rates of the sensors may not be the same,
sensor clocks can drift apart over time. Therefore, when a
node calculates the wake up time using Equation 1, it can
further deduct a small time value from the calculated result to
ensure it will always wake up before its upstream node starts
transmitting.
Many sensor networks apply data fusion algorithms when
a sensor relays data packets for the others. For example, data
values can be aggregated and compressed on their way to the
TABLE I
NETWORKING PARAMETERS
20 Kbps Sleep Power
0.5 WCarrier Sensing Range
250 m Contention window (CW)
0.5 W DIFS
0.45 WSIFS
Bandwidth
Rx Power
Tx Range
Tx Power
Idle Power
0.05 W
550 m
64 ms
10 ms
5 ms
TABLE II
TRANSMISSION DURATION PARAMETERS
Frame Size (bytes) Tx Latency (ms)
11.0
11.0
14.2
43.0
RTS/CTS
ACK (in S-MAC/RMAC)
PION
DATA (in S-MAC/RMAC)
10
10
14
50
sink node. Therefore, the wake-up time and NAV segments
cannot be easily calculated using a fixed durDATA. To solve this
problem, a PION can further include a field of accumulated data
transmission duration. When a PION is forwarded, the relaying
node adds its own durDATA value into the accumulated data
transmission duration in the PION. The neighboring nodes and
downstream nodes can thus correctly set their NAV segments
or wake-up timers.
IV. SIMULATION EVALUATION
To evaluate our RMAC design, we evaluated it using ver-
sion 2.29 of the ns-2 simulator. We simulate the Two Ray
Ground radio propagation model and a single omni-directional
antenna at each sensor node. We compare RMAC against
S-MAC without the adaptive listening mode [4]. We did not
include adaptive listening in S-MAC because the end-to-end
latency results from adaptive listening can be easily derived
from the basic S-MAC simulation results (the latency will be re-
duced by half), but adaptive listening also consumes much more
energy than the basic S-MAC. Table I shows the key parameters
we used in our simulations; these are the default settings in the
standard S-MAC simulation module distributed with the ns-
2.29 package. According to the ns-2 documentation, the default
250m transmission range and the 550m carrier sensing range
are modeled after the 914MHz Lucent WaveLAN DSSS radio
interface, which is not typical for a sensor node. However, sim-
ilar proportions of carrier sensing to transmission range are also
observed in some state-of-art sensor nodes [5]. In future work,
we will investigate the impact of smaller carrier sensing range.
In our simulations, traffic loads are generated by constant
bit rate (CBR) flows, and all data packets are 50 bytes in size.
Intermediate relaying nodes do not aggregate or compress data.
We also assume that the application data processing at any node
can be finished within a SIFS period; thus, data processing
introduces no extra delivery delays. The transmission latencies
for different types of packets are shown in Table II.
The transmission latencies in Table II are calculated as:
durFrame =p + (Frame Size · E)
Bandwidth
where we use the default 5 bytes for the preamble size p and the
default encoding ratio E of 2 in our simulations. The duration
of the DATA period in S-MAC can then be calculated as:
TDATA(S-MAC) = CW + DIFS + durRTS + SIFS + durCTS
where durRTS and durCTS are the transmission latencies of the
RTS and CTS frames, respectively. The duration of the DATA
+ 1 ms (2)
(3)
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2007 proceedings.

1481

Page 5

n n-1210
Fig. 5. Chain scenario
period in RMAC is calculated as:
TDATA(RMAC) = CW + DIFS + durPION + N · (SIFS + durPION)
where durPION is the transmission duration of a PION frame.
The PION relaying number N defines how many PION frames
can be forwarded in each DATA period. In order to enable
multihop relaying of a PION, N should be greater than 1. In
our simulations, we chose N = 4.
Finally, the duty cycle R is defined as the proportion of the
radio awake time to the entire cycle time of a sensor node:
R =Tawake
Tcycle
TSYNC+ TDATA+ TSLEEP
We keep the same duty cycle (5%) for both RMAC and S-MAC,
although this makes the whole cycle in RMAC longer than in
S-MAC due to RMAC’s longer DATA period. The duty cycle-
related settings are shown in Table III.
In our simulations, we assume all the nodes in the network
have already been synchronized to use a single wake-up and
sleep schedule. There is no synchronization traffic during our
simulations, but nodes still wake up at the beginning of the
SYNC period and listen to the medium. Also, we do not
include any routing traffic in the simulations, as we assume the
existence of a routing protocol deployed to provide the shortest
path between any two nodes.
(4)
=
TSYNC+ TDATA
(5)
A. Overview of Scenarios
We use three types of scenarios in our simulations: chain
scenarios, cross scenarios, and realistic scenarios.
Figure 5 shows an example of a chain scenario. All nodes
are equally spaced in a straight line, and neighboring nodes are
placed 200 m apart. One single CBR (constant bit rate) flow
sends packets from the node 0 to the node n. The length of the
chains varies from 1 hop to 24 hops. The chain scenario helps
us to study the protocols for basic multihop delivery.
Figure 6 shows an example of a cross scenario. Two straight
chains of nodes cross each other at a center node. The two
chains are of the same length, and the single node at the
crossing point is shared by the two chains. Therefore, the
length of the chains must be of a even number of hops. All
the neighboring nodes are placed 200 meters apart as well.
There are two CBR flows, each along one chain of nodes, from
one end of a chain to the other. The two CBR flows generate
packets at the same time and at the same rate, and thus their
traffic contends with each other at the center. The length of the
two chains is varied from 2 hops to 24 hops. Cross scenarios
are used to study the protocols for basic inter-flow contention.
Finally, Figure 7 shows an example of a realistic scenario
composed of 200 sensor nodes and a sink node. The 200 sensor
nodes are uniform randomly distributed in a 2000 m by 2000 m
square area, and the sink node is located at the top right corner
of the square. Figure 8 shows the histogram of the path lengths
from the sensors to the sink. The maximum path length from
a sensor to the sink is 15 hops, and most of the sensors are
TABLE III
CYCLE DURATION PARAMETERS
TSYNC(ms)
TDATA(ms)
55.2104.0
55.2168.0
TSLEEP(ms)
3025.8
4241.8
Tcycle(ms)
3185.0
4465.0
S-MAC
RMAC
TABLE IV
RESULTS OF 24-HOP NETWORKS
Scenario Latency
Tcycle
(seconds)
3.185
3.185
4.465
4.465
Latency
Tcycle
(cycles)
23.52
27.32
3.90
4.57
PathLength·Tcycle
Latency
(hops/cycle)
1.02
0.88
6.16
5.25
(seconds)
74.9
87.0
17.4
20.4
S-MAC
S-MAC
RMAC
RMAC
chain
cross
chain
cross
about 7 to 13 hops from the sink. All traffic in the network
is from a sensor node to the sink, generated as follows: at a
periodic interval, a random sensor node is selected to send one
data packet to the sink node. If a node is selected to send a
packet, it is taken out from the selection pool. If the selection
pool becomes empty, which means each of the 200 nodes has
sent a data packet to the sink, then the selection pool is reset
to contain all 200 nodes.
B. Latency Evaluation
In this subsection, we evaluate the performance of end-to-end
delivery latency. We use a typical light traffic load for sensor
networks. For the chain and cross scenarios, each CBR flow
generates a traffic load of 100 packets at the rate of 1 packet
every 50 seconds; the entire simulation runs for 5500 seconds
of simulation time. For the realistic scenario as well, data is
generated every 50 seconds, but each sensor sends only one
data packet to the sink node; the simulation runs for 10300
seconds of simulation time.
1) Latency Evaluation in Chain Scenarios: Figure 9 shows,
for the chain and cross scenarios, how the average packet
delivery latency varies with the path length; error bars show
the minimum and maximum delivery latencies.
For the chain scenarios, delivery latency in both S-MAC
and RMAC increases as the hop count of the path increases.
However, delivery latency in S-MAC increases at a much faster
rate, although it actually has a shorter operational cycle than
does RMAC. This shows the benefit of RMAC’s capability
of multihop delivery within a single cycle. This capability
can be better presented in Table IV. Using the cases of the
24-hop chain and cross scenarios, the last two columns in the
table show the total number of operational cycles needed for a
packet to finish the 24-hop delivery and the average number of
hops over which a packet can be forwarded in a single cycle.
For the 24-hop chain scenario, S-MAC can forward a data
packet over only 1.02 hops per cycle. It is slightly more than 1
hop, because for the first hop (from node 0 to node 1), S-MAC
does not need a full cycle to deliver the packet. Depending
upon when the data packet is generated at node 0, node 0 may
be able to send the packet to 1 immediately, if a data packet is
generated during a DATA period. Otherwise, node 0 must wait
for the start of the next DATA period; this waiting time may
vary, but is never more than one cycle.
On the other hand, RMAC, can forward a data packet an
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2007 proceedings.

1482