1

Contents
1. Introduction .................................................................................................................. 3
2. S-MAC Protocol ........................................................................................................... 5
2.1 Overview of S-MAC ................................................................................... 5
2.2 Periodic Sleep and Listen ............................................................................ 8
2.3 Synchronization ......................................................................................... 10
2.3.1 Synchronization Related Components in S-MAC.............................. 10
2.3.2 Choosing First Schedule..................................................................... 13
2.3.3 Updating and Maintaining Schedules................................................. 14
2.3.4 Periodical Neighbor Discovery .......................................................... 16
2.3.5 Periodical Neighbor List Updating..................................................... 16
2.4 CSMA/CA in S-MAC ............................................................................... 18
2.4.1 Carrier Sense ...................................................................................... 18
2.4.2 Collision Avoidance ........................................................................... 21
2.5 Overhearing Avoidance............................................................................. 22
2.6 Message Passing........................................................................................ 24
2.7 Adaptive listening...................................................................................... 25
3. The Network Simulator .............................................................................................. 31
3.1 What is NS-2 ............................................................................................. 31
3.2 How to Get Started .................................................................................... 32
4. Simulating S-MAC with NS-2 ................................................................................... 34
4.1 S-MAC in NS-2 ......................................................................................... 34
4.1.1 Implemented S-MAC Features........................................................... 34
4.1.2 S-MAC Parameters Settings............................................................... 35
4.1.3 S-MAC Modes.................................................................................... 36
4.1.4 Problems and Bugs of S-MAC in NS-2.28 ........................................ 36
4.2 Preparations for Simulating S-MAC ......................................................... 41
4.2.1 NO Ad-Hoc Routing Agent (NOAH)................................................. 41
4.2.2 Exponential Traffic Source Agent...................................................... 42
4.3 An Example Tcl Script for Simulating S-MAC ........................................ 43
4.4 Tracing....................................................................................................... 49
4.4.1 How to Trace in ns-2 .......................................................................... 49
4.4.2 Trace Format....................................................................................... 50
4.4.3 Tracing Radio State change for Energy Measures ............................. 51
4.5 Abstraction and Simulation Control .......................................................... 53
4.5.1 Abstraction Methods .......................................................................... 53
2

4.5.2 Simulation Control ............................................................................. 54

4.5.3 Scripts for Abstraction and Simulation Control ................................. 55
5. Simulation Results...................................................................................................... 58
5.1 Definition of Performance Measures......................................................... 58
5.2 Simulations for Validating S-MAC in NS-2 ............................................. 60
5.2.1 Common Settings for Reproduction Simulations.................................. 60
5.2.2 Measurement of Energy Consumption ............................................... 61
5.2.3 Measurement of Latency .................................................................... 62
5.2.4 Measurement of Throughput .............................................................. 64
5.3 Steady-State Simulations and Results ....................................................... 66
5.3.1 Common Settings for Steady-State Simulations ................................ 66
5.3.2 Single Traffic Source.......................................................................... 68
5.3.3 Two Traffic Sources ........................................................................... 77
6. Conclusion .................................................................................................................. 80
Bibliography ................................................................................................................... 82
 3

Chapter 1
Introduction

Motivation

Wireless sensor networks (WSN) are a trend of the past few years. The availability of
micro-sensors; low power, yet reasonably efficient wireless communication equipments;
embedded systems; distributed computation techniques and improved small-scale
energy supplies have made this emerging technological vision possible.
A wireless sensor network is a network made of numerous small, independent and
spacially distributed devices using sensors to monitor conditions at different locations,
such as temperature, sound, vibration, pressure, motion or pollutants. These small and
inexpensive devices, typically the size of a 35 mm film canister and the price about
several US$s, are self-contained units consisting of a battery, radio front end, sensors,
and a minimal amount of on-board computing power. All these components together in
a single device form a so-called sensor node. The sensor nodes self-organize their
networks, rather than having a pre-programmed network topology.
Though the WSN technology is still in its early days, the range of potential
applications is mind-boggling. Applications include environmental control such as
forest fire detection, air pollution and rainfall observation in agriculture; surveillance
tasks of many kinds like intruder surveillance in premises; military monitoring and
healthcare applications.
Due to the small and inexpensive characteristics of sensor nodes, they can be
produced and deployed in large numbers, and their resources in terms of energy,
memory, computational speed and bandwidth are severely constrained. In addition,
sensor nodes are often deployed in hostile environments or over large geographical
areas, so the battery of a sensor node is often not rechargeable. Therefore, how to reduce
the energy consumption to prolong the service lifetime of sensor nodes becomes a
critical issue.
As power consumption is one of the biggest problems of sensor networks and it is
greatly affected by the communication between nodes, the communication protocols of
different layers are designed with the energy conservation in mind. Medium access
control (MAC) has been and still is one of the most active research areas for wireless
sensor networks (as it is for ad hoc networks). In most of the work about the protocol of
4

MAC layer, the question is how to ensure that the sensor nodes can sleep as long as
possible, not being able to communicate. Some of the more recent and relevant papers
are [5, 6, 8], the PicoRadio MAC [9], the S-MAC [1,2] and the STEM work [7].
This thesis will focus on investigating and simulating S-MAC [1,2] using ns-2
framework, which is a popular network simulator [13]. Some simulations are run to
evaluate the performance of S-MAC and the simulation results will be analyzed and
compared to the results measured from hardware experiments presented in [2].

Organization of the thesis

After this introduction about the motivation of the thesis, some important features in S-
MAC will be introduced in detail in Chapter 2.
Chapter 3 gives a brief overview of Ns-2 and introduces how to get started with this
popular network simulator.
Chapter 4 describes how to simulate S-MAC with ns-2 and what preparations
should be done before starting simulations. The problems and bugs found in the S-MAC
source code in ns-2.28 will be presented in this chapter. A tcl script sample will be
explained to show how to set up a simulation for S-MAC in ns-2. How to trace in ns-2
and how to extract results from a trace file will also be discussed. Finally, a shell script
will be introduced to show how to implement simulation control in ns-2.
Chapter 5 presents and analyzes the results from the simulations in ns-2.
Chapter 6 summarizes the finished work and proposes further work and suggestions
on this study topic.
 5

Chapter 2
S-MAC Protocol

2.1 Overview of S-MAC

S-MAC, the abbreviation for Sensor-MAC, is a medium access control (MAC) protocol
designed for wireless sensor networks, proposed by SCADDS project group at USC/ISI
[11]. Wireless sensor networking technology is emerging in these years and becomes a
popular research area of computer science and technology. Wireless sensor networks are
the integration of sensor techniques, nested computation techniques, distributed
computation techniques and wireless communication techniques. They can be widely
used in many areas, such as environment monitoring, medical systems, and intelligent
building systems. The features for wireless sensor networks are listed as below:

Such networks consist of many distributed sensor nodes. Each node has one or
more sensors, an embedded processor, and a low-power radio, and is normally
battery-operated.
In some applications, sensor nodes are distributed within a vast expanse, such as
earthquake monitoring in desert area. Sometimes their working environments are
quite dangerous and even not accessible for humans.
Normally, sensor nodes in one network collaborate for a common application. They
communicate and exchange information in a peer-to-peer way (ad hoc fashion),
instead of by accessing a base station.
Sensor nodes keep silent for most of the time, but they will become active suddenly
when something is detected.
As time elapses in a network, some nodes may die, some nodes may move away,
some new nodes may be added. The topology may change over time.
A message is a meaningful unit of data that a node can process. For saving energy,
messages will be processed in a store-and-forward fashion, which is called in-
network data processing, instead of being processed at a certain node in a
centralized way.

From these features, we can identify the following problems that we have to solve,
when we design a good MAC protocol for wireless sensor networks.
6

1. The foremost one is energy efficiency.

As stated above, sensor nodes are expected to be battery-equipped. Due to their
working environments, recharging or replacing batteries for each node is difficult and
uneconomical, sometimes even impossible. Therefore, how to reduce the energy
consumption to prolong the service lifetime of sensor nodes becomes a critical issue. To
solve the energy problem, we should find out the sources of energy waste. As viewed
from hardware layer, radio communication consumes most of energy. Moreover, the
usage of radio has close relation with MAC protocols. Among existing wireless MAC
protocols for shared-medium networks, we have identified the following major sources
of energy waste.

The first one is idle listening. For contention-based MAC protocols, such as IEEE
802.11 ad-hoc mode, in order to perform effective carrier sense against possible
collisions, it puts nodes to listen to the channel all the time when nodes are idle.
And radio will consume almost the same power as in receiving state. A
considerable percentage of energy will be wasted on idle listening, especially when
the traffic load on the network is light. Among those factors for energy waste, idle
listening is a dominant one.

The second one is collision or corruption. Normally, collision may occur when
neighboring nodes contend for free medium, and lossy channel will result in
corruption of transmitted packets. When either of two cases happens, corrupted
packets should be re-transmitted, which increases energy consumption.

The third source is overhearing, which happens when a node receives some packets
that are destined to other nodes.

The last one is control packet overhead. Exchanging control packets between
sender and receiver also consumes some energy.

2. Scalability and self-configuration ability

As described before, for a wireless sensor network, its topology and size may change
over time. So a good MAC protocol should accommodate to such changes.

3. Latency, throughput, bandwidth utilization, fairness, etc

There are common attributes for most of MAC protocols. Take latency for example,
its importance depends on the actual applications. For most of sensor network
applications, the speed of changes on physical objects sensed by sensor nodes is much
slower than the network speed. So latency is less important and can be tolerated in a
certain range in such cases.
 7

From the above discussion, we can figure out that S-MAC, which is specially
designed for wireless sensor networks, will differ from other traditional wireless MAC
protocols in the following aspects: energy efficiency and self-configuration ability are
the primary goals, while others attributes, like latency and fairness, are secondary. Now
we introduce briefly what functions and features have been implemented in S-MAC.
The first feature that S-MAC introduces is periodic sleep and listen. The basic idea is
to let each node follow a periodic sleep and listen schedule, as shown in Fig. 2.1. In
listen period, the node wakes up for performing listening and communicating with other
nodes. When sleep period comes, the nodes will try to sleep by turning off their radios.
In this way, the time spent on idle listening can be significantly reduced, which
accordingly saves a lot of energy, especially when traffic load is low. The duty cycle is
defined as the ratio of listen period to a complete sleep and listen cycle. In S-MAC, the
low-duty-cycle mode is the default operation for all nodes. We introduce this feature in
section 2.2.

Listen Sleep Listen Sleep

time
Fig. 2.1. Periodic listen and sleep

For schedule-based MAC protocols, to synchronize nodes is a serious problem. To

achieve maximum energy saving and improve latency, S-MAC defines a complete
synchronization mechanism, including periodic SYNC packets broadcast, schedule
table and neighbor list maintenance, periodic neighbor discovery, periodic neighbor list
updating, etc. The basic idea is as follows. Each S-MAC node puts the information of
its own schedule in a SYNC packet and broadcasts it to its neighbors periodically.
When a new node joins the network, it will try to follow an existing schedule before
choosing one by itself. When hearing different schedules on its neighbors, the node will
record them in a table and follow all of them. More details about synchronization will
be introduced in section 2.3.
In shared-medium networks, how to avoid collision is a common topic for all
contention-based MACs. In this aspect, S-MAC is quite similar with the DCF protocol
in the IEEE 802.11 standards. The features that S-MAC has adopted include physical
and virtual carrier sense, RTS/CTS/DATA/ACK sequence for hidden station problem.
The contents regarding this part are put in section 2.4.
Overhearing will become another major source of energy waste, especially when the
node density is high and the traffic load is heavy in the network. S-MAC tries to avoid
overhearing by letting all interfering nodes, which are immediate neighbors of both the
sender and receiver, go to sleep after they hear an RTS or CTS packet. We talk about
this problem in section 2.5.
To efficiently transmit long messages in both energy and latency respects, S-MAC
supports message passing. This function divides a long message into a number of small
8

fragments and transmits them in a burst. S-MAC uses only a pair of RTS/CTS for one
message passing, but requests an ACK packet for each fragment. The RTS/CTS packets
reserve the medium for transmitting all fragments. That is to say, the longer the message
the node has, the more time it will occupy the medium. Obviously in this way, S-MAC
trades fairness on fragment level for fairness and latency on message level. But this is
reasonable for wireless sensor network applications because of its features in aspects of
data management. We talk about message passing in section 2.6.
Low-duty-cycle operation reduces energy consumption at the cost of increased
latency. When one node receives a data packet from its previous-hop node, it cannot
retransmit the packet to its next-hop node right now. It has to wait until the next listen
time for the next-hop node comes. So there exists a potential delay on each hop, when a
data packet is transmitted through a multi-hop network. To reduce such latency, S-MAC
proposes an important mechanism called adaptive listening. The basic idea is to give all
nodes, which are involved in a transmission, an additional chance for transmitting their
packets at the end of the transmission. These nodes include the sender, the receiver, and
all their immediate neighbors that overhear the transmission. In this way, a data packet
can be retransmitted immediately after its last transmission. We discuss adaptive
listening in detail in section 2.7.

2.2 Periodic Sleep and Listen

The main technique used to reduce energy consumption in S-MAC is to make each
node in the network follow a listen and sleep cycle. A complete cycle of listen and sleep
period is called a frame. During sleep period, the node will turn off its radio if possible.
In this way, a large amount of energy consumption caused by unnecessary idle listen
can be avoided especially when traffic load is light. During listen period, the node may
start sending or receiving packets if necessary. S-MAC provides a controllable
parameter duty cycle, whose value is the ratio of the listen period to the frame length. In
fact, the listen period is normally fixed according to some physical and MAC layer
parameters. The user can adjust the duty cycle value from 1% to 100% to control the
length of sleep period. Normally, the frame length is the same for all nodes in network.
The listen period is further divided into two parts. The first one called SYNC period
is designed for SYNC packets, which are broadcast packets and used to solve
synchronization problems between neighboring nodes. We will discuss all
synchronization problems in S-MAC in section 2.3. The second one called DATA
period is designed for transmitting DATA packets. The format of S-MAC frame is
shown is Fig. 2.2.
 9

Listen
Sleep
SYNC DATA

Guard
SYNC DIFS Contention window for SYNC durSync time

Proc Guard
DATA DIFS Contention window for DATA durCtrl Delay
SIFS durCtrl time

Fig. 2.2. S-MAC frame format

Each S-MAC node should have at least one schedule to follow. Each schedule is
controlled by a schedule timer, which can reschedule the next period when it expires at
the end of a current period. In Fig. 2.3 below, we can see that each frame will have three
expiration points, which are called checking points.

1 2 3 1 2 3

SYNC DATA Sleep SYNC DATA Sleep

Fig. 2.3. Three checking points in a frame

At any of these checking points, S-MAC will decide what to do in the coming period.
For example, at checking point 2, S-MAC checks if it has a data packet in the buffer to
send. If yes, it will start carrier sensing. Otherwise, S-MAC will never try to send any
data packet in this frame, if adaptive listening is not applied (adaptive listening is
introduced in section 2.7). In other words, even if S-MAC receives a new data packet
from its upper layer right in the middle of the DATA period, it will buffer it and wait
until the next checking point 2 comes, rather than start contending for the medium right
away.
Letting the node follow a sleep and listen schedule doesn’t mean that the node must
keep listening in the listen period or must go to sleep when the scheduled sleep period
comes. The actions of S-MAC at a certain time depend not only on the current
scheduled period, but also on some other factors. Those factors include current MAC
state, radio state, channel state, neighbors’ state, etc.
For example, at checking point 3, S-MAC will go to sleep by turning off its radio,
only when all the following listed conditions are satisfied.

My radio is not in receiving or sending state.

10

If I have not only one schedule in my schedule table (a border node), this
checking point must belong to my primary schedule. (Primary schedule is
introduced in section 2.3.1)
I am idle, neither a sender nor a receiver of an ongoing data transmission. For
example, I cannot go to sleep, if I have sent back a CTS packet to my neighbor
in last DATA period and am now waiting for the data packet.
I am not in a neighbor discovery period. (to be introduced in section 2.3.4)
I am not executing adaptive listening now. (to be introduced in section 2.7)

To know more about the behavior of S-MAC at each checking point, please refer to
the method SMAC::handleCounterTimer(int id) in the source file smac.cc1 in ns-2.28.
In this section, we mainly talk about the basic idea of schedule mechanism in S-MAC.
In latter sections, you will see that not only the sleep and listen schedule, but also other
features of S-MAC, such as overhearing avoidance and adaptive listening, can make the
node go to sleep or wake the node up.

2.3 Synchronization
2.3.1 Synchronization Related Components in S-MAC

SYNC Packet

As mentioned before, each S-MAC node needs to exchange its schedule by periodically
broadcasting a SYNC packet to its neighbors. The period of sending a SYNC packet is
called the synchronization period. The default value in ns-2 is 10 frames (one frame =
one sleep and listen cycle). Sending or receiving SYNC packets takes place in SYNC
period. The definition of SYNC packet frame in ns-2 is shown in Table 2.1.

Table 2.1. The SYNC frame

Field Comment
type Flag indicating this is a SYNC packet
length Fixed size with 9 Bytes
srcAddr ID of the sender
syncNode ID of the sender’s synchronization node
sleepTime Sender’s next sleep time from now
state Indicating if the sender has changed its schedule recently
crc Cyclic Redundancy Check

1
S-MAC source file in ns-2, locates in path ns-2.28\mac\
 11

From the table above, we can see that the most valuable information in a SYNC
packet is sleepTime, which tells all nodes that receive this packet when the next sleep
period on the sender node comes. To avoid synchronization errors caused by clock drift
on each node, the sleepTime uses a relative value rather than an absolute time.

Schedule Table

Each S-MAC node maintains one schedule table, which stores its own schedule and the
schedules of all its known neighbors. The establishment of the schedule table will be
introduced in the next subsection. There are two classes of schedules in the schedule
table. We call the schedule that the node itself is on primary schedule and other
schedules in the schedule table secondary schedules. A node may have no secondary
schedule, for example, if all its neighbors follow the same schedule. But every node
should have a primary schedule. The maximum number of records in the table is limited
by a user-adjustable S-MAC parameter, which defines the maximum number of
different schedules. Table 2.2. shows how each field in the schedule table is defined in
ns2.

Table 2.2. Field definition of schedule table

Field Comment
txSync Flag indicating need to send sync
txData Flag indicating need to send data
numPeriods Counter for sending sync periodically
numNodes Number of nodes on this schedule
syncNode The node who initialized this schedule
chkSched Flag indicating need to check numNodes

Now we explain why S-MAC introduces such a table. We intuitively hope that only
one schedule exists in the whole network, because sleep durations and energy saving
will be maximized when all nodes are on the same schedule. And we know that some
neighboring nodes can get synchronized through exchanging SYNC packet between
them. But in practice this mechanism takes effect only locally. The existence of multiple
schedules in a network is quite common, especially in a large multi-hop network where
nodes do not start initializing at the same time and join in a random way. We call those
nodes that share the same schedule a virtual cluster, and nodes with neighbors in two or
more clusters border nodes. Obviously, if the border node wants to talk to its neighbors
at their scheduled listen time, it has to know when its neighbors wake up and go to sleep.
Schedule table is designed for this purpose.
A schedule is actually a timer. Both primary schedule and other secondary schedules
have their own timers. These timers run independently and their workings are quite
similar. We take a simple example to illustrate how a border node works under multiple
12

schedules. We assume that node B has two neighbors node A and C. As shown in Fig.
2.4, B has two schedules in its schedule table. One is its own schedule (primary
schedule), which is the same as A’s, and the other is heard form C. B will allocate a
schedule timer for either of the two schedules. The two schedule timers run
independently.

A SYNC DATA SYNC DATA

B SYNC DATA SYNC DATA

SYNC DATA SYNC DATA

C SYNC DATA SYNC DATA

Fig. 2.4. A border node with two schedules

We first see how B broadcasts SYNC packets. To ensure that both A and C can
receive the SYNC packets in their own SYNC period, B has to broadcast its SYNC
packets periodically on both schedules. Please note that, in a SYNC packet, a border
node always tells its neighbors the time from now to its next sleep time according to its
primary schedule, but not to any of its secondary schedule.
The similar way is applied to broadcast data packets. When B has a data packet to
broadcast, it has to broadcast it twice. One takes place on A’s DATA period and the
other on C’s DATA period.
Now we discuss unicast data packets. Suppose B receives a data packet destined to C
from the upper layer, it first searches in its schedule table to find out the schedule that C
is following, and it sets the txData flag on that schedule to 1. When C’s next DATA
period comes, the corresponding schedule timer on B will inform B that its data buffer
has a data packet destined to C and now it is time to send it out.
From the above discussion, we can see that a border node has to follow several
schedules to get synchronized with its neighbors that are on the different schedules.
Obviously, border nodes will consume much more energy than non-border nodes. The
paper [3] proposes an algorithm called global schedule algorithm that allows all nodes
in a multi-hop network to converge on a single global schedule. This algorithm has been
implemented in S-MAC in ns-2.28. However, studying S-MAC under multiple
schedules is not the intention of this thesis.
 13

Neighbor List

Another important component in S-MAC is neighbor list. Each S-MAC node has to set
up such a table to records the information of all its known neighbors. The number of
records in the list is also limited by a user-adjustable S-MAC parameter, which defines
the maximum number of neighbors for each node. Like schedule table, neighbor list is
established also through exchanging SYNC packets between neighboring nodes. Table
2.3 below shows the definition for each field in neighbor list.

Table 2.3. Field definition of neighbor list

Field Comment
nodeId ID of this node
schedId Schedule ID in schedule table that this node follows
active Flag indicating this node is active recently
state Flag indicating the node has changed schedule

Neighbor list plays an important role in S-MAC. When S-MAC processes a unicast
data request received from the upper layer, it will first check its neighbor list to see if
the destination node is on the list. If not, the request will be refused. If yes, the flag
txData of the schedule that the destination node follows is set (if no other sending
request). Then when the next DATA period on this schedule arrives, the node will try to
send out this packet.

2.3.2 Choosing First Schedule

When a new node joins the network, it first listens for a fixed period (normally a
synchronization period). We call this period initial listening. Either of the following two
cases may happen.

1. No SYNC packet received during the initial listening.

At end of this period, the node chooses a schedule by itself and sets a schedule timer
for it. Normally the first cycle starts with SYNC period. Meanwhile the schedule is
added to the first entry of its schedule table. To announce this new schedule, the flag
txSync of this schedule is set, which indicates that the node will try to broadcast a
SYNC packet in the next SYNC period.

2. Get a SYNC packet before the initial listening ends.

That is the node’s first SYNC packet received. It immediately follows the schedule
that comes with the received SYNC packet, instead of choosing by itself after the
initial listening. The value of sleepTime in the SYNC packet determines the starting
point of the first cycle. Meanwhile the schedule is added to the first entry of the
14

schedule table, and the sender of the SYNC packet is added to the neighbor list. The
node also needs announce this schedule by setting the flag txSnyc in this schedule.

2.3.3 Updating and Maintaining Schedules

Now we know from the last subsection that after initial listening the node may get its
first schedule by choosing itself or by following an existing one. In this subsection, we
discuss how S-MAC maintains its schedule table and neighbor list every time it receives
a SYNC packet from one of its neighbors after it has chosen its first schedule.
The algorithm for handling received SYNC packets is listed as follows. The method
implementing this algorithm in smac.cc is SMAC::handleSYNC(Packet *p). However,
there are two such methods with the same name are defined in smac.cc of ns-2.28,
which are mutually exclusive at the compiling time. One is defined inside the
JOURNAL_PAPER2 code and the other outside. In this thesis, we consider only the
inside one, because most of our simulations use the JOURNAL_PAPER code.

1. This is my first SYNC packet.

This may happen only after I have chosen my first schedule by myself (option 1
in last sub-section). In this case, I will discard my first schedule by removing it from
my schedule table and follow the new one in the SYNC packet by adding it to the
first entry of the schedule table. And the schedule timer that is associated with the
discarded schedule will be rescheduled according to the value of sleepTime in the
SYNC packet. Of course, the node that sent this SYNC packet will be added to my
neighbor list (my first neighbor).

2. This is not my first SYNC packet after I have chosen my first schedule.

We have to consider the following five possible situations. For simplification, we

use N representing the sender of this SYNC packet and S representing the schedule
in the SYNC packet. The algorithm is put in Table 2.4 below.

2
A macro defined in smac.h, the S-MAC header file in ns-2
 15

Table 2.4. General algorithm for processing SYNC packets

Condition Action
1 N is a known neighbor Update S in my schedule table by rescheduling its schedule
in my neighbor list and timer with the value of sleepTime in the SYNC packet. This
it has not changed its can eliminate clock drift between two nodes.
primary schedule since I
got its last SYNC
packet.
2 N is a known neighbor Step1: Process the schedule that N has switched from.
in my neighbor list, but The number of the nodes on this schedule has to be decreased
it has switched its by one. If the number goes to 0 after decrease, this schedule
primary schedule to S, has to be removed from my schedule list. If now I happen to
which is new to me, have a DATA sending request, I must defer changing till the
since I got its last SYNC sending is over.
packet.
Step2: Process the new schedule S that N has switched to.
If my schedule table is not full, S is added and assigned to a
new schedule timer. Otherwise N has to be deleted from my
neighbor list.

Step3: If the schedule that N switched from is my primary

schedule, I need to execute check_my_schedule, which checks
if I become the only one on my primary schedule. If yes, I have
to choose the next available schedule in my schedule table and
set it as my new primary schedule (delete the old one). But if
now I happen to have a DATA sending request, I must defer
check_my_schedule until the current sending is over.

3 N is a known neighbor Step1: Process the schedule that N switched from.

in my neighbor list, but The number of the nodes on the schedule that N used to follow
it has switched its has to be decreased by one. If the number goes to 0 after
primary schedule to S, decrease, this schedule has to be removed from my schedule
which is an existing one list. If now I happen to have a DATA sending request, I must
in my schedule table, defer changing till the sending is over.
since I got its last SYNC
packet. Step2: Process the schedule S that N has switched to.
Update S in my schedule table by rescheduling its schedule
timer with the value of sleepTime in the SYNC packet. And the
number of nodes on S is increased by one.
4 N is an unknown If neither my schedule table nor neighbor list is full, add S to
neighbor to me and S is my schedule table and assign a new schedule timer to S. Then
also new to me. add N to my neighbor list.
5 N is an unknown Update S in my schedule table by rescheduling its schedule
neighbor to me, but S is timer with the value of sleepTime in the SYNC packet. If my
known in my schedule neighbor list is not full, N is added to it. And the number of
table. nodes on S is increased by one.
16

2.3.4 Periodical Neighbor Discovery

In S-MAC, neighboring nodes discover each other through exchanging SYNC packets.
However, sometimes two neighboring nodes may miss each other forever, for example,
when they follow different schedules, whose SYNC periods do not overlap. Periodical
neighbor discovery can prevent this from happening.
The basic idea of neighbor discovery in S-MAC is to make each node periodically
execute neighbor discovery for a whole synchronization time. During neighbor
discovery time, S-MAC will never try to go to sleep when its sleep period comes, so
that the node can listen more time than usually and have more chances to hear a new
neighbor. For a border node, neighbor discovery is only executed on its primary
schedule. The reason is that on secondary schedule, the node will not try to go to sleep
when scheduled sleep period arrives.
Fig. 2.5 shows how the neighbor discovery period is defined and its relationship with
other periods defined in S-MAC. The neighbor discovery period may vary, depending
on the current number of its known neighbors. In ns-2, the period of executing neighbor
discovery is 2 synchronization periods if the node has no neighbor. Otherwise, the
period is much longer and reaches 33 synchronization periods.

SYNC DATA Sleep One Frame

One Synchronization Period = 10 Frames

Neighbour Discovery

One Neighbour Discovery Period = 2 or 33 Synchonization Periods

Fig. 2.5. Hierarchy of periods in S-MAC

2.3.5 Periodical Neighbor List Updating

The schedule table and neighbor list will be updated each time when the node gets a
SYNC packet from one of its neighbors. Except that, each S-MAC node also needs to
check its neighbor list periodically to see if some of its neighbors have been inactive for
a certain time (moved away or died for some reason), which need to be removed from
the neighbor list. Doing this is necessary and important, because it cannot only save
space for the neighbor list, but also avoid unnecessary energy consumption caused by
keeping trying to talk to an inactive neighbor, especially in a multi-hop mobile sensor
network.
A timer is allocated to control periodical updating of the neighbor list. Its expiration
period must be larger than the synchronization period. The reason for it will be
 17

explained later. When the timer expires, the following steps will be executed. (Relevant
methods in the source file smac.cc in ns-2.28 includes handleUpdateNeighbTimer(),
update_myNeighbList(), update_neighbList())

Step 1: Check if I have a DATA sending request now. If yes, skip the following steps
and defer updating till the current sending is over. If no, from now, I will be temporarily
disabled from receiving new requests from the upper layer to avoid error operation
during updating. (In ns-2, this is done by setting the flag txRequest to 1, which prevents
S-MAC from receiving a new request from the upper layer.)

Step 2: Update the number of nodes on a certain schedule if its flag chkSched is set.
This may happen when I got a SYNC packet from one of my known neighbors, which
had switched to another schedule since I got its last SYNC packet, and I should
decrease the number of nodes on the schedule that this neighbor had switched from. But
at that time I had a DATA sending request, so I had to defer decreasing. And now is
time to do it.

Step 3: Update neighbor list. Check each record in my neighbor list to see whether its
active flag is set or not.

If yes, the flag is reset. (The flag will probably be set again when I get this
neighbor’s SYNC packet next time before my next time for neighbor list updating
arrives.)

If no, which means that I have not received the SYNC packet from this neighbor
node for a long time (at least a neighbor list updating period), this neighbor node
has to be deleted from my neighbor list. Accordingly, the number of nodes on the
schedule that the deleted neighbor used to follow should be decreased. If after
decrease the number becomes 0, this schedule has to be removed from my schedule
table.

Step 4: If the inactive neighbor nodes that I dropped in step 3 are on my primary
schedule, I have to execute check_my_schedule, which has been introduced in Table 2.4
Part 2.

Step 5: Reset the timer to schedule next neighbor list updating and enable receiving new
requests from the upper layer again.

Now we explain the reason why the period for updating neighbor list must be longer
than the period for synchronization. Fig. 2.6 shows an example, which has two
neighboring nodes A and B. We assume the period for updating neighbor list is smaller
than synchronization period, and A can always receive SYNC packets from B
18

successfully. We can see from the figure that A executes neighboring list updating twice
in one synchronization period for B. It is easy to imagine that, at the second updating
time for A (red arrow), A thinks that B has not been active recently and removes B from
its neighbor list, because A has not got B’s SYNC packet since last time when it
updated its neighbor list. B will become unknown to A until B’s next broadcasting time
comes. In this blank period, A cannot talk to B, because it takes it for granted that B is
not active. However, this is not true, because B keeps active all the time.

A
Neighbour List Blank
Updating Period for B

B
Synchronization Period

A updates B A deletes B B Broadcasts SYNC Packet

Fig. 2.6. Neighbor list updating period smaller than synchronization period

2.4 CSMA/CA in S-MAC

S-MAC achieves energy saving mainly by utilizing the schedule mechanism. The
schedule controls nodes’ periodic sleep and listen. From this point of view, S-MAC
looks like a schedule-based MAC protocol, e.g. TDMA. However, with respect to
transmission control and collision avoidance, S-MAC is more like a contention-based
MAC protocol, especially like the DCF (Distributed Coordination Function) in IEEE
802.11 protocols. In this section, we will introduce the CSMA/CA mechanism in S-
MAC, including carrier sense (including physical and virtual mechanisms) and
RTS/CTS mechanism for collision avoidance and hidden station problem.

2.4.1 Carrier Sense

Like DCF in 802.11, carrier sense in S-MAC is performed both through physical and
virtual mechanisms. The medium is determined as free only when both of them indicate
that it is free.
Physical carrier sense is performed at physical layer by checking the current radio
state. Every time when the radio starts receiving or transmitting, the PHY layer will
inform the MAC thereof. It happens also when the receiving or transmitting is over.
 19

Obviously, the medium will be determined as busy when radio is in receiving or

transmitting state.
Virtual carrier sense is performed at the MAC layer. We know that in 802.11, each
station maintains a so-called network allocation vector (NAV), which is actually a
counter. It will count down to zero at a uniform rate after it is assigned with a certain
value. NAV mechanism requests that each packet sent by MAC contains a duration
field, which indicates how long the current transmission will last. When a node receives
a packet destined to another node, the duration value in the packet will tell the node how
long it has to keep silent. The node’s NAV will be updated with the duration value, only
if the duration value is larger than the current NAV value. Virtual carrier sense indicates
that the medium is idle, when the NAV value is zero. When non-zero, the indication is
busy.
The similar virtual carrier sense mechanism is also applies to S-MAC. However,
unlike that in 802.11, S-MAC defines two NAVs. One is simply called NAV and used to
indicate if the medium is busy or not, just the same as in 802.11. The other one is called
Neighbor NAV, which tracks its neighbors’ NAV. Only when both of the NAVs have
counted down to zero, the virtual carrier sense indicates the medium is free. The
structure of and the way of running for two NAVs are quite similar. Table 2.5 lists all
events that make two NAVs update their values. If not mentioned, the duration value
used to update the NAV value is always the duration value in the packet that is received
or sent in corresponding event.

Table 2.5. Differences between NAV and Neighbor NAV

NAV Neighbor NAV

Receive RTS destined to other node Receive RTS destined to me
Receive CTS destined to other node After CTS is sent out (for DATA
timeout)
Receive DATA destined to other Receive DATA destined to me
node
Receive ACK destined to other node After DATA (unicast) is sent out
Error found in received packet, NAV After ACK is sent out
is updated by an EIFS value
Collision detected when the radio is ACK timeout, but not reached
receiving a packet and another maximum number of times to extend
packet arrives, NAV will be updated Tx time
by an EIFS value right after the radio
finishes receiving

From the above table, we can see that one node uses its NAV for virtual carrier sense
when it interferes in one of its neighbor’s transmission, and uses its Neighbor NAV
when it is either a sender or a receiver during a transmission process. Besides their
20

functions for virtual carrier sense, the NAVs also play other roles in S-MAC listed as
below.

1. Neighbor NAV will act as a timer for DATA timeout on the node, which has sent
out the CTS packet and is waiting for the arrival of the DATA packet.

2. Adaptive listening (to be introduced in latter parts of this chapter) will be triggered
when either of the two NAVs counts down to zero.

S-MAC obtains a transmission chance through contending for the medium in a

contention window. Going back to Fig. 2.2, we find that there are two contention
windows defined in one frame. One is for sending SYNC packets in the SYNC period
and the other is for sending DATA packets in the DATA period. Both contention
windows have fixed size (fixed number of slots), which must be 2n-1, e.g. 31 slots for
SYNC and 63 for DATA. Actually, S-MAC can have a third contention window in the
sleep period, if adaptive listening is applied (We will discuss adaptive listening in
section 2.7). Here we consider only S-MAC without adaptive listening. Now we take a
simple example and see how carrier sense is performed before sending a SYNC packet
in the SYNC period. The following steps are also applicable to sending a DATA packet
in the DATA period.
When the schedule timer expires at the end of the sleep period indicating the coming
of a new SYNC period, it will check the conditions for sending a SYNC packet. If the
syncFlag on this schedule is set and both of the NAVs have zero values (virtual carrier
sense indicates free medium), the node will be ready to broadcast a SYNC packet. If the
radio is in sleep state, it will be awoken first. Then the node starts physical carrier sense.
The duration for carrier sense is chosen uniformly within the contention window and
consists of a DIFS. One of two following possibilities may happen during this period.

1. If nothing is heard throughout the whole carrier sense period, the node will assume
that the medium is free and start transmitting the packet right away.

2. Once the medium is sensed busy during the carrier sense period, the node will stop
sensing and defer sending the packet. When the same period in the next frame
arrives, the node will retry sending. While retrying, it will follow the same
procedures described above.

In the above discussion, S-MAC always chooses the number of slots for carrier sense
within the fixed contention window size, uniformly and independently. This is not like
the binary exponential back off introduced in 802.11.
 21

2.4.2 Collision Avoidance

We know that the RTS/CTS mechanism defined in the DCF can efficiently reduce the
durations of collisions and solve the so-called hidden station problem. This medium
reservation technique has been introduced into S-MAC. Prior to the actual DATA
packet, the sender should exchange RTS and CTS packets with the receiver. But only
unicast packets follow the sequence of RTS/CTS/DATA/ACK. Broadcast packets will
be sent without using RTS/CTS. In this sub-section, we discuss unicast packet only.
We have learnt that the virtual carrier sense mechanism introduced in subsection
4.2.1 is achieved by distributing reservation information announcing the impending use
of the medium. And the reservation information is recorded in the duration field of
RTS/CTS/DATA/ACK packets. RTS/CTS packets will reserve for the whole
transmission process. All immediate neighbors of both the sender and the receiver will
learn the coming transmission from the RTS or CTS packets and will keep silent during
the reserved period. Although the combination of carrier sense and RTS/CTS
mechanisms can largely reduce the probability and durations of collisions, collisions
cannot be completely avoided. If two neighboring nodes finish carrier sense and start
sending at almost the same time, collision will occur. We take a simple example to see
how S-MAC sends a data packet out and assume that the channel is ideal (no corruption
case).
Consider two neighboring nodes A and B, which follow the same schedule and have
discovered each other. A receives a sending request destined to B from the upper layer.
We also assume that A does not have any other sending request at present. The carrier
sense does not start immediately and needs to wait until the next DATA period comes.
A will follow the steps described in last sub-section to start carrier sense.
Fig. 2.7 below shows one possible case. We can see from the figure that A and B
exchange RTS/CTS within the DATA period and use their scheduled sleep time for the
data packet transmission. Actually the length of DATA period is carefully designed. It
is fixed according to some physical-layer and MAC layer parameters, e.g. the radio
bandwidth and the contention window size. S-MAC has one feature in the DATA
period that no matter how many slots for carrier sense have been chosen from the fixed
size contention window, the exchange of RTS and CTS can always be done within the
DATA period if no collision and corruption occurs. But the transmission of the DATA
packet normally needs to be extended to the schedule sleep period. Normally, S-MAC is
working under a relatively low duty cycle (e.g. 10%). The sleep period in a frame is
much longer than the DATA period. So in normal cases, the whole transmission process
can be done in one frame and will not be prolonged to the next SYNC period. In the
following example, the transmission between A and B ends before the next SYNC
period. If adaptive listening is not applied, both A and B will still have time to sleep.
22

Carrier Tx Got Tx Got

A Sense RTS CTS DATA ACK

Got Tx Got Tx
B RTS CTS DATA ACK

Schedule DATA Period Sleep Period SYNC

Fig. 2.7. A successful data transmission between two nodes

Now we see what will happen when collision occurs. If B also sent out the RTS at
almost the same time when A sent the RTS out, two RTS packets collide. Neither of
them will receive the RTS packet from the other and send a CTS packet back. After a
short wile, A’s CTS timer expires. If now A’s primary schedule is in the sleep period, A
will go to sleep by turning its radio off. When the next DATA period on the same
schedule comes, A will resend the RTS. The maximum number of RTS retries for
sending a DATA packet is user-adjustable in S-MAC. When the retry times reach the
maximum number, A will give up sending the DATA packet and signal its upper layer
about the failure of sending. The same procedures will be followed when B’s CTS
timeout timer expires.

2.5 Overhearing Avoidance

For contention-based protocols like IEEE-802.11, overhearing is one of the major
sources of energy waste. Overhearing takes place on a node when it receives some
packets that are destined for other nodes. In 802.11, measures like latency and
bandwidth utilization are considered in the first place. To achieve better performance in
a shared-medium network, carrier sense, especially virtual carrier sense should be
performed more efficiently. The best way to achieve it is to let each node keep listening
to all its neighbors’ transmissions. Obviously, this method will lead to large amounts of
energy consumptions on overhearing, especially when node density is high and the
traffic load in the network is heavy.
For S-MAC, saving energy is its primary goal. To avoid overhearing, S-MAC forces
interfering nodes to go to sleep after they receive an RTS or a CTS packet that is not
destined for them. In this way, nodes that interfere their neighbors’ transmissions will
not hear DATA packets, which normally take much longer transmission time than
control packets, and following ACK packets. We take an example in Fig. 2.8 to
illustrate this algorithm.
 23

RTS RTS

E C A B D F

CTS CTS

Fig. 2.8. C and D overhear the transmission between A and B

The above figure shows a five-hop linear network. Each node can only hear its
immediate neighbors. We assume that all the nodes share the same schedule. Suppose A
is communicating with B in the same way that we discussed in Fig. 2.7. We first see
which nodes should go to sleep during this transmission.
We know that collision only happens on the receiver side. Obviously, D is supposed
to go to sleep, because its transmission interferes with B’s reception of the DATA
packet. C is two hops away from B, so C’s transmission will not interfere with B’s
reception. But if C talks to E while A is sending data to B, C will not receive any packet
from E because collision happens on C. C’s transmission is a waste of energy and it also
needs to go to sleep. Both E and F are at least two hops away from the nodes that are
transmitting, and they will never produce interference. Therefore, E and F have no need
to sleep. In a word, those nodes that are the immediate neighbors of the sender or the
receiver should go to sleep.
Now we discuss when C and D should go to sleep. We first see C, who is A’s
immediate neighbor. C can hear the RTS packet that A sends to B. However, C does not
go to sleep after receiving the RTS, because at this moment the communication has not
been really set up and may be cancelled for some reason, e.g. collision on RTS packets.
Therefore, it has to keep listening for a CTS timeout period to see if it can hear the
following CTS packet. If C receives the CTS packet, it will go to sleep right now.
However, in this example, C cannot hear the CTS that B sends back to A. Therefore,
after the CTS timeout period, C will keep listening for another CTS timeout period and
try to hear the DATA packet. As soon as C hears the DATA packet, it knows from the
duration field in the DATA packet that how long exactly the current transmission will
last and goes to sleep right now. If no DATA packet is heard in this period, C will go to
sleep only when C’s primary schedule is now in the sleep period. For D, who is B’s
immediate neighbor, it can only hear the CTS packets sent by B. D will go to sleep right
after it gets the CTS and updates its NAV with the duration value in the CTS and goes
to sleep right after receiving the CTS.
24

2.6 Message Passing

Except that overhearing leads to energy waste in contention-based protocols like IEEE
802.11, control packet overhead will be another reason. Control overhead means cost
(energy or time) spent on exchanging control packets (RTS/CTS/ACK) when unicasting
a data packet. In this section, we talk about how S-MAC reduces energy consumptions
caused by control overhead.
We know that transmitting a long message using a single data packet through a lossy
channel is hazardous and riskful. Even when a few bits in the packet are corrupted
during the transmission, the whole packet must be re-transmitted. This will waste a lot
of time and energy. Therefore, some MAC protocols like 802.11 support a
fragmentation mechanism, which breaks a long message into some small fragments. All
fragments are sent in a burst, and using one pair of RTS/CTS, if none of them is
corrupted. If one of the fragments is corrupted, another pair of RTS/CTS is needed.
When receiver has gotten all fragments, its MAC is responsible for assembling all the
fragments into a whole and passing it upwards.
S-MAC adopts a modified fragmentation mechanism for transmitting a long message,
called message passing. Its basic idea is to fragment a long message into many small
fragments and send them in a burst. This means only one pair of RTS/CTS is used for
all fragments, but the receiver should acknowledge each fragment it receives. RTS and
CTS reserve the medium for transmitting all the fragments. When one of the fragments
is corrupted during transmission, ACK timeout will happen on the sender side. The
sender has to extend the reserved transmission time for one more DATA/ACK pair and
resend the lost fragment immediately. S-MAC sets a limit on how many extensions can
be made for one message. This prevents some nodes from occupying the medium for
too long in some special cases, e.g. the receiver loses its connection with the sender
during the transmission.
As for neighboring nodes that may interfere with the ongoing transmission, they will
follow the same way described in section to go to sleep after they hear the RTS or CTS.
However, some special cases may happen. For example, the neighboring nodes miss the
chance of receiving the RTS or CTS for some reason, e.g. they were sleeping at that
time, and they wake up afterwards. Or a new node happens to join the network in the
middle of the transmission. Then what should these nodes do in these cases? Actually in
S-MAC, besides RTS and CTS, both DATA fragment and ACK packets have the
duration field, which is now the time needed for transmitting all the remaining data
fragments and ACK packets. Fig. 2.9 illustrates how to set duration value (NAV value)
for each packet in the transmission of a 3-fragment message in a burst. So no matter
which of them is received by the interfering neighbor nodes, they will know the time the
current transmission will last and how long they should sleep. This is also the reason
why S-MAC requests the receiver to acknowledge each DATA fragment that it receives.
Using the Fragment/ACK pair in message passing resembles the RTS/CTS pair in the
way it solves the hidden station problem. Sending the ACK frequently will make the
 25

neighboring nodes, which can only hear the receiver, update their NAVs in time. For
example, again in Fig. 2.8, D goes to sleep right after it has received the CTS from B.
However, one fragment is corrupted during the transmission and the original reserved
time for the whole transmission has to be extended. When the original reserved time is
over, D may wake up from sleep. It will know the extended transmission time from the
ACK packet and go to sleep again.

SIFS SIFS SIFS SIFS SIFS SIFS SIFS

RTS Fragment 0 Fragment 1 Fragment 2
Sender

CTS ACK 0 ACK 1 ACK 2

Receiver
NAV (RTS)
NAV (CTS)
NAV (Fragment 0)
NAV (ACK 0)
NAV (Fragment 1)
NAV (ACK 1)
NAV (Fragment 2)

Fig. 2.9. RTS/CTS/DATA/ACK and NAV settings in message passing

From the above discussion, we find that the message passing mechanism in S-MAC
can effectively reduce the control overhead in transmitting a long message, by sending
all fragments in a burst and using only a pair of RTS/CTS for it. When the sender fails
to get an ACK for any fragment, message passing will provide some opportunities for
re-transmitting the lost or corrupted fragment, instead of giving up the transmission
immediately and re-contending for the medium. This approach seems to be unfair to
those nodes that have a short message to send. However, in this way, application-level
performance for each node can be improved greatly, if compared to the traditional MAC
protocols. That is what sensor networks desire.

2.7 Adaptive listening

In this section, we introduce adaptive listening, which is one of the most important and
attractive features in S-MAC. In the previous sections, we have mainly discussed how
S-MAC reduces energy consumptions. Among those techniques, the scheme of periodic
listen and sleep contributes the most. On the other hand, the schedule mechanism will
increase the latency of sending packets in a multi-hop network. Although both
synchronization mechanism and message passing mechanism have decreased the
latency to a certain degree, adaptive listening is the dominant technique that S-MAC has
proposed to efficiently and largely reduce the latency in a multi-hop transmission.
Let us look at an example to see how S-MAC transmits a packet in a three-hop linear
network. Suppose there are four nodes A, B, C, and D, which are put in a line, as shown
26

in Fig 2.10. Each node can hear only its immediate neighbors. A is the source and D is
the sink. Now a data packet is generated at the source node and destined to the sink
node. We assume all nodes share the same schedule and no message passing technique
is applied.

Source Sink
A B C D

Fig. 2.10. A three-hop network with one source and one sink

We first see the case shown in Fig. 2.11. When adaptive listening is not employed,
each node has at most one chance to send the data packet out in each frame, because
checking to send the data packet only takes place at the beginning of each DATA period.
If the arrival of the data packet at a certain node misses this checkpoint of this frame, it
has to wait until the next DATA period comes. That is to say, when each node strictly
follows its sleep schedule, there is a potential delay on each hop. We can see from the
Fig. 2.11 that we need three frames to transmit the data packet from the source A to the
sink D. The data packet travels only one hop in each frame.

R Data
A

C A R Data
B

C A R Data
C

C A
D

S D Sleep S D Sleep S D Sleep

Schedule
Frame n Frame n+1 Frame n+2

R C Data A S SYNC Period D Scheduled DATA Period

RTS CTS DATA ACK

Fig. 2.11. Transmitting a data packet through a three-hop network,

without adaptive listening

Now we consider the case if adaptive listening is applied. The basic idea is that at the
end of one transmission, S-MAC will give those nodes, which are involved in this
transmission including sender, receiver, and neighbors of both them that overhear this
transmission, another chance of transmitting data packets. In this way, one node may
 27

have two DATA periods for sending or receiving data packets in a frame. We use Fig.
2.12 below to illustrate how adaptive listening functions in S-MAC.

R Data
A

C A R Data
B

Sleeping C A R Data
C

C A
D

S D ALP S D Sleep S D Sleep

Schedule
Frame n Frame n+1 Frame n+2

R C Data A S SYNC Period D

RTS CTS DATA ACK Scheduled DATA Period

ALP Adaptive Listen Period Packet transmitted in adaptive listening

Fig. 2.12. Transmitting a data packet through a three-hop network,

with adaptive listening

We start with the transmission between A and B. As shown in Fig. 2.12, transmitting
the data packet from A to B (including carrier sense and exchange of RTS/CTS) starts
from the scheduled DATA period and extends to the following sleep period. We have
known from the previous sub-section 2.4.1 that both the sender A and the receiver B
will use their Neighbor NAVs to perform virtual carrier sense, while C is overhearing
this transmission and will use its NAV for virtual carrier sense. Both NAV and
Neighbor NAV contain the same value, which is the time reserved for the current
transmission. The expiration event of those NAVs (count down to zero, indicating the
end of the current transmission) will trigger the execution of adaptive listening on their
owner nodes. The following universal steps will be executed when adaptive listening is
triggered at a certain node.

1). Check if the remaining time in current frame (from now to the next listen time) is
shorter than a DATA period. If yes, give up executing the following steps and exit.
Otherwise, go step 2.
The reason for executing this step will be explained later in this section. And we
assume the example in Fig. 2.12 satisfies this condition.

2). Set a timer (called adaptive listening timer) to bring me back to sleep (if conditions
allow me to sleep at that time). The expiration time for the timer is equal to a DATA
period (here called adaptive listening period, see the green box in Fig. 2.12).
28

3). If I am still sleeping, I have to wake up now.

This may happen to the node, such as C in Fig. 2.12, which is sleeping because it
overheard its neighbor’s previous transmission.

4). Check if the flag txData on my primary schedule is set (that is to see if I have a
buffered unicast data packet to send on my primary schedule). If yes, I will try to send
out the data packet by following the same way I do in the schedule DATA period
(described in section 2.4). Otherwise I have to keep awake, because my neighbors, who
are also adaptive listening now, may want to talk to me.
Please notice that broadcast data packet will never be sent when I am adaptive
listening, because I am not sure whether all my neighbors are also adaptive listening
now. Some of my neighbors may not be aware of the previous transmission that I was
involved in, so they do not execute adaptive listening as me and may be asleep now.
For the example shown in Fig. 2.12, only B satisfies the sending condition, because it
just got the data packet from A that needs to be retransmitted to C. After exchanging
RTS/CTS with C successfully, B transmits the data packet to C, as shown in the red box
in Fig. 2.12. For A, it has nothing to send and has to keep awake. But it will hear the
RTS that B sends to C. So A has to go to sleep to avoid overhearing the transmission
between B and C.

5). The adaptive listening timer set in step 2 expires. If I am still awake only because I
have nothing to send and hear nothing during this adaptive listening period, now I will
go back to sleep again.
For the example in Fig. 2.12, no node goes to sleep for such reasons stated above.
Both B and C are impossible, because B is transmitting to C. And A overheard this
transmission and may have gone to sleep before its adaptive listening timer expires.

Now we explain why S-MAC checks the remaining time in the current frame before
starting adaptive listening. From the above discussions, we see that the essential of
adaptive listening is to add another DATA period (adaptive listening period) in the
scheduled sleep period, so that nodes can obtain an additional chance for sending or
receiving data packet. And we do not want to see the adaptive listening period overlap
the next coming SYNC period, because this may interfere with the transmission of the
SYNC packets. So that is the reason. But we have to realize one fact, that is, even if the
adaptive listening period is located exactly inside the sleep period, the transmission may
extend to the next SYNC period. One example for such cases is shown in Fig. 2.13. So
we can say only that making the adaptive listening period not overlap the next SYNC
period is to give the priority to the SYNC packets, but adaptive listening does not assure
that it never collides with the next SYNC period.
 29

R Data
A

C A R Data
B

Sleeping C A
C

S D ALP S D
Schedule
Frame n Frame n+1

Fig. 2.13. Adaptive listening extends to the next frame

From the above discussion, we see that adaptive listening can greatly reduce the
latency caused by the periodic sleep of each node in multi-hop networks. Consider one
data packet, which is to be transmitted through a multi-hop network. When adaptive
listening is not applied, the data packet can jump only one hop in a frame time. When
adaptive listening is applied, the data packet can be retransmitted to the next-hop node
immediately after its last transmission is over.
It should be mentioned that theoretically the range of adaptive listening is limited to
one hop, because we assume that neighbors that are two hops away cannot hear each
other. Under this assumption, one data packet is able to jump at most two hops in a
frame time. We use Fig. 2.14 to illustrate this problem. At the end of the transmission
between A to B, the adaptive listening is triggered and B starts to retransmit the data
packet to C. As happened before, at the end of the transmission between B and C, a
second adaptive listening will be triggered. We assume that the remaining time from
now to the next listen time is long enough to accommodate an adaptive listening period.
Now C tries to retransmit the data packet to D and sends out a RTS packet after carrier
sensing. But obviously D is sleeping, because D has not been aware of the adaptive
listening that has happened to its neighbors. So C will encounter a CTS timeout and
have to wait until the next DATA period comes.
30

R Data
A

C A R Data
B

Sleeping C A R Sleeping R Data

C

Sleeping C A
D

S D ALP ALP S D Sleep

Schedule
Frame n Frame n+1

R C Data A S SYNC Period D

RTS CTS DATA ACK Scheduled DATA Period

ALP Adaptive Listen Period Packet transmitted in adaptive listening

Fig. 2.14. Adaptive listening triggered twice in a frame

 31

Chapter 3
The Network Simulator

3.1 What is NS-2

NS-2 (Network Simulator version 2) is an object-oriented, discrete-event-driven
network simulator targeted at networking research, which has been extensively used by
the networking research community. The latest version for ns-2 is version 2.28, which is
available on the ns-2 homepage [13].
Ns-2 is a powerful network simulator. It provides substantial support for simulation
of TCP, routing, multicast protocols over wired and wireless (local and satellite)
networks, etc. Users can define arbitrary network topologies composed of nodes, routers,
links and shared medium. A rich set of protocol objects can then be attached to nodes,
usually as agents. The simulator suite also includes a graphical visualizer called network
animator (Nam) to assist the users get more insights about their simulation by
visualising packet trace data.
Ns-2 is written in C++, with an Otcl interpreter as a frontend. Otcl is an object-
oriented variant of the well-known scripting language tcl. C++ is utilized for per-packet
processing and forms the core of the simulator. Otcl is used for simulation scenario
generation, periodic or triggered action generation and for manipulating existing C++
objects.
Ns-2 is open-source software and free to use for all users. Due to its open source
nature, a user can modify parameters at different layers, create his or her own
applications, and develop new protocol. The freeware nature of ns-2 makes it very
attractive to students and network researchers and ideal for study and research purpose.
32

3.2 How to Get Started

NS-2 is powerful and attractive for every network user and researcher. But if you are a
first-time user, you may find ns-2 is not easy to get started. Even though you can search
out large amounts of ns-related documents on the Internet, which are written usually by
experienced ns users or developers, most of them are quite obscure and not friendly to
new users. So the purpose of this section is to share my experience in getting ns-2
started.
Since ns is an object-oriented simulator written in both C++ and Otcl, you should
know at least one object-oriented programming language, like C++ or Java. Do not
worry if you only know C++ but never used or heard of Otcl, because writing some
simple simulation scripts in Otcl will not be difficult for a C++ user. But if you are
already an experienced C++ programmer, you will find a lot of fun in using ns-2,
because the greatest fun in ns-2 is to debug or write C++ source code. In addition, it
would be a great help, if you know Perl or any other languages good at processing data
file, because ns requires users to extract simulation results by themselves. And how to
extract your desired information from a huge trace file correctly and efficiently is also a
considerable problem especially when you plan to use ns to simulate a huge network
system and have large amounts of data to analyze.
The first guide documents worth recommending for ns beginners are “Marc Greis's
tutorial” and “ns by Example”, which can be found on the ns-2 homepage [13]. These
two tutorials are especially written for new ns users and will give you an idea about how
ns-2 looks like and works. You would better not jump to read Ns Manual (the ns-2
official reference) if you do not have any preliminary knowledge of ns, because this
manual is not a tutorial for beginners. The ns manual is more like a technical document,
which mainly helps ns users or developers deeply understand how each internal
component of ns-2 is organized and developed. It will be one of the most valuable
documents you should read and put at hand, after you have become a little familiar with
ns and want to go deeper into ns-2.
Before you start to write your own tcl script, you had better first check the example
folder of ns-2 to see if there are some example scripts that have similar configurations
with yours. The example folder is located in, e.g. ns-2.28 \tcl\ex\, where you can find a
lot of example scripts for all kinds of simulation scenarios. Besides the example folder,
there also exists a test folder under the path, e.g. ns-2.28\tcl\test\, where many test
scripts can be found. Those test scripts can be executed to verify the correctness of the
installation of ns-2. Normally when a new protocol or module is developed or
implemented in ns-2, the ns-2 developer or programmer will write such a test script for
it. And this test file will be the best example, which can tell us how to configure ns-2 to
simulate this new protocol or module.
If you are studying a new protocol with ns-2, reading and understanding, its source
code in ns-2 is necessary. No bug, no code. So debugging work should be performed
carefully before you start your experiments. Do not forget to check the ns-2 homepage
 33

to see if there is a new updated version available. Though ns-2 formal release version is
not likely updated frequently, there will be small updates in daily snapshot. Minding the
homepage of the group that is responsible for developing this protocol or join the
mailing list or forum the research group provides can make you synchronize with the
latest development of the topic you are studying.
You are suggested to subscribe to ns-users mailing list, if you want to communicate
with other ns users throughout the world. Especially when you encounter a hard
problem, to which you cannot find out a solution even in all documents you have
checked (ns-2 is such a huge system that you are very likely to encounter such
problems), the mailing list is the first place where you should go for help. If you do not
like to receive tens of mails sent by the mailing list everyday, you can directly use the
search function provided by the ns official web site, which can be linked from the ns
homepage (the link is at the bottom of that page, named “Search ns web pages”). There
you can search the contents of all the publicly available WWW documents and mailing
list archives at Ns and Nam's site. No matter in mailing list or on search web, quite often
you can get a surprise and find what you want there. For S-MAC users, a mailing list for
discussing or announcing S-MAC related problems has also been created. The web page
for subscribing to S-MAC mailing list is http://mailman.isi.edu/mailman/listinfo/smac-
users.
34

Chapter 4
Simulating S-MAC with NS-2

4.1 S-MAC in NS-2

4.1.1 Implemented S-MAC Features

S-MAC is developed based on the Mote platform that runs TinyOS and its
implementation in TinyOS reflects the latest protocol development. But as a hardware
implementation, which needs real hardware as its running platform, it is not suitable for
us to study S-MAC in a simulation way. S-MAC has been also implemented in ns-2, the
network simulator. The latest official release is integrated in ns-2.28. If you want to use
the most recent updated and debugged version, you have to download a new ns-2 daily
snapshot or update to the latest CVS. More information about the updating of ns-2 and
S-MAC can be found on the ns-2 homepage [13].
In this thesis, we study S-MAC with ns-2 and install the ns-2.28 all-in-one version on
the SUSE Linux system (Professional 9.2). After installation, the source files (in C++)
for S-MAC, smac.h and smac.cc, can be found in the path ns-2.28\mac\.
Most of the features proposed in the paper [2] have been implemented in this version.
But, this version is still not the final version for S-MAC, because we found a portion of
code still in testing. We call this portion code JOUNAL_PAPER code, because a macro
named JOURNAL_PAPER controls compiling this portion code. By default, the
definition statements for this macro are disabled in the S-MAC header file and
JOURNAL_PAPER code will not be compiled when we install ns-2.28. For our
purpose of study, we have to consider JOURNAL_PAPER code, because it implements
some important features of S-MAC, such as adaptive listening and message passing. We
list all features of S-MAC that have been implemented in ns-2-28 as follows. The
detailed descriptions of these features have been presented in chapter 2.
 35

Basic features

Listen and sleep periodically according to schedules

Both physical and virtual carrier sense
Overhearing avoidance
RTS/CTS mechanism for unicast data packets
Synchronization algorithm (including schedule choosing, schedule updating and
maintaining)
Neighbor discovery

Features in JOURNAL_PAPER code

Adaptive listening
Message passing (partially implemented)
Improved synchronization algorithm
Neighbor list updating
Global schedule algorithm (not to be discussed in this thesis)

4.1.2 S-MAC Parameters Settings

All preset parameters for S-MAC can be found and modified in the header file smac.h,
including user adjustable S-MAC parameters, internal S-MAC parameters, and physical
layer parameters. Some other parameters will be assigned at the start of the simulation
run, because their values depend on some interactive parameters. For example, the sleep
time and cycle time (frame time) depend on the value of duty cycle that users have set
in the tcl script. We call those parameters, which can be set in tcl scripts in an
interactive way, interactive parameters. All three interactive parameters are listed in
Table 4.1 below.

Table 4.1. S-MAC Interactive Parameters

Name Comment
syncFlag_ If it is set to 1, S-MAC runs with periodic sleep. If it is set to 0, S-
MAC runs without periodic sleep.
dutyCycle_ The value of duty cycle in percent. It controls the length of sleep.
If not set, ns-2 uses the default value 10%. This parameter is
active only when syncFlag_ is set to 1.
selfConfigFlag_ If it is set to 1, all S-MAC nodes follow the schedule initialization
algorithm described in section 2.3.
If it is set to 0, the schedule start time (first listen period start
time) for each node is user-configurable.
36

4.1.3 S-MAC Modes

For the purpose of comparison, S-MAC can be configured to run under three modes,
which are listed as below:

Mode 1: S-MAC without periodic sleep

If the parameter syncFlag_ is set to 0, S-MAC will work under this mode. In this mode,
each node does not follow periodic sleep and listen cycle and runs in a fully active mode.
But overhearing avoidance is still available in this mode. That is, the node will go to
sleep when it overhears its neighbor’s transmission. Please note that in ns-2.28, we
cannot set S-MAC to this mode in the case of JOURNAL_PAPER defined.

Mode 2: S-MAC with periodic sleep, but without adaptive listening

If the parameters syncFlag_ is set to 1 and JOURNAL_PAPER code is not compiled, S-
MAC will work in this mode. In this mode, only the basic features listed in sub-section
4.1.1 are available. No adaptive listening and message passing are available in this
mode.

Mode 3: S-MAC with periodic sleep and adaptive listening.

If we compile JOURNAL_PAPER code in S-MAC source code and set syncFlag_ to 1,
we can simulate all features of S-MAC, such as adaptive listening and message passing,
listed in sub-section 4.1.1.

4.1.4 Problems and Bugs of S-MAC in NS-2.28

We have found the following problems and bugs for S-MAC in ns-2.28.

Segmentation error

As mentioned before, we cannot set S-MAC to mode 1 in the case of

JOURNAL_PAPER defined. If we use the JOURNAL_PAPER code and then set the
flag syncFlag_ to 0, a segmentation error will occur during the simulation run. The
reason is that the JOURNAL_PAPER code is not designed to support S-MAC running
in mode 1. That is to say, we cannot simulate S-MAC in mode 1 if JOURNAL_PAPER
is used. In other words, if we simulate S-MAC in mode 1, some features like message
passing, which are only available in the case of JOURNAL_PAPER defined, will not be
supported.
 37

Constant data packet size at MAC layer

When you run S-MAC without using the JOURNAL_PAPER code, you may take
notice of such a confusing phenomenon. S-MAC will send all data packets with a
uniform size, regardless of their actual payloads. Checking the source code of S-MAC,
you will find that it defines a macro called SIZEOF_SMAC_DATAPKT. The default
value of this macro found in smac.h is 50 (Bytes). When S-MAC is sending or receiving
a data packet, S-MAC always uses this macro value, instead of the packet’s actual
payload, to calculate the duration for transmitting this packet. Obviously this is
unreasonable. But we do not think this is a bug for S-MAC, because it seems to be an
author’s temporary solution. It would not be a difficult task for us to fix this problem.
But we do not change it, because we are not very clear about the author’s real intention.
In our simulations with message passing disabled (JOURNAL_PAPER not compiled),
we can simulate S-MAC using CBR traffic source with different packet size, by directly
modifying the value of SIZEOF_SMAC_DATAPKT (need to recompile S-MAC before
running).
But if JOURNAL_PAPER code is compiled and message passing is enabled, the
situation will be different. For message passing, see below.

One problem in message passing

The message passing mechanism has been implemented in JOURNAL_PAPER code.

For simplification, S-MAC in ns-2 divides a long message into an integer number of
equal-size fragments. The equal fragment size is SIZEOF_SMAC_DATAPKT. The
code for calculating the number of fragments can be found in the method
SMAC::sendMsg(Packet *pkt, Handler *h) in smac.cc and listed as below.

int fragNum = ch->size_ / SIZEOF_SMAC_DATAPKT ;

if (fragNum == 0) fragNum = 1;

In above code, ch->size_ stands for the actual payload of the packet. The number of
fragments is calculated by a division operation and the result is converted to an integer
number forcibly. Obviously in this way, some information in the message may get lost
during the fragmentation process. For example, if payload is 120 Bytes and
SIZEOF_SMAC_DATAPKT is 50 Bytes, we get only 2 fragments with size 50 Bytes
each. So we replaced the above code with the following.
38

int fragNum = ch->size_ / SIZEOF_SMAC_DATAPKT ;

if (ch->size_ % SIZEOF_SMAC_DATAPKT != 0) {
fragNum ++;
}

After modification, a message with 120 Bytes will be divided into 3 fragments with
each 50 Bytes. It now seems more reasonable, although we have to send additional bits
for it.

Wrong value for neighbor list updating period

We have introduced periodical neighbor list updating in sub-section 2.3.5. The period
for updating neighbor list is defined by a macro SMAC_UPDATE_NEIGHB_PERIOD
in smac.h. Its default value is 50. Since this is just a number defined in the code, we
have to know its unit. According to the following code in the construction function
SMAC::SMAC() in smac.cc, it seems that the period is 50 seconds. (mhUpdateNeighb_
is the timer for updating neighbor list periodically)

mhUpdateNeighb_.sched(SMAC_UPDATE_NEIGHB_PERIOD);

But this is not a safe value, because it may result in unexpected errors. In subsection
2.3.5, we have explained the reason why the period for updating neighbor list should be
longer than the period for synchronization. The default value for synchronization period
is 10 frames, while the length of one frame depends on the value of duty cycle we use.
Table 4.2 below shows that when the duty cycle is 1%, the synchronization period is
longer than 50s.

Table 4.2 Synchronization period vs. Duty cycle

Duty cycle One Frame Length Synchronization Period

1% 11.221 s 112.21s
10% 1.123 s 11.23 s

So we have to change the period for the neighbor list updating from 50 s to 50 frames.
That is more reasonable, because it is 5 times longer than the synchronization period
and independent of the duty cycle. The modified code is shown as bolow.

mhUpdateNeighb_.sched(SMAC_UPDATE_NEIGHB_PERIOD*CLKTICK2SEC(cycleTime_));
 39

S-MAC callback missing

First, we talk about how S-MAC receives packets from its upper layer. Like other
MACs, S-MAC can only process a sending request at a time. So it needs a buffer for
storing packets from the upper layer. In ns-2, S-MAC is directly connected to a queue
module called Interface Queue (Ifq), which buffers packets from the link layer. The
queue size for Ifq is user-adjustable in ns-2, and we always use its default value 50 in
our simulations. Every time S-MAC has finished the current sending request (successful
or unsuccessful), it has to inform the Ifq about it (we call it callback in ns-2). Then the
Ifq dequeues a packet and passes it to S-MAC, if it is not empty. If the Ifq is empty now,
the Ifq will pass the packet to S-MAC as soon as it gets a new one from the link layer.
In a word, the workings for Ifq can be described as no asking, no sending. That is, if S-
MAC doesn’t do callback, Ifq will never send packets to it automatically. But we found
somewhere in the source file smac.cc that callback is missing, which may result in
occasional errors when running S-MAC.
Two such errors are found in the method SMAC::unicastMsg(int numfrags, Packet
*p), which will be called when S-MAC receives a new unicast packet from the Ifq. The
first error place is shown as below.

If (found == 0) {
printf ("Neighbor unknown; cannot send pkt\n");
txMsgDone(); // debug here, should signal upper layer before return
return 0;
}

The above code checks if the destination node that the received data packet is
destined for is in the neighbor list. If not, S-MAC will discard the packet and give up
sending. Obviously, a callback is missing here. The consequence is that once this
“Neighbor unknown” event happens for some reason, S-MAC will not receive any
packet from the Ifq from then on. In S-MAC, the callback is implemented in the method
txMsgDone(). So we must add this method before the return statement (code in red).
The second error place in the same method is shown as below. The same code as the
following can be found also in the method SMAC::bcastMsg(Packet *p).

if (txRequest_ == 0) {
txRequest_ = 1;}
else {
txMsgDone(); // debug here, should signal upper layer before return
return 0;}
40

The above code checks if the flag txRequest_ is set or not. If yes (indicating that S-
MAC already has a data packet to send), S-MAC has to discard the new received packet.
Similarly, a callback statement txMsgDone() is missing before return statement. You
might question the possibility of executing the else statements, because the Ifq will
never send new packets to S-MAC when S-MAC has not finished with the current
sending request. But there exists one exception, which has been discussed in sub-section
2.3.5. That is, S-MAC will temporarily disable receiving new sending request from the
upper layer (by setting the flag txRequest_ to 1), when it is ready to update neighbor list.

Different schedule starting time in JOURNAL_PAPER code

We have introduced the algorithm for S-MAC to choose the first schedule in subsection
2.3.2. When a new node does not hear any SYNC packet during the initial listening
period, it has to choose a schedule by itself. In S-MAC, choosing a scheduling means
choosing the starting time of the first listen period. The following code is extracted from
the method SMAC::setMySched(Packet *pkt) in smac.cc and will be executed for
choosing the node’s own schedule after the initial listening period.

if (pkt == 0) { // freely choose my schedule

#ifdef JOURNAL_PAPER
schedState_++;
mhCounter_[0]->sched(CLKTICK2SEC(listenTime_+index_*10));
schedTab_[0].syncNode = index_;
#else
mhCounter_[0]->sched(CLKTICK2SEC(listenTime_));
#endif
...

We can see that if JOURNAL_PAPER is not defined, all nodes start their first
schedules with a listen period. This means if we set the parameter selfConfigFlag_ to
one, there will always be one schedule in the network. All nodes share the same
schedule.
But if the JOURNAL_PAPER code is considered, the starting time of the first listen
period at different nodes will differ, depending on its index (node id). The purpose of
doing this for the S-MAC author is to introduce the scene of multiple schedules to S-
MAC simulations. An example for this case is shown in Fig. 4.1. We can see that the
starting time of the first listen period for different nodes is staggered. So this scene can
be used to simulate the scenario when nodes join the network at equidistant fixed
intervals.
However, the scene of multiple schedules is not involved in this thesis. So we delete
the parts in red colour in above code.
 41

0 Initial Listening Listen Listen

1 Initial Listening Listen Listen

2 Initial Listening Listen Listen

3 Initial Listening Listen Listen

Fig. 4.1. Different schedule for each node

4.2 Preparations for Simulating S-MAC

In this section, we introduce what modules we have added to ns-2 necessary for
simulating S-MAC.

4.2.1 NO Ad-Hoc Routing Agent (NOAH)

When we simulate a wireless network in ns-2, we should specify a routing protocol for
it. NS-2.28 has implemented four ad-hoc routing protocols for wireless simulations,
including DSDV (Destination-Sequenced Distance-Vector), DSR (Dynamic Source
Routing), TORA (Temporally Ordered Routing Algorithm), and AODV (Ad hoc On-
demand Distance Vector). Any one of these four routing protocols can be used to
simulate S-MAC. But for purpose of our study, we are only interested in the
performance of S-MAC, but not the routing protocols. To measure the performance of
S-MAC in a pure condition, we expect to use such a special routing protocol, which
provides static or manual routing mechanisms and will not produce any routing packet
after the simulation starts. Unfortunately, static routing and manual routing defined in
ns-2 are only available for wired simulations, but not for wireless simulations.
We found a third-party routing agent for ns-2, which accords with our desires. That is
the so-called no ad-hoc routing agent (NOAH), which is a wireless routing agent that
supports static multi-hop routing. NOAH is quite suitable for simulation scenarios
where routing packets are not desired. For more detailed information about installation
instructions and the usage of NOAH, please visit the web site listed in [12]. Although
this plug-in is claimed to work with ns-2.26, we found that it works quite well with ns-
2.28 as well.
42

4.2.2 Exponential Traffic Source Agent

In ns-2, traffic sources generate packets in the application layer at each source node.
Three traffic sources have been implemented in ns-2.28, including exponential on/off
traffic source, pareto on/off traffic source, and CBR (constant bit rate) traffic source.
However, we hope to generate packets with exponentially distributed inter-arrival times
and packet sizes when simulating S-MAC. Someone has developed a new traffic source
agent and we adapt it to our simulations, called EXPO_Traffic (its Otcl class name is
Application/Traffic/MyExponential). The source code is in the file expo_traffic.cc. We
will not go into details about the source code. The following steps show how to add this
new traffic generator to ns-2.

Step 1: place the source file expo_traffic.cc in ns-2.28/tools/

Step 2: add the following statements to the file ns-2.28/tcl/lib/ns-default.tcl (line 489)
Application/Traffic/MyExponential set interval_ 1
Application/Traffic/MyExponential set packetSize_ 100
Application/Traffic/MyExponential set maxpkts_ 268435456
Note: set default values for member variables. If we create a new object without
assigning these variables explicitly, ns-2 will use the default values set in ns-default.tcl.

Step 3: In the file /common/packet.h

Line 166, add:
PT_EXPO,
Line 206, add:
name_[PT_EXPO]= "expo";
Note: create a new packet type “expo” for this traffic source

Step 4: In the file ns-2.28/trace/trace.cc line 200, add:

|| t == PT_EXPO
Note: inform the trace agent of the new added packet type. And “expo” will be
displayed in the trace file.

Step 5: In the file ns-2.28/Makefile.in, in OBJ_CC (line 169), add:

tools/expo_traffic.o
Note: configure compilation path for the new source file

Step 6: Go to the directory ns-2.28/ and execute the following commands:

./configure
make clean
make
Note: to use the new traffic generator, we should recompile ns-2 first.
 43

The EXPO traffic generator has four generation modes.

Mode 1: AdPd (Deterministic inter-arrival time and deterministic packet size)
Mode 2: AePd (Exponential inter-arrival time and deterministic packet size)
Mode 3: AdPe (Deterministic inter-arrival time and exponential packet size)
Mode 4: AePe (Exponential inter-arrival time and exponential packet size)

And it defines two commands used to configure generation modes.

interval-exp If called, inter-arrival time conforms to exponential distribution.
If not, inter-arrival time conforms to deterministic distribution.
size-exp If called, packet size conforms to exponential distribution.
If not, packet size conforms to deterministic distribution.

The member variables that parameterize this agent are:

packetSize_ constant (Pd) or mean (Pe) packet size (default is 100Bytes)
interval_ constant (Ad) or mean (Ae) interval between packets (default is 1s)
maxpkts_ the maximum number of packets to generate (default is 268435456)

The following tcl code illustrates how to create an EXPO traffic source over a UPD
agent.

set expo [new Application/Traffic/MyExponential]

$expo set packetSize_ 500 # mean packet size, 500 Bytes
$expo set interval_ 1.0 # mean inter-arrival time, 1s
$expo set maxpkts_ 2000 # maximum number of packets to generate
$expo size-exp # packet size conforms to exponential distribution
$expo interval-exp # inter-arrival time conforms to exponential distribution
$expo set-seed 0 # set seed for random number generator
$expo attach-agent $udp # attach the EXPO traffic source to a UDP agent

4.3 An Example Tcl Script for Simulating S-MAC

To simulate S-MAC with ns-2, we must create a tcl script first. In this section, we
illustrate how to set up a tcl script for simulating S-MAC in ns-2.28. We take a ten-hop
linear network as an example, because most of our simulations run over this ten-hop
topology. The scenario for this example is described as below.

Topology: 11 S-MAC nodes form a ten-hop linear wireless network, as shown in Fig.
4.2. Each node can hear only its immediate neighbors. The first node (node 0) is the
source and the last node (node 10) is the sink.
44

Routing protocol: NOAH (NO Ad-Hoc Routing Agent)

Traffic pattern: Packets are sent from the source node to the sink node. Packets’ inter-
arrival times at the source node conform to an exponential distribution with mean value
10s. Packet size is fixed to 100 Bytes. The generator keeps generating until the end of
the simulation.

Scheduling: The generator starts generating at 60 s and stops at 2000 s.

Source Sink

...
0 1 2 ... 8 9 10

Fig. 4.2. Ten-hop linear network with one source and one sink

Normally a tcl script for wireless simulation starts with a list of tcl variables
definition statements. And we use those variables to store our parameters preferences
for the simulation. This is convenient for parameters management. Each parameter is
stored in a tcl variable using tcl command set.
Two classes of parameters are defined and listed as below. The node configuration
parameters specify the components that we want to simulate in each node and will be
used in later node configuration step. Running parameters include the trace file name,
the number of nodes to be created for simulation and the simulation running time.

# Node configuration parameters

set opt(chan) Channel/WirelessChannel ;# channel type
set opt(prop) Propagation/TwoRayGround ;# radio propagation model
set opt(netif) Phy/WirelessPhy ;# network interface type
set opt(mac) Mac/SMAC ;# MAC type
set opt(ifq) Queue/DropTail/PriQueue ;# IFq type
set opt(ll) LL ,# like layer type
set opt(ant) Antenna/OmniAntenna ;# antenna model
set opt(ifqlen) 50 ;# buffer size of IFq
set opt(adhocRouting) NOAH ;# routing protocol

# Running parameters
set sim(tr) trace.tr ;# trace file name
set sim(nn) 11 ;# number of nodes
set sim(stop) 100000.0 ;# simulation stop time
 45

The following code configures parameters for S-MAC. These S-MAC parameters
have been introduced in subsection 4.1.2.

Mac/SMAC set syncFlag_ 1 ;# enable sleep listen cycles

Mac/SMAC set dutyCycle_ 10 ;# S-MAC with 10% duty cycle
Mac/SMAC set selfConfigFlag_ 1 ;# disable user-configurable schedule

The following steps are quite common for wireless simulations.

set ns_ [new Simulator] ;# create a simulator instance

set wtopo [new Topography]
$wtopo load_flatgrid 2500 200
set tracefd [open $sim(tr) w]
$ns_ trace-all $tracefd
create-god $sim(nn)
;# create wireless topography object
;# specify length and width of the topography
;# open trace file defined before
;# trace all event during simulation
;# create god

The following statement sets the random seed value for random number generator. If
we want ns-2 to produce different results every time we run the simulation (independent
replications), the seed value should be zero. If we expect reproducible simulation results,
the seed value can be any non-zero integer number.

ns-random 0 ;# independent simulations

The next step is node configuration. In ns-2, node is the basic simulation entity and
can be configured to have different components and characteristics in different
simulations. In wired simulations, we normally create node objects directly using the
default node configuration. But in wireless simulations, we must explicitly specify all
components that each node object will have, before actually creating node objects. The
node configuration parameters have been chosen at the beginning and stored in tcl
variables (in the form of $opt()). In this step, we actually configure nodes with those
variables. The node configuration command is shown as below. These options are easy
to understand according to their names. The last three options turn on or off the trace
options at Agent/Router/MAC levels. In this example, we decide to turn tracing on at
the agent and router level only.
46

$ns_ node-config -adhocRouting $opt(adhocRouting) \

-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topoInstance $wtopo \
-agentTrace ON \ ;# tracing at agent level turned on
-routerTrace OFF \ ;# tracing at router level turned off
-macTrace OFF ;# tracing at mac level turned off

Besides the configurable node, each component model inside the node is also
configurable. For example, we can set the height and gain for antenna. But in this
example, we do not reconfigure any of them, and use their default values. Ns-2 has put
all default parameters in the file ns-2.28\tcl\lib\ ns-default.tcl. In multi-hop simulations,
one default value that we need to know is the communication range of wireless nodes. If
both antenna model (Antenna/OmniAntenna) and network interface model
(Phy/WirelessPhy) are configured to use their default values (like in this example), the
default value for communication range is 250 meters. If another different value is
desired, please follow the directions in section 18.4 (communication range) in ns-
manual [14].
After node configuration is done, actual nodes can be created like following.

for {set i 0} {$i < $sim(nn) } {incr i} {

set node_($i) [$ns_ node]
$node_($i) random-motion 0 ;# disable random motion
}

Then we position each node in the topography that we have defined before. This
simulation scenario requires that each node can hear only its immediate neighbors. And
the default radio transmission range is 250 meters. So we need to space out the nodes
200 meters apart. The following code creates the topology for this scenario.
 47

for {set i 0} {$i < $sim(nn) } {incr i} {

$node_($i) set Z_ 0.0
$node_($i) set X_ [expr 50.0+[expr 200.0*$i]]
$node_($i) set Y_ 100.0
}

We use NOAH as the routing protocol not only in this example, but also in all our S-
MAC simulation scenarios. The following code sets up a static routing table for 10-hop
network using routing command.

for {set i 0} {$i < $sim(nn) } {incr i} {

set cmd "[$node_($i) set ragent_] routing $sim(nn)"
for {set to 0} {$to < $sim(nn) } {incr to} {
if {$to < $i} {
set hop [expr $i - 1]
} elseif {$to > $i} {
set hop [expr $i + 1]
} else {
set hop $i
}
set cmd "$cmd $to $hop"
}
eval $cmd
}

The next step is to define the traffic model. We should set up an agent at the
transportation layer. Since we are studying the behaviors of S-MAC, UDP agent is a
better choice than TCP agent, because UDP is quite simple and connectionless. The
following code creates a UDP agent and attaches it to the source node. Accordingly, a
Null agent is created and attached to the sink node. Then we connect the udp agent and
null agent together, which establishes a virtual path between the source node and the
sink node.

set udp [new Agent/UDP] ;# create a new UDP agent

$ns_ attach-agent $node_(0) $udp ;# attach udp to source node
set null [new Agent/Null] ;# create a new Null agent
$ns_ attach-agent $node_([expr $sim(nn)-1]) $null ;# attach null to sink node
$ns_ connect $udp $null ;# connect udp to null
48

To generate packets at the source node, we need to create a traffic source and attach it
to the UDP agent. The following code creates an EXPO traffic that we have introduced
in sub-section 4.2.2, and configure it to work in AePd (Exponential inter-arrival time
and deterministic packet size) mode. Notice that the maximum number of packet to
generate is not explicitly specified, because its default value is big enough to make the
generator always keep generating packets during the whole simulation time (2000 s in
this example).

set expo [new Application/Traffic/MyExponential]

$expo set packetSize_ 100
$expo set interval_ 10.0s
$expo interval-exp
$expo attach-agent $udp

Ns-2 is a discrete event based simulator. When the simulation starts running, a
scheduler is created to control the simulating process. In the tcl script, we should tell the
scheduler the exact time when a certain event should occur. Those events are described
in the following comments.

$ns_ at 60.0 "$expo start" ;# when expo starts

for {set i 0} {$i < $sim(nn) } {incr i} { ;# when nodes stop
$ns_ at $sim(stop) "$node_($i) reset";
}
$ns_ at $sim(stop) "finish" ;# when call finish procedure
$ns_ at $sim(stop).01 "puts \"NS EXITING...\" ;
$ns_ halt"; # when stop simulation

The definition of finish procedure is shown below.

proc finish {} {
global ns_ tracefd
$ns_ flush-trace
close $tracefd
exit 0}

In all tcl scripts for ns-2, the last statement should be:

$ns_ run
 49

4.4 Tracing
4.4.1 How to Trace in ns-2

Tracing is a necessary technique for each discrete-event simulator, because it tells us

what has happened inside the model during its running and the output analysis is also
based on the tracing results. Normally for a simulation tool, trace data can be either
displayed directly during execution of the simulation, or stored in a file to be post-
processed and analyzed. Ns-2 supports the latter one better, though Nam (an animation
tool designed for working with ns-2) can implement the first one to a certain extent. In
this section, we use the example presented in section 4.3 to show how to generate traces
and record data into a trace file, and how to analyze and abstract useful information
from the trace file.
Ns-2 is able to trace all packets that are received, dropped and sent by agents, routers,
MAC layers or interface queues. Before the simulation starts running, we should tell ns-
2 what events we want to trace. The following code taken from the example in section
4.3 is related to trace configuration.

set sim(tr) trace.tr ;# specify the trace file name

…
set tracefd [open $sim(tr) w] ;# open trace file defined before
$ns_ trace-all $tracefd ;# record all traces in the trace file
…
$ns_ node-config
-agentTrace ON \ ;# turn on tracing at agent level
-routerTrace OFF \ ;# turn off tracing at router level
-macTrace OFF ;# turn off tracing at mac level
…
proc finish {} {
global ns_ tracefd ;# set outer variables to global, visible inside
$ns_ flush-trace ;# flush the trace buffer before simulation ends
close $tracefd ;# close the opened trace file
…

For more tracing options that ns-2 provides, please refer to the ns manual[14]. We
keep using the above trace settings in all our simulations, because such settings have
already satisfied our needs for measures, except for the measure energy consumption. In
subsection 4.4.3, we will talk about how to trace energy consumption for S-MAC in ns-
2.
50

4.4.2 Trace Format

All trace data will be recorded into a specified trace file in a certain format. Ns-2
defines two trace formats, old format and new format. The old format is the default
trace format in ns-2 and supports all type of simulations. The new format is especially
designed for tracing wireless simulations, which is more standardized than the old one.
However, S-MAC in ns-2-28 still does not support the new trace format. Therefore, we
consider the old format. A trace record in a S-MAC trace file is shown in Fig. 4..3
below.

s 274.090231333 _3_ MAC --- 0 RTS 10 [0.11 4 3]

1 2 3 4 5 6 7 8 9

Fig. 4.3. S-MAC Trace format

We can know from this trace record that at 274.090231333 s, node 3 sends an RTS
packet to node 4. Now we explain what these field mean in the usual case.

1. The first field represents the event type, whose value can be s (send), r (receive),
d (drop) or f (forward).

2. The second field the time this event happens.

3. The third field records the id of the node, on which this event takes place.

4. The fourth field shows the layer where this event happens. Its possible value
may be one of the following four: AGT (agent), RTR (router), IFQ (interface
queue), and MAC (mac).

5. The fifth field is normally a short broken line, which is reserved for special
events. For example, when collision occurs, the broken line is replaced with
COL.

6. The sixth field is the global sequence number for this packet, which is the
integer number used to identify this packet in the whole network and distinguish
it from others. Sequence number is only available for data packets and not
allocated for control packets, like RTS/CTS/ACK and SYNC packets in S-MAC
(using a zero instead).
 51

7. The seventh field is the packet type. The actual value is determined by the
application or MAC layer, which creates this packet. For example, cbr represents
that it is a data packet generated by a CBR traffic source.

8. The eighth field is the packet size in bytes.

9. The ninth field including three numbers in brackets concerns MAC layer
information. Originally, there will be four numbers in the brackets. But S-MAC
revises this format. The first number is the duration field of this packet. In Fig.
4.3, the duration field of this RTS packet is 0.11 s, which is the remaining time
reserved for the coming transmission. The second number stands for the MAC
address of the receiver of this packet, and the third number for the sender.

The above nine fields are common for all traces if S-MAC is employed. But some
packets may have additional fields to record other information, like routing and IP
information. But for our purpose of study, considering these nine fields are already
enough.

4.4.3 Tracing Radio State change for Energy Measures

Achieving remarkable energy conservation on sensor nodes is the primary design goal
for S-MAC. So evaluating the performance of energy consumption for S-MAC is one of
the main tasks in this thesis.
In ns-2, tracing is the usual way to get simulation data. For tracing energy
consumptions of nodes in wireless simulations, ns-2 defines an energy model, which
traces the energy level at each wireless node during the simulation. The tracing results
will be written to the trace file. So using energy model would be the most convenient
way to measure energy consumptions. Unluckily, the energy model in the ns-2.28
release version did not support S-MAC until we have done all the simulations for this
thesis. Now the latest energy model has been updated to support S-MAC and released as
a daily snapshot version available on the ns-2 download page. For more information
about installation and usage of the new energy model updated for S-MAC, please refer
to [20].
Since we could not use the energy model to measure energy consumptions directly,
we had to find out a solution. We know in a normal network stack, physical layer
controls radio communications. But in ns-2, S-MAC defines a virtual radio on MAC
layer, which is in fact a state variable that reflects the change of radio state. There are
four radio states defined in S-MAC, sleep, idle, transmitting, and receiving. S-MAC
changes the value of the radio state variable according to some events. For example,
when S-MAC passes a packet to the network interface (the physical layer model in ns-2)
52

through the interface between them, S-MAC assumes that the transmission of this
packet starts immediately at the physical layer and sets its radio variable to transmitting
state. At the same time, S-MAC calculates the duration of transmitting this packet and
starts a timer called sending timer with the duration timer. When the sending timer
expires, S-MAC knows the sending is over (the lower layer will not acknowledge this),
then it sets the radio variable back to idle state.
The radio variable state in S-MAC gives us a hint. That is to trace the radio states, by
adding a print statement after each assignment statement that changes radio state in the
source file smac.cc (need to recompile ns-2). The following code is an example of this
change in smac.cc.

radioState_ = RADIO_SLP;
//new added print statement for tracing radio state
printf("@ %d %f %d\n", index_, Scheduler::instance().clock(), radioState_);

The printed information by the above statement includes the node id, the starting time
of changing the state, and the current state. When S-MAC is running in ns-2, all such
information will be printed out to the terminal window. Using the output redirection
function of Linux, we can easily store all of them into a text file. So we can execute the
following command to run a simulation.

ns example.tcl > radiotrace

After the simulation ends, we can get two trace files, one is the standard ns-2 trace file
that we have introduced before, and the other one is the trace file for radio states from
the terminal window. The information in the radio trace file is the time when each node
changes its radio from one state to another. To calculate energy consumptions, we need
to write a Perl script to calculate the amount of time that the radio on each node has
spent in each of these four states. The energy consumption for the radio in each state at
each node is then calculated by multiplying the time with the radio power consumed in
that state. The total energy consumption at a certain node is easy to get by a simple sum
operation.
 53

4.5 Abstraction and Simulation Control

This section describes how to extract trace files and how to implement simulation
control in ns-2.

4.5.1 Abstraction Methods

The trace file only records the raw data obtained directly from the simulation. These
raw data cannot tell us further information about the performances of the simulated
objects. So we have to post-process the trace file and extract our wanted information
from it. Since ns-2 is not designed for this purpose, we hope to use a third-part program
that can do this job, instead of extracting the trace file by hand. By searching the
Internet, we found such a powerful tool, called Trace graph, which is an ns-2 trace file
analyzer and free to download on the webite [21]. Trace graph uses the ns-2 trace file as
its input and analyzes it automatically. By using this tool, we can directly obtain the
usual measures, such as delay and throughput, which can also be visualized in 2-D or 3-
D graphs. Although this tool has been developed to support most of trace formats that
ns-2 has defined so far, unfortunately it does not support the trace format in the case of
S-MAC employed (mainly because it does not recognize the ninth field mentioned
above that S-MAC has revised). But we still recommend trying this tool, if it does
support your trace format.
Since no suitable tool is available for abstraction, we have to write programs in a
certain language to extract trace files. Normally, extracting a trace file does not require a
complicated algorithm. But it must be efficient and fast, especially in reading and
filtering data, because sometimes a trace file can be very huge (File sizes of more than 1
Gigabytes are possible in our simulation). Nearly any programming language that
supports file operation and process is able to do this work. Our choice is Perl (Practical
Extraction and Report Language)[22], one of the best programming languages for data
processing and filtering. There are so many advantages of using Perl to extract trace
files. First, it is intended to be practical (easy to use, efficient, complete) rather than
beautiful (tiny, elegant, minimal). It is easy to use without having to consider too many
programming techniques. In addition, it has very powerful built-in support for text
processing, so that processing a huge text file is not a difficult task for it. It is also easy
to start with, if you know some other programming languages, like C and Java. All
these characteristics accord with our requirements for processing trace files.
54

4.5.2 Simulation Control

All simulation problems can be divided into two types, terminating simulations and
steady-state simulations. In this thesis, we choose steady-state simulations, because we
are more interested in the long-run behavior of S-MAC. For a steady-state simulation,
two main problems should be solved. One is duration of the initial transient period. The
other one is analysis of correlated data. We call both these problems simulation control.

Transient period detection

One of the characteristics for steady-state simulations is that each simulation will
spend a period of time to enter a stationary state after it is launched. This period is
called initial transient period or warm-up period. In this period, the system is
converging to a stable state. The data measured from this period fluctuate a lot and need
to be discarded, because they will significantly bias our simulation results. The main
reason for the existence of the initial transient period is that all the queues in the system
are normally empty at the beginning of a steady-state simulation. When simulation
starts, the system will need some time to make the number of customs (or packets) in
queues stable. In our simulations, eleven nodes form a ten-hop linear network and each
node has an interface queue (buffer queue for S-MAC) with default size 50. Such a
long-queued system potentially has a rather long transient period especially when traffic
load is heavy. So applying transient period detection is meaningful for our simulations.
Many methods have been developed for detecting transient period. We choose one of
the rules of thumb, that is, the transient period is over if the observations have crossed
the sample mean 25 times. We have implemented this rule in the Perl script extract.pl,
which is used to extract results from the trace file.

Replication control for correlated data

The other aspect of the simulation control is called replication control. For a steady-state
simulation, we must run a sufficient number of independent replications for the analysis
of correlated data [4]. To make each replication independent, we have considered the
following requirements:

Use the same initial conditions for each replication.

Apply initial transient period detection to each replication.
Use different random number seed for each replication.
Run each replication long enough to make the number of observations significantly
larger than that discarded in the transient period. As shown is Fig. 4.4 below, m
should be much bigger than I.
 55

Fig. 4.4. Independent replications for simulation control

We apply the following sequence procedure [4] to control the number of replications
required for one simulation. This algorithm constructs a confidence interval for each
measure, which should satisfy a specific precision.

4.5.3 Scripts for Abstraction and Simulation Control

Ns-2 is a powerful network simulation tool, which is able to simulate a complicated

scenario containing various network protocols and components at a satisfying speed.
But as far as result abstraction and simulation control are concerned, ns-2 does not seem
to be a complete simulation tool that is able to provide good support in every aspect of
simulation studies. The only task for ns-2 is to run the model that a user has set up in the
tcl script and record all events happening during the simulation into a text file. Once the
simulation stops, all other jobs, including the abstraction of the trace file and analysis of
simulation results, are left to users. To improve efficiency in doing these jobs and
implement simulation control, we have written three scripts for these purposes, which
include two Perl scripts (extract.pl and control.pl) and one bash shell script (run.sh). We
use the following file names listed below to explain how to use these scripts to extract
trace files and realize simulation control in ns-2.
56

tclFile: Tcl script for ns-2

traceFile: ns-2 trace file
radioFile: trace file for radio, from terminal
resultFile: file for storing extraction results

We first see how those two Perl scripts work. First of all, we run the replication using
the following command:

ns tclFile > radioFile

After the simulation stops, we will get two trace files radioFile and traceFile. Then
we run the script extract.pl to extract them, by using these two trace files as input. The
command is:

perl extract.pl traceFile radioFile >> resultFile

The results extracted from this replication are stored in resultFile and contain the
values of three measures that we will define in section 5.1. Before we can run the script
control.pl, the above steps should have been executed repeatedly at least three timers
(initial replications). Running the script control.pl will use resultFile as the input file,
which contains all sample values from all done replications. The command is:

perl control.pl resultFile

The script control.pl checks if the sample values of all measures from the done
replications have satisfied the confidence conditions. If yes, it will print out the final
result. Otherwise, we have to run more replications by repeating all the steps above until
the confidence conditions are satisfied.
To save time and improve efficiency, we have written a shell script (bash), run.sh, to
control the running of all the steps above. So for one simulation that requires several
replications, we only need to type a shell command. The shell script is shown at the end
of this section.
 57

for currNumRepl in 1 2 3
do
echo "NS2 is executing replication $currNumRepl ..."
until ns $tclFile > $radioFile
do
echo "Error occurs! Run again..."
done
echo "Ns-2 Done!"
echo "Perl script is extracting results for replication $currNumRepl ..."
perl extract.pl $traceFile $radioFile $currNumRepl >> $resultFile
echo "Perl Done!"
done
currNumRepl=3

until perl control.pl $resultFile

do
currNumRepl=`expr $currNumRepl + 1`
echo "NS2 is executing replication $currNumRepl ..."
until ns $tclFile > $radioFile
do
echo "Error occurs! Run again..."
done
echo "Ns-2 Done!"
echo "Perl script is extracting results for replication $currNumRepl ..."
perl extract.pl $traceFile $radioFile $currNumRepl >> $resultFile
echo "Perl Done!"
done

echo "Simulation ends with $currNumRepl replications"

exit 0
58

Chapter 5
Simulation Results

In this chapter, we present our simulation results for studying S-MAC. First, three
measures for analyzing the performance of S-MAC are defined in the first section. In
the second section, we introduce the terminating simulations with ns-2 for reproducing
the results of experiments on Mica Motes hardware presented in [2]. The steady-state
simulation results under different scenarios are to be discussed in section 5.3.

5.1 Definition of Performance Measures

To evaluate the performance of S-MAC from various aspects, we define three measures
for analyzing our simulation results from the steady-state simulations, which will be
described in section 5.3.

Energy Consumption per Byte

We have discussed in subsection 4.4.3 how to measure energy consumptions in ns-2 by

tracing the radio state variable of S-MAC. Now we give the exact definition for the
measure of energy consumption in our simulations.

Mean energy consumption per byte =

Total energy consumptions on all nodes
Total bytes in data packets received by sink node

We do not use the total energy consumed on all nodes as the measure for energy
consumption, because they are accumulated values and will keep increasing over
running time. However, as a proper measure for steady-state simulations, an averaged
value is more meaningful and reasonable than an accumulated value. Moreover, the
measured mean energy consumption per byte can tell us about how much energy cost S-
 59

MAC should pay for sending a single byte under different traffic loads and S-MAC
modes.

End-to-End Delay

Since S-MAC has proposed adaptive listening for reducing latency caused by the
periodic sleep mechanism, we are interested in how effective the adaptive listening
mechanism is in reducing latency. The second measure is defined as end-to-end delay,
which is calculated from the time when one packet is generated at the source node to the
time when this packet is received by the sink node. In our simulations, we compute the
mean end-to-end delay over a ten-hop network, using the following definition.

Mean end-to-end delay =

Sum of end-to-end delays for all received packets
Total number of packets received by sink node

End-to-End Goodput

Goodput measures only data packets received at the application layer. We define the
measure of goodput in the similar way that we define the end-to-end delay, using the
following definition for output analysis.

End-to-end goodput =
Total bytes in data packets received by sink node
Time from first packet generated at source to last packet received by sink node
60

5.2 Simulations for Validating S-MAC in NS-2

S-MAC has been implemented on the Mote hardware. To verify the design principles
and demonstrate the effectiveness of S-MAC, the paper [2] presents some experiment
results on Mica Motes. In this thesis, we reproduce most of these experiments with ns-2.
The intention is to compare the S-MAC implementation in ns-2 with that in Mote
hardware to show how close the S-MAC model built in ns-2.28 has approached its
hardware implementation. To make the comparisons between network hardware and
simulation software more reasonable, the parameters used in our simulations have been
set as close as possible to those used in the hardware experiments.
In the following subsections, we give both the simulation configurations and the
simulation results in graphs for each scenario. Moreover, we compare our simulation
results with those measured from the experiments on the Mote hardware to check their
consistency.

5.2.1 Common Settings for Reproduction Simulations

This subsection presents the common settings for all simulation scenarios presented in
this section.

Topology: We only reproduce the multi-hop experiments on Mica mote presented in [2]
and use the topology shown in Fig. 5.1.

Source Sink

...
0 1 2 ... 8 9 10

Fig. 5.1 Ten-hop linear network with one source and one sink

The above figure shows a ten-hop linear network with 11 nodes. The first node is the
source and the last node is the sink. Each node can hear only its immediate neighbors.
We use an ideal channel in all our simulations.

Traffic pattern: we attach a UDP agent and a CBR traffic source to the source node.
The CBR source generates 20 packets (each 80 Bytes, because it will be added with 20
bytes IP header at the routing layer, so the actual size at MAC layer is 100 Bytes). We
use NOAH routing protocol introduced in section 4.2.1.

S-MAC modes: for comparisons, we run each simulation in three S-MAC modes
introduced in section 4.1.3 and use the following configurations.
 61

Mode 1: S-MAC without periodic sleep

Set syncFlag_ to zero and exclude the JOURNAL_PAPER code.

Mode 2: S-MAC with periodic sleep, but without adaptive listening

Set syncFlag_ to one and include the JOURNAL_PAPER code, but modify the
S-MAC source code to disable the adaptive listening function.

Mode 3: S-MAC with periodic sleep and adaptive listening

Set syncFlag_ to one and include the JOURNAL_PAPER code, enabling the
adaptive listening.

S-MAC settings: first, we should debug the S-MAC source code in ns-2.28 according
to the contents in section 4.1.4. Except for those listed in Table 5.1 below that are
forced to match those used in hardware measurements, all other parameters use default
values in ns-2.28.

Table 5.1. Modified parameters for reproduction simulations

SYNC_CW 15
DATA_CW 31
SIZEOF_SMAC_DATAPKT 100 Bytes

Simulation control: all the simulations presented in this section belong to terminating
simulations. We use the event when the sink node receives the last CBR packet sent by
the source node as the simulation stopping condition. For each simulation, we run five
independent replications and compute the average value, without applying replication
control.

5.2.2 Measurement of Energy Consumption

Measure definition: aggregate energy consumed at all nodes on the entire network.

Scenario: varying the CBR packet inter-arrival times at the source node from 0s to 10s,
where 0s means all 20 packets are generated and queued at almost the same time at the
source node. However, ns-2 does not support zero inter-arrival time for traffic sources,
so we use 0.001s instead.
62

35
No periodic sleep

Energy consumption (J)

30
25
20 10% duty cycle
without adaptive
15 listen
10 10% duty cycle
5 with adaptive
listen
0
0 1 2 3 4 5 6 7 8 9 10 11
Packet inter-arrival time (S)

Fig. 5.2. Aggregate energy consumptions at all nodes in the network

Fig. 5.2 shows the measured aggregate energy consumptions at all nodes on the
network to transmit a fixed number of data packets from the source to the sink. We
compare the results in the above figure with those in Fig. 10 in [2] and find that the
results in both S-MAC without periodic sleep and S-MAC with adaptive listening show
quite good consistency in both the tendency and the absolute values. However, in S-
MAC without adaptive listening, the energy consumptions measured from our
simulations almost double the values measured from the hardware experiments. Caused
by such deviations, unlike in hardware experiments, the energy consumptions in S-
MAC without adaptive listening and S-MAC with adaptive listening do not converge as
the inter-arrival time increases. Theoretically, when the traffic load is very light on the
network, S-MAC with adaptive listening will not achieve better energy efficiency than
S-MAC without adaptive listening. The reason is that the energy consumed in
transmitting packets does not dominate the total energy consumptions, when the packet
inter-arrival times are long enough. Therefore, the two curves in mode 2 and mode 3 in
Fig. 5.2 should get closer, when the traffic load becomes lighter.

5.2.3 Measurement of Latency

Measure definition: compute mean latency of all data packets at the different number
of hops across the network. The number n in the following figures means n hops
counted from the source node.

Scenario 1: under the lowest traffic load

In the hardware experiments, the next packet is generated at the source node
immediately after the sink node receives the last packet. However, this method is not
 63

easy to implement in ns-2. Therefore, we generate CBR packets every 25s. The
simulation results are shown in Fig. 5.3 below.

14
12 No periodic sleep
Mean Latency (S)

10
8 10% duty cycle
without adaptive
6 listen
4 10% duty cycle
with adaptive
2 listen
0
0 1 2 3 4 5 6 7 8 9 10 11
Number of hops

Fig. 5.3. Mean latency V.S. number of hops, under the lowest traffic load

Comparing Fig. 5.3 above with Fig. 11 in [2], we do not see much difference in them.
The paper [2] has analyzed the multi-hop latency in S-MAC and proposed three
theoretical equations in the three S-MAC modes. The equations show that the latency
on a multi-hop network will increase linearly with the number of hops in all the three S-
MAC modes. They also predict that the slope of the latency line in S-MAC with
adaptive listening will be only half of that without adaptive listening. In Fig. 5.3, we can
see that our simulation results accord with the theoretical analysis.

Scenario 2: under the highest traffic load

The packet inter-arrival time is 0.001s. The results are shown in Fig. 5.4 below.
120

100
No periodic sleep
Mean latency (S)

80
10% duty cycle
60 without adaptive
listen
40
10% duty cycle
with adaptive
20
listen
0
0 1 2 3 4 5 6 7 8 9 10 11
Number of hops

Fig. 5.4. Mean latency V.S. number of hops, under the highest traffic load
64

Comparing Fig. 5.4 above with Fig. 12 in [2], we found that the latency values in
Fig.12 do not have the same order of magnitude with ours. If we multiply all the values
in Fig. 12 in [2] by 10, both the figures will be quite similar. Therefore, we infer that the
paper [2] uses another measure in Fig. 12, instead of using the same measure as in
measuring latency under the lowest traffic load.
In this scenario, we generate 20 packets and throw them to the queue at the source
node at almost the same time. Under such an extreme heavy traffic load, we must
consider the queuing delay when we analyze the mean latency. It is easy to imagine that
the latter generated packets will have larger queuing delay than the previous ones.
Moreover, the queuing delay at each hop will decrease as the number of hops increases.
Therefore, we can see in Fig. 5.4 that the latency does not increase linearly as the
number of hops increases. Compared with S-MAC without adaptive listening, S-MAC
with adaptive listening shows its power in reducing latency in multi-hop transmissions.
The reason is the adaptive listening can make one packet jump two hops in a frame,
which reduces the latency significantly.

5.2.4 Measurement of Throughput

Measure definition: we compute the throughout, using the payloads received at the
MAC layer.

Scenario 1: under the highest traffic load

We use the same settings as in measuring latency at the different number of hops under
the highest traffic load. The results are shown in Fig. 5.5 below.

250
No periodic
Throughput (Byte/S)

200 sleep

150 10% duty cycle

without adaptive
100 listen
10% duty cycle
50 with adaptive
listen
0
0 1 2 3 4 5 6 7 8 9 10 11
Number of hops

Fig. 5.5. Throughput V.S. number of hops, under the highest traffic load
 65

Comparing Fig. 5.5 with Fig. 5.4, we can find that under the highest traffic load,
throughput has a very close connection with latency. At the same number of hops, the
larger the latency is in Fig. 5.4, the lower the throughput is in Fig. 5.5. The simulation
results show that under the highest traffic load, S-MAC without periodic sleep achieves
much higher bandwidth utilization than the two S-MAC modes with periodic sleep. The
reason is in the S-MAC without adaptive listening, each node can send or receive only
one data packet in a frame, which wastes a lot of bandwidth especially under heavy
traffic loads. The adaptive listening allows the node to send or receive more than one
packet in a frame. Therefore, as shown in Fig. 5.5, S-MAC with adaptive listening can
achieve better bandwidth utilization than S-MAC without adaptive listening.

Scenario 2: measure end-to-end throughput under different traffic loads

The packet inter-arrival time varies from 0.001s to 10s. The results are shown in Fig.
5.6 below.
140

120 No periodic sleep

Throughput (Byte/S)

100

80 10% duty cycle

without adaptive
60 listen
40 10% duty cycle with
adaptive listen
20

0
0 1 2 3 4 5 6 7 8 9 10 11
Packet inter-arrival time (S)

Fig. 5.6. End-to-End throughput under different traffic loads

The above figure is quite consistent with that in Fig. 14 in [2]. We can see from Fig.
5.6 that when the traffic load is very light, the three curves overlap, because the three S-
MAC modes spend almost the same time to send a fixed number of packets from the
source to the sink. As the traffic load increases, the throughput of all three modes
increases. When the traffic load reaches maximum, we get the same results as in Fig.
5.5.
66

5.3 Steady-State Simulations and Results

To investigate the long-run performance of S-MAC, we perform steady-state
simulations. In this section, we introduce various scenarios that we have set up for
running steady-state simulations and analyze the simulation results.

5.3.1 Common Settings for Steady-State Simulations

Topology: a ten-hop linear network with one source and one sink, the same as in Fig.
5.1. We use NOAH as the routing protocol and use an ideal channel in all our
simulations.

S-MAC mode settings: three S-MAC modes, using the same settings as in section 5.2.1.

S-MAC source code: debug S-MAC source code in ns-2.28 according to the contents
in section 4.1.4.

Performance measures: three measures defined in section 5.1.

Simulation control: apply both initial transient period detection and replication control
introduced in section 4.6.2. For each replication, we run the model for a fixed time,
during which the traffic source will keep generating packets at the source node.
Normally in all our steady-state simulations, the fixed model running time is chosen
long enough to guarantee that at least 8000 packets will be received by the sink node in
each replication.

Parameters settings: some important parameters used in the steady-state simulations

are listed in the following tables.
 67

Table 5.2. Modified S-MAC parameters (default values in brackets)

Name Comment Value

SYNC_CW Number of slots in the SYNC contention window 15 (31)
DATA_CW Number of slots in the DATA contention window 31 (63)
SIZEOF_SMAC_DATAPKT Fixed data packet size in bytes 100 (50)
durDataPkt_ Time for transmitting a data packet in ms 83 (43)
syncTime_ Length of SYNC period in ms 39.2 (55.2)
dataTime_ Length of DATA period in ms 73.0 (105)
listenTime_ Length of listen period in ms 112.2 (160.2)
sleepTime_ (10% duty cycle) Length of sleep period in ms 1010.8 (1442.8)
cycleTime_ (10% duty cycle) Length of one frame in ms 1123 (1603)

Table 5.3. Some PHY and MAC layer parameters

Name Comment Value

BANDWIDTH Radio bandwidth 20 kbps
ENCODE_RATIO Manchester encoding 2
SIZEOF_SMAC_CTRLPKT Size of control packet 10 Bytes
SIZEOF_SMAC_SYNCPKT Size of SYNC packet 9 Bytes
slotTime_ Slot time in contention window 1 ms
difs_ DCF interframe space 10 ms
sifs_ Short interframe space 5 ms
eifs_ Extended interframe space 50 ms
durSyncPkt_ Time for transmitting a SYNC packet 10.2 ms
durCtrlPkt_ Time for transmitting a control packet 11 ms
timeWaitCtrl_ CTS or ACK timeout time 18 ms

Table 5.4. Parameters for replication control

Parameter Comment Value

n0 Initial number of replications 3
α Confidence interval 0.01
γ Relative error 0.1

Table 5.5. Radio power in different modes for calculating energy consumption

Radio State Power (mJ)

sleep 0.015
idle 14.4
transmitting 36.0
receiving 14.4
68

5.3.2 Single Traffic Source

In this scenario, we attach only one traffic source to the source node. We consider two
types of traffic sources, the EXPO traffic source (see section 4.2.2) or the exponential
On/Off traffic source.

1. EXPO traffic source

The EXPO traffic source can be configured to generate packets in four modes. We
consider two extreme cases. One is AdPd, which has completely deterministic
characteristic. The other one is AePe, which has completely exponential characteristic.

AdPd traffic source (deterministic inter-arrival times, deterministic packet sizes)

Measure 1: Mean energy consumption per byte

25
Mean energy consumption per-byte

No periodic sleep
20
(mJ/Byte)

15 10% duty cycle

without adaptive
listen
10
10% duty cycle
with adaptive
5 listen

0
0 1 2 3 4 5 6 7 8 9 10 11
Mean inter-arrival time (S)

Fig. 5.7. Energy consumption, with AdPd traffic source

In Fig. 5.7, we can see that when the traffic load on the network is light, two S-MAC
modes with periodic sleep show great advantage over S-MAC without periodic sleep.
The reason is that when the traffic load is light, idle listening dominates the total energy
consumption and the periodic sleep mechanism will show its power in this case.
Comparing two S-MAC modes with periodic sleep, we see that adaptive listening can
help S-MAC achieve better energy efficiency, especially when the traffic load is heavy.
The reason is that adaptive listening can efficiently reduce latency caused by periodic
sleep in a multi-hop transmission, which accordingly reduces the average time for
transmitting a single byte.
 69

Measure 2: Mean end-to-end delay

Mean end-to-end delay (S) 1000

No periodic sleep
800

600 10% duty cycle

without adaptive
400 listen
10% duty cycle with
200 adaptive listen

0
0 1 2 3 4 5 6 7 8 9 10 11
Mean inter-arrival time (S)

Fig. 5.8. End-to-End delay, with AdPd traffic source

Fig. 5.8 shows the mean end-to-end delay measured under different traffic loads. We
can see that for both S-MAC with adaptive listening and S-MAC without adaptive
listening, the end-to-end delay drops sharply at a certain point. However, for S-MAC
without periodic sleep the delay curve is nearly a horizontal line, which stays at a quite
low level (about 1.41s), This means that even the highest traffic load in Fig. 5.8 (1s) is
still low for S-MAC without periodic sleep, but this is already quite heavy for both S-
MAC modes with periodic sleep.
We first look at S-MAC without adaptive listening. When the traffic load is light
(inter-arrival time bigger than 7s), the end-to-end delay remains at a low value, which is
about 13s. This value is quite close to that in Fig.5.3, which is measured under the
lightest traffic load. As the traffic load increases, more and more packets will be stuck
in the queues and the delay will increase rapidly. Finally, the delay stops increasing and
reaches a saturation value, which is about 910s. The saturation delay is very huge
because the network has a very large queue size (queue size is 50 at each node).
Now we analyze why the end-to-end delay will drop sharply at certain point. We use
Fig.5.9, which is a part of the ten-hop network used in this simulation, to illustrate this
problem. In Fig. 5.9, each node receives the packet from its previous-hop neighbor and
forwards it to its next-hop neighbor. We assume that all nodes follow the same schedule
and the channel is ideal (the same assumptions for all our simulations). Before
discussing, we should remember that in S-MAC without adaptive listening, each node
has only one chance to send the packet in a frame. If it misses this chance, it will have
to wait for the next DATA period.
70

N N+1 N+2 N+3

Fig. 5.9. Interfering nodes in a linear network

We first consider the case of two one-hop neighbors. In Fig. 5.9, if both node N and
node N+1 have a packet to send in the same frame, only one of them can transmit the
packet successfully and the other one has to go to sleep to avoid overhearing.
Now we see what happen to two two-hop neighbors. If both node N and node N+2
has a packet to send in the same frame, one of the following cases will happen.

1. If node N and node N+2 start sending at almost the same time, collision will
occur at node N+1. The consequence is node N will encounter a CTS timeout.
Then node N has to wait until the next DATA period comes. For node N+2, it
will transmit the packet to node N+3 successfully, because it will not be
influenced by the collision.

2. If node N sends out an RTS earlier than node N+2, node N+1 will send back a
CTS, which will be overheard by node N+2. To avoid overhearing the coming
long data packet, node N+2 goes to sleep immediately.

3. If node N+2 sends out an RTS earlier than node N, node N+1 will go to sleep to
avoid overhearing. Therefore, node N will encounter a CTS timeout.

From the above discussions, we can see that if two two-hop neighbors start carrier
sense for sending packets in the same frame, only one of them can send the packet
successfully and the other node has to wait for the next frame. In other words, two-
hop neighbors will interfere with each other, if they both have packets to send in the
same frame. If we consider two three-hop neighbors, there will be no such
interference between them.
Therefore, the conclusion is that if adaptive listening is not applied, the range of
interference between nodes is two hops. When the packet inter-arrival time is smaller
than the average time for passing a data packet over three hops, serious interference
will occur on the entire multi-hop network and the average delay for each packet will
be huge. The reason is that if one node misses the chance of transmitting the data
packet to its next-hop neighbor in the current frame, not only this packet but also all
queued packets at this node are delayed for a frame length. As time goes on, the
traffic jam will become more serious.
If the packet inter-arrival time is set larger than such an average time mentioned
before, the probability of interference will be largely reduced and the queuing delay
for each packet will be reduced.
 71

Let’s go back to our simulation results in Fig. 5.8. We notice that the turning point
in the curve for S-MAC without adaptive listening is at about 4s. According to our
analysis before, we can infer that 4s is the approximate average time for passing a
single data packet across three hops. If we have a look at the results in Fig. 5.3, we
can find that under a very light traffic load, the mean latency for passing a packet
across three hops is very close to 4s, which proves our inference.
Now we consider S-MAC with adaptive listening. Fig. 5.8 shows that the end-to-
end delay in S-MAC with adaptive listening reaches its saturation value at 2s, which
is only half of that in S-MAC without adaptive listening. The reason is that the
adaptive listening can pass a data packet across two hops in a frame, or make a node
transmit two data packets to its next-hop neighbor in a frame. Therefore, we can see
in Fig. 5.8 that that the saturation value of the end-to-end delay in S-MAC with
adaptive listening is much smaller than that in S-MAC without adaptive listening.
The simulation results prove that the adaptive listening is quite effective in reducing
the latency in multi-hop transmissions.

Measure 3: End-to-end goodput

100

No periodic sleep
Mean end-to-end goodput

80

60
(Byte/S)

10% duty cycle

without adaptive
40 listen
10% duty cycle with
20 adaptive listen

0
0 1 2 3 4 5 6 7 8 9 10 11
Mean inter-arrival time (S)

Fig. 5.10 End-to-End goodput, with AdPd traffic source

Fig. 5.10 shows the measured end-to-end goodput under different traffic loads. We
see that the goodput of all the three modes increases as the traffic load increases. Three
curves overlap on the right side of the above figure. The reason is that when the traffic
load is very light, the three S-MAC modes spend almost the same time to transmit the
same number of data packets. As the packet inter-arrival time decreases, the goodput of
S-MAC without adaptive listening stops increasing at 7s. If we have a look at Fig. 5.8,
we can see that the end-to-end delay of S-MAC without adaptive listening starts
increasing also at 7s. The same situation happens to S-MAC with adaptive listening.
When the inter-arrival time reaches 1s, the goodput of S-MAC with adaptive listening
are more than twice as large as that of S-MAC without adaptive listening, which implies
72

that under a heavy traffic load, S-MAC with adaptive listening can achieve much better
bandwidth utilization than S-MAC without adaptive listening.

AePe traffic source (exponential inter-arrival time, exponential packet size)

In this scenario, we attach an AePe traffic source to the source node. In the current S-
MAC implementations in ns-2.28, if we want to simulate S-MAC with variable packet
sizes instead of a fixed size, we must compile the JOURNAL_PAPER code to enable
the message passing function. However, if we enable the JOURNAL_PAPER code, we
cannot set S-MAC to mode 1. We have explained the reason in section 4.1.4. Therefore,
we consider only S-MAC without adaptive listening and S-MAC with adaptive listening
in this scenario. Fig. 5.11 shows how a data packet is generated by the AePe traffic
source at the application layer and is fragmented by S-MAC at the MAC layer.

AePe Traffic Source

Payload = Exponential.sample (80 Bytes)

NOAH
Payload = Payload +20 Bytes (IP header)

S-MAC
Number of Fragments = ⎢⎡ Payload/100 ⎥⎤
size of each fragment = 100 Bytes

Fig. 5.11. Flow chart of message passing with AePe traffic source

The simulation results for the three measures are shown in the following figures. (Mean
energy consumption per byte in Fig. 5.12, mean end-to-end delay in Fig. 5.13, end-to-
end goodput in Fig. 5.14)
 73

Mean energy consumption per-Byte

25

20
10% duty cycle
without adaptive
(mJ/Byte)

15
listen
10% duty cycle with
10
adaptive listen

0
0 1 2 3 4 5 6 7 8 9 10 11
Mean inter-arrival time (S)

Fig. 5.12. Energy consumption, with AePe traffic source

1000
Mean end-to-end delay (S)

800
10% duty cycle
600 without adaptive
listen
10% duty cycle with
400
adaptive listen

200

0
0 1 2 3 4 5 6 7 8 9 10 11
Mean inter-arrival time (S)

Fig. 5.13. End-to-End delay, with AePe traffic source

35
Mean end-to-end goodput (Byte/S

30

25 10% duty cycle

without adaptive
20 listen
15 10% duty cycle with
adaptive listen
10

0
0 1 2 3 4 5 6 7 8 9 10 11
Mean inter-arrival time (S)

Fig. 5.14. End-to-End goodput, with AePe traffic source

74

The main purpose of this scenario is to test the message passing function that S-MAC
has proposed to achieve better energy conservation and latency in transmitting long
messages. However, We compare the above three figures with those measured under
AdPd respectively, and do not see big difference between each pair of them. In fact,
current S-MAC implementation in ns-2.28 has not supported message passing very well.
To solve the information loss problem (in section 4.1.4), we make some changes in the
source code. The consequence after modification is that S-MAC has to transmit extra
bytes for those messages, which are not multiples of a fragment size (the value of
SIZEOF_SMAC_DATAPKT in smac.h). However, when calculating energy
consumption per byte and goodput, we only count the actual payloads of the messages
received at the application layer of the sink node. Therefore, the advantage of message
passing is traded off.

2. Exponential On/Off traffic source

The exponential On/Off traffic source is such a packet generator in ns-2, by which
packets are sent at a fixed rate during on periods like an AdPd source, and no packets
are sent during off periods. Both on and off periods are sampled from an exponential
distribution. We use the Fig. 5.15 (the left part) below to illustrate this process.

Det (T ′), Det ( P′)

On AdPd

Exp (λon ) Exp (λoff )

Off Det(T), Det(P)

Fig. 5.15. On/Off traffic source (left) and AdPd traffic source (right)

On/Off source model has been widely adopted in networks research to capture the
burst nature of the network traffic. In our simulations, we attach an exponential On/Off
traffic source to the source node. To compare the results using the On/Off source with
those using the AdPd source, we should make the two sources generate the same traffic
flow.
 75

We now analyze how to choose parameters for the On/Off traffic source. We consider
the following parameters:

For On/Off traffic source:

1/ λon : the mean value for the exponential distributed time in on state
1/ λoff : the mean value for the exponential distributed time in off state
T′ : the constant inter-arrival time for generating packets in on state
P′ : the constant size of the packets generated in on state

For AdPd traffic source:

T: the constant inter-arrival time for generating packets
P: the constant packet size

We define:
λoff
π on : the long-run percentage of time in on state, and equal to
λon + λoff
λon
π off : the long-run percentage of time in off state, and equal to
λon + λ off

To make the average traffic flow generated by the two sources equal (at the same
average generating rate), the following equation should be satisfied.
P′ λoff P′ P
π on ⋅ + π off ⋅ 0 = ⋅ =
T′ λon + λoff T ′ T
If we let λon = λoff and P′ = P , we can get the following result:
1
T'= T
2
In this scenario, we use the following parameter settings for the On/Off traffic source.
P′ =80 Bytes, λon = λoff =1/(10T ′ ), T ′ varies from 0.5s to 5s, 0.5s each step

The simulation results for the three measures are shown in the following figures,
(Mean energy consumption per byte in Fig. 5.16, mean end-to-end delay in Fig. 5.17,
end-to-end goodput are shown in Fig. 5.18), which should be compared with those
measured under AdPd traffic source. After comparison, except the results for the delay,
we do not see too many differences between the results under On/Off and under AdPd.
As for the results for end-to-end delay in Fig. 5.17, we can see that the exponential
On/Off traffic source greatly smoothes the sharp drop of the delay in Fig. 5.8.
The simulation results show that under burst traffic loads, S-MAC has almost the
same behavior as in using deterministic traffic sources.
76

25

Mean energy consumption per-byte 20 No periodic sleep

(mJ/Byte)
15
10% duty cycle without
adaptive listen
10

5
10% duty cycle with
adaptive listen

0
0

5
0,5

1,5

2,5

3,5

4,5

5,5
Constant inter-arrival time
during on periods (S)

Fig. 5.16. Energy consumption, with On/Off traffic source

1000
Mean end-to-end delay (S)

800
No periodic sleep
600
10% duty cycle without
adaptive listen
400
10% duty cycle with
adaptive listen
200

0
0

5
0,5

1,5

2,5

3,5

4,5

5,5

Constant inter-arrival time during

on periods (S)

Fig. 5.17. End-to-end delay, with On/Off traffic source

100
Mean end-to-end goodput

80
No periodic sleep
(Byte/S)

60
10% duty cycle without
adaptive listen
40 10% duty cycle with
adaptive listen
20

0
0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 5,5
Constant inter-arrival time
during on periods (S)

Fig. 5.18. End-to-end goodput, with On/Off traffic source

 77

5.3.3 Two Traffic Sources

In this scenario, we attach two traffic sources to the source node. One is AdPd traffic
source and the other is exponential On/Off traffic source. Two sources generate packets
with constant size (80bytes) simultaneously at the source node during the run of
simulations. The packet inter-arrival time at AdPd source is fixed to 7s, which is a
moderate traffic load for S-MAC. We vary the interval-times during on periods at
On/Off source from 0.25 to 10s and configure the exponential On/Off traffic source in
the same way as we described in section5.3.2 (simulating a single exponential On/Off
traffic load).
The purpose of this simulation is to investigate that in different S-MAC modes, how
information source with a constant bit rate (we suppose AdPd source a information
source) will be influenced by a noise source with a burst nature (we suppose On/Off
source a noise source).
Besides mean end-to-end delay that we have defined in section 5.1, we consider the
coefficient of variance (CV) for end-to-end delay and use the following definition:

Standard Deviation
Coefficient of Variance =
Mean

Mean end-to-end delay

1000
Mean end-to-end delay (S)

800

No periodic sleep
600
10% duty cycle without
adaptive listen
400 10% duty cycle with
adaptive listen

200

0
0,25 1 2 3 4 5 6 7 8 9 10
Constant inter-arrival time
during on periods (S)

Fig. 5.19. Mean end-to-end delay for AdPd packets,

with both AdPd source and On/Off traffic source
78

Fig. 5.19 shows the measured mean end-to-end delay of all data packets generated by
AdPd traffic source. We can see from the figure that the delay in S-MAC without
adaptive listening is much higher than that of the other two modes. Furthermore, the
delay remains at a very high level and does not drop even when the traffic load of
On/Off source is very light. Going back to Fig. 5.8, we can see that in S-MAC without
adaptive listening, when the inter-arrival time is smaller than 7s, the end-to-end delay
will increase rapidly. This means that 7s is the critical value for S-MAC without
adaptive listening. In this scenario, the inter-arrival time of AdPd traffic souce is fixed
to 7s. Therefore, no matter how the On/Off source changes its load, S-MAC without
adaptive listening will be always under heavy traffic load and the end-to-end delay will
be very huge.
As for S-MAC with adaptive listening, it is more sensitive to the noise source than S-
MAC without adaptive listening, because its delay increases dramatically as the traffic
load increases. In this scenario, S-MAC with adaptive listening encounters its critical
point at 3.5s, which is actually the inter-arrival time during on periods of the On/Off
source. Since we set λon = λoff , the overall inter-arrival time for the On/Off source will
be doubled and becomes 7s. Remember that the inter-arrival time of AdPd source is
fixed to 7s. Therefore, the overall inter-arrival time on the network is 3.5s. This value is
very close to 3s, which is the critical value for S-MAC with adaptive listening under a
single AdPd traffic source (see Fig. 5.8). This value is a little bigger than 3s, because
the exponential nature of the On/Off traffic source will smooth the delay curve.
 79

CV of end-to-end delay
1,0
Coefficient of variation

0,8
No periodic sleep
0,6
10% duty cycle without
adaptive listen
0,4 10% duty cycle with
adaptive listen
0,2

0,0
1

9
10
25
0,

Constant inter-arrival time

during on periods (S)

Fig. 5.20. CV of end-to-end delay for AdPd packets,

with both AdPd source and On/Off traffic source
Fig. 5.20 shows the measured CV for end-to-end delay. We can see two peaks in Fig.
5.20. One is in S-MAC with adaptive listening at 3s and the other is in S-MAC without
periodic sleep at 0.5s. According to the definition of CV, the closer the CV is to 1, the
higher the delay jitter will be and the closer the distribution of the delay will be to
exponential. When the traffic load is moderate, S-MAC with adaptive listening shows a
bad jitter performance. However, when the traffic load is very heavy, S-MAC with
adaptive listening will show much better jitter performance than S-MAC without
periodic sleep. As for S-MAC without adaptive listening, there is no peak in its CV
curve in Fig. 5.20. The reason is that in such traffic load, its delay will keep very high
and will not be sensitive to the change of the traffic load. Therefore, the good jitter
performance for S-MAC without adaptive listening is at the cost of high end-to-end
delay and low throughput.
80

Chapter 6
Conclusion

Finished work

During the course of the master thesis work, we have done the following three main
tasks.

1. We have investigated the source code of S-MAC in ns-2.28 and found out how S-
MAC works internally. Some important features of S-MAC, such as message
passing, schedule synchronization, adaptive listening etc, have been extracted from
the ns-2.28 source code and explained in detail.

2. We have found some bugs and problems in the S-MAC source code in ns-2.28 and
proposed the solutions to them.

3. Thirdly, two types of simulations have been run for different purpose.
To reproduce the S-MAC experiments on Mote hardware, we have run some
terminating simulations using the approximate settings presented in the paper [2].
The purpose of doing reproduction simulations is to compare the S-MAC model
implemented in ns-2 with that in Mote hardware and see how close one is to the
other. Our simulation results have shown quite good consistency between two S-
MAC implementations.
To analyze the long-run performance of S-MAC, we have run many steady-state
simulations and applied simulation control for each of them. We use three traffic
source models in our simulations, which include three statistical characteristics,
deterministic, exponential and exponential On/Off.

Through analyzing the simulation results, we have the following conclusions:

S-MAC with periodic sleep efficiently reduces the energy consumptions due to idle
listening. However, periodic sleeping increases latency and reduces throughput. The
adaptive listening largely reduces such cost and finds out a good balance point among
energy consumption, latency and throughput.
 81

Further work

1. S-MAC is being developed. Although we have found many problems and fixed
some bugs, we cannot guarantee that we have found all the problems and bugs in
current version of ns-2. Before the new version of ns-2 is released, debugging work
should be continued.

2. Multiple schedules for S-MAC.

In all our simulation scenarios, we only consider that all nodes on the network share
the same schedule. In fact, multiple schedules are quite common in practice,
especially in a large multi-hop network. The paper [3] has proposed a so-called
global schedule algorithm to make all nodes converge to a single global schedule,
and proposed a so-called fast path algorithm to help S-MAC find out a fast data
forwarding path in multi-hop transmissions. Therefore, studying these new features
of S-MAC should be our future work.

3. S-MAC with various duty-cycle settings

Duty-cycle is a use-adjustable parameter in S-MAC, which determines the length of
the sleep period in a frame. Changing the duty cycle will change the performance of
S-MAC. Therefore, simulating S-MAC using different duty-cycle values under
different traffic loads will be an interesting topic. Furthermore, considering very-
low-duty-cycle, e.g. 1% duty cycle would make more sense.

One suggestion

Except in ns-2, S-MAC has also been implemented in TinyOS on the Mote platform,
which reflects the latest development of S-MAC. Furthermore, current implementation
of S-MAC in ns-2.28 is not quite satisfying, because there are still many unsolved
problems and bugs in it. Therefore, investigating S-MAC implementation both in ns-2
and in TinyOS would be more helpful.
82

Bibliography

[1] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient MAC protocol for

wireless sensor networks. In Proc. IEEE Infocom, pages 1567-1576, New York,
NY, June 2002.

[2] W. Ye, J. Heidemann and D.Estrin. Medium access control with coordinated,
adpative sleeping for wireless sensor networks. ACM/IEEE Transactions
Networking, 12(3):493-506, June 2004.

[3] Y. Li, W. Ye and J. Heidemann. Energy and latency control in low duty cycle
MAC protocols. USC/ISI Technical Report ISI-TR-595, August 2004.

[4] A. M. Law, W. D. Kelton. Simulation, Modeling and Analysis, 3rd Edition.

McGraw-Hill, [2000].

[5] L. Bao and J. J. Garcia-Luna-Aceves. A New Approach to Channel Access

Scheduling for Ad Hoc Networks. In Proc. 7th Ann. Intl. Conf. on Mobile
Computing and Networking, pages 210–220,Rome, Italy, July 2001. ACM.

[6] V. Kanodia, C. Li, A Sabharwal, B. Sadeghi, and E. W. Knightly. Distributed

Multi-Hop Scheduling and Medium Access with Delay and Throughput
Constraints. In Proc. 7th Ann. Intl. Conf. on Mobile Computing and Networking,
pages 200–209, Rome, Italy, July 2001. ACM.

[7] C. Schurgers, V. Tsiatsis, S. Ganeriwal, and M. B. Srivastava. Optimizing Sensor

Networks in the Energy-Latency-Density Design Space. IEEE Transactions on
Mobile Computing, 1(1), 2002.

[8] A. Woo and D. Culler. A Transmission Control Scheme for Media Access in
Sensor Networks. In Proc. 7th Ann. Intl. Conf. on Mobile Computing and
Networking, pages 221–235, Rome, Italy, July 2001. ACM.

[9] L. Charlie Zhong, R. C. Shah, C. Guo, and J. M. Rabaey. An Ultra-Low Power and
 83

Distributed Access Protocol for Broadband Wireless Sensor Networks. In IEEE

Broadband Wireless Summit, Las Vegas, NV, May 2001.
[10] R. German. Simulation and Modeling I Lecture Notes in Computer Science.
Erlangen-Nürnberg University, Erlangen, Winter Term 2003/2004.

[11] SCADDS: Scalable Coordination Architectures for Deeply Distributed Systems

web page.http://www.isi.edu/scadds/projects/smac/

[12] NO Ad-Hoc Routing Agent (NOAH) web page.

http://icapeople.epfl.ch/widmer/uwb/ns-2/noah/

[13] The Network Simulator - ns-2 homepage.

http://www.isi.edu/nsnam/ns/

[14] The VINT project. The NS Manual. UC Berkeley, LBL, USC/ISI, and Xerox PARC.
http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf

[15] M. Greis. Tutorial for the network simulator ns.

http://www.isi.edu/nsnam/ns/tutorial/index.html

[16] The Network Simulator: Building Ns web page.

http://www.isi.edu/nsnam/ns/ns-build.html

[17] NsNam Site Search web page.

http://www.isi.edu/nsnam/htdig/search.html

[18] J. Chung and M. Claypool. NS by example

Worcester Polytechnic Institute. The Department of Computer Science.
http://nile.wpi.edu/NS/

[19] Smac-users -- Discussions by users of S-MAC web page.

http://mailman.isi.edu/mailman/listinfo/smac-users

[20] Energy Model Update in ns-2 web page.

http://www.isi.edu/ilense/software/smac/ns2_energy.html

[21] Trace Graph web page.

http://www.geocities.com/tracegraph/

[22] The Perl Directory at Perl.org. Perl version 5.8.7 document.

http://perldoc.perl.org/perl.pdf