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