Stability analysis of MAC Protocol TDMA, CSMA/CD and Un-Slotted Aloha

With
Wireless Network Protocols

Abstract

Time division multiple access (TDMA) is a probabilistic media Access Control (MAC)
protocol in which is a channel access method for shared medium network. It allows
several users to share the same frequency channel by dividing the signal into different
time slots. Carrier Sense Multiple Access (CSMA) is also a probabilistic media Access
Control (MAC) in which a node verifies the absence of other traffic before transmitting
on a shared transmission medium.

In this thesis, we plan to use ns2 to simulate the TDMA to transmit data at first, and
then simulate the data transfer with CSMA, unslotted ALOHA with different variation and
different variation of packet sizes. After the simulations, we will use performance metrics
like throughput; end to end delay etc. to analysis data and make conclusion for stability
among them.
Introduction

Time division multiple access (TDMA), is a technology used in digital cell telephone
communication, is a probabilistic media Access Control (MAC) protocol in which is a
channel access method for shared medium network [1]. It is a method that can divides
the spectrum into time slots so that the more amounts of data can be carried [2]. In this
way, specific frequency is not one-to -one to a user, but a single frequency can provide
multiple data channels to co response multiple users. Although TDMA is considered the
most in advanced technology, it was widely used all over the world in the past few
years.

The statistics shows that about 9% digital cell phone user chose TDMA in US in
1999[2].Like TDMA, CSMA (Carrier Sense Multiple Access) is also a probabilistic media
Access Control (MAC). It can detect the absence of other traffic before transmitting on a
shared transmission medium [3]. There are two modifications of CSMA, the one is
called CSMA/CD, and the other one is CSMA/CA which is used in our thesis, where CD
is short for collision detection and CA stand for collision avoidance. CSMA/CD refers to
use the terminating transmission to detect and deal with the collision and then prevent
the collision happening again to improve the performance. On the other hand,
CSMA/CA, it acts to reduce the probability of the first-time collision happen on the
channel. Because it checks if the channel is clear or not once a node receives a packet.
If the channel is idle, then the packet is sent; however, if the channel is busy, the node
will wait a period of time and then check it again until the channel is clear. That ensure
there is only one node is transmitting at one time so that prevent the collision
fundamentally [4].
Objectives

In this thesis, we are going to use network simulator (ns2) to simulate the data transfer
with TDMA protocol and 802.11 (CSMA\CA) protocol.
1. To evaluate the performance of CSMA/CD, TDMA and Un-slotted Aloha with the
end-to-end delay, throughput with different amount of packet size in wireless
network with different routing protocols like AODV, DSDV and DSR.

NS2 Simulator
NS is an event driven network simulator developed at UC Berkeley that simulates
variety of IP networks. It implements network protocols such as TCP and UPD, traffic
source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management
mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and
more. NS also implements multicasting and some of the MAC layer protocols for LAN
simulations. The NS project is now a part of the VINT project that develops tools for
simulation results display, analysis and converters that convert network topologies
generated by well-known generators to NS formats. Currently, NS (version 2) written in
C++ and OTcl (Tcl script language with Object-oriented extensions developed at MIT) is
available. This document talks briefly about the basic structure of NS, and explains in
detail how to use NS mostly by giving examples. Most of the figures that are used in
describing the NS basic structure and network components are from the 5th VINT/NS
Simulator Tutorial/Workshop slides and the NS Manual (formerly called "NS Notes and
Documentation"), modified little bit as needed. For more information about NS and the
related tools, visit the VINT project home page.
Figure 1. Simplified User's View of NS
As shown in Figure 1, in a simplified user's view, NS is Object-oriented Tcl (OTcl) script
interpreter that has a simulation event scheduler and network component object
libraries, and network setup (plumbing) module libraries (actually, plumbing modules are
implemented as member functions of the base simulator object). In other words, to use
NS, you program in OTcl script language. To setup and run a simulation network, a user
should write an OTcl script that initiates an event scheduler, sets up the network
topology using the network objects and the plumbing functions in the library, and tells
traffic sources when to start and stop transmitting packets through the event scheduler.
The term "plumbing" is used for a network setup, because setting up a network is
plumbing possible data paths among network objects by setting the "neighbor" pointer
of an object to the address of an appropriate object. When a user wants to make a new
network object, he or she can easily make an object either by writing a new object or by
making a compound object from the object library, and plumb the data path through the
object. This may sound like complicated job, but the plumbing OTcl modules actually
make the job very easy. The power of NS comes from this plumbing.
Another major component of NS beside network objects is the event scheduler. An
event in NS is a packet ID that is unique for a packet with scheduled time and the
pointer to an object that handles the event. In NS, an event scheduler keeps track of
simulation time and fires all the events in the event queue scheduled for the current time
by invoking appropriate network components, which usually are the ones who issued
the events, and let them do the appropriate action associated with packet pointed by the
event. Network components communicate with one another passing packets, however
this does not consume actual simulation time. All the network components that need to
spend some simulation time handling a packet (i.e. need a delay) use the event
scheduler by issuing an event for the packet and waiting for the event to be fired to itself
before doing further action handling the packet. For example, a network switch
component that simulates a switch with 20 microseconds of switching delay issues an
event for a packet to be switched to the scheduler as an event 20 microsecond later.
The scheduler after 20 microsecond dequeues the event and fires it to the switch
component, which then passes the packet to an appropriate output link component.
Another use of an event scheduler is timer. For example, TCP needs a timer to keep
track of a packet transmission time out for retransmission (transmission of a packet with
the same TCP packet number but different NS packet ID). Timers use event schedulers
in a similar manner that delay does. The only difference is that timer measures a time
value associated with a packet and does an appropriate action related to that packet
after a certain time goes by, and does not simulate a delay.
NS is written not only in OTcl but in C++ also. For efficiency reason, NS separates the
data path implementation from control path implementations. In order to reduce packet
and event processing time (not simulation time), the event scheduler and the basic
network component objects in the data path are written and compiled using C++. These
compiled objects are made available to the OTcl interpreter through an OTcl linkage
that creates a matching OTcl object for each of the C++ objects and makes the control
functions and the configurable variables specified by the C++ object act as member
functions and member variables of the corresponding OTcl object. In this way, the
controls of the C++ objects are given to OTcl. It is also possible to add member
functions and variables to a C++ linked OTcl object. The objects in C++ that do not
need to be controlled in a simulation or internally used by another object do not need to
be linked to OTcl. Likewise, an object (not in the data path) can be entirely implemented
in OTcl. Figure 2 shows an object hierarchy example in C++ and OTcl. One thing to
note in the figure is that for C++ objects that have an OTcl linkage forming a hierarchy,
there is a matching OTcl object hierarchy very similar to that of C++.
Figure 2. C++ and OTcl: The Duality

Figure 3. Architectural View of NS

Figure 3 shows the general architecture of NS. In this figure a general user (not an NS
developer) can be thought of standing at the left bottom corner, designing and running
simulations in Tcl using the simulator objects in the OTcl library. The event schedulers
and most of the network components are implemented in C++ and available to OTcl
through an OTcl linkage that is implemented using tclcl. The whole thing together
makes NS, which is a OO extended Tcl interpreter with network simulator libraries.
This section briefly examined the general structure and architecture of NS. At this point,
one might be wondering about how to obtain NS simulation results. As shown in Figure
1, when a simulation is finished, NS produces one or more text-based output files that
contain detailed simulation data, if specified to do so in the input Tcl (or more
specifically, OTcl) script. The data can be used for simulation analysis (two simulation
result analysis examples are presented in later sections) or as an input to a graphical
simulation display tool called Network Animator (NAM) that is developed as a part of
VINT project. NAM has a nice graphical user interface similar to that of a CD player
(play, fast forward, rewind, pause and so on), and also has a display speed controller.
Furthermore, it can graphically present information such as throughput and number of
packet drops at each link, although the graphical information cannot be used for
accurate simulation analysis.

References
1. Ian F. Akyildiz and Janise McNair, Medium Access Control Protocols for Multimedia
Traffic in Wireless Networks[A], Georgia Institute of Technology Loren Carrasco
Martorell and Ramon Puigjaner, Universitat de les llles Balears Yelena Yesha,
University of Maryland at Baltimore Count, July/August. 2009.
2. TDMA IS-136 (Time Division Multiple Access).[Online]
[Link]
3. Carries Sense Multiple Access[Online]
[Link]