Ulzhan Kakenova1,

Kayrat Kakenov2, Gulmira Yessenbayeva2

 

Karaganda State Technical University 1, Karaganda Economic University 2,

The Republic of Kazakhstan

 

S-MAC PROTOCOL PROTOTYPE IMPLEMENTATION

 

 

1 Protocol Introduction

Locally managed synchronizations and periodic sleep listen schedules based on these synchronizations form the basic idea behind the Sensor-MAC (S -MAC) protocol [2]. Neighboring nodes form virtual clusters to set up a common sleep schedule. If two neighboring nodes reside in two different virtual clusters, they wake up at listen periods of both clusters. Schedule exchanges are accomplished by periodical SYNC packet broadcasts to immediate neighbors. The period for each node to send a SYNC packet is called the synchronization period. Figure 1 represents a sample sender receiver communication. Collision avoidance is achieved by a carrier sense, which is represented as CS in the figure. Furthermore, RTS/CTS packet exchanges are used for unicast type data packets.

 

 

Fig.1. S-MAC Messaging Scenario

 

Advantages: The energy waste caused by idle listening is reduced by sleep schedules. In addition to its implementation simplicity, time synchronization overhead may be prevented with sleep schedule announcements.

 

Disadvantages: Broadcast data packets do not use RTS/CTS which increases collision probability. Adaptive listening incurs overhearing or idle listening if the packet is not destined to the listening node. Sleep and listen periods are predefined and constant, which decreases the efficiency of the algorithm under variable traffic load.

 

2 Methods

Based on the template assigned to our project, we focused to implement the

SMAC protocol by diving the implementation into two main methods:

- Synchronization method

- Collision Avoidance (RTS/CTS/DATA/ACK)

Synchronization method

In this method each node goes to sleep for some time, and then wakes up and listens to see if any other node wants to talk to it. During sleep, the node turns off its radio, and sets a timer to awake itself later. The duration of time for listening and sleeping can be selected according to different application scenarios.

An interval of 1s is chosen for the entire sleep and wake interval where the wake time is set to 200ms i.e., 20 percent. The _rst 30ms are reserved for the sync messages sent through broadcast. In addition the protocol makes sure that each node checks the sequence number of the sender of the incoming packet. If the sending node has a lower sequence number than the receiver, it synchronizes to the time of the sending node and increment the sequence number by one.

Collision Avoidance (RTS/CTS/DATA/ACK)

Collision avoidance is a basic task of MAC protocols. The SMAC implementation considers a contention-based scheme. It is important to mention that any packet transmitted by a node is received by all its neighbors even though only one of them is the intended receiver.

Since multiple senders may want to send to a receiver at the same time, the nodes need to contend for the medium to avoid collisions using RTS/CTS mechanism and also to address the hidden terminal problem. Finally, broadcast packets are sent without using RTS/CTS and Unicast packets follow the sequence of RTS/CTS/DATA/ACK between the sender and the receiver.

 

3 Experimental Setup/Measurement Procedure

After the Cooja simulation completion of the S-MAC protocol in Contiki, the experimental setup was divided in two main parts: TARWIS Testbed and NS-2 Simulator. The tests in TARWIS were performed three di_erent scenarios in the next order:

1 Small network section with sequential node IDs (15-19).

2 Small network sections of few sensors with non-sequential node IDs (7, 8, 4, 3, 5, 6).

3 Full network of 40 sensors.

The aim of these three different tests was based on the design of our implementation which was based on the behavior that we observed in the Cooja simulator. It is important to mention that our SMAC protocol implementation in C was under the assumption that the collision avoidance part should require a sequence of node IDs. The TARWIS testbed is shown in figure 2 with the specification of the entire node ID's.

 

 

Fig.2. TARWIS Sensors Topology

 

Based on this assumption, the first test will be performed in a TARWIS section where all the nodes are somehow in the same range and in a coverage sequence. The second test scenario would be considering pairs in another small region of the network where there are pairs of nodes in sequence but not necessarily in the same coverage range, for example nodes 3 and 4 are close but 5 is not in the range of them. The third scenario is considering the whole 40 sensor network in TARWIS and analyzes their behavior.

As an additional test, we considered the NS-2 simulator which supports C++.

This has the aim to test an additional neighbor discovery implementation that was added to our original implementation in Contiki but this time the protocol was translated into a C++ version. Then this version is used to test not only the neighbor discovery but also the two main methods of the protocol: synchronization and collision avoidance. The NS-2 simulation considers 5 nodes in order to verify the correctness of the protocol code implementation.

 

4 Results and Analysis

The analysis for the local sensors (with five sensors) was performed using Cooja simulator. The synchronization and collision avoidance were working as expected in Cooja under the assumption of having sequentially numbered node ids for the unicast packet transmission.

Nevertheless, the program failed to perform the collision avoidance part in

TARWIS as the node ids were not arranged sequentially in the testbed. Based

on the three different TARWIS test scenarios, we made an attempt to implement the neighbor table for each node using linked list/hash tables, which helps the nodes to know their neighbors that come under the transmission range of the source node.

Unfortunately, we could not implement due to time constraints. Hence to evaluate the SMAC protocol for the project we had to rely on NS-2 simulator.

Using the NS-2 simulator, the latency (end-to-end delay of a packet) and packet delivery ratio (ratio of the successfully delivered packets to the total packets originating from all sources) are calculated for 1-5 hops and presented in the figures 3 and 4. We observe that the latency increases linearly in time for multiple hops and in addition in figure 3, we compare the latency with the case of null-MAC.

 

Fig.3. Average Latency for 1-5 hops(Right) Packet Delivery Ratio(Left)

 

It is evident from the simulation results shown in the graphs that the ratio of the successfully delivered packets to the total packets originating from all sources (packet delivery rate) does not show deep variations. Moreover, the PDR remains stable when different traffic rates are applied. On the other hand, the latency increases linearly in time for multiple hops which is acceptable due to the increasing number of hops from 1 to 5. In general the packet delivery rate and latency performance is in the appropriate range since it avoids collisions due to hidden terminals. Hence, SMAC achieves energy-savings with delivery guarantees.

 

Fig.4. Packet Delivery Ratio

 

Finally, SMAC latency performance is higher compared to Null-MAC and the packet delivery ratio is very poor for Null-MAC compared against SMAC because Null-MAC doesn’t send acknowledgements and SMAC performs the RTS/CTS handshakes and sends ACK whenever data is received by a node.

 

5 Conclusions

In this paper we presented the experiment on Sensor MAC protocol for WSNs, an energy-aware medium access protocol for wireless sensor networks. SMAC is one of the basic MAC protocols which provide sleep schedules in order to conserve energy. This sleep schedule works so that all the nodes of a particular area are not active at all times, but only those nodes are activated which are needed to provide maintenance for full accessibility of network. Through extensive simulations, we compared the network performance using the Tarwis Testbed, and later different simulators such as Cooja and NS-2 were used. Due to the above mentioned errors in performing the experiment on Tarwis, the SMAC protocol was tested in NS-2 network simulator where we measured all significant results such as packet latency and delivery rate. The main objective was to evaluate how the packet delivery rate and latency behave for different rates of traffic.

 

References

1. Ilker Demirkol, Cem Ersoy, and Fatih Alagz. MAC Protocols for Wireless Sensor Networks: a Survey. - Communications Magazine, IEEE, April, 2006, Volume 44, Issue:4.- Page: 2.

2. W. Ye, J. Heidemann, D. Estrin Article:Medium Access Control With Coordinated Adaptive Sleeping for Wireless sensor Networks. IEEE/ACM Transactions on Networking, June 2004, Volume: 12, Issue 3.- Page(s): 493 - 506.