An Assignment Project Report

On

STOP AND WAIT ARQ PROTOCOL SIMULATION

Submitted in partial fulfilment of requirements for the award of the

Degree of

BACHELOR OF TECHNOLOGY

in

INFORMATION TECHNOLOGY
Under the guidance of

Ms.S.Gowsika

Submitted By

Ajeethkumar M(17BIT3005)

Chandru S(17BIT3021)

Dhanushkumar M(17BIT3023)

Gowtam (17BIT3035)

Mohana Prasanth G(17BIT3063)

DEPARTMENTOF INFORMATION TECHNOLOGY

M.KUMARASAMY COLLEGE OF ENGINEERING

(Autonomous)

KARUR – 639 113

 10th October , 2019

An Assignment Project Report Contents

Cover page
Abstract
1. Introduction
2.Simulation tool(optional)
3. Project Methodology
3.1 Block diagram of proposed system
3.2 Description of working flow of proposed system
4. Results and Discussion
5. Conclusion
Abstract
Stop and Wait is a connection oriented transmission. In this project, we present the analysis of
the Stop-and-Wait ARQ (Automatic Repeat request) protocol with the notable complication
that the transmission errors occur in a burst, correlated manner. Fixed-length packets of data
are sent from transmitter to receiver over an error-prone channel. The receiver notifies the
transmitter whether a packet was received correctly or not by returning a feedback message
over the backward channel. If necessary, the packet is retransmitted until it is received
correctly, after which the transmission of another packet starts. For the Stop-and-Wait
protocol, no other packets are transmitted while the transmitter waits for a feedback message.
We model the transmitter side as a discrete-time queue with infinite storage capacity and
independent and identically distributed (iid) packet arrivals. Arriving packets are stored in the
queue until they are successfully transmitted over the channel. The probability of an
erroneous transmission is modulated by a two-state Markov Chain, rather than assuming
stationary channel errors.In this we have used NS2 simulator for simulation of Stop and Wait
protocol.

Keywords: wireless telecommunication, queueing theory, performance evaluation, generating

func- tions, automatic repeat request.
Introduction
Stop and wait: sender sends one data frame, waits for acknowledgement (ACK) from receiver
before proceeding to transmit next frame This simple flow control will break down if ACK
gets lost or errors occur ! sender may wait for ACK that never arrives. Stop and wait Protocol
also provides for a one directional flow of thw data from sender to receiver . The
communication channel is once again assumed to be error free as in protocol..however this
time the receiver has only a finite buffer capacity and a finite processing speed, so the
protocol must explicitly prevent the sender from flooding the receiver with data faster than it
can be handled.

For noisy link, pure stop and wait protocol will break down, and solution is to incorporate
some error control mechanism. Stop and wait with ARQ: Automatic Repeat request (ARQ),
an error control method, is incorporated with stop and wait flow control protocol

 If error is detected by receiver, it discards the frame and send a negative

ACK(NAK), causing sender to re-send the frame

 In case a frame never got to receiver, sender has a timer: each time a frame is sent,
timer is set !

 If no ACK or NAK is received during timeout period, it re-sends the

frame
 Timer introduces a problem: Suppose timeout and sender retransmits a frame but
receiver actually received the previous transmission  receiver has duplicated
copies
 To avoid receiving and accepting two copies of same frame, frames and ACKs are
alternatively labeled 0 or 1: ACK0 for frame 1, ACK1 for frame 0
 An important link parameter is defined by
propagation time Rd
a= =
frame time VL

where R is data rate (bps), d is link distance (m), V is propagation velocity

(m/s) and L frame length (bits)

 In error free case , efficiency or maximum link utilisation of the Stop and wait with
ARQ is:
1
U=
1+2 a

Simulation tool
Network Simulator 2 (NS2) is a discrete event simulator targeted at networking research. It
provides support for simulation of TCP, routing and multicast protocols over wired and
wireless networks. Currently the development of NS2 is supported by DARPA, NSF and
ACIRI. NS2l can be used for non-commercial use free of charge.

Language used
TCL is a Tool command language, commands are the most vital part of the language. TCL
commands are built in-to the language with each having its own predefined function. These
commands form the reserved words of the language and cannot be used for other variable
naming. The advantage with these TCL commands is that, you can define your own
implementation for any of these commands to replace the original built-in functionality.
Each of the TCL commands validates the input and it reduces the work of the interpreter.
TCL command is actually a list of words, with the first word representing the command to
be executed. The next words represent the arguments. In order to group the words into a
single argument, we enclose multiple words with "" or {}.
Project methodology
Block diagram of proposed system
Source code

set ns [new Simulator]

set n0 [$ns node]

set n1 [$ns node]

$ns at 0.0 "$n0 label Sender"

$ns at 0.0 "$n1 label Receiver"
$n0 color red
$n1 color blue

set nf [open stop-n-wait.nam w]

$ns namtrace-all $nf
set f [open stop-n-wait.tr w]
$ns trace-all $f

$ns duplex-link $n0 $n1 0.2Mb 200ms DropTail

$ns duplex-link-op $n0 $n1 orient right
$ns queue-limit $n0 $n1 10

Agent/TCP set nam_tracevar_ true

set tcp [new Agent/TCP]

$tcp set windowInit_ 1
$tcp set maxcwnd_ 1
$ns attach-agent $n0 $tcp

set sink [new Agent/TCPSink]

$ns attach-agent $n1 $sink

$ns connect $tcp $sink

set ftp [new Application/FTP]

$ftp attach-agent $tcp

$ns add-agent-trace $tcp tcp

$ns monitor-agent-trace $tcp
$tcp tracevar cwnd_

$ns at 0.1 "$ftp start"

$ns at 3.0 "$ns detach-agent $n0 $tcp ; $ns detach-agent $n1 $sink"
$ns at 3.5 "finish"

$ns at 0.0 "$ns trace-annotate \"Stop and Wait with normal operation\""

$ns at 0.05 "$ns trace-annotate \"FTP starts at 0.1\""

$ns at 0.11 "$ns trace-annotate \"Send Packet_0\""

$ns at 0.35 "$ns trace-annotate \"Receive Ack_0\""
$ns at 0.56 "$ns trace-annotate \"Send Packet_1\""
$ns at 0.79 "$ns trace-annotate \"Receive Ack_1\""
$ns at 0.99 "$ns trace-annotate \"Send Packet_2\""
$ns at 1.23 "$ns trace-annotate \"Receive Ack_2 \""
$ns at 1.43 "$ns trace-annotate \"Send Packet_3\""
$ns at 1.67 "$ns trace-annotate \"Receive Ack_3\""
$ns at 1.88 "$ns trace-annotate \"Send Packet_4\""
$ns at 2.11 "$ns trace-annotate \"Receive Ack_4\""
$ns at 2.32 "$ns trace-annotate \"Send Packet_5\""
$ns at 2.55 "$ns trace-annotate \"Receive Ack_5 \""
$ns at 2.75 "$ns trace-annotate \"Send Packet_6\""
$ns at 2.99 "$ns trace-annotate \"Receive Ack_6\""

$ns at 3.1 "$ns trace-annotate \"FTP stops\""

proc finish {} {
global ns
$ns flush-trace
#close $nf

# puts "filtering..."
# exec tclsh ../ns-allinone-2.1b5/nam-1.0a7/bin/namfilter.tcl A1-stop-n-wait.nam
puts "running nam..."
exec nam stop-n-wait.nam &
exit 0
}

$ns run
Output
Description of working flow of proposed system
The source node transmits the frames one by one. Each frame in the buffer has a sequence
number starting from 1 and increasing up to the window size. The source node has a window
i.e. a buffer to store the frames. This buffer size is the number of frames to be transmitted
continuously. The size of the window depends on the protocol designer. For the first frame,
the receiving node forms a positive acknowledgement if the frame is received without error.
If subsequent frames are received without error (up to window size) cumulative positive
acknowledgement is formed. If the frame is received with error, it is retransmitted again after
a time. Similarly even the frames received without error after the receipt of a frame with error
are neglected. The source node retransmits frame of window from the first error frame. If the
frames are errorless in the next transmission and if the acknowledgment is error free, the
window slides by the number of error-free frames being transmitted. If the acknowledgment
is transmitted with error, the frames of window at source are retransmitted, and window
doesn’t slide. This concept of repeating the transmission from the first error frame in the
window is called as STOP AND WAIT transmission flow control protocol.
Results and discussion
Receiver will send back an ACK to sender if the correct frame received (right frame in right
order). If the frame is lost or damaged, receiver will remain silence. If there is no ACK back
not back on time, sender will resend group of frames. The receiver is only “loyalty” to the
first incoming frame, no matter what are the conditions of the following frame, even they are
correct, “ignore” them still. The throughput of the system will remain constant with one
packet lengths then it returns back to zero and. The Stop And Wait ARQ is better for no loss
in packet in transmission.
Conclusion
In this project we made an analysis of the Stop And Wait ARQ which is a data link layer error
control protocols and simulation software without considering the bit errors. Further
enhancement can be made to analyze the effect of timer timeout and packet on the throughput
of the system considering bit errors. Also we can analyze the effect of data rate on
throughput. This simulation performs an unreliable channel using TCP Packets and
acknowledges are consciously dropped to show working structure of Stop and Wait.