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 SMAC 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.

but they will become active suddenly when something is detected. Wireless sensor networks are the integration of sensor techniques. an embedded processor.5 Chapter 2 S-MAC Protocol 2. The topology may change over time. sensor nodes are distributed within a vast expanse. and is normally battery-operated. A message is a meaningful unit of data that a node can process. messages will be processed in a store-and-forward fashion. instead of by accessing a base station. Sometimes their working environments are quite dangerous and even not accessible for humans. instead of being processed at a certain node in a centralized way. For saving energy. the abbreviation for Sensor-MAC.1 Overview of S-MAC S-MAC. distributed computation techniques and wireless communication techniques. Each node has one or more sensors. some nodes may move away. Wireless sensor networking technology is emerging in these years and becomes a popular research area of computer science and technology. is a medium access control (MAC) protocol designed for wireless sensor networks. and intelligent building systems. . and a low-power radio. The features for wireless sensor networks are listed as below: Such networks consist of many distributed sensor nodes. some nodes may die. They communicate and exchange information in a peer-to-peer way (ad hoc fashion). nested computation techniques. such as earthquake monitoring in desert area. Normally. In some applications. we can identify the following problems that we have to solve. sensor nodes in one network collaborate for a common application. As time elapses in a network. proposed by SCADDS project group at USC/ISI [11]. which is called innetwork data processing. such as environment monitoring. They can be widely used in many areas. medical systems. Sensor nodes keep silent for most of the time. From these features. when we design a good MAC protocol for wireless sensor networks. some new nodes may be added.

Take latency for example. radio communication consumes most of energy. such as IEEE 802. Latency. As viewed from hardware layer. Therefore. 2. Due to their working environments. we have identified the following major sources of energy waste. collision may occur when neighboring nodes contend for free medium. Exchanging control packets between sender and receiver also consumes some energy.11 ad-hoc mode. For contention-based MAC protocols. in order to perform effective carrier sense against possible collisions. recharging or replacing batteries for each node is difficult and uneconomical. bandwidth utilization. and lossy channel will result in corruption of transmitted packets. The second one is collision or corruption. As stated above. its importance depends on the actual applications. And radio will consume almost the same power as in receiving state. the usage of radio has close relation with MAC protocols. it puts nodes to listen to the channel all the time when nodes are idle. The third source is overhearing. for a wireless sensor network. idle listening is a dominant one. The foremost one is energy efficiency. throughput. Moreover. corrupted packets should be re-transmitted. the speed of changes on physical objects sensed by sensor nodes is much slower than the network speed. Normally.6 1. So latency is less important and can be tolerated in a certain range in such cases. Among existing wireless MAC protocols for shared-medium networks. 3. When either of two cases happens. fairness. So a good MAC protocol should accommodate to such changes. The last one is control packet overhead. To solve the energy problem. Scalability and self-configuration ability As described before. especially when the traffic load on the network is light. A considerable percentage of energy will be wasted on idle listening. The first one is idle listening. etc There are common attributes for most of MAC protocols. how to reduce the energy consumption to prolong the service lifetime of sensor nodes becomes a critical issue. sometimes even impossible. we should find out the sources of energy waste. which increases energy consumption. For most of sensor network applications. . which happens when a node receives some packets that are destined to other nodes. Among those factors for energy waste. sensor nodes are expected to be battery-equipped. its topology and size may change over time.

When hearing different schedules on its neighbors.1. the low-duty-cycle mode is the default operation for all nodes. In listen period. S-MAC tries to avoid overhearing by letting all interfering nodes. etc. Each S-MAC node puts the information of its own schedule in a SYNC packet and broadcasts it to its neighbors periodically. to synchronize nodes is a serious problem.4. In this way. This function divides a long message into a number of small . periodic neighbor list updating. the nodes will try to sleep by turning off their radios. as shown in Fig. schedule table and neighbor list maintenance. The features that S-MAC has adopted include physical and virtual carrier sense.11 standards. Periodic listen and sleep For schedule-based MAC protocols. In this aspect.3. how to avoid collision is a common topic for all contention-based MACs. S-MAC is quite similar with the DCF protocol in the IEEE 802. which are immediate neighbors of both the sender and receiver. Overhearing will become another major source of energy waste.1. RTS/CTS/DATA/ACK sequence for hidden station problem. Listen Sleep Listen Sleep time Fig. like latency and fairness. We talk about this problem in section 2. In S-MAC. especially when the node density is high and the traffic load is heavy in the network. which accordingly saves a lot of energy. The first feature that S-MAC introduces is periodic sleep and listen. The basic idea is as follows. To efficiently transmit long messages in both energy and latency respects. The basic idea is to let each node follow a periodic sleep and listen schedule.5. S-MAC defines a complete synchronization mechanism. When a new node joins the network. In shared-medium networks. will differ from other traditional wireless MAC protocols in the following aspects: energy efficiency and self-configuration ability are the primary goals. The duty cycle is defined as the ratio of listen period to a complete sleep and listen cycle.7 From the above discussion.2. S-MAC supports message passing. go to sleep after they hear an RTS or CTS packet. are secondary. To achieve maximum energy saving and improve latency. periodic neighbor discovery. the time spent on idle listening can be significantly reduced. More details about synchronization will be introduced in section 2. 2. including periodic SYNC packets broadcast. We introduce this feature in section 2. especially when traffic load is low. which is specially designed for wireless sensor networks. it will try to follow an existing schedule before choosing one by itself. the node wakes up for performing listening and communicating with other nodes. Now we introduce briefly what functions and features have been implemented in S-MAC. the node will record them in a table and follow all of them. we can figure out that S-MAC. The contents regarding this part are put in section 2. 2. while others attributes. When sleep period comes.

.8 fragments and transmits them in a burst.6. We will discuss all synchronization problems in S-MAC in section 2. the longer the message the node has. an additional chance for transmitting their packets at the end of the transmission. whose value is the ratio of the listen period to the frame length. But this is reasonable for wireless sensor network applications because of its features in aspects of data management. So there exists a potential delay on each hop. The second one called DATA period is designed for transmitting DATA packets. 2.3. The user can adjust the duty cycle value from 1% to 100% to control the length of sleep period. A complete cycle of listen and sleep period is called a frame. The first one called SYNC period is designed for SYNC packets. the more time it will occupy the medium. which are involved in a transmission. That is to say. When one node receives a data packet from its previous-hop node. Normally.2. The format of S-MAC frame is shown is Fig. 2. the listen period is normally fixed according to some physical and MAC layer parameters. the frame length is the same for all nodes in network. but requests an ACK packet for each fragment. We talk about message passing in section 2. when a data packet is transmitted through a multi-hop network. the node will turn off its radio if possible. S-MAC uses only a pair of RTS/CTS for one message passing. and all their immediate neighbors that overhear the transmission. In fact. which are broadcast packets and used to solve synchronization problems between neighboring nodes. it cannot retransmit the packet to its next-hop node right now. In this way. In this way. To reduce such latency. It has to wait until the next listen time for the next-hop node comes.7. Obviously in this way. the node may start sending or receiving packets if necessary. These nodes include the sender. a large amount of energy consumption caused by unnecessary idle listen can be avoided especially when traffic load is light. The basic idea is to give all nodes. S-MAC trades fairness on fragment level for fairness and latency on message level. S-MAC provides a controllable parameter duty cycle. During listen period. Low-duty-cycle operation reduces energy consumption at the cost of increased latency. S-MAC proposes an important mechanism called adaptive listening. a data packet can be retransmitted immediately after its last transmission. the receiver. The listen period is further divided into two parts. We discuss adaptive listening in detail in section 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. During sleep period. The RTS/CTS packets reserve the medium for transmitting all fragments.

only when all the following listed conditions are satisfied. For example. 2. if adaptive listening is not applied (adaptive listening is introduced in section 2.9 Listen SYNC DATA Sleep Guard time SYNC DIFS Contention window for SYNC durSync DATA DIFS Contention window for DATA durCtrl Proc Delay SIFS durCtrl Guard time Fig. In other words.3 below. . S-MAC will go to sleep by turning off its radio.7). 1 2 3 1 2 3 SYNC DATA Sleep SYNC DATA Sleep Fig. but also on some other factors. at checking point 3. Otherwise. My radio is not in receiving or sending state. In Fig. at checking point 2.3. Each schedule is controlled by a schedule timer. it will start carrier sensing. For example. If yes. which are called checking points. S-MAC checks if it has a data packet in the buffer to send. which can reschedule the next period when it expires at the end of a current period. The actions of S-MAC at a certain time depend not only on the current scheduled period. rather than start contending for the medium right away. neighbors’ state. 2. 2. radio state. S-MAC will never try to send any data packet in this frame. S-MAC will decide what to do in the coming period. S-MAC frame format Each S-MAC node should have at least one schedule to follow. channel state. even if S-MAC receives a new data packet from its upper layer right in the middle of the DATA period. Three checking points in a frame At any of these checking points.2. 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. it will buffer it and wait until the next checking point 2 comes. Those factors include current MAC state. we can see that each frame will have three expiration points. etc.

1 Synchronization Related Components in S-MAC SYNC Packet As mentioned before.10 If I have not only one schedule in my schedule table (a border node). neither a sender nor a receiver of an ongoing data transmission.3. I cannot go to sleep. each S-MAC node needs to exchange its schedule by periodically broadcasting a SYNC packet to its neighbors. we mainly talk about the basic idea of schedule mechanism in S-MAC. Table 2.1.3 Synchronization 2. I am not in a neighbor discovery period. but also other features of S-MAC.28.1. In latter sections. locates in path ns-2. such as overhearing avoidance and adaptive listening. Sending or receiving SYNC packets takes place in SYNC period. For example. (to be introduced in section 2.28\mac\ .3. (Primary schedule is introduced in section 2. The period of sending a SYNC packet is called the synchronization period. 2. you will see that not only the sleep and listen schedule.1) I am idle. can make the node go to sleep or wake the node up.4) I am not executing adaptive listening now. this checking point must belong to my primary schedule. please refer to the method SMAC::handleCounterTimer(int id) in the source file smac. if I have sent back a CTS packet to my neighbor in last DATA period and am now waiting for the data packet. (to be introduced in section 2. The SYNC frame Field type length srcAddr syncNode sleepTime state crc 1 Comment Flag indicating this is a SYNC packet Fixed size with 9 Bytes ID of the sender ID of the sender’s synchronization node Sender’s next sleep time from now Indicating if the sender has changed its schedule recently Cyclic Redundancy Check S-MAC source file in ns-2.7) To know more about the behavior of S-MAC at each checking point. The default value in ns-2 is 10 frames (one frame = one sleep and listen cycle). The definition of SYNC packet frame in ns-2 is shown in Table 2. In this section.cc1 in ns-2.3.

Schedule Table Each S-MAC node maintains one schedule table. But every node should have a primary schedule. And we know that some neighboring nodes can get synchronized through exchanging SYNC packet between them.2. and nodes with neighbors in two or more clusters border nodes. To avoid synchronization errors caused by clock drift on each node. There are two classes of schedules in the schedule table. The maximum number of records in the table is limited by a user-adjustable S-MAC parameter. The existence of multiple schedules in a network is quite common. The establishment of the schedule table will be introduced in the next subsection. A node may have no secondary schedule. the sleepTime uses a relative value rather than an absolute time. which stores its own schedule and the schedules of all its known neighbors. 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. We take a simple example to illustrate how a border node works under multiple . Obviously. These timers run independently and their workings are quite similar. But in practice this mechanism takes effect only locally. We call those nodes that share the same schedule a virtual cluster.2. if all its neighbors follow the same schedule. especially in a large multi-hop network where nodes do not start initializing at the same time and join in a random way. because sleep durations and energy saving will be maximized when all nodes are on the same schedule. Both primary schedule and other secondary schedules have their own timers. if the border node wants to talk to its neighbors at their scheduled listen time.11 From the table above. it has to know when its neighbors wake up and go to sleep. shows how each field in the schedule table is defined in ns2. We intuitively hope that only one schedule exists in the whole network. Field definition of schedule table Field txSync txData numPeriods numNodes syncNode chkSched Comment Flag indicating need to send sync Flag indicating need to send data Counter for sending sync periodically Number of nodes on this schedule The node who initialized this schedule Flag indicating need to check numNodes Now we explain why S-MAC introduces such a table. Table 2. for example. which defines the maximum number of different schedules. A schedule is actually a timer. Schedule table is designed for this purpose. We call the schedule that the node itself is on primary schedule and other schedules in the schedule table secondary schedules. Table 2.

studying S-MAC under multiple schedules is not the intention of this thesis. Suppose B receives a data packet destined to C from the upper layer. One takes place on A’s DATA period and the other on C’s DATA period. When B has a data packet to broadcast. A border node with two schedules We first see how B broadcasts SYNC packets. However.4. it has to broadcast it twice. 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. When C’s next DATA period comes. B will allocate a schedule timer for either of the two schedules. 2. border nodes will consume much more energy than non-border nodes. which is the same as A’s. B has to broadcast its SYNC packets periodically on both schedules. This algorithm has been implemented in S-MAC in ns-2. As shown in Fig. but not to any of its secondary schedule. and it sets the txData flag on that schedule to 1. . in a SYNC packet.4. One is its own schedule (primary schedule). Obviously.28. and the other is heard form C. A SYNC DATA SYNC DATA B SYNC DATA SYNC DATA SYNC DATA SYNC DATA C SYNC DATA SYNC DATA Fig. 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. The two schedule timers run independently. a border node always tells its neighbors the time from now to its next sleep time according to its primary schedule.12 schedules. B has two schedules in its schedule table. Please note that. The similar way is applied to broadcast data packets. it first searches in its schedule table to find out the schedule that C is following. We assume that node B has two neighbors node A and C. 2. we can see that a border node has to follow several schedules to get synchronized with its neighbors that are on the different schedules. From the above discussion. To ensure that both A and C can receive the SYNC packets in their own SYNC period. Now we discuss unicast data packets.

The number of records in the list is also limited by a user-adjustable S-MAC parameter. Normally the first cycle starts with SYNC period. the flag txSync of this schedule is set.13 Neighbor List Another important component in S-MAC is neighbor list. Table 2. neighbor list is established also through exchanging SYNC packets between neighboring nodes. Table 2. At end of this period. the node chooses a schedule by itself and sets a schedule timer for it. instead of choosing by itself after the initial listening. When S-MAC processes a unicast data request received from the upper layer. Then when the next DATA period on this schedule arrives. which indicates that the node will try to broadcast a SYNC packet in the next SYNC period. Get a SYNC packet before the initial listening ends. Like schedule table. the request will be refused. If not.3 below shows the definition for each field in neighbor list. 2. That is the node’s first SYNC packet received. the node will try to send out this packet. If yes. it will first check its neighbor list to see if the destination node is on the list. 2. Meanwhile the schedule is added to the first entry of the .2 Choosing First Schedule When a new node joins the network.3. Each S-MAC node has to set up such a table to records the information of all its known neighbors. The value of sleepTime in the SYNC packet determines the starting point of the first cycle. Field definition of neighbor list Field nodeId schedId active state Comment ID of this node Schedule ID in schedule table that this node follows Flag indicating this node is active recently Flag indicating the node has changed schedule Neighbor list plays an important role in S-MAC. It immediately follows the schedule that comes with the received SYNC packet. the flag txData of the schedule that the destination node follows is set (if no other sending request). No SYNC packet received during the initial listening. which defines the maximum number of neighbors for each node. it first listens for a fixed period (normally a synchronization period). We call this period initial listening. 1. Meanwhile the schedule is added to the first entry of its schedule table.3. Either of the following two cases may happen. To announce this new schedule.

This is my first SYNC packet. One is defined inside the JOURNAL_PAPER2 code and the other outside. 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. 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 sender of the SYNC packet is added to the neighbor list. 1. For simplification.h. Of course. The method implementing this algorithm in smac. 2 A macro defined in smac. we use N representing the sender of this SYNC packet and S representing the schedule in the SYNC packet. In this subsection. 2. the S-MAC header file in ns-2 . the node that sent this SYNC packet will be added to my neighbor list (my first neighbor). because most of our simulations use the JOURNAL_PAPER code. This may happen only after I have chosen my first schedule by myself (option 1 in last sub-section). And the schedule timer that is associated with the discarded schedule will be rescheduled according to the value of sleepTime in the SYNC packet. The algorithm for handling received SYNC packets is listed as follows.cc of ns-2.28. we consider only the inside one. there are two such methods with the same name are defined in smac.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. This is not my first SYNC packet after I have chosen my first schedule. In this case.3. which are mutually exclusive at the compiling time. In this thesis.14 schedule table. We have to consider the following five possible situations. However. 2. The algorithm is put in Table 2.cc is SMAC::handleSYNC(Packet *p).4 below. The node also needs announce this schedule by setting the flag txSnyc in this schedule.

which is an existing one in my schedule table. but S is known in my schedule table. Step3: If the schedule that N switched from is my primary schedule. Step2: Process the schedule S that N has switched to. If the number goes to 0 after decrease. Step1: Process the schedule that N switched from. Otherwise N has to be deleted from my neighbor list. I have to choose the next available schedule in my schedule table and set it as my new primary schedule (delete the old one). I must defer check_my_schedule until the current sending is over. If now I happen to have a DATA sending request. If my neighbor list is not full. I need to execute check_my_schedule. S is added and assigned to a new schedule timer. And the number of nodes on S is increased by one. 3 N is a known neighbor in my neighbor list. add S to my schedule table and assign a new schedule timer to S. which checks if I become the only one on my primary schedule. since I got its last SYNC packet. but it has switched its primary schedule to S. this schedule has to be removed from my schedule list. 2 Step1: Process the schedule that N has switched from. If my schedule table is not full. N is a known neighbor in my neighbor list. Update S in my schedule table by rescheduling its schedule timer with the value of sleepTime in the SYNC packet. N is an unknown neighbor to me. And the number of nodes on S is increased by one. this schedule has to be removed from my schedule list. The number of the nodes on the schedule that N used to follow has to be decreased by one. Action Update S in my schedule table by rescheduling its schedule timer with the value of sleepTime in the SYNC packet.15 Table 2. If neither my schedule table nor neighbor list is full.4. But if now I happen to have a DATA sending request. If yes. General algorithm for processing SYNC packets 1 Condition N is a known neighbor in my neighbor list and it has not changed its primary schedule since I got its last SYNC packet. . This can eliminate clock drift between two nodes. which is new to me. I must defer changing till the sending is over. The number of the nodes on this schedule has to be decreased by one. I must defer changing till the sending is over. Update S in my schedule table by rescheduling its schedule timer with the value of sleepTime in the SYNC packet. Then add N to my neighbor list. N is added to it. If the number goes to 0 after decrease. If now I happen to have a DATA sending request. but it has switched its primary schedule to S. Step2: Process the new schedule S that N has switched to. 4 5 N is an unknown neighbor to me and S is also new to me. since I got its last SYNC packet.

16 2.5 shows how the neighbor discovery period is defined and its relationship with other periods defined in S-MAC. sometimes two neighboring nodes may miss each other forever. The reason for it will be . However. but also avoid unnecessary energy consumption caused by keeping trying to talk to an inactive neighbor. when they follow different schedules. Except that.4 Periodical Neighbor Discovery In S-MAC. the node will not try to go to sleep when scheduled sleep period arrives. neighboring nodes discover each other through exchanging SYNC packets. 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). Doing this is necessary and important. which need to be removed from the neighbor list. For a border node. 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. especially in a multi-hop mobile sensor network. S-MAC will never try to go to sleep when its sleep period comes. Fig. the period is much longer and reaches 33 synchronization periods. so that the node can listen more time than usually and have more chances to hear a new neighbor. SYNC DATA Sleep One Frame One Synchronization Period = 10 Frames Neighbour Discovery One Neighbour Discovery Period = 2 or 33 Synchonization Periods Fig. A timer is allocated to control periodical updating of the neighbor list. the period of executing neighbor discovery is 2 synchronization periods if the node has no neighbor. The basic idea of neighbor discovery in S-MAC is to make each node periodically execute neighbor discovery for a whole synchronization time. Its expiration period must be larger than the synchronization period. for example.5. whose SYNC periods do not overlap. because it cannot only save space for the neighbor list. Otherwise. neighbor discovery is only executed on its primary schedule. The neighbor discovery period may vary. During neighbor discovery time. Periodical neighbor discovery can prevent this from happening.3. Hierarchy of periods in S-MAC 2. 2. In ns-2. The reason is that on secondary schedule. depending on the current number of its known neighbors.

If yes. Accordingly. the flag is reset. We assume the period for updating neighbor list is smaller than synchronization period. If no. update_neighbList()) Step 1: Check if I have a DATA sending request now. from now. This may happen when I got a SYNC packet from one of my known neighbors. (In ns-2.4 Part 2. But at that time I had a DATA sending request. Check each record in my neighbor list to see whether its active flag is set or not. Step 4: If the inactive neighbor nodes that I dropped in step 3 are on my primary schedule.) Step 2: Update the number of nodes on a certain schedule if its flag chkSched is set. (Relevant methods in the source file smac.17 explained later. the following steps will be executed. this neighbor node has to be deleted from my neighbor list. which prevents S-MAC from receiving a new request from the upper layer. And now is time to do it.cc in ns-2. and A can always receive SYNC packets from B . Now we explain the reason why the period for updating neighbor list must be longer than the period for synchronization. Fig. this is done by setting the flag txRequest to 1.6 shows an example. I will be temporarily disabled from receiving new requests from the upper layer to avoid error operation during updating. (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. the number of nodes on the schedule that the deleted neighbor used to follow should be decreased. Step 3: Update neighbor list. 2. When the timer expires. which had switched to another schedule since I got its last SYNC packet. this schedule has to be removed from my schedule table. skip the following steps and defer updating till the current sending is over. 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). If yes. and I should decrease the number of nodes on the schedule that this neighbor had switched from.28 includes handleUpdateNeighbTimer(). which has been introduced in Table 2. update_myNeighbList(). which has two neighboring nodes A and B. I have to execute check_my_schedule.) If no. so I had to defer decreasing. If after decrease the number becomes 0. Step 5: Reset the timer to schedule next neighbor list updating and enable receiving new requests from the upper layer again.

S-MAC looks like a schedule-based MAC protocol. Neighbor list updating period smaller than synchronization period 2. It is easy to imagine that. A cannot talk to B. . we will introduce the CSMA/CA mechanism in SMAC.11 protocols. A thinks that B has not been active recently and removes B from its neighbor list. at the second updating time for A (red arrow).4. because A has not got B’s SYNC packet since last time when it updated its neighbor list. carrier sense in S-MAC is performed both through physical and virtual mechanisms.6. e. However. Every time when the radio starts receiving or transmitting.4 CSMA/CA in S-MAC S-MAC achieves energy saving mainly by utilizing the schedule mechanism.18 successfully. especially like the DCF (Distributed Coordination Function) in IEEE 802. In this section. Physical carrier sense is performed at physical layer by checking the current radio state. S-MAC is more like a contention-based MAC protocol. We can see from the figure that A executes neighboring list updating twice in one synchronization period for B. From this point of view. The schedule controls nodes’ periodic sleep and listen.g. 2. this is not true. including carrier sense (including physical and virtual mechanisms) and RTS/CTS mechanism for collision avoidance and hidden station problem. The medium is determined as free only when both of them indicate that it is free. because B keeps active all the time. the PHY layer will inform the MAC thereof. TDMA. However.1 Carrier Sense Like DCF in 802. B will become unknown to A until B’s next broadcasting time comes. In this blank period. 2. with respect to transmission control and collision avoidance.11. It happens also when the receiving or transmitting is over. because it takes it for granted that B is not active. A Neighbour List Updating Period Blank for B B Synchronization Period A updates B A deletes B B Broadcasts SYNC Packet Fig.

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. The similar virtual carrier sense mechanism is also applies to S-MAC. 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. When non-zero. We know that in 802. Virtual carrier sense indicates that the medium is idle. which is actually a counter. just the same as in 802. only if the duration value is larger than the current NAV value. the indication is busy. when the NAV value is zero. One is simply called NAV and used to indicate if the medium is busy or not. Table 2. The other one is called Neighbor NAV.11. we can see that one node uses its NAV for virtual carrier sense when it interferes in one of its neighbor’s transmission.19 Obviously. However. the virtual carrier sense indicates the medium is free. When a node receives a packet destined to another node. The node’s NAV will be updated with the duration value. The structure of and the way of running for two NAVs are quite similar. unlike that in 802. the duration value in the packet will tell the node how long it has to keep silent. each station maintains a so-called network allocation vector (NAV).11.5. which tracks its neighbors’ NAV. Differences between NAV and Neighbor NAV NAV Receive RTS destined to other node Receive CTS destined to other node Neighbor NAV Receive RTS destined to me 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. If not mentioned. Only when both of the NAVs have counted down to zero.11. the medium will be determined as busy when radio is in receiving or transmitting state.5 lists all events that make two NAVs update their values. S-MAC defines two NAVs. 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. Virtual carrier sense is performed at the MAC layer. Table 2. and uses its Neighbor NAV when it is either a sender or a receiver during a transmission process. Besides their .

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. the node will retry sending. Here we consider only S-MAC without adaptive listening. Then the node starts physical carrier sense. we find that there are two contention windows defined in one frame. Going back to Fig. it will be awoken first. In the above discussion. 2. the node will assume that the medium is free and start transmitting the packet right away. it will follow the same procedures described above. When the same period in the next frame arrives.20 functions for virtual carrier sense. the node will be ready to broadcast a SYNC packet. One of two following possibilities may happen during this period. Neighbor NAV will act as a timer for DATA timeout on the node. When the schedule timer expires at the end of the sleep period indicating the coming of a new SYNC period. If nothing is heard throughout the whole carrier sense period. it will check the conditions for sending a SYNC packet. Once the medium is sensed busy during the carrier sense period. The duration for carrier sense is chosen uniformly within the contention window and consists of a DIFS. If the radio is in sleep state. If the syncFlag on this schedule is set and both of the NAVs have zero values (virtual carrier sense indicates free medium). if adaptive listening is applied (We will discuss adaptive listening in section 2. 31 slots for SYNC and 63 for DATA. The following steps are also applicable to sending a DATA packet in the DATA period. 1. 1. Now we take a simple example and see how carrier sense is performed before sending a SYNC packet in the SYNC period. the node will stop sensing and defer sending the packet. e.11. S-MAC always chooses the number of slots for carrier sense within the fixed contention window size. Actually.2. which has sent out the CTS packet and is waiting for the arrival of the DATA packet. One is for sending SYNC packets in the SYNC period and the other is for sending DATA packets in the DATA period.7). S-MAC obtains a transmission chance through contending for the medium in a contention window. While retrying. which must be 2n-1.g. S-MAC can have a third contention window in the sleep period. uniformly and independently. Both contention windows have fixed size (fixed number of slots). This is not like the binary exponential back off introduced in 802. . 2. the NAVs also play other roles in S-MAC listed as below.

This medium reservation technique has been introduced into S-MAC.g. But only unicast packets follow the sequence of RTS/CTS/DATA/ACK. And the reservation information is recorded in the duration field of RTS/CTS/DATA/ACK packets. The carrier sense does not start immediately and needs to wait until the next DATA period comes. the sender should exchange RTS and CTS packets with the receiver. A receives a sending request destined to B from the upper layer. both A and B will still have time to sleep.7 below shows one possible case. 2.1 is achieved by distributing reservation information announcing the impending use of the medium. In this sub-section. It is fixed according to some physical-layer and MAC layer parameters. 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. If two neighboring nodes finish carrier sense and start sending at almost the same time. 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. we discuss unicast packet only.4. 10%). the whole transmission process can be done in one frame and will not be prolonged to the next SYNC period. RTS/CTS packets will reserve for the whole transmission process. In the following example. e. the exchange of RTS and CTS can always be done within the DATA period if no collision and corruption occurs. So in normal cases. Normally. We have learnt that the virtual carrier sense mechanism introduced in subsection 4. But the transmission of the DATA packet normally needs to be extended to the schedule sleep period. If adaptive listening is not applied. Actually the length of DATA period is carefully designed. 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).g. Consider two neighboring nodes A and B. which follow the same schedule and have discovered each other. 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. Although the combination of carrier sense and RTS/CTS mechanisms can largely reduce the probability and durations of collisions.2. A will follow the steps described in last sub-section to start carrier sense. the radio bandwidth and the contention window size. S-MAC is working under a relatively low duty cycle (e.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. the transmission between A and B ends before the next SYNC period. Broadcast packets will be sent without using RTS/CTS. The sleep period in a frame is much longer than the DATA period.21 2. Prior to the actual DATA packet. collisions cannot be completely avoided. collision will occur. . Fig. We also assume that A does not have any other sending request at present.

When the retry times reach the maximum number. 2. A’s CTS timer expires. Obviously. A successful data transmission between two nodes Now we see what will happen when collision occurs. If now A’s primary schedule is in the sleep period. When the next DATA period on the same schedule comes. After a short wile. 2. nodes that interfere their neighbors’ transmissions will not hear DATA packets. two RTS packets collide. carrier sense. The best way to achieve it is to let each node keep listening to all its neighbors’ transmissions. In this way. A will go to sleep by turning its radio off. .11.5 Overhearing Avoidance For contention-based protocols like IEEE-802. If B also sent out the RTS at almost the same time when A sent the RTS out. saving energy is its primary goal. To avoid overhearing.11. and following ACK packets. To achieve better performance in a shared-medium network. For S-MAC.8 to illustrate this algorithm. which normally take much longer transmission time than control packets. S-MAC forces interfering nodes to go to sleep after they receive an RTS or a CTS packet that is not destined for them. A will resend the RTS. In 802. The maximum number of RTS retries for sending a DATA packet is user-adjustable in S-MAC. this method will lead to large amounts of energy consumptions on overhearing. 2. measures like latency and bandwidth utilization are considered in the first place. overhearing is one of the major sources of energy waste.7. A will give up sending the DATA packet and signal its upper layer about the failure of sending. especially when node density is high and the traffic load in the network is heavy. especially virtual carrier sense should be performed more efficiently. Overhearing takes place on a node when it receives some packets that are destined for other nodes. Neither of them will receive the RTS packet from the other and send a CTS packet back. We take an example in Fig. The same procedures will be followed when B’s CTS timeout timer expires.22 Carrier Sense Tx RTS Got CTS Tx DATA Got ACK A B Schedule Got RTS Tx CTS Got DATA Tx ACK DATA Period Sleep Period SYNC Fig.

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

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

2. 2. application-level performance for each node can be improved greatly. in this way. adaptive listening is the dominant technique that S-MAC has proposed to efficiently and largely reduce the latency in a multi-hop transmission. Although both synchronization mechanism and message passing mechanism have decreased the latency to a certain degree. message passing will provide some opportunities for re-transmitting the lost or corrupted fragment. one fragment is corrupted during the transmission and the original reserved time for the whole transmission has to be extended. D goes to sleep right after it has received the CTS from B. Suppose there are four nodes A. if compared to the traditional MAC protocols. as shown . It will know the extended transmission time from the ACK packet and go to sleep again. However. SIFS SIFS SIFS SIFS SIFS SIFS SIFS RTS Sender Fragment 0 Fragment 1 Fragment 2 CTS Receiver ACK 0 ACK 1 ACK 2 NAV (RTS) NAV (CTS) NAV (Fragment 0) NAV (ACK 0) NAV (Fragment 1) NAV (ACK 1) NAV (Fragment 2) Fig. the scheme of periodic listen and sleep contributes the most.25 neighboring nodes. B. the schedule mechanism will increase the latency of sending packets in a multi-hop network. That is what sensor networks desire. On the other hand.7 Adaptive listening In this section. we introduce adaptive listening.9. which is one of the most important and attractive features in S-MAC. In the previous sections. This approach seems to be unfair to those nodes that have a short message to send. C. which can only hear the receiver. 2. again in Fig.8. When the original reserved time is over. and D. However. update their NAVs in time. we have mainly discussed how S-MAC reduces energy consumptions. which are put in a line. D may wake up from sleep. Among those techniques. we find that the message passing mechanism in S-MAC can effectively reduce the control overhead in transmitting a long message. When the sender fails to get an ACK for any fragment. For example. RTS/CTS/DATA/ACK and NAV settings in message passing From the above discussion. Let us look at an example to see how S-MAC transmits a packet in a three-hop linear network. instead of giving up the transmission immediately and re-contending for the medium. by sending all fragments in a burst and using only a pair of RTS/CTS for it.

Source Sink A B C D Fig. without adaptive listening Now we consider the case if adaptive listening is applied. We assume all nodes share the same schedule and no message passing technique is applied.10. receiver. 2. R Data A B C A R Data C C A R Data D C A Schedule S D Sleep S D Sleep S D Sleep Frame n Frame n+1 Frame n+2 R RTS C CTS Data DATA A ACK S SYNC Period D Scheduled DATA Period Fig. 2. A is the source and D is the sink. because checking to send the data packet only takes place at the beginning of each DATA period. and neighbors of both them that overhear this transmission. it has to wait until the next DATA period comes. Transmitting a data packet through a three-hop network. one node may . which are involved in this transmission including sender. when each node strictly follows its sleep schedule. When adaptive listening is not employed.10.11. The basic idea is that at the end of one transmission. S-MAC will give those nodes.11.26 in Fig 2. A three-hop network with one source and one sink We first see the case shown in Fig. Each node can hear only its immediate neighbors.11 that we need three frames to transmit the data packet from the source A to the sink D. In this way. Now a data packet is generated at the source node and destined to the sink node. each node has at most one chance to send the data packet out in each frame. The data packet travels only one hop in each frame. If the arrival of the data packet at a certain node misses this checkpoint of this frame. another chance of transmitting data packets. That is to say. We can see from the Fig. there is a potential delay on each hop. 2. 2.

As shown in Fig. give up executing the following steps and exit. The reason for executing this step will be explained later in this section.27 have two DATA periods for sending or receiving data packets in a frame. 2. 2. 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 satisfies this condition. R Data A B C A R Data C Sleeping C A R Data D C A Schedule S D ALP Frame n S D Sleep S D Sleep Frame n+1 Frame n+2 R RTS C CTS Data DATA A ACK S SYNC Period D Scheduled DATA Period ALP Adaptive Listen Period Packet transmitted in adaptive listening Fig. which is the time reserved for the current transmission. If yes. while C is overhearing this transmission and will use its NAV for virtual carrier sense. go step 2. Transmitting a data packet through a three-hop network. 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. 2.4. 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. We use Fig. And we assume the example in Fig. We have known from the previous sub-section 2. 2. Check if the remaining time in current frame (from now to the next listen time) is shorter than a DATA period. 2. . Otherwise.12 below to illustrate how adaptive listening functions in S-MAC.12). Both NAV and Neighbor NAV contain the same value.1 that both the sender A and the receiver B will use their Neighbor NAVs to perform virtual carrier sense.12. Set a timer (called adaptive listening timer) to bring me back to sleep (if conditions allow me to sleep at that time). 1). with adaptive listening We start with the transmission between A and B.12. The following universal steps will be executed when adaptive listening is triggered at a certain node.

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

B

C

A

R

Data

C

Sleeping

C

A

Schedule

S

D
Frame n

ALP

S

D
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

B

C

A R

Data

C

Sleeping

C

A R

Sleeping

R

Data

D

Sleeping

C

A

Schedule

S

D

ALP

ALP
Frame n

S

D

Sleep

Frame n+1

R

RTS

C

CTS

Data

DATA

A

ACK

S

SYNC Period

D

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 objectoriented 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.

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

33 to see if there is a new updated version available. there will be small updates in daily snapshot. You are suggested to subscribe to ns-users mailing list. the mailing list is the first place where you should go for help. There you can search the contents of all the publicly available WWW documents and mailing list archives at Ns and Nam's site. . The web page for subscribing to S-MAC mailing list is http://mailman. 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. if you want to communicate with other ns users throughout the world.edu/mailman/listinfo/smacusers. For S-MAC users. If you do not like to receive tens of mails sent by the mailing list everyday. Though ns-2 formal release version is not likely updated frequently. named “Search ns web pages”). you can directly use the search function provided by the ns official web site. quite often you can get a surprise and find what you want there.isi. which can be linked from the ns homepage (the link is at the bottom of that page. 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). Especially when you encounter a hard problem. a mailing list for discussing or announcing S-MAC related problems has also been created. No matter in mailing list or on search web.

because it implements some important features of S-MAC. the network simulator.cc.1. can be found in the path ns-2. If you want to use the most recent updated and debugged version. we have to consider JOURNAL_PAPER code. you have to download a new ns-2 daily snapshot or update to the latest CVS.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.28\mac\. this version is still not the final version for S-MAC.2). because we found a portion of code still in testing. In this thesis. The latest official release is integrated in ns-2. For our purpose of study. we study S-MAC with ns-2 and install the ns-2. The detailed descriptions of these features have been presented in chapter 2.h and smac. More information about the updating of ns-2 and S-MAC can be found on the ns-2 homepage [13].28 all-in-one version on the SUSE Linux system (Professional 9. We list all features of S-MAC that have been implemented in ns-2-28 as follows.28.34 Chapter 4 Simulating S-MAC with NS-2 4. We call this portion code JOUNAL_PAPER code. the source files (in C++) for S-MAC. because a macro named JOURNAL_PAPER controls compiling this portion code. S-MAC has been also implemented in ns-2. smac. 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. which needs real hardware as its running platform.1 S-MAC in NS-2 4. it is not suitable for us to study S-MAC in a simulation way.28. . But as a hardware implementation. Most of the features proposed in the paper [2] have been implemented in this version. But. After installation. By default. such as adaptive listening and message passing.

1 below. If not set. S-MAC Interactive Parameters Name syncFlag_ Comment If it is set to 1. We call those parameters. 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. All three interactive parameters are listed in Table 4. ns-2 uses the default value 10%. and physical layer parameters.1. For example. internal S-MAC parameters. dutyCycle_ The value of duty cycle in percent. SMAC runs without periodic sleep.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. It controls the length of sleep. . interactive parameters. Some other parameters will be assigned at the start of the simulation run.1. selfConfigFlag_ If it is set to 1. S-MAC runs with periodic sleep. including user adjustable S-MAC parameters.h. the sleep time and cycle time (frame time) depend on the value of duty cycle that users have set in the tcl script. This parameter is active only when syncFlag_ is set to 1. the schedule start time (first listen period start time) for each node is user-configurable.3. because their values depend on some interactive parameters. all S-MAC nodes follow the schedule initialization algorithm described in section 2. Table 4. which can be set in tcl scripts in an interactive way. If it is set to 0. If it is set to 0.2 S-MAC Parameters Settings All preset parameters for S-MAC can be found and modified in the header file smac.

which are listed as below: Mode 1: S-MAC without periodic sleep If the parameter syncFlag_ is set to 0. In this mode. That is. each node does not follow periodic sleep and listen cycle and runs in a fully active mode.36 4. Please note that in ns-2. listed in sub-section 4. but without adaptive listening If the parameters syncFlag_ is set to 1 and JOURNAL_PAPER code is not compiled.1. a segmentation error will occur during the simulation run. will not be supported. S-MAC can be configured to run under three modes. only the basic features listed in sub-section 4. S-MAC will work under this mode. the node will go to sleep when it overhears its neighbor’s transmission. such as adaptive listening and message passing. Mode 2: S-MAC with periodic sleep. The reason is that the JOURNAL_PAPER code is not designed to support S-MAC running in mode 1. SMAC will work in this mode. we cannot set S-MAC to mode 1 in the case of JOURNAL_PAPER defined. .1. we cannot set S-MAC to this mode in the case of JOURNAL_PAPER defined.1. Mode 3: S-MAC with periodic sleep and adaptive listening. If we use the JOURNAL_PAPER code and then set the flag syncFlag_ to 0.28 We have found the following problems and bugs for S-MAC in ns-2.28. some features like message passing.28. No adaptive listening and message passing are available in this mode. But overhearing avoidance is still available in this mode. we can simulate all features of S-MAC.1 are available.4 Problems and Bugs of S-MAC in NS-2. which are only available in the case of JOURNAL_PAPER defined.3 S-MAC Modes For the purpose of comparison. Segmentation error As mentioned before. 4. if we simulate S-MAC in mode 1. In this mode.1. If we compile JOURNAL_PAPER code in S-MAC source code and set syncFlag_ to 1.1. That is to say. we cannot simulate S-MAC in mode 1 if JOURNAL_PAPER is used. In other words.

In above code. because we are not very clear about the author’s real intention. But we do not change it. you may take notice of such a confusing phenomenon.37 Constant data packet size at MAC layer When you run S-MAC without using the JOURNAL_PAPER code. The default value of this macro found in smac. if (fragNum == 0) fragNum = 1. some information in the message may get lost during the fragmentation process.cc and listed as below. The equal fragment size is SIZEOF_SMAC_DATAPKT. . see below. For example. S-MAC will send all data packets with a uniform size. One problem in message passing The message passing mechanism has been implemented in JOURNAL_PAPER code. to calculate the duration for transmitting this packet. instead of the packet’s actual payload. For message passing. regardless of their actual payloads. int fragNum = ch->size_ / SIZEOF_SMAC_DATAPKT . In our simulations with message passing disabled (JOURNAL_PAPER not compiled). It would not be a difficult task for us to fix this problem. if payload is 120 Bytes and SIZEOF_SMAC_DATAPKT is 50 Bytes. The number of fragments is calculated by a division operation and the result is converted to an integer number forcibly. S-MAC in ns-2 divides a long message into an integer number of equal-size fragments. we can simulate S-MAC using CBR traffic source with different packet size. you will find that it defines a macro called SIZEOF_SMAC_DATAPKT. Handler *h) in smac. Checking the source code of S-MAC. So we replaced the above code with the following. Obviously in this way. For simplification.h is 50 (Bytes). S-MAC always uses this macro value. the situation will be different. because it seems to be an author’s temporary solution. When S-MAC is sending or receiving a data packet. ch->size_ stands for the actual payload of the packet. we get only 2 fragments with size 50 Bytes each. Obviously this is unreasonable. But if JOURNAL_PAPER code is compiled and message passing is enabled. But we do not think this is a bug for S-MAC. The code for calculating the number of fragments can be found in the method SMAC::sendMsg(Packet *pkt. by directly modifying the value of SIZEOF_SMAC_DATAPKT (need to recompile S-MAC before running).

if (ch->size_ % SIZEOF_SMAC_DATAPKT != 0) { fragNum ++.sched(SMAC_UPDATE_NEIGHB_PERIOD*CLKTICK2SEC(cycleTime_)). we have explained the reason why the period for updating neighbor list should be longer than the period for synchronization. although we have to send additional bits for it. According to the following code in the construction function SMAC::SMAC() in smac.38 int fragNum = ch->size_ / SIZEOF_SMAC_DATAPKT .h. while the length of one frame depends on the value of duty cycle we use.221 s 1.cc.123 s Synchronization Period 112. Wrong value for neighbor list updating period We have introduced periodical neighbor list updating in sub-section 2. because it is 5 times longer than the synchronization period and independent of the duty cycle. That is more reasonable. } After modification. It now seems more reasonable. Its default value is 50. Table 4.21s 11. Table 4. In subsection 2. . it seems that the period is 50 seconds. The period for updating neighbor list is defined by a macro SMAC_UPDATE_NEIGHB_PERIOD in smac. But this is not a safe value.5. Since this is just a number defined in the code. The modified code is shown as bolow. (mhUpdateNeighb_ is the timer for updating neighbor list periodically) mhUpdateNeighb_.3.23 s So we have to change the period for the neighbor list updating from 50 s to 50 frames. because it may result in unexpected errors. mhUpdateNeighb_.5.2 Synchronization period vs.sched(SMAC_UPDATE_NEIGHB_PERIOD).3. The default value for synchronization period is 10 frames. we have to know its unit.2 below shows that when the duty cycle is 1%. a message with 120 Bytes will be divided into 3 fragments with each 50 Bytes. the synchronization period is longer than 50s. Duty cycle Duty cycle 1% 10% One Frame Length 11.

we talk about how S-MAC receives packets from its upper layer.cc that callback is missing. the Ifq will pass the packet to S-MAC as soon as it gets a new one from the link layer.} else { txMsgDone(). S-MAC will discard the packet and give up sending. a callback is missing here. In S-MAC. should signal upper layer before return . cannot send pkt\n"). S-MAC will not receive any packet from the Ifq from then on. Obviously. In a word. But we found somewhere in the source file smac. Packet *p). If not. Then the Ifq dequeues a packet and passes it to S-MAC. In ns-2. should signal upper layer before return return 0.} // debug here. If the Ifq is empty now. So it needs a buffer for storing packets from the upper layer. and we always use its default value 50 in our simulations. it has to inform the Ifq about it (we call it callback in ns-2). So we must add this method before the return statement (code in red). the callback is implemented in the method txMsgDone(). txMsgDone(). That is. // debug here. The consequence is that once this “Neighbor unknown” event happens for some reason. Two such errors are found in the method SMAC::unicastMsg(int numfrags. } The above code checks if the destination node that the received data packet is destined for is in the neighbor list. Like other MACs. S-MAC can only process a sending request at a time. S-MAC is directly connected to a queue module called Interface Queue (Ifq). no sending. The first error place is shown as below. The same code as the following can be found also in the method SMAC::bcastMsg(Packet *p). if SMAC doesn’t do callback. The second error place in the same method is shown as below. the workings for Ifq can be described as no asking. return 0. The queue size for Ifq is user-adjustable in ns-2. if (txRequest_ == 0) { txRequest_ = 1. which may result in occasional errors when running S-MAC. If (found == 0) { printf ("Neighbor unknown. Every time S-MAC has finished the current sending request (successful or unsuccessful). Ifq will never send packets to it automatically. if it is not empty. which buffers packets from the link layer. which will be called when S-MAC receives a new unicast packet from the Ifq.39 S-MAC callback missing First.

4.5. All nodes share the same schedule. But if the JOURNAL_PAPER code is considered. a callback statement txMsgDone() is missing before return statement. When a new node does not hear any SYNC packet during the initial listening period. The purpose of doing this for the S-MAC author is to introduce the scene of multiple schedules to SMAC simulations. S-MAC has to discard the new received packet.. An example for this case is shown in Fig. You might question the possibility of executing the else statements. S-MAC will temporarily disable receiving new sending request from the upper layer (by setting the flag txRequest_ to 1). there will always be one schedule in the network. In S-MAC.. But there exists one exception. depending on its index (node id). This means if we set the parameter selfConfigFlag_ to one.3. it has to choose a schedule by itself. because the Ifq will never send new packets to S-MAC when S-MAC has not finished with the current sending request. We can see that the starting time of the first listen period for different nodes is staggered. So we delete the parts in red colour in above code. The following code is extracted from the method SMAC::setMySched(Packet *pkt) in smac. all nodes start their first schedules with a listen period. schedTab_[0].1. That is.syncNode = index_. However. Similarly. when it is ready to update neighbor list. the scene of multiple schedules is not involved in this thesis. mhCounter_[0]->sched(CLKTICK2SEC(listenTime_+index_*10)). Different schedule starting time in JOURNAL_PAPER code We have introduced the algorithm for S-MAC to choose the first schedule in subsection 2. which has been discussed in sub-section 2. choosing a scheduling means choosing the starting time of the first listen period.40 The above code checks if the flag txRequest_ is set or not. the starting time of the first listen period at different nodes will differ. if (pkt == 0) { // freely choose my schedule #ifdef JOURNAL_PAPER schedState_++.cc and will be executed for choosing the node’s own schedule after the initial listening period. . So this scene can be used to simulate the scenario when nodes join the network at equidistant fixed intervals.3. #endif . We can see that if JOURNAL_PAPER is not defined. #else mhCounter_[0]->sched(CLKTICK2SEC(listenTime_)).2. If yes (indicating that SMAC already has a data packet to send).

Different schedule for each node 4. TORA (Temporally Ordered Routing Algorithm). NS-2. and AODV (Ad hoc Ondemand Distance Vector). please visit the web site listed in [12]. static routing and manual routing defined in ns-2 are only available for wired simulations. For more detailed information about installation instructions and the usage of NOAH. but not for wireless simulations.28 has implemented four ad-hoc routing protocols for wireless simulations. including DSDV (Destination-Sequenced Distance-Vector). we introduce what modules we have added to ns-2 necessary for simulating S-MAC. But for purpose of our study. .1. Any one of these four routing protocols can be used to simulate S-MAC. We found a third-party routing agent for ns-2.1 NO Ad-Hoc Routing Agent (NOAH) When we simulate a wireless network in ns-2. we expect to use such a special routing protocol. That is the so-called no ad-hoc routing agent (NOAH).2. we are only interested in the performance of S-MAC.41 0 Initial Listening Listen Listen 1 Initial Listening Listen Listen 2 Initial Listening Listen Listen 3 Initial Listening Listen Listen Fig. we found that it works quite well with ns2. but not the routing protocols.26. which accords with our desires. 4. Although this plug-in is claimed to work with ns-2. which provides static or manual routing mechanisms and will not produce any routing packet after the simulation starts.2 Preparations for Simulating S-MAC In this section. NOAH is quite suitable for simulation scenarios where routing packets are not desired. 4. Unfortunately. To measure the performance of S-MAC in a pure condition. DSR (Dynamic Source Routing). which is a wireless routing agent that supports static multi-hop routing.28 as well. we should specify a routing protocol for it.

28/tools/ Step 2: add the following statements to the file ns-2. Note: create a new packet type “expo” for this traffic source Step 4: In the file ns-2. add: || t == PT_EXPO Note: inform the trace agent of the new added packet type.2 Exponential Traffic Source Agent In ns-2.42 4. and CBR (constant bit rate) traffic source. add: PT_EXPO. we hope to generate packets with exponentially distributed inter-arrival times and packet sizes when simulating S-MAC. Three traffic sources have been implemented in ns-2. pareto on/off traffic source. Step 5: In the file ns-2.tcl. add: tools/expo_traffic. The source code is in the file expo_traffic. We will not go into details about the source code.cc line 200.o Note: configure compilation path for the new source file Step 6: Go to the directory ns-2.cc.cc in ns-2. .28/tcl/lib/ns-default.in.28.28/ and execute the following commands: . If we create a new object without assigning these variables explicitly. in OBJ_CC (line 169). ns-2 will use the default values set in ns-default./configure make clean make Note: to use the new traffic generator.2. However.28/trace/trace.28/Makefile. Step 3: In the file /common/packet. including exponential on/off traffic source. we should recompile ns-2 first. Line 206. add: name_[PT_EXPO]= "expo". called EXPO_Traffic (its Otcl class name is Application/Traffic/MyExponential).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. And “expo” will be displayed in the trace file.h Line 166. Step 1: place the source file expo_traffic. traffic sources generate packets in the application layer at each source node. Someone has developed a new traffic source agent and we adapt it to our simulations. The following steps show how to add this new traffic generator to ns-2.

The scenario for this example is described as below. 4. because most of our simulations run over this ten-hop topology. we must create a tcl script first. Each node can hear only its immediate neighbors. inter-arrival time conforms to deterministic distribution. The first node (node 0) is the source and the last node (node 10) is the sink.0 # mean inter-arrival time. set expo [new Application/Traffic/MyExponential] $expo set packetSize_ 500 # mean packet size. inter-arrival time conforms to exponential distribution. 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.28. If not. 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. If not. We take a ten-hop linear network as an example. packet size conforms to exponential distribution. we illustrate how to set up a tcl script for simulating S-MAC in ns-2.3 An Example Tcl Script for Simulating S-MAC To simulate S-MAC with ns-2. size-exp If called. interval-exp If called. as shown in Fig. 500 Bytes $expo set interval_ 1. 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.2. In this section.43 The EXPO traffic generator has four generation modes. Topology: 11 S-MAC nodes form a ten-hop linear wireless network.

Source Sink 0 1 2 . The generator keeps generating until the end of the simulation. The node configuration parameters specify the components that we want to simulate in each node and will be used in later node configuration step.# network interface type . 4. Scheduling: The generator starts generating at 60 s and stops at 2000 s.# MAC type .# like layer type . And we use those variables to store our parameters preferences for the simulation.# radio propagation model ..# buffer size of IFq .# IFq type .# channel type .# trace file name .. # Node configuration parameters set opt(chan) Channel/WirelessChannel set opt(prop) Propagation/TwoRayGround set opt(netif) Phy/WirelessPhy set opt(mac) Mac/SMAC set opt(ifq) Queue/DropTail/PriQueue set opt(ll) LL set opt(ant) Antenna/OmniAntenna set opt(ifqlen) 50 set opt(adhocRouting) NOAH # Running parameters set sim(tr) set sim(nn) set sim(stop) .2.# routing protocol trace. Each parameter is stored in a tcl variable using tcl command set.44 Routing protocol: NOAH (NO Ad-Hoc Routing Agent) Traffic pattern: Packets are sent from the source node to the sink node.0 .# simulation stop time . . This is convenient for parameters management. Two classes of parameters are defined and listed as below. 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.tr 11 100000. Running parameters include the trace file name. Packets’ interarrival times at the source node conform to an exponential distribution with mean value 10s. Packet size is fixed to 100 Bytes.# antenna model .. the number of nodes to be created for simulation and the simulation running time.# number of nodes . 8 9 10 Fig..

# create wireless topography object . In this example.# S-MAC with 10% duty cycle .45 The following code configures parameters for S-MAC.2.# enable sleep listen cycles . The last three options turn on or off the trace options at Agent/Router/MAC levels. If we expect reproducible simulation results. we normally create node objects directly using the default node configuration. we must explicitly specify all components that each node object will have. node is the basic simulation entity and can be configured to have different components and characteristics in different simulations. Mac/SMAC set syncFlag_ Mac/SMAC set dutyCycle_ Mac/SMAC set selfConfigFlag_ 1 10 1 . But in wireless simulations. These S-MAC parameters have been introduced in subsection 4. If we want ns-2 to produce different results every time we run the simulation (independent replications). we decide to turn tracing on at the agent and router level only. before actually creating node objects. In ns-2. In wired simulations. the seed value can be any non-zero integer number. .# create god The following statement sets the random seed value for random number generator.# specify length and width of the topography .# create a simulator instance .# disable user-configurable schedule The following steps are quite common for wireless simulations. ns-random 0 . In this step.1. The node configuration command is shown as below. the seed value should be zero. set ns_ [new Simulator] set wtopo [new Topography] $wtopo load_flatgrid 2500 200 set tracefd [open $sim(tr) w] $ns_ trace-all $tracefd create-god $sim(nn) .# trace all event during simulation . These options are easy to understand according to their names.# open trace file defined before . we actually configure nodes with those variables. The node configuration parameters have been chosen at the beginning and stored in tcl variables (in the form of $opt()).# independent simulations The next step is node configuration.

In multi-hop simulations. actual nodes can be created like following. .tcl. we can set the height and gain for antenna. This simulation scenario requires that each node can hear only its immediate neighbors.# tracing at mac level turned off Besides the configurable node. for {set i 0} {$i < $sim(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) random-motion 0 } .# tracing at router level turned off OFF .# tracing at agent level turned on OFF \ . So we need to space out the nodes 200 meters apart. And the default radio transmission range is 250 meters. Ns-2 has put all default parameters in the file ns-2.28\tcl\lib\ ns-default. the default value for communication range is 250 meters.# disable random motion Then we position each node in the topography that we have defined before. For example.46 $ns_ node-config -adhocRouting -llType -macType -ifqType -ifqLen -antType -propType -phyType -channelType -topoInstance -agentTrace -routerTrace -macTrace $opt(adhocRouting) \ $opt(ll) \ $opt(mac) \ $opt(ifq) \ $opt(ifqlen) \ $opt(ant) \ $opt(prop) \ $opt(netif) \ $opt(chan) \ $wtopo \ ON \ . The following code creates the topology for this scenario. If another different value is desired. each component model inside the node is also configurable. If both antenna model (Antenna/OmniAntenna) and network interface model (Phy/WirelessPhy) are configured to use their default values (like in this example). we do not reconfigure any of them. please follow the directions in section 18.4 (communication range) in nsmanual [14]. one default value that we need to know is the communication range of wireless nodes. and use their default values. After node configuration is done. But in this example.

Accordingly. The following code sets up a static routing table for 10-hop network using routing command. which establishes a virtual path between the source node and the sink node. but also in all our SMAC simulation scenarios. Then we connect the udp agent and null agent together.47 for {set i 0} {$i < $sim(nn) } {incr i} { $node_($i) set Z_ 0. The following code creates a UDP agent and attaches it to the source node. 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 .# create a new UDP agent .# connect udp to null . a Null agent is created and attached to the sink node.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. because UDP is quite simple and connectionless.0 $node_($i) set X_ [expr 50. We should set up an agent at the transportation layer.0 } We use NOAH as the routing protocol not only in this example.# create a new Null agent . set udp [new Agent/UDP] $ns_ attach-agent $node_(0) $udp set null [new Agent/Null] $ns_ attach-agent $node_([expr $sim(nn)-1]) $null $ns_ connect $udp $null . UDP agent is a better choice than TCP agent.# attach null to sink node .# attach udp to source node .0+[expr 200.0*$i]] $node_($i) set Y_ 100. Since we are studying the behaviors of S-MAC.

$ns_ at 60. In the tcl script.. and configure it to work in AePd (Exponential inter-arrival time and deterministic packet size) mode.0 "$expo start" for {set i 0} {$i < $sim(nn) } {incr i} { $ns_ at $sim(stop) "$node_($i) reset". When the simulation starts running. we should tell the scheduler the exact time when a certain event should occur. Those events are described in the following comments..# when nodes stop . the last statement should be: $ns_ run .2.# when expo starts .01 "puts \"NS EXITING.# when call finish procedure # when stop simulation The definition of finish procedure is shown below. $ns_ halt".48 To generate packets at the source node. we need to create a traffic source and attach it to the UDP agent. 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). The following code creates an EXPO traffic that we have introduced in sub-section 4.2. set expo [new Application/Traffic/MyExponential] $expo set packetSize_ 100 $expo set interval_ 10. Notice that the maximum number of packet to generate is not explicitly specified.\" . } $ns_ at $sim(stop) "finish" $ns_ at $sim(stop). a scheduler is created to control the simulating process. proc finish {} { global ns_ tracefd $ns_ flush-trace close $tracefd exit 0} In all tcl scripts for ns-2.0s $expo interval-exp $expo attach-agent $udp Ns-2 is a discrete event based simulator. .

3 is related to trace configuration. except for the measure energy consumption. .# set outer variables to global.# turn off tracing at mac level . In subsection 4. because such settings have already satisfied our needs for measures.# record all traces in the trace file . Ns-2 supports the latter one better.3 to show how to generate traces and record data into a trace file. please refer to the ns manual[14]. The following code taken from the example in section 4.# turn off tracing at router level .4 Tracing 4. In this section. because it tells us what has happened inside the model during its running and the output analysis is also based on the tracing results. trace data can be either displayed directly during execution of the simulation. and how to analyze and abstract useful information from the trace file.# turn on tracing at agent level . MAC layers or interface queues.49 4. visible inside .# open trace file defined before . we will talk about how to trace energy consumption for S-MAC in ns2.3. we use the example presented in section 4. dropped and sent by agents. set sim(tr) trace.4.# specify the trace file name .tr … set tracefd [open $sim(tr) w] $ns_ trace-all $tracefd … $ns_ node-config -agentTrace ON \ -routerTrace OFF \ -macTrace OFF … proc finish {} { global ns_ tracefd $ns_ flush-trace close $tracefd … .1 How to Trace in ns-2 Tracing is a necessary technique for each discrete-event simulator. Before the simulation starts running.# flush the trace buffer before simulation ends .# close the opened trace file For more tracing options that ns-2 provides. or stored in a file to be postprocessed and analyzed. Normally for a simulation tool. though Nam (an animation tool designed for working with ns-2) can implement the first one to a certain extent.4. we should tell ns2 what events we want to trace. We keep using the above trace settings in all our simulations. routers. Ns-2 is able to trace all packets that are received.

2. and MAC (mac). 4. d (drop) or f (forward). old format and new format.11 4 3] 5 6 7 8 9 Fig. Ns-2 defines two trace formats. However. A trace record in a S-MAC trace file is shown in Fig. 3. For example. the broken line is replaced with COL. 1.2 Trace Format All trace data will be recorded into a specified trace file in a certain format. The third field records the id of the node. S-MAC Trace format We can know from this trace record that at 274. RTR (router). Now we explain what these field mean in the usual case. . The new format is especially designed for tracing wireless simulations. The fourth field shows the layer where this event happens. r (receive). which is more standardized than the old one. node 3 sends an RTS packet to node 4.50 4.0 RTS 10 [0.4. like RTS/CTS/ACK and SYNC packets in S-MAC (using a zero instead). IFQ (interface queue). s 274.090231333 _3_ MAC 1 2 3 4 --.090231333 s. Therefore. 5. 4. The second field the time this event happens. on which this event takes place. which is the integer number used to identify this packet in the whole network and distinguish it from others. 6. The first field represents the event type. The old format is the default trace format in ns-2 and supports all type of simulations. 4. S-MAC in ns-2-28 still does not support the new trace format. we consider the old format. when collision occurs. Sequence number is only available for data packets and not allocated for control packets.3 below. Its possible value may be one of the following four: AGT (agent). The sixth field is the global sequence number for this packet. which is reserved for special events.3.. whose value can be s (send). The fifth field is normally a short broken line.

But in ns-2. The second number stands for the MAC address of the receiver of this packet. But for our purpose of study. For example. The first number is the duration field of this packet. Unluckily. But S-MAC revises this format. But some packets may have additional fields to record other information. and receiving. 8. tracing is the usual way to get simulation data.3 Tracing Radio State change for Energy Measures Achieving remarkable energy conservation on sensor nodes is the primary design goal for S-MAC. like routing and IP information.4. ns-2 defines an energy model. Since we could not use the energy model to measure energy consumptions directly. 4. 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. 4.3. there will be four numbers in the brackets. please refer to [20]. For tracing energy consumptions of nodes in wireless simulations. We know in a normal network stack. For more information about installation and usage of the new energy model updated for S-MAC. S-MAC changes the value of the radio state variable according to some events. considering these nine fields are already enough. There are four radio states defined in S-MAC. In ns-2. The actual value is determined by the application or MAC layer. The above nine fields are common for all traces if S-MAC is employed. Originally. The ninth field including three numbers in brackets concerns MAC layer information. The eighth field is the packet size in bytes. So evaluating the performance of energy consumption for S-MAC is one of the main tasks in this thesis. and the third number for the sender. The seventh field is the packet type.11 s. cbr represents that it is a data packet generated by a CBR traffic source.28 release version did not support S-MAC until we have done all the simulations for this thesis. idle. So using energy model would be the most convenient way to measure energy consumptions. In Fig. For example. which traces the energy level at each wireless node during the simulation. The tracing results will be written to the trace file. sleep. the duration field of this RTS packet is 0.51 7. the energy model in the ns-2. 9. S-MAC defines a virtual radio on MAC layer. we had to find out a solution. which is the remaining time reserved for the coming transmission. transmitting. which is in fact a state variable that reflects the change of radio state. which creates this packet. when S-MAC passes a packet to the network interface (the physical layer model in ns-2) . physical layer controls radio communications.

Using the output redirection function of Linux. we can easily store all of them into a text file. The total energy consumption at a certain node is easy to get by a simple sum operation. The information in the radio trace file is the time when each node changes its radio from one state to another. then it sets the radio variable back to idle state. Scheduler::instance(). So we can execute the following command to run a simulation. The radio variable state in S-MAC gives us a hint. the starting time of changing the state. all such information will be printed out to the terminal window. ns example. radioState_ = RADIO_SLP.52 through the interface between them.cc (need to recompile ns-2). S-MAC knows the sending is over (the lower layer will not acknowledge this). and the other one is the trace file for radio states from the terminal window.cc. radioState_). one is the standard ns-2 trace file that we have introduced before. S-MAC calculates the duration of transmitting this packet and starts a timer called sending timer with the duration timer. 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 following code is an example of this change in smac. 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. At the same time. . When the sending timer expires. index_. To calculate energy consumptions. 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. we can get two trace files. //new added print statement for tracing radio state printf("@ %d %f %d\n".tcl > radiotrace After the simulation ends. S-MAC assumes that the transmission of this packet starts immediately at the physical layer and sets its radio variable to transmitting state.clock(). and the current state. The printed information by the above statement includes the node id. When S-MAC is running in ns-2.

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

. 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. We have implemented this rule in the Perl script extract.54 4. two main problems should be solved. We call both these problems simulation control. This period is called initial transient period or warm-up period. The other one is analysis of correlated data. 4. When simulation starts. Apply initial transient period detection to each replication. For a steady-state simulation. As shown is Fig.4 below.5. Use different random number seed for each replication.2 Simulation Control All simulation problems can be divided into two types. Many methods have been developed for detecting transient period. One is duration of the initial transient period. the transient period is over if the observations have crossed the sample mean 25 times. Such a long-queued system potentially has a rather long transient period especially when traffic load is heavy. For a steady-state simulation. Run each replication long enough to make the number of observations significantly larger than that discarded in the transient period. In our simulations. we have considered the following requirements: Use the same initial conditions for each replication. Replication control for correlated data The other aspect of the simulation control is called replication control. eleven nodes form a ten-hop linear network and each node has an interface queue (buffer queue for S-MAC) with default size 50. To make each replication independent. In this period. The data measured from this period fluctuate a lot and need to be discarded. the system is converging to a stable state. terminating simulations and steady-state simulations.pl. the system will need some time to make the number of customs (or packets) in queues stable. we must run a sufficient number of independent replications for the analysis of correlated data [4]. which is used to extract results from the trace file. 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. So applying transient period detection is meaningful for our simulations. that is. We choose one of the rules of thumb. because they will significantly bias our simulation results. we choose steady-state simulations. because we are more interested in the long-run behavior of S-MAC. In this thesis. m should be much bigger than I.

pl) and one bash shell script (run. are left to users. . Once the simulation stops.5. 4. Independent replications for simulation control We apply the following sequence procedure [4] to control the number of replications required for one simulation.3 Scripts for Abstraction and Simulation Control Ns-2 is a powerful network simulation tool. which should satisfy a specific precision. This algorithm constructs a confidence interval for each measure.sh). ns-2 does not seem to be a complete simulation tool that is able to provide good support in every aspect of simulation studies.55 Fig.4. which is able to simulate a complicated scenario containing various network protocols and components at a satisfying speed. 4. which include two Perl scripts (extract. 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. 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. including the abstraction of the trace file and analysis of simulation results.pl and control. we have written three scripts for these purposes. To improve efficiency in doing these jobs and implement simulation control. all other jobs. But as far as result abstraction and simulation control are concerned.

from terminal file for storing extraction results We first see how those two Perl scripts work. The shell script is shown at the end of this section. which contains all sample values from all done replications. The command is: perl control. we have to run more replications by repeating all the steps above until the confidence conditions are satisfied. we will get two trace files radioFile and traceFile.pl to extract them. by using these two trace files as input. .pl checks if the sample values of all measures from the done replications have satisfied the confidence conditions.sh. To save time and improve efficiency. First of all. we run the replication using the following command: ns tclFile > radioFile After the simulation stops. Running the script control.pl resultFile The script control. the above steps should have been executed repeatedly at least three timers (initial replications).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. to control the running of all the steps above. Before we can run the script control. we have written a shell script (bash). So for one simulation that requires several replications.56 tclFile: traceFile: radioFile: resultFile: Tcl script for ns-2 ns-2 trace file trace file for radio.pl. run. Then we run the script extract. it will print out the final result. If yes. we only need to type a shell command.1.pl will use resultFile as the input file. Otherwise. The command is: perl extract.

pl $resultFile do currNumRepl=`expr $currNumRepl + 1` echo "NS2 is executing replication $currNumRepl ." done echo "Ns-2 Done!" echo "Perl script is extracting results for 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.57 for currNumRepl in 1 2 3 do echo "NS2 is executing replication $currNumRepl ...pl $traceFile $radioFile $currNumRepl >> $resultFile echo "Perl Done!" done currNumRepl=3 until perl control...." until ns $tclFile > $radioFile do echo "Error occurs! Run again.pl $traceFile $radioFile $currNumRepl >> $resultFile echo "Perl Done!" done echo "Simulation ends with $currNumRepl replications" exit 0 ..." perl extract......

we present our simulation results for studying S-MAC. In the second section.3. 5. 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. the measured mean energy consumption per byte can tell us about how much energy cost S- .3 how to measure energy consumptions in ns-2 by tracing the radio state variable of S-MAC. we introduce the terminating simulations with ns-2 for reproducing the results of experiments on Mica Motes hardware presented in [2]. we define three measures for analyzing our simulation results from the steady-state simulations.1 Definition of Performance Measures To evaluate the performance of S-MAC from various aspects. First. three measures for analyzing the performance of S-MAC are defined in the first section. Moreover. as a proper measure for steady-state simulations.4. which will be described in section 5.3. The steady-state simulation results under different scenarios are to be discussed in section 5. an averaged value is more meaningful and reasonable than an accumulated value. Energy Consumption per Byte We have discussed in subsection 4. because they are accumulated values and will keep increasing over running time. However.58 Chapter 5 Simulation Results In this chapter. Now we give the exact definition for the measure of energy consumption in our simulations.

The second measure is defined as end-to-end delay. 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 compute the mean end-to-end delay over a ten-hop network.59 MAC should pay for sending a single byte under different traffic loads and S-MAC modes. In our simulations. using the following definition. 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. 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 . 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.

. we run each simulation in three S-MAC modes introduced in section 4.1 Ten-hop linear network with one source and one sink The above figure shows a ten-hop linear network with 11 nodes. We use NOAH routing protocol introduced in section 4.. the paper [2] presents some experiment results on Mica Motes..2. 5. 5. In this thesis. because it will be added with 20 bytes IP header at the routing layer.1 Common Settings for Reproduction Simulations This subsection presents the common settings for all simulation scenarios presented in this section.1. Moreover. 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. Topology: We only reproduce the multi-hop experiments on Mica mote presented in [2] and use the topology shown in Fig.2. To make the comparisons between network hardware and simulation software more reasonable. we compare our simulation results with those measured from the experiments on the Mote hardware to check their consistency.2 Simulations for Validating S-MAC in NS-2 S-MAC has been implemented on the Mote hardware. Each node can hear only its immediate neighbors. 5. so the actual size at MAC layer is 100 Bytes).1. . To verify the design principles and demonstrate the effectiveness of S-MAC. The first node is the source and the last node is the sink.3 and use the following configurations. we give both the simulation configurations and the simulation results in graphs for each scenario.60 5. S-MAC modes: for comparisons. Traffic pattern: we attach a UDP agent and a CBR traffic source to the source node.1.. In the following subsections. we reproduce most of these experiments with ns-2. The CBR source generates 20 packets (each 80 Bytes. . We use an ideal channel in all our simulations. 8 9 10 Fig. Source Sink 0 1 2 . the parameters used in our simulations have been set as close as possible to those used in the hardware experiments.28 has approached its hardware implementation.

we run five independent replications and compute the average value.4.001s instead. Mode 2: S-MAC with periodic sleep.28. Modified parameters for reproduction simulations SYNC_CW DATA_CW SIZEOF_SMAC_DATAPKT 15 31 100 Bytes Simulation control: all the simulations presented in this section belong to terminating simulations.2 Measurement of Energy Consumption Measure definition: aggregate energy consumed at all nodes on the entire network. For each simulation. 5. enabling the adaptive listening. . but modify the S-MAC source code to disable the adaptive listening function. where 0s means all 20 packets are generated and queued at almost the same time at the source node.1 below that are forced to match those used in hardware measurements. Scenario: varying the CBR packet inter-arrival times at the source node from 0s to 10s. without applying replication control. all other parameters use default values in ns-2. However.1.2. S-MAC settings: first.1. Mode 3: S-MAC with periodic sleep and adaptive listening Set syncFlag_ to one and include the JOURNAL_PAPER code. Except for those listed in Table 5. so we use 0.61 Mode 1: S-MAC without periodic sleep Set syncFlag_ to zero and exclude the JOURNAL_PAPER code. but without adaptive listening Set syncFlag_ to one and include the JOURNAL_PAPER code. We use the event when the sink node receives the last CBR packet sent by the source node as the simulation stopping condition. ns-2 does not support zero inter-arrival time for traffic sources. we should debug the S-MAC source code in ns-2.28 according to the contents in section 4. Table 5.

unlike in hardware experiments. when the traffic load becomes lighter. 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. Scenario 1: under the lowest traffic load In the hardware experiments.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.3 Measurement of Latency Measure definition: compute mean latency of all data packets at the different number of hops across the network. 5.2. when the packet inter-arrival times are long enough. S-MAC with adaptive listening will not achieve better energy efficiency than S-MAC without adaptive listening.2 should get closer.2. the two curves in mode 2 and mode 3 in Fig.62 35 Energy consumption (J) 30 25 20 15 10 5 0 0 1 2 3 4 5 6 7 8 9 10 11 Packet inter-arrival time (S) 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen No periodic sleep Fig. We compare the results in the above figure with those in Fig. 5. in SMAC without adaptive listening. this method is not . However. 5. Therefore. 5. the energy consumptions measured from our simulations almost double the values measured from the hardware experiments. The number n in the following figures means n hops counted from the source node. the energy consumptions in SMAC without adaptive listening and S-MAC with adaptive listening do not converge as the inter-arrival time increases. Theoretically. Caused by such deviations. Aggregate energy consumptions at all nodes in the network Fig. when the traffic load is very light on the network. However. the next packet is generated at the source node immediately after the sink node receives the last packet. The reason is that the energy consumed in transmitting packets does not dominate the total energy consumptions.

001s. Mean latency V. Mean latency V. number of hops. 5.S. In Fig.4 below. we do not see much difference in them. number of hops.3 above with Fig. The paper [2] has analyzed the multi-hop latency in S-MAC and proposed three theoretical equations in the three S-MAC modes. 5. 5. under the lowest traffic load Comparing Fig. we generate CBR packets every 25s. we can see that our simulation results accord with the theoretical analysis.3. Therefore. 5. 5.4. 120 Mean latency (S) 100 80 60 40 20 0 0 1 2 3 4 5 6 7 8 9 10 11 No periodic sleep 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Number of hops Fig.63 easy to implement in ns-2.3. The equations show that the latency on a multi-hop network will increase linearly with the number of hops in all the three SMAC modes. 14 No periodic sleep Mean Latency (S) 12 10 8 6 4 2 0 0 1 2 3 4 5 6 7 8 9 10 11 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Number of hops Fig.3 below. The results are shown in Fig.S. under the highest traffic load . 5. Scenario 2: under the highest traffic load The packet inter-arrival time is 0. 11 in [2]. The simulation results are shown in Fig. 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.

64 Comparing Fig. which reduces the latency significantly. S-MAC with adaptive listening shows its power in reducing latency in multi-hop transmissions.4 Measurement of Throughput Measure definition: we compute the throughout. the queuing delay at each hop will decrease as the number of hops increases. Throughput V. instead of using the same measure as in measuring latency under the lowest traffic load. 5. Therefore. 5. both the figures will be quite similar. we must consider the queuing delay when we analyze the mean latency. we can see in Fig.S. 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. 250 Throughput (Byte/S) 200 150 100 50 0 0 1 2 3 4 5 6 7 8 9 10 11 No periodic sleep 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Number of hops Fig. number of hops.4 that the latency does not increase linearly as the number of hops increases. Therefore. In this scenario.2. under the highest traffic load . 12 in [2] by 10. Under such an extreme heavy traffic load. we found that the latency values in Fig. 5. The results are shown in Fig.12 do not have the same order of magnitude with ours. 5. It is easy to imagine that the latter generated packets will have larger queuing delay than the previous ones. we generate 20 packets and throw them to the queue at the source node at almost the same time. Moreover. If we multiply all the values in Fig. The reason is the adaptive listening can make one packet jump two hops in a frame. Compared with S-MAC without adaptive listening. using the payloads received at the MAC layer.5 below.4 above with Fig. 12 in [2]. 12.5. 5. we infer that the paper [2] uses another measure in Fig.

The results are shown in Fig. the throughput of all three modes increases. 14 in [2]. 5. each node can send or receive only one data packet in a frame. S-MAC with adaptive listening can achieve better bandwidth utilization than S-MAC without adaptive listening. As the traffic load increases.4. the lower the throughput is in Fig. we can find that under the highest traffic load. The adaptive listening allows the node to send or receive more than one packet in a frame. throughput has a very close connection with latency.5. 5. 5.6 below.5.5. S-MAC without periodic sleep achieves much higher bandwidth utilization than the two S-MAC modes with periodic sleep.5 with Fig.65 Comparing Fig. as shown in Fig. which wastes a lot of bandwidth especially under heavy traffic loads. because the three SMAC modes spend almost the same time to send a fixed number of packets from the source to the sink. 140 Throughput (Byte/S) 120 100 80 60 40 20 0 0 1 2 3 4 5 6 7 8 9 10 11 Packet inter-arrival time (S) No periodic sleep 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Fig. 5. The reason is in the S-MAC without adaptive listening. . The simulation results show that under the highest traffic load. 5. 5. 5. We can see from Fig. 5. the three curves overlap. When the traffic load reaches maximum. the larger the latency is in Fig. Scenario 2: measure end-to-end throughput under different traffic loads The packet inter-arrival time varies from 0.6 that when the traffic load is very light. Therefore.001s to 10s. we get the same results as in Fig.4.6. End-to-End throughput under different traffic loads The above figure is quite consistent with that in Fig. 5. At the same number of hops.

Parameters settings: some important parameters used in the steady-state simulations are listed in the following tables. 5.2. .3 Steady-State Simulations and Results To investigate the long-run performance of S-MAC. during which the traffic source will keep generating packets at the source node. We use NOAH as the routing protocol and use an ideal channel in all our simulations. Performance measures: three measures defined in section 5. 5. For each replication.1. we perform 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.3.66 5. we run the model for a fixed time. using the same settings as in section 5.28 according to the contents in section 4. S-MAC source code: debug S-MAC source code in ns-2.1.4. S-MAC mode settings: three S-MAC modes. the same as in Fig. In this section. Normally in all our steady-state simulations.1 Common Settings for Steady-State Simulations Topology: a ten-hop linear network with one source and one sink.2. Simulation control: apply both initial transient period detection and replication control introduced in section 4. we introduce various scenarios that we have set up for running steady-state simulations and analyze the simulation results.6.1.1.

4. Radio power in different modes for calculating energy consumption Radio State sleep idle transmitting receiving Power (mJ) 0.8) 1123 (1603) Table 5.2.5.0 14. Modified S-MAC parameters (default values in brackets) Name SYNC_CW DATA_CW SIZEOF_SMAC_DATAPKT durDataPkt_ syncTime_ dataTime_ listenTime_ sleepTime_ (10% duty cycle) cycleTime_ (10% duty cycle) Comment Number of slots in the SYNC contention window Number of slots in the DATA contention window Fixed data packet size in bytes Time for transmitting a data packet in ms Length of SYNC period in ms Length of DATA period in ms Length of listen period in ms Length of sleep period in ms Length of one frame in ms Value 15 (31) 31 (63) 100 (50) 83 (43) 39. Some PHY and MAC layer parameters Name BANDWIDTH ENCODE_RATIO SIZEOF_SMAC_CTRLPKT SIZEOF_SMAC_SYNCPKT slotTime_ difs_ sifs_ eifs_ durSyncPkt_ durCtrlPkt_ timeWaitCtrl_ Comment Radio bandwidth Manchester encoding Size of control packet Size of SYNC packet Slot time in contention window DCF interframe space Short interframe space Extended interframe space Time for transmitting a SYNC packet Time for transmitting a control packet CTS or ACK timeout time Value 20 kbps 2 10 Bytes 9 Bytes 1 ms 10 ms 5 ms 50 ms 10.2 (55.8 (1442.2) 1010.01 0.3.2) 73.2 ms 11 ms 18 ms Table 5.67 Table 5.4 .0 (105) 112. Parameters for replication control Parameter n0 α γ Comment Initial number of replications Confidence interval Relative error Value 3 0.2 (160.1 Table 5.4 36.015 14.

One is AdPd. idle listening dominates the total energy consumption and the periodic sleep mechanism will show its power in this case.68 5. 5. AdPd traffic source (deterministic inter-arrival times.7. The reason is that when the traffic load is light. The other one is AePe.7. Energy consumption. the EXPO traffic source (see section 4. The reason is that adaptive listening can efficiently reduce latency caused by periodic sleep in a multi-hop transmission.2.3. with AdPd traffic source In Fig. two S-MAC modes with periodic sleep show great advantage over S-MAC without periodic sleep.2 Single Traffic Source In this scenario. We consider two extreme cases.2) or the exponential On/Off traffic source. 5. 1. especially when the traffic load is heavy. . We consider two types of traffic sources. EXPO traffic source The EXPO traffic source can be configured to generate packets in four modes. Comparing two S-MAC modes with periodic sleep. which has completely exponential characteristic. we see that adaptive listening can help S-MAC achieve better energy efficiency. which accordingly reduces the average time for transmitting a single byte. we can see that when the traffic load on the network is light. we attach only one traffic source to the source node. which has completely deterministic characteristic. deterministic packet sizes) Measure 1: Mean energy consumption per byte Mean energy consumption per-byte (mJ/Byte) 25 No periodic sleep 20 15 10 5 0 0 1 2 3 4 5 6 7 8 9 10 11 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Mean inter-arrival time (S) Fig.

5.5. We use Fig. each node has only one chance to send the packet in a frame.41s). but this is already quite heavy for both SMAC modes with periodic sleep. with AdPd traffic source Fig. However.5. to illustrate this problem. for S-MAC without periodic sleep the delay curve is nearly a horizontal line. End-to-End delay. each node receives the packet from its previous-hop neighbor and forwards it to its next-hop neighbor. When the traffic load is light (inter-arrival time bigger than 7s). Now we analyze why the end-to-end delay will drop sharply at certain point. This value is quite close to that in Fig. We assume that all nodes follow the same schedule and the channel is ideal (the same assumptions for all our simulations).9. 5. which is measured under the lightest traffic load. As the traffic load increases. 5. which stays at a quite low level (about 1. which is a part of the ten-hop network used in this simulation. 5.69 Measure 2: Mean end-to-end delay 1000 Mean end-to-end delay (S) 800 600 400 200 0 0 1 2 3 4 5 6 7 8 9 10 11 No periodic sleep 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Mean inter-arrival time (S) Fig. which is about 13s. The saturation delay is very huge because the network has a very large queue size (queue size is 50 at each node). This means that even the highest traffic load in Fig. In Fig. which is about 910s. We first look at S-MAC without adaptive listening. Before discussing.8 (1s) is still low for S-MAC without periodic sleep. the delay stops increasing and reaches a saturation value.9.8. the end-to-end delay remains at a low value. more and more packets will be stuck in the queues and the delay will increase rapidly. 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. we should remember that in S-MAC without adaptive listening. Finally.3.8 shows the mean end-to-end delay measured under different traffic loads. it will have to wait for the next DATA period. If it misses this chance. .

node N+1 will send back a CTS. the probability of interference will be largely reduced and the queuing delay for each packet will be reduced. node N+1 will go to sleep to avoid overhearing. To avoid overhearing the coming long data packet. If the packet inter-arrival time is set larger than such an average time mentioned before. If node N sends out an RTS earlier than node N+2. Interfering nodes in a linear network We first consider the case of two one-hop neighbors. When the packet inter-arrival time is smaller than the average time for passing a data packet over three hops. node N+2 goes to sleep immediately.70 N N+1 N+2 N+3 Fig. As time goes on. If node N+2 sends out an RTS earlier than node N. Therefore. node N will encounter a CTS timeout. Then node N has to wait until the next DATA period comes. twohop neighbors will interfere with each other. we can see that if two two-hop neighbors start carrier sense for sending packets in the same frame. If we consider two three-hop neighbors. If both node N and node N+2 has a packet to send in the same frame. the conclusion is that if adaptive listening is not applied. 1. it will transmit the packet to node N+3 successfully. one of the following cases will happen. The consequence is node N will encounter a CTS timeout.9. 3. which will be overheard by node N+2.9. there will be no such interference between them. From the above discussions. 5. Now we see what happen to two two-hop neighbors. . serious interference will occur on the entire multi-hop network and the average delay for each packet will be huge. If node N and node N+2 start sending at almost the same time. In other words. not only this packet but also all queued packets at this node are delayed for a frame length. only one of them can send the packet successfully and the other node has to wait for the next frame. The reason is that if one node misses the chance of transmitting the data packet to its next-hop neighbor in the current frame. For node N+2. 2. In Fig. Therefore. the traffic jam will become more serious. if they both have packets 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. the range of interference between nodes is two hops. because it will not be influenced by the collision. 5. if both node N and node N+1 have a packet to send in the same frame. collision will occur at node N+1.

5. we can see in Fig.10 shows the measured end-to-end goodput under different traffic loads. The reason is that when the traffic load is very light.8. which proves our inference. We notice that the turning point in the curve for S-MAC without adaptive listening is at about 4s. which implies .8. Measure 3: End-to-end goodput 100 Mean end-to-end goodput (Byte/S) 80 60 40 20 0 0 1 2 3 4 5 6 7 8 9 10 11 Mean inter-arrival time (S) No periodic sleep 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Fig. which is only half of that in S-MAC without adaptive listening.10 End-to-End goodput. we can infer that 4s is the approximate average time for passing a single data packet across three hops. The simulation results prove that the adaptive listening is quite effective in reducing the latency in multi-hop transmissions. If we have a look at the results in Fig. If we have a look at Fig.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 three S-MAC modes spend almost the same time to transmit the same number of data packets. 5. 5. the goodput of S-MAC without adaptive listening stops increasing at 7s. or make a node transmit two data packets to its next-hop neighbor in a frame. 5. We see that the goodput of all the three modes increases as the traffic load increases. According to our analysis before. 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.3. we can see that the end-to-end delay of S-MAC without adaptive listening starts increasing also at 7s. As the packet inter-arrival time decreases. Three curves overlap on the right side of the above figure. The reason is that the adaptive listening can pass a data packet across two hops in a frame. Therefore. 5.8 shows that the end-toend delay in S-MAC with adaptive listening reaches its saturation value at 2s. The same situation happens to S-MAC with adaptive listening. 5. Fig. with AdPd traffic source Fig. the goodput of S-MAC with adaptive listening are more than twice as large as that of S-MAC without adaptive listening. 5.71 Let’s go back to our simulation results in Fig. Now we consider S-MAC with adaptive listening. When the inter-arrival time reaches 1s.

if we enable the JOURNAL_PAPER code. 5. S-MAC with adaptive listening can achieve much better bandwidth utilization than S-MAC without adaptive listening.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. mean end-to-end delay in Fig. 5. However.13. exponential packet size) In this scenario.sample (80 Bytes) NOAH Payload = Payload +20 Bytes (IP header) S-MAC Number of Fragments = ⎡ Payload/100 ⎤ ⎢ ⎥ size of each fragment = 100 Bytes Fig. we consider only S-MAC without adaptive listening and S-MAC with adaptive listening in this scenario. 5.4. we cannot set S-MAC to mode 1. we must compile the JOURNAL_PAPER code to enable the message passing function. AePe traffic source (exponential inter-arrival time. (Mean energy consumption per byte in Fig. Fig.14) . end-toend goodput in Fig. In the current SMAC implementations in ns-2. We have explained the reason in section 4. 5.72 that under a heavy traffic load.12.1. if we want to simulate S-MAC with variable packet sizes instead of a fixed size. we attach an AePe traffic source to the source node.28. Flow chart of message passing with AePe traffic source The simulation results for the three measures are shown in the following figures. Therefore. 5. AePe Traffic Source Payload = Exponential.11.

5.14. End-to-End delay. Energy consumption.73 Mean energy consumption per-Byte (mJ/Byte) 25 20 15 10 5 0 0 1 2 3 4 5 6 7 8 9 10 11 Mean inter-arrival time (S) 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Fig. with AePe traffic source .12. 5. 5. with AePe traffic source Mean end-to-end goodput (Byte/S 35 30 25 20 15 10 5 0 0 1 2 3 4 5 6 7 8 9 10 11 Mean inter-arrival time (S) 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Fig. with AePe traffic source 1000 Mean end-to-end delay (S) 800 600 400 200 0 0 1 2 3 4 5 6 7 8 9 10 11 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Mean inter-arrival time (S) Fig.13. End-to-End goodput.

current S-MAC implementation in ns-2. 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. and do not see big difference between each pair of them. 5. We use the Fig. we attach an exponential On/Off traffic source to the source node. 2. the advantage of message passing is traded off. To compare the results using the On/Off source with those using the AdPd source. We compare the above three figures with those measured under AdPd respectively.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. To solve the information loss problem (in section 4. The consequence after modification is that S-MAC has to transmit extra bytes for those messages.28 has not supported message passing very well. Both on and off periods are sampled from an exponential distribution. we make some changes in the source code. Det ( P′) On Exp (λon ) Off Exp (λoff ) AdPd Det(T). However. Exponential On/Off traffic source The exponential On/Off traffic source is such a packet generator in ns-2. However.h). In our simulations. we only count the actual payloads of the messages received at the application layer of the sink node. Det (T ′). by which packets are sent at a fixed rate during on periods like an AdPd source. and no packets are sent during off periods. we should make the two sources generate the same traffic flow. Det(P) Fig.1. Therefore. 5. .4). In fact.15 (the left part) below to illustrate this process.15. which are not multiples of a fragment size (the value of SIZEOF_SMAC_DATAPKT in smac. when calculating energy consumption per byte and goodput.

we use the following parameter settings for the On/Off traffic source. . 5.8. end-to-end goodput are shown in Fig. λoff P′ P′ P ⋅ = π on ⋅ + π off ⋅ 0 = λon + λoff T ′ T T′ If we let λon = λoff and P′ = P . we do not see too many differences between the results under On/Off and under AdPd.5s to 5s. mean end-to-end delay in Fig. we can get the following result: 1 T'= T 2 In this scenario. 5.17. The simulation results show that under burst traffic loads.17. λon = λoff =1/(10T ′ ).75 We now analyze how to choose parameters for the On/Off traffic source. 5.16. we can see that the exponential On/Off traffic source greatly smoothes the sharp drop of the delay in Fig. After comparison. except the results for the delay. S-MAC has almost the same behavior as in using deterministic traffic sources. P′ =80 Bytes. As for the results for end-to-end delay in Fig.18). 5. 0.5s each step The simulation results for the three measures are shown in the following figures. and equal to off To make the average traffic flow generated by the two sources equal (at the same average generating rate). which should be compared with those measured under AdPd traffic source. 5. the following equation should be satisfied. 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 : T′ : P′ : the mean value for the exponential distributed time in off state the constant inter-arrival time for generating packets in on state 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: π on : π off : λoff λon + λoff λon the long-run percentage of time in off state. T ′ varies from 0. and equal to λon + λ the long-run percentage of time in on state. (Mean energy consumption per byte in Fig.

with On/Off traffic source .5 1.5 2 2. End-to-end goodput.5 2.5 Constant inter-arrival time during on periods (S) 5.5 3 3.5 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Constant inter-arrival time on periods (S) during Fig.5 5 5.5 2.5 4.18.5 1.5 4. with On/Off traffic source 100 Mean end-to-end goodput (Byte/S) 80 No periodic sleep 60 40 20 0 0 0.5 4 4.76 25 Mean energy consumption per-byte (mJ/Byte) 20 No periodic sleep 15 10% duty cycle without adaptive listen 10 5 10% duty cycle with adaptive listen 0 0 1 2 3 4 0. 5.5 1 1.5 3.5 5 Constant inter-arrival time during on periods (S) Fig. with On/Off traffic source 1000 Mean end-to-end delay (S) 800 No periodic sleep 600 400 200 0 0 1 2 3 4 0. Energy consumption.5 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Fig. 5.17.5 5 5.5 3.16. 5. End-to-end delay.

5.2 (simulating a single exponential On/Off traffic load).25 to 10s and configure the exponential On/Off traffic source in the same way as we described in section5. One is AdPd traffic source and the other is exponential On/Off traffic source.3. we attach two traffic sources to the source node.3 Two Traffic Sources In this scenario.25 1 2 3 4 5 6 7 8 9 10 Constant inter-arrival time during on periods (S) Fig. Besides mean end-to-end delay that we have defined in section 5.1.77 5.19. Two sources generate packets with constant size (80bytes) simultaneously at the source node during the run of simulations. We vary the interval-times during on periods at On/Off source from 0.3. we consider the coefficient of variance (CV) for end-to-end delay and use the following definition: Coefficient of Variance = Mean end-to-end delay 1000 Standard Deviation Mean 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. which is a moderate traffic load for S-MAC. The packet inter-arrival time at AdPd source is fixed to 7s. Mean end-to-end delay for AdPd packets. with both AdPd source and On/Off traffic source . 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).

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

20.2 0.4 0.5s.20. the closer the CV is to 1.20 shows the measured CV for end-to-end delay. However. Therefore. CV of end-to-end delay for AdPd packets. S-MAC with adaptive listening will show much better jitter performance than S-MAC without periodic sleep. the higher the delay jitter will be and the closer the distribution of the delay will be to exponential.8 No periodic sleep 0. As for S-MAC without adaptive listening. S-MAC with adaptive listening shows a bad jitter performance. When the traffic load is moderate.0 0. its delay will keep very high and will not be sensitive to the change of the traffic load. One is in S-MAC with adaptive listening at 3s and the other is in S-MAC without periodic sleep at 0.20. 25 10 1 2 3 4 5 6 7 8 9 10% duty cycle with adaptive listen Constant inter-arrival time during on periods (S) Fig. when the traffic load is very heavy. the good jitter performance for S-MAC without adaptive listening is at the cost of high end-to-end delay and low throughput. 5. with both AdPd source and On/Off traffic source Fig. 5. 5.79 CV of end-to-end delay 1. . We can see two peaks in Fig. 5.0 Coefficient of variation 0.6 10% duty cycle without adaptive listen 0. there is no peak in its CV curve in Fig. The reason is that in such traffic load. According to the definition of CV.

However. which include three statistical characteristics. have been extracted from the ns-2. 1. To analyze the long-run performance of S-MAC.28 source code and explained in detail. Through analyzing the simulation results. deterministic. 3.28 and proposed the solutions to them. The adaptive listening largely reduces such cost and finds out a good balance point among energy consumption. schedule synchronization. we have the following conclusions: S-MAC with periodic sleep efficiently reduces the energy consumptions due to idle listening. we have run many steady-state simulations and applied simulation control for each of them. such as message passing.80 Chapter 6 Conclusion Finished work During the course of the master thesis work. periodic sleeping increases latency and reduces throughput. 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. We use three traffic source models in our simulations.28 and found out how SMAC works internally. Our simulation results have shown quite good consistency between two SMAC implementations. two types of simulations have been run for different purpose. To reproduce the S-MAC experiments on Mote hardware. exponential and exponential On/Off. We have found some bugs and problems in the S-MAC source code in ns-2. Thirdly. We have investigated the source code of S-MAC in ns-2. we have run some terminating simulations using the approximate settings presented in the paper [2]. . 2. Some important features of S-MAC. we have done the following three main tasks. latency and throughput. adaptive listening etc.

and proposed a so-called fast path algorithm to help S-MAC find out a fast data forwarding path in multi-hop transmissions. which determines the length of the sleep period in a frame. e. Multiple schedules for S-MAC. S-MAC with various duty-cycle settings Duty-cycle is a use-adjustable parameter in S-MAC. Therefore. especially in a large multi-hop network.28 is not quite satisfying. Before the new version of ns-2 is released. debugging work should be continued. S-MAC has also been implemented in TinyOS on the Mote platform. considering verylow-duty-cycle. 2. because there are still many unsolved problems and bugs in it. . Furthermore. 3. which reflects the latest development of S-MAC. The paper [3] has proposed a so-called global schedule algorithm to make all nodes converge to a single global schedule. studying these new features of S-MAC should be our future work. investigating S-MAC implementation both in ns-2 and in TinyOS would be more helpful. Although we have found many problems and fixed some bugs.81 Further work 1. S-MAC is being developed. multiple schedules are quite common in practice. In all our simulation scenarios. 1% duty cycle would make more sense. current implementation of S-MAC in ns-2. Therefore. Therefore.g. we only consider that all nodes on the network share the same schedule. Furthermore. we cannot guarantee that we have found all the problems and bugs in current version of ns-2. In fact. simulating S-MAC using different duty-cycle values under different traffic loads will be an interesting topic. One suggestion Except in ns-2. Changing the duty cycle will change the performance of S-MAC.

Intl. Italy. Estrin. Rabaey. In Proc. on Mobile Computing and Networking. R. Heidemann and D. Garcia-Luna-Aceves. Kelton. Li.82 Bibliography [1] W. and M. ACM. [4] A. [6] V. ACM/IEEE Transactions Networking. M. Medium access control with coordinated. Knightly. Charlie Zhong. Simulation. Intl. C. Ye. Li. W. IEEE Transactions on Mobile Computing. D. ACM. B. J. Culler. Srivastava. Rome. B. and D. Heidemann.Rome. Ganeriwal. July 2001. Law. IEEE Infocom. [5] L. In Proc. pages 221–235. An Ultra-Low Power and . pages 200–209. Schurgers. and J. 1(1). McGraw-Hill. M. 2002. on Mobile Computing and Networking. S. NY. Heidemann. A New Approach to Channel Access Scheduling for Ad Hoc Networks. Kanodia. [7] C. 3rd Edition. 7th Ann. 12(3):493-506. An energy-efficient MAC protocol for wireless sensor networks. Shah. Energy and latency control in low duty cycle MAC protocols. adpative sleeping for wireless sensor networks. Ye. June 2004. A Sabharwal. New York. Sadeghi. Guo. pages 1567-1576. 7th Ann. [2] W. In Proc. Bao and J. [3] Y. V. July 2001. pages 210–220. Conf. [2000]. Intl. Ye and J. on Mobile Computing and Networking. C. Optimizing Sensor Networks in the Energy-Latency-Density Design Space. USC/ISI Technical Report ISI-TR-595.Estrin. Italy. Tsiatsis. J. Modeling and Analysis. W. [8] A. C. [9] L. August 2004. In Proc. and E. Conf. ACM. 7th Ann. Conf. W. Rome. June 2002. Distributed Multi-Hop Scheduling and Medium Access with Delay and Throughput Constraints. A Transmission Control Scheme for Media Access in Sensor Networks. Italy. J. July 2001. Woo and D.

http://www.ns-2 homepage.8. http://www.edu/nsnam/htdig/search. LBL.pdf . Greis.wpi.edu/nsnam/ns/tutorial/index.org/perl.isi.html [17] NsNam Site Search web page.isi. http://perldoc. May 2001.isi.html [21] Trace Graph web page. USC/ISI. NV. Tutorial for the network simulator ns.edu/nsnam/ns/ [14] The VINT project.isi.edu/nsnam/ns/doc/ns_doc. Erlangen. and Xerox PARC. Winter Term 2003/2004. Simulation and Modeling I Lecture Notes in Computer Science.Discussions by users of S-MAC web page.pdf [15] M. UC Berkeley. Las Vegas.html [18] J.html [16] The Network Simulator: Building Ns web page.isi.isi. [10] R.ch/widmer/uwb/ns-2/noah/ [13] The Network Simulator . German. The Department of Computer Science. http://icapeople.perl.com/tracegraph/ [22] The Perl Directory at Perl. [11] SCADDS: Scalable Coordination Architectures for Deeply Distributed Systems web page. Claypool. http://mailman. The NS Manual. Erlangen-Nürnberg University. Perl version 5. http://www. In IEEE Broadband Wireless Summit.83 Distributed Access Protocol for Broadband Wireless Sensor Networks.edu/NS/ [19] Smac-users -. http://www.edu/ilense/software/smac/ns2_energy.http://www. http://nile. http://www.edu/scadds/projects/smac/ [12] NO Ad-Hoc Routing Agent (NOAH) web page.isi.isi.epfl. http://www. http://www.org.edu/nsnam/ns/ns-build.edu/mailman/listinfo/smac-users [20] Energy Model Update in ns-2 web page.geocities. Chung and M. NS by example Worcester Polytechnic Institute.7 document.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.