FACULTY OF ENGINEERING
SCHOOL OF ELECTRONIC AND
COMMUNICATIONS ENGINEERING
Degree in Computer Engineering
(Course reference FT281)
3rd Year Project Report
Submitted by:
Paul Lynam
May 2003
Paul Lynam, FT281 3rd Year Project
FT281 Third Year Project
“Protocol Modelling and Simulation”
Report By: Paul Lynam
Project Supervisor: Bertrand Faust
Protocol Modelling and Simulation
2
Paul Lynam, FT281 3rd Year Project
Table Of Contents
1. Introduction ................................................................................................ 5
2. Background and Design ................................................................ 7
2.1 Initial Research .......................................................................................... 7
2.2 Designing the Stop & Wait Flow Control.................................... 7
3. Implementation..................................................................................... 12
3.1 Attaching The Code .............................................................................. 12
3.2 Creating The Node Model ................................................................. 14
3.3 Creating A Project.................................................................................. 15
4. Results ........................................................................................................... 16
4.1 Configuring The Counters ................................................................. 16
4.2 Simulating Error-Free Transmission ............................................ 16
4.3 Non-Error Free Transmission .......................................................... 17
5. Sliding Window Protocol........................................................... 22
6. Conclusion ................................................................................................ 24
Appendix A ..................................................................................................... 25
Appendix B ..................................................................................................... 30
Appendix C ..................................................................................................... 37
Appendix D ..................................................................................................... 49
Protocol Modelling and Simulation
3
Paul Lynam, FT281 3rd Year Project
Acknowledgements
Mr Bertrand Faust
Project Supervisor
Big thanks for all his time and effort during the project
Mr Andrew Dillon
Technician
Thanks to Andy for assistance with the software and PCs throughout.
References
[1] OPNET Technologies Modeller Documentation accompanying the software
[2] OPNET Technologies Training Documentation: Stop-and-Wait Retransmission
Protocol
Protocol Modelling and Simulation
4
Paul Lynam, FT281 3rd Year Project
1. Introduction
This three-month, full time project was entitled ‘Protocol Modelling and
Simulation’ with the objective in the project to implement flow control mechanisms
as processes that could be included in an OPNET simulation.
OPNET stands for Optimised Network Engineering Tools. It is a simulation and
design tool for telecommunications networks. OPNET can simulate communication
networks and protocols in order to assess their performances.
In OPNET a process is modelled as a Finite State Machine (FSM) to which C/C++
code can be attached to describe some particular behaviour. The process can then be
integrated with other processes to build a node model, itself part of a network model.
Figure 1 below shows an example of a process, which is modelled as a FSM.
The
symbol represents a state of the FSM. The states are linked together by
transitions. Transitions may be unconditional or may need a certain condition to be
satisfied before taking place. As shown in figure 1, the text within brackets, which
accompanies the transition, is the name of the condition that must be satisfied in order
for the transition to occur.
Protocol Modelling and Simulation
5
Paul Lynam, FT281 3rd Year Project
Figure 1 - A process modelled as a FSM
During the project, standard flow control mechanisms were implemented such as Stop
& Wait and Sliding Window. The project provided invaluable experience in building
a first level of competence in a modelling and simulation tool widely used by
industry.
It should be noted that this project was initially intended to be undertaken by two
persons, however due to a change in circumstances the project was undertaken by
myself, and I worked alone through the course of the project with help from the
project supervisor, Mr Bertrand Faust.
Protocol Modelling and Simulation
6
Paul Lynam, FT281 3rd Year Project
2. Background and Design
2.1 Initial Research
For the first eight days of the project, the main aim was to become familiar with the
OPNET software package. A number of introductory tutorials were studied, dealing
with critical areas of the OPNET package such as:

Use of the Project, Node and Process editors

Set-up and configuration of Local Area Networks

Construction of a M/M/1 Queue

Configuration of a simulation and analysis of results.

Frequently used Kernel procedures

Implementation of a packet switching network
These tutorials were invaluable in building up a good overall knowledge of the
OPNET simulation package, and so once the tutorials were completed, I was ready to
tackle the first part of the project – implementing a Stop & Wait flow control
mechanism.
2.2 Designing the Stop & Wait Flow Control
Having viewed the ‘OPNET Training’ documentation supplied by Mr Faust, the basic
functionality of the Stop & Wait Flow Control mechanism was explained. The
requirements of this protocol were identified as follows:
Protocol Modelling and Simulation
7
Paul Lynam, FT281 3rd Year Project

Receive frames from a higher layers

Transmit frames over the physical layer

Must receive an acknowledgement before sending the next frame

Queue frames arriving from the higher layer if the process is waiting for
acknowledgement of the previous frame

Retransmit the frame if an acknowledgement is not received before the end of
a timeout period.
The timer is set each time a new frame is sent and if the timer expires (i.e. the
transmitter has not received acknowledgement of the previous frame sent) then
the unacknowledged frame is resent. The timeout period is set to slightly more
than the length of time taken for a new frame to be sent across the link plus the
time taken for an acknowledgement to be sent back to the transmitter.

Must count the number of frames received by the receiver

Must count the number of acknowledgements received by the transmitter
As this was the first attempt at implementing such a protocol in OPNET, it was
decided by the project supervisor to keep the complexity to a minimum. It was
decided that only one node would generate packets and one node would receive
acknowledgements instead of both nodes being able to generate packets and receive
acknowledgements.
The ‘OPNET Training’ documentation recommends a five-stage approach to
implementing the process model for the Stop & Wait protocol:
1. Context Definition
2. Process-Level Decomposition
3. Enumeration Of Events
Protocol Modelling and Simulation
8
Paul Lynam, FT281 3rd Year Project
4. State Transition Diagram Development
5. Specification Of Process Actions
As a result, an event response table was drawn up for the steps involved in
implementing the Stop & Wait protocol. The transmitter was dealt with first. This
design will be known as ‘Version 1’ of the Stop & Wait protocol implementation as
the design was heavily modified later in the project. This event response table may be
viewed in Appendix A of this report.
Figure 2 - Stop & Wait Protocol – Transmitter (Version 1)
The State Transition Diagram for Version 1 was implemented in the form of a FSM as
shown in Figure 2 above. The main reason for this initial design was so that the use of
transition executives could be excluded.
Protocol Modelling and Simulation
9
Paul Lynam, FT281 3rd Year Project
A transition executive is a piece of code which is executed when a transition occurs
from one state in the FSM to another state. The inclusion of transition executives
makes coding of the process models slightly more complex and so the simpler coding
of the process model in Figure 2 was the deciding factor in choosing this design.
However, after many weeks of code alterations and modifications, Version 1 failed to
operate properly. After a lengthy discussion between the project supervisor and
myself, it was decided to opt for the more complex design, which included the use of
transition executives. The event response table for this design, known as Version 2,
can be seen in Appendix A.
Figure 3 below shows the implementation of this design in a FSM
Figure 3 - Stop & Wait Protocol – Transmitter (Version 2)
Note the use of transition executives in Version 2 of the design.
Protocol Modelling and Simulation
10
Paul Lynam, FT281 3rd Year Project
The design of the receiver in the Stop & Wait protocol was quite simple and did not
require a state transition diagram. The FSM for the receiver is shown in figure 4
below. The complete code for the receiver side of the Stop & Wait protocol is shown
in Appendix B of this report.
In this case the receiver simply resends the received packet back to the transmitter as
an acknowledgement. This approach was taken to again reduce the complexity of the
system. In ideal circumstances, a new, and very small packet would be generated at
the receiver and sent back to the transmitter. This would dramatically increase the
efficiency of the link between the transmitter and receiver.
Figure 4 - Stop & Wait Protocol - Receiver (Version 2)
Protocol Modelling and Simulation
11
Paul Lynam, FT281 3rd Year Project
3. Implementation
3.1 Attaching The Code
Implementation of the Stop & Wait protocol for Version 2 of the design involved the
construction of the FSM and the subsequent attachment of the C/C++ code to the
process model shown in figure 3, to describe the desired behaviour of the model. The
complete code for the model is shown in Appendix B of this report.
The construction of the Finite State Machine (FSM) is a simple ‘drag and drop’
procedure, which involves placing unnamed states in the desired positions and
renaming them as appropriate. For example, in figure 3 one of the states is named
ACK Wait, which is a state entered when the system is waiting for an
acknowledgement of a packet to arrive at the transmitter, before the next new packet
can be sent.
The C/C++ code to be attached was relatively simple for the Stop & Wait protocol.
The condition that must be satisfied in order for each transition to occur is defined in
the Header Block, while the transition executive (the piece of code which executes
when a transition occurs) is defined in the Function Block.
Taking an example from figure 3, we can see that a transition occurs from the ACK
Wait state back to the ACK Wait state when the condition ‘Frame_Arrival’ is true and
then the ‘Queue_Frame’ executive is executed.
The condition ‘Frame_Arrival’ is defined in the Header Block as follows:
#define Frame_Arrival ( op_intrpt_type () == \
OPC_INTRPT_STRM && op_intrpt_strm () == SRC_IN_STRM )
Protocol Modelling and Simulation
12
Paul Lynam, FT281 3rd Year Project
The condition ‘Frame_Arrival’ will be satisfied if a stream interrupt occurs. A stream
interrupt is only detected when it occurs on the input stream from the source as
defined.
When the condition ‘Frame_Arrival’ is satisfied and the transition from the ACK
Wait state back to the ACK Wait state occurs, the ‘Queue_Frame’ executive will
execute. The code for the ‘Queue_Frame’ executive is shown below:
static void
Q_Frame(void)
{
/* Obtain a pointer to the arriving packet */
pkptr = op_pk_get (SRC_IN_STRM);
/* insert the new packet at tail of the subqueue 0 */
if (op_subq_pk_insert (0, pkptr, OPC_QPOS_TAIL) !=
OPC_QINS_OK)
{
/* if the insertion failed, discard the packet */
op_pk_destroy (pkptr);
}
}
This code, along with all the code for the transition executives is contained in the
Function Block. Firstly, a pointer is used to point to the packet which is causing the
stream interrupt on the source input stream. This packet is then inserted at the tail of a
subqueue. A queue is split up into smaller subqueues, however in this case our
subqueue was set to an infinite size so there was no need to switch to other subqueues
as this subqueue would never be filled. The final piece of code ensures that the packet
will be destroyed if it fails to be inserted into the subqueue.
Protocol Modelling and Simulation
13
Paul Lynam, FT281 3rd Year Project
The packet pointer (pkptr) used in the above piece of code is a variable which must
first be defined in ‘State Variables’ so that it will be recognised when all the code is
compiled. This state variable is of type Packet * and is obviously named pkptr for
clarity. All other variables used in the coding process must be defined in the State
Variables. See Appendix B for the completed code for the Stop & Wait protocol.
3.2 Creating The Node Model
The process model created must then be placed within a node model, which is seen at
the node level. This node model is shown in figure 5 below.
Figure 5 - Stop & Wait Node Model (Transmitter)
The process model in figure 3 is placed inside the ‘saw’ node. The src, xmt, and rcv
nodes are pre-existing OPNET nodes that generate, transmit and receive packets
respectively. Packets are generated in the ‘src’ node and sent to the ‘saw’ node. These
packets are received into the ‘saw’ node via the source input stream discussed earlier.
Protocol Modelling and Simulation
14
Paul Lynam, FT281 3rd Year Project
The ‘xmt’ and ‘rcv’ nodes then transmit or receive packets as required across the link
at the project level.
3.3 Creating A Project
At the project level, there are simply two nodes, one node that sends packets and the
other node that sends acknowledgements. The link connecting these two nodes was
configured with a bit rate of 9600 bits/second. The source was configured to generate
packets which were 9600 bits in length so that each packet would take one second to
traverse the link. The two nodes connected via this link at the project level are shown
in figure 6.
Figure 6 - Transmitting & Receiving Nodes
Protocol Modelling and Simulation
15
Paul Lynam, FT281 3rd Year Project
4. Results
4.1 Configuring The Counters
Before any results were recorded, two counters were initialised, one at the receiver to
count the number of packets sent across the link (frames received) and a second to
count the number of acknowledgements received back at the transmitter (acknowl
count). Please refer to Appendix B for the code to initialise these counters.
4.2 Simulating Error-Free Transmission
A simulation of the Stop & Wait protocol was simulated over 100 seconds and the
following results were obtained.
Figure 7 - Results of Stop & Wait simulation
Protocol Modelling and Simulation
16
Paul Lynam, FT281 3rd Year Project
As we can see from figure 7, both the frames received and acknowl count counters
increase at a uniform rate to a maximum value of 45 packets each at the end of the
100-second simulation period. This packet count of 45 can be proven correct.
The source only begins generating packets after 10 seconds so this means there is only
a 90 second period in which packets will traverse the link. As the packets are 9600
bits in length and the bit rate of the link is 9600 bits/second, it will take 1 second for a
packet to cross the link. So, a new packet will take 1 second to be sent from the
transmitter to receiver and the same packet will take a further 1-second to be sent
from the receiver to the transmitter (remember the acknowledgement is simply the
original packet resent back to the transmitter). Hence in the 90 seconds available, 45
packets and 45 acknowledgements will be sent across the link.
The queue size also increases as packets are generated and then queued when in the
ACK Wait state.
4.3 Non-Error Free Transmission
The next step was to introduce errors into the link between the transmitter and
receiver. This is achieved by adjusting the bit error rate (ber) of the link, as well as
changing the ecc threshold value of the receiving node for both the transmitter and
receiver. The ecc threshold is the highest proportion of bit errors allowed in a packet
in order for the packet to be accepted by the receiver and forwarded to an output
stream. As an example, a receiver with an "ecc threshold" value of 0.20 will accept
packets with no more than 20% of their bits in error.
Firstly, the ber and the ecc threshold values were both set to zero and the following
results were obtained:
Protocol Modelling and Simulation
17
Paul Lynam, FT281 3rd Year Project
Figure 8 - Results obtained for ber = 0 and ecc = 0
The results are as expected. The number of packets sent by the generator is the same
as the number of packets received by the receiver because the ber of the link set to 0.
For the same reason the number of acknowledgements received at the transmitter is
the same as the number of frames received at the receiver.
However, if we view the results with a ber 1  10-4 and an ecc threshold of 0 the
results are dramatically different (simulation over 2500 seconds):
Protocol Modelling and Simulation
18
Paul Lynam, FT281 3rd Year Project
Figure 9 - Results obtained for ber = 1e-4 and ecc = 0
From figure 9, the number of packets sent is 870, and the number of frames received
is 325, which means that 545 frames were lost between the transmitter and receiver
due to the ber of 1  10-4 and an ecc threshold at the receiver of 0. The threshold value
at the transmitter side was set to 1 so that no acknowledgements would be rejected by
the transmitter as a result of errors. Hence the number of acknowledgements received
was the same as the number of frames received. If we divide the number of frames
sent by the number of frames received, we see that, on average, each frame was sent
2.6 times. This is formally proven below.
Protocol Modelling and Simulation
19
Paul Lynam, FT281 3rd Year Project
For the results obtained in figure 9, we can calculate the Probability of a single packet
being in error:
P = 1-(1-ber)N
where
N = number of bits in a frame
b = probability of error per bit (ber)
P = probability of error per packet
P = 1 - [1 - (1  10-4)]9600
P = 0.617
There is a high probability that a single frame is in error. This would explain the large
number of frames lost at the receiver because the ecc threshold is set to zero which
means that any frames that have even a single bit in error will be rejected by the
receiver. If we multiply the probability of a single packet being in error by the number
of frames sent:
0.617  870 = 537  545 (the number of packets actually received)
We can also derive and a formal expression for the number of times each packet is
sent.
The probability of successful transmission of a packet after the first attempt:
1  (1-P)
The probability of successful transmission of a packet after the two attempts:
2  P(1-P)
The probability of successful transmission of a packet after the three attempts:
3  P2(1-P)
The probability of successful transmission of a packet after the n attempts:
n  Pn-1(1-P)
Protocol Modelling and Simulation
20
Paul Lynam, FT281 3rd Year Project

  nP n 1 (1  P) =
n 1
1
1 P
1
1
=
= 2.61 as expected
1  P 1  0.617
Also, if we divide the number of times packets were sent by the average number of
times each packet was sent:
870
= 333  325 packet received.
2.61
Refer to Appendix C for a complete analysis of all results obtained.
Protocol Modelling and Simulation
21
Paul Lynam, FT281 3rd Year Project
5. Sliding Window Protocol
Towards the end of the project, once the Stop & Wait protocol had been implemented
successfully, it was decided to begin implementation of a Sliding Window protocol in
OPNET. However, there were only a few days of the project left so not much progress
was made on the Sliding Window Protocol.
The major advantage of the Sliding Window protocol over the Stop & Wait protocol
is that multiple frames can be sent without acknowledgement in the Sliding Window
protocol. Another advantage of the Sliding Window approach is that one single
acknowledgement can acknowledge all previous frames received with a lower
sequence number than the acknowledgement.
As there may be a number of outstanding unacknowledged packets at any one time,
each packet is labelled with it’s own sequence number so that when an
acknowledgement is received with the same sequence number, then it is known which
packets have been acknowledged and which packets have not been acknowledged.
As with the Stop & Wait protocol, the first step was to develop an Event Response
Table (ERT) and from this construct a State Transition Diagram. The ERT for the
Sliding Window protocol can be viewed in Appendix D of this report. Figure 10
below shows the state transition diagram for the Sliding Window protocol. There was
no time in the project to implement any code for the Sliding Window protocol.
Protocol Modelling and Simulation
22
Paul Lynam, FT281 3rd Year Project
Figure 10 – Sliding Window Protocol – Transmitter
Protocol Modelling and Simulation
23
Paul Lynam, FT281 3rd Year Project
6. Conclusion
I found this to be a very useful and interesting project, as I have built up a good base
of knowledge in the use of OPNET. The OPNET software is widely used in industry
as a simulation and design tool for telecommunications networks. The project also
integrated well into this year’s curriculum as I had studied protocols and flow control
mechanisms only a few months before undertaking the project.
The project was originally designed for two people but early in the project I was
informed that I would have to undertake the project alone. Because of the
circumstances, I didn’t complete the design and implementation of many protocols. If
two people had been assigned to the project then I’m sure we could have made more
progress over the past three months.
The Stop & Wait protocol was successfully implemented after many changes to the
initial design. Much of the time during the project was also spent becoming familiar
with the various OPNET-specific kernel procedures and other OPNET-specific code.
Initially, a less complex design was used to implement the Stop & Wait protocol but
this failed to operate correctly when simulated. A more complex design involving the
use of transition executives was used and this operated as expected. A lot of time was
lost during the initial stages of the project trying to implement the simpler design
which never worked correctly.
I have found the last three months to be of invaluable experience and I would
undoubtedly enjoy a full-time position in industry working with the OPNET
simulation package.
Protocol Modelling and Simulation
24
Paul Lynam, FT281 3rd Year Project
Appendix A
Event Response Table – Transmitter (Version 1)
Condition
Frame Arrival
Initial State
Init
IDLE
Event/Action
Power-Up
If a frame
arrives from the
source, while in
the IDLE state,
then copy the
frame, send the
frame and set
the timer.




Unconditional
Frame Arrival
Send_Frame
ACK Wait

Unconditional
Q_Frame
Protocol Modelling and Simulation
Executive
Send_Frame
Enter Executives
Remove
packet
from
subqueue
Copy
Frame
Send
Frame
Set
Timer
If a frame
arrives from the
source, while in
the ACK Wait
state, then put
the frame into
the queue.

Final State
IDLE
Send_Frame
ACK_Wait
Q_Frame
Q_Frame
Enter Executives
Get
Pointer
Insert
Packet
Into Subqueue
ACK_Wait
25
Paul Lynam, FT281 3rd Year Project
Timeout
ACK Wait
If the timer
expires while in
the ACK Wait
state, then
resend the
frame.


Unconditional
Resend_Frame
ACK_Rec
&& Q_empty
ACK_Wait

Protocol Modelling and Simulation
Send
Copy Of
Frame
Reset
Timer
If an ACK is
received while
in the
ACK_Wait
state, then obtain
a pointer to the
packet, destroy
the packet and
cancel the timer.

Destroy_Frame
Resend_Frame
Enter Executives
ACK_Wait

Unconditional
Resend_Frame
Destroy_Frame
Destroy_Frame
Enter Executives
Get
pointer
to packet
Destroy
Packet
Cancel
Timer
IDLE
26
Paul Lynam, FT281 3rd Year Project
ACK_Rec
&& Q_!empty
ACK_Wait
If an ACK is
Destroy_Frame_0 Destroy_Frame_0
received while
Enter Executives
in the
ACK_Wait
state, then obtain
a pointer to the
packet, destroy
the packet and
cancel the timer.



Unconditional
Get
pointer
to packet
Destroy
Packet
Cancel
Timer
Destroy_Frame_0
Send_Frame
Event Response Table - Transmitter (Version 2)
State
INIT
IDLE
Event
Frame
Arrival
Condition/Exec
utive
Unconditional
Frame_Arrival/
Send_Frame
Action
If a frame arrives from the
source, while in the IDLE
state, then remove the frame
from the subqueue, copy the
frame, send the frame and set
the timer.
Final State
IDLE
ACK Wait
- Remove packet from
subqueue
- Copy Frame
- Send Frame
- Set Timer
Protocol Modelling and Simulation
27
Paul Lynam, FT281 3rd Year Project
State
ACK Wait
Event
Frame
Arrival
Condition/Exe
cutive
Frame_Arrival/
Queue_Frame
Action
Final State
If a frame arrives from the
source, while in the ACK
Wait state, then obtain a
pointer to the new packet
and insert the packet at the
tail of the subqueue
ACK Wait
- Obtain a pointer to the
new frame
- Insert the new frame at
the tail of subqueue 0
State
ACK Wait
Event
Timeout
Condition/Exe
cutive
Time_out/Send
_Frame_Copy
Action
If the timer expires while
in the ACK Wait state;
Final State
ACK Wait
- Send the copy of the
previous packet to the
receiver.
- Set the timer
State
ACK Wait
Event
ACK
Received
and queue
not empty
Condition/Execu
tive
ACK_Received_
Q_not_empty/AC
K_Handle_And_
Send_Frame
Action
Final State
If an ACK is received
and the subqueue is not
empty:
ACK Wait
- Increment the packet
counter
- Destroy the ACK
- Obtain a pointer to the
packet at the head of
the subqueue
- Copy Frame
- Send Frame
- Set Timer
Protocol Modelling and Simulation
28
Paul Lynam, FT281 3rd Year Project
State
ACK Wait
Event
ACK
Received
and queue
empty
Condition/Execu
tive
ACK_Received_
Q_empty/ACK_
Handle
Action
Final State
If an ACK is received
and the subqueue is
empty, then increment
the packet counter and
destroy the ACK. Wait
for the next packet to
be queued.
IDLE
- Increment the packet
counter
- Destroy the ACK
Protocol Modelling and Simulation
29
Paul Lynam, FT281 3rd Year Project
Appendix B
*******************Header Block (T/X)********************
/* packet stream definitions */
#define RCV_IN_STRM 0
#define SRC_IN_STRM 1
#define XMT_OUT_STRM 0
#define Timeout 5
/* transition macros */
#define Frame_Arrival ( op_intrpt_type () == \
OPC_INTRPT_STRM && op_intrpt_strm () == SRC_IN_STRM )
#define ACK_Rec_Q_not_empty ( op_intrpt_type () == \
OPC_INTRPT_STRM && op_intrpt_strm () == RCV_IN_STRM &&
op_q_empty () == OPC_FALSE )
#define ACK_Rec_Q_empty ( op_intrpt_type () == \
OPC_INTRPT_STRM && op_intrpt_strm () == RCV_IN_STRM &&
op_q_empty () == OPC_TRUE )
#define Time_out ( op_intrpt_type () == \
OPC_INTRPT_SELF && op_intrpt_code () == Timeout )
#define
#define
#define
#define
#define
Send_Frame S_Frame ()
Send_Frame_Copy S_Frame_Copy ()
Queue_Frame Q_Frame ()
ACK_Handle ACK_Han ()
ACK_Handle_And_Send_Frame ACK_Han_And_S_Frame ()
/* Function
static void
static void
static void
static void
static void
Declarations */
S_Frame(void);
S_Frame_Copy(void);
Q_Frame(void);
ACK_Han(void);
ACK_Han_And_S_Frame(void);
Protocol Modelling and Simulation
30
Paul Lynam, FT281 3rd Year Project
**********************Function Block (T/X)***************
static void
S_Frame(void)
{
data_rate = 9600;
/*
/*
/*
/*
/*
*/
a request has been made to forward a packet
over one of the queue’s output streams, only
if the queue is empty, the packet will be pulled
from the subqueue with the same index as the
output stream
*/
*/
*/
*/
/* determine which subqueue is being accessed */
//
subq_index = op_intrpt_code ();
/* access the first packet in subqueue 0 */
pkptr = op_subq_pk_remove (0, OPC_QPOS_HEAD);
/* determine the packet length (in bits) */
pk_len = op_pk_total_size_get (pkptr);
/* set the timer length to 3 propagations of a */
/* packet across the link
*/
trans_time = 3*((double) pk_len / data_rate);
/* copy the packet before sending it */
cp_pkptr = op_pk_copy (pkptr);
/* forward it to the destination over requested stream
*/
op_pk_send (pkptr, XMT_OUT_STRM);
/* Increment the packet counter */
pkts_sent = pkts_sent + 1;
/* Write out the value of the statistic */
op_stat_write (pkts_snt_stathandle, pkts_sent);
/* Set the timer */
evh = op_intrpt_schedule_self (op_sim_time () +
trans_time, 5);
}
Protocol Modelling and Simulation
31
Paul Lynam, FT281 3rd Year Project
static void
Q_Frame(void)
{
/* Obtain a pointer to the arriving packet */
pkptr = op_pk_get (SRC_IN_STRM);
/* Determine which subqueue will be accessed */
//
subq_index = op_intrpt_code ();
/* insert the new packet at tail of the subqueue 0 */
if (op_subq_pk_insert (0, pkptr, OPC_QPOS_TAIL) !=
OPC_QINS_OK)
{
/* if the insertion failed, discard the packet */
op_pk_destroy (pkptr);
}
}
static void
ACK_Han_And_S_Frame(void)
{
data_rate = 9600;
/* Cancel the timer */
op_ev_cancel (evh);
/* destroy the acknowledgment */
pkptr = op_pk_get (RCV_IN_STRM);
op_pk_destroy (pkptr);
/* Increment the packet counter */
ack_count = ack_count + 1;
/* Write out the value of the statistic */
op_stat_write (ack_cnt_stathandle, ack_count);
/* determine which subqueue is being accessed */
//
subq_index = op_intrpt_code ();
/* access the first packet in the subqueue 0 */
pkptr = op_subq_pk_remove (0, OPC_QPOS_HEAD);
/* determine the packet length (in bits) */
pk_len = op_pk_total_size_get (pkptr);
Protocol Modelling and Simulation
32
Paul Lynam, FT281 3rd Year Project
/* set the timer length to 3 propogations of a */
/* packet across the link
*/
trans_time = 3*((double) pk_len / data_rate );
/* copy the packet before sending it */
cp_pkptr = op_pk_copy (pkptr);
/* forward it to the destination over requested stream
*/
op_pk_send (pkptr, XMT_OUT_STRM);
/* Increment the packet counter */
pkts_sent = pkts_sent + 1;
/* Write out the value of the statistic */
op_stat_write (pkts_snt_stathandle, pkts_sent);
/* Set the timer */
evh = op_intrpt_schedule_self (op_sim_time () +
trans_time, 5);
}
static void
ACK_Han(void)
{
/* Cancel the timer */
op_ev_cancel (evh);
/* destroy the acknowledgment */
pkptr = op_pk_get (RCV_IN_STRM);
op_pk_destroy (pkptr);
/* Increment the packet counter */
ack_count = ack_count + 1;
/* Write out the value of the statistic */
op_stat_write (ack_cnt_stathandle, ack_count);
}
Protocol Modelling and Simulation
33
Paul Lynam, FT281 3rd Year Project
static void
S_Frame_Copy(void)
{
data_rate = 9600;
pkptr = op_pk_copy (cp_pkptr);
/* Send the copied packet to the transmitter */
op_pk_send (pkptr, XMT_OUT_STRM);
/* determine the packet length (in bits) */
pk_len = op_pk_total_size_get (cp_pkptr);
/* set the timer length to 3 propagations of a */
/* packet across the link
*/
trans_time = 3*((double) pk_len / data_rate );
/* Increment the packet counter */
pkts_sent = pkts_sent + 1;
/* Write out the value of the statistic */
op_stat_write (pkts_snt_stathandle, pkts_sent);
/* Set the timer */
evh = op_intrpt_schedule_self (op_sim_time () +
trans_time, 5);
}
*********************State Variables (T/X)***************
Type
Evhandle
Packet *
Packet *
Int
Stathandle
Double
OpT_Packet_Size
Double
Int
Stathandle
Protocol Modelling and Simulation
Name
evh
pkptr
cp_pkptr
ack_count
ack_cnt_stathandle
trans_time
pk_len
data_rate
pkts_sent
pkts_snt_stathandle
34
Paul Lynam, FT281 3rd Year Project
*******************Header Block (R/X)********************
/*packet stream definitions */
#define RCV_IN_STRM 0
#define XMT_OUT_STRM 0
/* transition macros */
#define Frame_Arrival ( op_intrpt_type () == \
OPC_INTRPT_STRM && op_intrpt_strm () == RCV_IN_STRM )
#define Send_ACK S_ACK ()
/* Function Declarations */
static void S_ACK(void);
**********************Function Block (R/X)***************
static void
S_ACK (void)
{
/* a new packet has arrived; acquire it */
pkptr = op_pk_get (RCV_IN_STRM);
/* copy the packet before sending it */
cp_pkptr = op_pk_copy (pkptr);
/* forward the copy to the destination over requested
stream */
op_pk_send (cp_pkptr, XMT_OUT_STRM);
/* Destroy the original packet received */
op_pk_destroy (pkptr);
/* Increment the packet counter */
rec_count = rec_count + 1;
/* Write out the value of the statistic */
op_stat_write (rec_cnt_stathandle, rec_count);
}
Protocol Modelling and Simulation
35
Paul Lynam, FT281 3rd Year Project
*********************State Variables (T/X)***************
int
Stathandle
Packet *
Packet *
rec_count
rec_cnt_stathandle
pkptr
cp_pkptr
Initialising the frames received and acknowl count counters:
***************State Variables (T/X & R/X)***************
Type
int
Stathandle
int
Stathandle
Name
ack_count
ack_cnt_stathandle
rec_count
rec_cnt_stathandle
********INIT state: enter executives (T/X & R/X)*********
ack_count = 0;
ack_cnt_stathandle = op_stat_reg ("acknowl count",
OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
rec_count = 0;
rec_cnt_stathandle = op_stat_reg ("frames received",
OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
Protocol Modelling and Simulation
36
Paul Lynam, FT281 3rd Year Project
Appendix C
*All of the following results were obtained over a simulation period of 2500 seconds*
Figure 11 - Results obtained for ber = 0 and ecc = 0
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1245
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (0)]9600 = 0
n=
1
1
=
=1
1 P
1 0
Each packet is sent once.
Protocol Modelling and Simulation
37
Paul Lynam, FT281 3rd Year Project
Figure 12 - Results obtained for ber = 0 and ecc = 0.1
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1245
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (0)]9600 = 0
n=
1
1
=
=1
1 P
1 0
Each packet is sent once.
Protocol Modelling and Simulation
38
Paul Lynam, FT281 3rd Year Project
Figure 13 - Results obtained for ber = 0 and ecc = 0.01
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1245
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (0)]9600 = 0
n=
1
1
=
=1
1 P
1 0
Each packet is sent once.
Protocol Modelling and Simulation
39
Paul Lynam, FT281 3rd Year Project
Figure 14 - Results obtained for ber = 1e-2 and ecc = 0
Packets Sent: 830
Frames Received: 0
ACK Received: 0
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-2)]9600 = 1
n=
1
1
=
=
1 P
11
The same packet is sent 830 times.
Protocol Modelling and Simulation
40
Paul Lynam, FT281 3rd Year Project
Figure 15 - Results obtained for ber = 1e-2 and ecc = 0.1
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1245
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-2)]9600 = 1
n=
1
1
=
=
1 P
11
This is an interesting result. According to the calculations, the same packet should be
sent 1245 times. However, each packet is only sent once because of the high ecc
threshold value set at the receiver (10%). The above formula does not take this factor
into account, the ecc threshold is taken as zero in the formula.
Protocol Modelling and Simulation
41
Paul Lynam, FT281 3rd Year Project
Figure 16 - Results obtained for ber = 1e-2 and ecc = 0.01
Packets Sent: 996
Frames Received: 498
ACK Received: 498
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-2)]9600 = 1
n=
1
1
=
=
1 P
11
Again, this formula gives an inaccurate answer, as it does not take into account the
ecc threshold value. On average, each packet is sent twice.
Protocol Modelling and Simulation
42
Paul Lynam, FT281 3rd Year Project
Figure 17 - Results obtained for ber = 1e-2 and ecc = 0.001
Packets Sent: 830
Frames Received: 0
ACK Received: 0
The same packet is sent 830 times.
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-2)]9600
P=1
Protocol Modelling and Simulation
43
Paul Lynam, FT281 3rd Year Project
Figure 18 - Results obtained for ber = 1e-3 and ecc = 0.001
Packets Sent: 988
Frames Received: 472
ACK Received: 472
On average, each packet is sent twice.
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-3)]9600
P=1
Protocol Modelling and Simulation
44
Paul Lynam, FT281 3rd Year Project
Figure 19 - Results obtained for ber = 1e-4 and ecc = 0
Packets Sent: 870
Frames Received: 325
ACK Received: 325
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-4)]9600 = 0.617
n=
1
1
=
= 2.61
1 P
1  0.617
On average, each packet is sent 2.6 times. This is confirmed is we divide 870 by 325
which gives an answer of 2.7
Protocol Modelling and Simulation
45
Paul Lynam, FT281 3rd Year Project
Figure 20 – Results obtained for ber = 1e-4 and ecc = 0.1
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1244
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 – [1 – (1  10-4)]9600
P = 0.617
n=
1
1
=
= 2.61
1 P
1  0.617
Again, this is another inaccurate result due to the limitations of the formula. Each
packet is sent only once and not 2.6 times.
Protocol Modelling and Simulation
46
Paul Lynam, FT281 3rd Year Project
Figure 21 - Results obtained for ber = 1e-4 and ecc = 0.01
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1244
Each packet is sent once.
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-4)]9600
P = 0.617
Protocol Modelling and Simulation
47
Paul Lynam, FT281 3rd Year Project
Figure 22 - Results obtained for ber = 1e-4 and ecc = 0.001
Packets Sent: 1245
Frames Received: 1245
ACK Received: 1244
Each packet is sent once.
Probability (Single Packet In Error):
P = 1-(1-ber)N
P = 1 - [1 - (1  10-4)]9600
P = 0.617
Protocol Modelling and Simulation
48
Paul Lynam, FT281 3rd Year Project
Appendix D
Sliding Window:
Event Response Table - Transmitter
State
INIT
IDLE
Event
Frame
Arrival
Condition/Exec
utive
Unconditional
Frame_Arrival_
Buffer_Ready
/Send_Frame
Action
If a frame arrives from the
source, while in the IDLE
state, and the windows size is
less than the buffer size:
Final State
IDLE
ACK Wait
- Remove packet from
subqueue
- Increment the window
- Set ‘ack not received’ flag
- Copy Packet
- Send Packet
- Increment sequence no.
- Set timer
State
Event
IDLE
Frame
Arrival
Condition/Executi
Action
ve
Frame_Arrival_
If a frame arrives from
Buffer_Not_Ready/ the source, while in the
Queue_Frame
IDLE state, and the
window size is greater
than or equal to the
buffer size,
Final State
ACK Wait
- Obtain a pointer to the
packet
- Insert the packet at
the tail of subqueue
Protocol Modelling and Simulation
49
Paul Lynam, FT281 3rd Year Project
State
IDLE
Event
Condition/Ex
Action
ecutive
Window<W Buffer_Ready If in the IDLE state, and
/Send_Frame the buffer is ready to
receive another packet
Final State
ACK Wait
- Remove packet from
subqueue
- Increment Window
- Set ‘ack not received’
Flag
- Copy Packet
- Send Packet
- Increment Sequence No
- Set Timer
State
Event
ACK Wait
Timeout
Condition/Execu
tive
Time_out/Send
_Copies_Frames
Action
If a timeout occurs while
in the ACK Wait state:
Final
State
ACK Wait
- Send all of the
unacknowledged packets
State
ACK Wait
Event
ACK
Received
Condition/Execu
tive
ACK_Received_
Q_empty/ACK_
Handle
Action
If an ACK is received
and the subqueue is
empty, while in the
ACK Wait state:
Final State
IDLE
- Destroy the ACK
- Cancel Timer
- Decrement Window
Size
Protocol Modelling and Simulation
50
Paul Lynam, FT281 3rd Year Project
State
ACK Wait
Event
ACK
Received
Condition/Execu
tive
ACK_Received_
Q_not_empty_buf
fer_not_ready/
ACK_Handle
Action
If an ACK is received
while the subqueue is
not empty and the
window size is greater
than or equal to the
buffer size:
Final State
IDLE
- Destroy the ACK
- Cancel Timer
State
ACK Wait
Event
Condition/Executive
Action
ACK
Received
ACK_Received_Q_
not_empty_buffer_
ready/
ACK_Handle_Send_
Frame
If an ACK is received
while the subqueue is
not empty and the
window size is less
than the buffer size:
Final
State
IDLE
- Destroy the ACK
- Cancel Timer
- Decrement window
size
- Remove the next
packet from subqueue
- Increment Window
- Set ‘ack not
received’ flag
- Copy packet
- Send packet
- Increment sequence
no.
- Set timer
Protocol Modelling and Simulation
51
Paul Lynam, FT281 3rd Year Project
State
Event
ACK Wait
Frame
Arrival
Condition/Exe
cutive
Frame_Arrival/
Q_Frame
Action
If a frame arrives from the
source, while in the ACK
Wait state,
Final
State
ACK Wait
- Obtain a pointer to the
new packet
- Insert the new packet at
the tail of the subqueue
Protocol Modelling and Simulation
52