Modeling and simulation of a point-to-point protocol

Modeling and simulation of a point -to-point protocol

DTU Fotonik Summer University 2013
Zhiheng Xu Yuxing Qiu
8/7/2013

Pablo Lanaspa

Modeling and simulation of a point-to-point protocol

Contents
PERFACE............................................................................................................................................................. 2 INTRODUCTION ................................................................................................................................................. 3 List of Abbreviations ...................................................................................................................................... 3 Terminology introduction.............................................................................................................................. 3 Packets introduction...................................................................................................................................... 4 MODEL DEVELOPMENT ..................................................................................................................................... 5 Part 1 ............................................................................................................................................................. 5 A. B. Process Model ................................................................................................................................... 5 Node Model ..................................................................................................................................... 13

Part 2 ........................................................................................................................................................... 13 A. B. Process Model ................................................................................................................................. 13 Node Model ..................................................................................................................................... 18

Part 3 ........................................................................................................................................................... 19 A. B. Process Model ................................................................................................................................. 20 Node Model ..................................................................................................................................... 25

Part 4 ........................................................................................................................................................... 27 A. B. C. D. Task 1 ............................................................................................................................................... 27 Task 2 ............................................................................................................................................... 29 Task 3 ............................................................................................................................................... 30 Task 4 ............................................................................................................................................... 31

References ........................................................................................................... Error! Bookmark not defined.

Modeling and simulation of a point-to-point protocol

PERFACE
This report was released at the end of the Summer University 2013 in Telecommunications at DTU, Denmark. Three students have worked in the Department of Photonics Engineering learning how to use OPNET and implementing this protocol in order to make this report. The authors would like to express their sincere appreciation to our advisor, Anna Manolova Fagertun, thanks for her understanding, patience and suggestions during this project; also to the other members on the teaching committee: Hao Yu, Ioan Turus and Jiayuan Wang, for their enthusiastic guidance and advice throughout this project. Finally, we are very thankful to Jesper Bevensee Jensen for giving us the nice opportunity to come here and enjoy doing what we really love-science and engineering.

Modeling and simulation of a point-to-point protocol

INTRODUCTION
The purpose of this project is to build a model of a reliable priority-aware symmetric point-to-point protocol and run simulations with this model to determine the performance of the protocol. To achieve this aim we have used a very powerful tool called OPNET in its 17.1 version. OPNET is software that provides performance analysis for computer networks and applications. Through this project and report we will show the steps we have followed in order to create the previously named protocol. There are many different forms in which this protocol can be made; we are only going to explain one of them, letting the reader think of some other ways to perform it by himself. Basically, the most important aim is to create some FSMs (Finite State Machines) in order to model the processes. We have divided this project into four different parts. In the first one we have created two process models: one for the traffic source module, another one for the traffic sink module and then we have verified the correct operation of them. In the second part we have created new packet formats and two process models: a P2P Transmitter and a P2P Receiver. In the following part we have combined the functionality of the P2P Transmitter and P2P Receiver for the purpose of making a new process model. Finally we have run some simulations using this protocol in order to test it and see which are the bounds, the advantages and the disadvantages of it. If the reader is going to work with OPNET for the first time, while following this report, we strongly recommend going through the tutorials that OPNET provides to their users to get in touch with some of the features of this software. At the beginning, working with this tool is a little bit tough but with perseverance and patience everybody can make this protocol by himself.

List of Abbreviations
FSMs: Finite State Machines P2P: Point- to-point protocol ACK: Acknowledgment

Terminology introduction
1. Packet: A network packet is a formatted unit of data carried by a packet-switched network, which makes the bandwidth of the communication medium better shared among users than if the network were only circuit switched. [1]

Modeling and simulation of a point-to-point protocol

2. Attribute: Attribute is a parameter that is user-controllable during the simulation, which uses instead of changing constants or numbers in the code and recompiling. 3. Statistics: Statistics are a vital part used to record the results of simulations. 4. Variable: Variables are some parameters that maintain some values during the execution of the program. For state variables, the values will maintain in the whole process model, while the values of temporary variables allocated only when the process is invoked.

Packets introduction
Three kinds of formatted packets are used in this project: User packet, P2P packet, ACK packet. Each of them contains some fields, which is described in the following table.
Table 1 Packet Introduction Table

Name User-packet

Fields priority

Size(in bits) 1

User-data

1024

P2P-packet

sequence_number

payload

Inherited

ack-packet

ack_number

Type in Further explanation of the Fields Modeler integer Imply the priority of the user packet, and the high-priority packets will be sent first during the progress. Integer Store the data specified by users, whose contents are actually irrelevant for the simulations. Integer Imply the validity of the user data, which is valid only when the sequence number is the as the receiver expected. packet A field used to store the information of a specified user packet, which contains the priority information as well as the user data. Integer An acknowledgment number which implies the correctness of the p2ppacket received by the receiver.

Modeling and simulation of a point-to-point protocol

MODEL DEVELOPMENT
Part 1
Traffic Source and Traffic Sink
In this part of project, the requests and methods of creating Traffic Source and Traffic Sink models will be introduced, as well as the results of modeling. Traffic Source is a node used to generate user packets, while Traffic sink is used to receive user packets and record some statistics at the same time. User packet is needed in the modeling of this part. A. Process Model 1. Context Definition

Figure 1 Context Definition of Traffic Source and Sink

According to the requests given, the operations are verified below: For traffic source 1) User packets are generated randomly and have to comply with: Intervals between two packets are exponentially distributed; Priority of user packet is selected randomly. 2) Attributes needed: The rate of packets (in packets/s); (default value: 0.5 packets/s) The fraction of high-priority packets. (default value: 0.5) 3) Statistics needed: Number of high priority packets generated; Number of low priority packets generated; Total number of packets generated.

For traffic sink 1) Statistics needed: Number of high priority packets received; Number of low priority packets received; Total number of packets received. End-to-end delay for high priority packets; End-to-end delay for low priority packets.

Modeling and simulation of a point-to-point protocol

2. Enumeration of Events The introduction of the events is listed below:

Table 2 Enumeration of Events of traffic source

Number 1

Event Name Begin_sim

Time_to_Generate

Description The event initiated by OPNET automatically when the BginSim of a node model is set to be enabled. It is a signal that tells the system to start initializing. The event which implies that it is the time to generate new user-packets.

Table 3 Enumeration of Events of traffic sink

Number 1

Event Name Begin_sim

Packet_arrival

Description The event initiated by OPNET automatically when the BginSim of a node model is set to be enabled. It is a signal that tells the system to start initializing. The event which implies that a user-packet arrive at this moment.

3. Event Response Table For Traffic Source The event response is showed below in the table:
Table 4 Event Response Table for Traffic source

Traffic Source
State
Init

Event
Begin_Sim(named PowerUp in the following image) Time_to_Generate (named NextPacket in the following image)

Condition
no

Action
1. Initialize; 2. Set the transmission timer for the first packet. 1. Create a formatted user-packet; 2. generate the priority of this user packet randomly; 3. Send the userpacket o a P2P modle; 4. Set the transmission timer for the next packet.

Next State
Idel

Idel

no

Idel

For Traffic Sink The event response is showed below in the table:

Modeling and simulation of a point-to-point protocol

Table 5 Event Response Table for Traffic sink

Traffic Source
State
Init

Event
Begin_Sim(named PowerUp in the following image) Packet_arrival (named NextPacket in the following image)

Condition
no

Action
Initialize. 1. Get the pointer of the packet received; 2. Get the priority of the received packet; 3. Record the number of the received packet; 4. compute the delay of different priority packets

Next State
Idel

Idel

no

Idel

4. Implementation For Traffic Source: 1) Figure of the state machine is showed below:

Figure 2 the Process Model of the Traffic Source

Modeling and simulation of a point-to-point protocol

2) Descriptions of the individual states are showed below:

Table 6 individual states defined in Traffic source process model

State Name

Unforced or Forced

Function

Code implement

Init

Forced

Init is a state used for initializing when the whole process begins.

Idel

Unforced

SendP acket

Forced

Idel is a state exists in the interval between two packets distributing. SendPacket is a forced Codes are written in the enter part of this state which state used to create and achieves the initialization of some default parameters. send user-packets after See the following items for details. the timer for 1. Generate and set the priority randomly for the transmission is expired, current user-packet. and the state will turn to 2. Send the packet to a P2P module. be Idel immediately 3. Set the transmission timer for the next user after the user-packet is packet. generated and sent out. 4. Write statistics to their statistic handles.

Codes are written in the enter part of this state which achieves the initialization of some default parameters. See the following items for details. 1. Give default values to some state variables. 2. Set the transmission timer for the first user packet. 3. Clear the packet counters of different priorities. 4. Register the local Statistic. Nothing is done here except waiting for the timer expired to generate and send another packet, so there is no code here.

3) Descriptions of the transitions between states are showed below: i. From state Init to state Idel The state will change from Init to Idel when PowerUp happen, which is the begin signal for the entire model. ii. From state Idel to state SendPacket The state will change from Idel to SendPacket when the timer for the next packet generation is expired, which is called NextPacket and can be found in the event list. iii. From state SendPacket to state Idel There is no condition for the changing from SendPacket to Idel because SendPacket is a forced state, and the state will change back to Idel as long as the functions in SendPacket is finished. For Traffic Sink 1) Figure of the state machine is showed below:

Modeling and simulation of a point-to-point protocol

Figure 3 the Process Model of the Traffic Sink

Modeling and simulation of a point-to-point protocol

2) Descriptions of the individual states are showed below:

Table 7 individual states defined in Traffic sink process model

State Name

Unforced or Forced

Function

Code implement

Init

Forced

Init is a state used for initializing when the whole process begins.

Idel

Unforced

Receiv ePack et

Forced

Idel is a state exists in the interval between two packets arrival. SendPacket is a forced state used to receive user-packets and record some statistics at the same time, and the state will turn to be Idel immediately after the user-packets arrival and some statistics recorded.

Codes are written in the enter part of this state which achieves the initialization of some default parameters. See the following items for details. 1. Give default values to some state variables. 2. Set the transmission timer for the first user packet. 3. Clear the packet counters of different priorities. 4. Register the local Statistic. Nothing is done here except waiting for the timer expired to generate and send another packet, so there is no code here. Codes are written in the enter part of this state which achieves the initialization of some default parameters. See the following items for details. 1. Get the pointer of the user-packet received. 2. Get the priority of the received packets. 3. Record the number of the received packets. 4. Compute the delay of different priority packets. 5. Write statistics to their statistic handles.

3) Descriptions of the transitions between states are showed below: i. From state Init to state Idel The state will change from Init to Idel when PowerUp happen, which is the begin signal for the entire model. ii. From state Idel to state ReceivePacket The state will change from Idel to ReceivePacket when there is a user-packet arriving, and this event is called NextPacket and can be found in the event list. iii. From state ReceivePacket to state Idel There is no condition for the changing from ReceivePacket to Idel because ReceivePacket is a forced state, and the state will change back to Idel as long as the functions in ReceivePacket is finished.

10

Modeling and simulation of a point-to-point protocol

5. Statistics list For Traffic Source o Number of high priority packets generated; o Number of low priority packets generated; o Total number of packets generated. For Traffic Sink o Number of high priority packets received; o Number of low priority packets received; o Total number of packets received. o End-to-end delay for high priority packets; o End-to-end delay for low priority packets.

6. Verifying Event-response table has been checked, making sure that for each state conditions for transition are completed and correct. Traffic source and sink are verified also by using the simulation tool. The result is showed below: In the following result, the total number of user-packet generated by the traffic source equals to the number of user-packet received by traffic sink, the same for the packets with different priorities.

Figure 4 total number of packets generated and received (For Source and Sink model)

Figure 5 number of packets with different priorities generated and received (For Source and Sink model)

11

Modeling and simulation of a point-to-point protocol

The total number of user-packet generated also equals to the sum of high priority packet generated and low priority packet generated, and the same for the received packets.

Figure 6 number of packets generated by source (For Source and Sink model)

Figure 7 number of packets received by sink (For Source and Sink model)

When the attribute of delay on the Packet Stream(in the node model, which will be explained in the next part of Traffic source and sink) is set as 0.1, the end-to-end delay for the packets of different priorities is showed below.

Figure 8 end-to-end delays for different priority packets

12

Modeling and simulation of a point-to-point protocol

B. Node Model 1. Figure of the node model

Figure 9 Node model of traffic source and sink

As it is showed above, the node model of the Traffic Source and Sink uses the process model of Traffic Source and the process model of Traffic Sink. 1. Statistics The statistics available in this node model is listed below: o o o o o o o o Number of high priority packets generated by the Traffic Source(called src in the above node model); Number of low priority packets generated by scr; Total number of packets generated by scr. Number of high priority packets received by the Traffic Sink(called sink in the above node model); Number of low priority packets received by sink; Total number of packets received by sink. End-to-end delay for high priority packets; End-to-end delay for low priority packets.

Part 2
P2P_Transmitter and P2P_Receiver
A. Process Model 1. Context definition

Source

Transmitter

Receiver

Sink

Figure 10 Context Definition of Transmitter and Receiver

2. Enumeration of events Transmitter events: PowerUp: It is used to Begin de Simulation with the following code: (op_intrpt_type () == OPC_INTRPT_BEGSIM) NextPacket: When a new packet arrives to the node this event is executed. The code: (op_intrpt_type () == OPC_INTRPT_STRM)

13

Modeling and simulation of a point-to-point protocol

TimerEvent: It is a self interruption. This event will be executed when the countdown set previously comes to 0. The code: (op_intrpt_type () == OPC_INTRPT_SELF)

Receiver vents: PowerUp: It is used to Begin de Simulation with the following code: (op_intrpt_type () == OPC_INTRPT_BEGSIM) NextPacket: When a new packet arrives to the node this event is executed. The code: (op_intrpt_type () == OPC_INTRPT_STRM) 3. Event response table For the Transmitter
Table 8 Event Response Table for Transmitteer

P2P Transmitter
State
Init

Event
Begin_Sim

Condition
no

Action
Initialize

Next state
Idel

acknowledgment packet arrive Idel user packet arrive

no

ignore it

Idel

no (because at this case, the queue must be empty) no the acknowledgment number is right & there is something in queue

1. packet the user packet into a p2p packet; 2.set the sequence number of the p2p packet; 3. send the user packet out to another receiver; 4. set a timer; retransmission 1. packet the user packet in the head of the queue into a p2p packet according to the priority of the packets; 2.set the sequence number of the p2p packet; 3. send the user packet out to another receiver; 4. set a timer; nothing

Wait

time-exp

Wait

Wait

wait

acknowledgment the acknowledgment packet arrive number is right & there is nothing in queue the acknowledgment number is wrong user packet arrive no

Idel

nothing(Come back to wait until time is expired) save it into the queue according to its priority

Wait Wait

14

Modeling and simulation of a point-to-point protocol

For the Receiver

Table 9 Event Response Table for Receiver

P2P Receiver
state
Init

event
Begin_Sim no

condition

action

next state
Idel

Idel

p2ppacket arrive

Initialize(indicate the sequence number needed at present) 1. Extract the payload from the p2p-packet; 2. send the payload of the p2p-packet to the traffic sink; 3. set the p2p-packet contains sequence number of the next expected p2p-packet; 4. the correct send the acknowledgment packet back to transmitter sequence number with the sequence number of the next expected p2ppacket p2p-packet contains send the acknowledgment packet back to transmitter the wrong sequence with the sequence number of the expected p2p-packet number at present

Idel

Idel

4. Implementation Transmitter State Machine: In this state machine there are two important unforced states that are the core of this process. The unforced ones were created in order to have a more visual diagram of the process and they include almost all the code necessary to execute this process. Idle is the first state of the process. We arrive at this step when the simulation have just started or when the queue is empty. Its mission is to send the first packet as soon as it is received and then we move to Wait state. Wait state is the main core of the process. Before arriving to this step, when a packet is sent the timer is set up. This state can receive two different interruptions: A new packet has come or the time has expired. If a new packet has come, we analyze the packet and depending of its size we can determine whether we an ACK or a new user packet has arrived. If an ACK packet has arrived we check if the sequence is correct, if it is we send the following packet, if it isnt we delete de ACK packet. If a user packet has arrived we queue it and wait until we receive the correct ACK packet. The other event which can interrupt this state is the Timer. If the Time has expired we resend the last packet sent and we set up the timer again. Always we have to send a packet we have to encapsulate it and add to it the correct sequence number that the receiver is expecting to receive, which is the same number that we received in the previous ACK packet sent by the receiver.

15

Modeling and simulation of a point-to-point protocol

The transmitter has two different subqueues, one for the high-priority packets and the other for the lowpriority ones. When a new packet is sent to the receiver we always look first in the high-priority packets subqueue and if it is empty we send the low-priority packets.

Figure 11 the Process Model of the Transmitter

Receiver State Machine: This process model has only one unforced state and three forced states that contain all the functionality of the process. Once the process has been initialized the process waits until a new P2P packet arrives. Then it reads the sequence number in the packet, if the sequence number is the correct one the original packet is extracted and it is sent to the sink. It the sequence number is not correct de P2P packet is destroyed and we move to NextSequence State. We have always to go through this state, in this state we send an ACK packet indicating the sequence number of the next expected P2P packet.

Figure 12 the Process Model of the Receiver

5. Statistics list We are going to select all the statistics that we have created for the simulation:

16

Modeling and simulation of a point-to-point protocol

Size of the 2 subqueues Number of retransmissions in total and per user-packet

6. Verifying Plotting some of the statistics we can see that the results make sense, so we can affirm that our transmitter and receiver are working correctly. In the first to plots we are analyzing the number of packets transmitted and received. Both plots are almost identic, the only difference is the time when they appear in the plot. It happens because of we configured the link with a little bit of delay (0.1 seconds). The second two plots are related to the high and low priority packets. We can see that we receive all of them but we receive first the high priority ones. That is the reason why there is a bigger delay in the lowpriority packets received. With all of this information we can affirm that this part is working in the correct way.

17

Modeling and simulation of a point-to-point protocol

Figure 13 total number of packets generated and received (For Transmitter and Receiver)

Figure 14 Details of Figure 13

Figure 15 number of different priority packets generated and received (For Transmitter and Receiver)

Figure 16 Details of Figure 15

B. Node Model 1. Figure of the node model Transmitter figure:

18

Modeling and simulation of a point-to-point protocol

Figure 17 Node model of p2p transmitter

Receiver figure:

Figure 18 Node model of p2p receiver

2. Implementation In the following table you can find for each module which process model we have used:
Table 10 Node implementation of the Transmitter and Receiver

Node Transmitter Transmitter Receiver Receiver

Module Src P2P_Transmitter Sink P2P_Receiver

Process Model PRJ1_TrafficSource P2P_transmitter PRJ1_TrafficSink P2P_Receiver

Part 3
Combination of P2P_Transmitter and P2P _Receiver

19

Modeling and simulation of a point-to-point protocol

A. Process Model 1. Context definition

Sink 1 Combine 1 Source 1 Combine 2

Sink 2

Source 2

Figure 19 Context Definition of the combining of the whole functions mentioned

2. Enumeration of events PowerUp: It is used to Begin de Simulation with the following code: (op_intrpt_type () == OPC_INTRPT_BEGSIM) NextPacket_SRC: This event is executed when a new UserPacket arrives from port number 0. The code: ((op_intrpt_type () == OPC_INTRPT_STRM) && (op_intrpt_strm() == 0)) NextPacket_P2P: This event is executed when a new P2PPacket arrives from port number 1. The code: ((op_intrpt_type () == OPC_INTRPT_STRM) && (op_intrpt_strm() == 1)) TimerEvent: It is a self interruption. This event will be executed when the countdown set previously comes to 0. The code: (op_intrpt_type () == OPC_INTRPT_SELF) 3. Event response table
Table 11 Event Response Table for p2p combined of the transmitter and the receiver

P2P Combined
state
Init

event
Begin_Sim no

condition

action
Initialize(indicate the sequence number needed at present) 1. extract the payload from the p2ppacket; 2. send the payload of the p2ppacket to the traffic sink; 3. set the sequence number of the next expected p2p-packet; 4. send the acknowledgment packet back to transmitter with the sequence number

next state
Idel

Idel

p2p-packet arrive (receiver function)

p2p-packet contains the correct sequence number

Idel

20

Modeling and simulation of a point-to-point protocol

of the next expected p2p-packet

send the acknowledgment packet back p2p-packet contains the to transmitter with the sequence wrong sequence number number of the expected p2p-packet at present acknowledgment packet arrive no (transmitter function) user packet arrive (transmitter function) time-exp (transmitter function) no(because at this case, the queue must be empty) no

Idel

ignore it

Idel

1. packet the user packet into a p2p packet; 2.set the sequence number of the p2p packet; 3. send the user packet out to another receiver; 4. set a timer; retransmission 1. packet the user packet in the head of the queue into a p2p packet according to the priority of the packets; 2.set the sequence number of the p2p packet; 3. send the user packet out to another receiver; 4. set a timer; nothing nothing(Come back to wait until time is expired) save it into the queue according to its priority 1. extract the payload from the p2ppacket; 2. send the payload of the p2ppacket to the traffic sink; 3. set the sequence number of the next expected p2p-packet; 4. send the acknowledgment packet back to transmitter with the sequence number of the next expected p2p-packet

Wait

Wait

acknowledgment packet arrive (transmitter the acknowledgment function) number is right & there is nothing in queue wait user packet arrive (transmitter function) the acknowledgment number is wrong no

the acknowledgment number is right & there is something in queue

Wait

Idel

Wait

Wait

p2p-packet arrive (receiver function)

p2p-packet contains the correct sequence number

Wait

21

Modeling and simulation of a point-to-point protocol

send the acknowledgment packet back p2p-packet contains the to transmitter with the sequence wrong sequence number number of the expected p2p-packet at present

Wait

4. Implementation This state machine is a combination of the transmitter and receiver ones. The functionality was explained in the last part, so here we are only going to explain the changes that have been made. The main difference from the last part is that now we really care about the ports that we are using. In part 2, we differenced the packets looking at the size of the packet. Now, we difference the packets in two different ports. The port that comes from the Source and the port that comes from other nodes. When a packet comes from the source we queue it. But when a packet comes from another node we look at its size in order to difference between ACK packets and P2Ppackets should go to the Sink. The state machine could be simplified in only two different unforced states, but we decided to use some forced states in order to make it more visual and easier to understand, separating the code in different places, going always step by step.

22

Modeling and simulation of a point-to-point protocol

Figure 20 Process model of the combined part

5. Statistics list We are going to select all the statistics that we have created for the simulation: Total number of packets generated: Total number of packets received Number of high-priority packets generated Number of high-priority packets received Number of low-priority packets generated Number of low priority packets received End to end delay for high priority packets End to end delay for low priority packets Size of the 2 subqueues Number of retransmissions in total and per user-packet Number of packets discarded after Rmax times trying to resend. (Optional)

23

Modeling and simulation of a point-to-point protocol

6. Verifying As in the last part we are going to create some plots with the porpoise of verifying that everything works correctly. Plotting some of the statistics we can see that the results make sense, so we can affirm that our transmitter and receiver are working correctly. In the first to plots we are analyzing the number of packets transmitted and received in different combined nodes. Both plots are almost identic, the only difference is the time when they appear in the plot. It happens because of we configured the link with a little bit of delay (0.1 seconds) and because now we dont distinguish between high-priority packets and low-priority packets. The second two plots are related to the high and low priority packets. We can see that we receive all of them but we receive first the high priority ones. That is the reason why there is a bigger delay in the lowpriority packets received. With all of this information we can affirm that this part is working in the correct way.

24

Modeling and simulation of a point-to-point protocol

Figure 21 total number of packets generated and received (For combined modle)

Figure 22 Details of Figure 21

Figure 23 number of different priority packets generated and received (For combined modle)

Figure 24 Details of Figure 23

B. Node Model 1. Figure of the node model

25

Modeling and simulation of a point-to-point protocol

Figure 25 Node model of conbined part

2. Implementation In the following table you can find for each module which process model we have used:
Table 12 Node implmentation of the combined part

Module Src Sink P2P_Combined 3.

Process model PRJ1_TrafficSource PRJ1_TrafficSink P2P_Combined

List of statistics available in the node model Total number of packets generated. Total number of packets received Number of high-priority packets generated Number of high-priority packets received Number of low-priority packets generated Number of low priority packets received End to end delay for high priority packets End to end delay for low priority packets Size of the 2 subqueues Number of retransmissions in total and per user-packet

26

Modeling and simulation of a point-to-point protocol

Number of packets discarded after Rmax times trying to resend. (Optional)

Part 4
Running simulation
A. Task 1 Purpose: Determine the average end-to-end delay for low-priority packets as a function of the packet rate and of the fraction of high-priority packets generated. Parameter setting: Fraction of high-priority packets: vary between 0.1 and 0.9 in steps of 0.2; Average packet rate: vary between 0.1 and 0.5 in steps of 0.1; (packets/s) Bit-error-rate = 0; Simulation time = 60 minutes; Seed value: 128

27

Modeling and simulation of a point-to-point protocol

Results:

Figure 26 Task 1 simulation result

Conclusions: 1) As the average packet rate goes higher and higher, the end-to-end delay for low-priority packets goes higher too. 2) With the packet rate staying constantly, the increase of the fraction of high-priority packets makes the end-to-end delay for low-priority packets grow. Analysis of the conclusions: 1) As the average packet rate goes higher, the number of the packets generated in one second goes higher, but the time for sending one packet in the transmission chain source-transmitter-receiversink stays the same, that is the extra packets generated have to wait in the queue for transmission, which increases the average packets waiting time in the queue of transmitter as well as receiver. So the delay becomes higher when the average packet rate goes higher. 2) With the packet rate staying constantly, if the fraction of high-priority packets increases, more packets with high priority need to be sent, that is the low-priority packets need to wait in the queue till all the transmissions of high-priority packets are finished, which means the delay of lowpriority packets becomes greater. So the delay becomes higher when the fraction of high-priority packets goes higher.

28

Modeling and simulation of a point-to-point protocol

B. Task 2 Purpose: Run simulation with 5 different values of the seed value for the random number generator and to see the end-to-end delay for low-priority with 95% confidence intervals as the average packet rate varies. Parameter setting: Fraction of high-priority packets: 0.5; Average packet rate: vary between 0.1 and 0.5 in steps of 0.1; (packets/s) Bit-error-rate = 0; Simulation time = 60 minutes; Seed values: vary between 128 and 1028 in steps of 200; Confidence interval: 95%. Results:

Figure 27 Task 2 simulation result

Conclusions: In total, the confidence intervals range little on each point, which implies that the model set up by OPNET is good. In general, the higher the average packet rate is, the bigger the confidence intervals are.

29

Modeling and simulation of a point-to-point protocol

Analysis of the conclusions: Because of the increase of the average packet rate, the uncertainty of the results rises, so the confidence intervals grow. C. Task 3 Purpose: Determine the average end-to-end delay for both high-priority and low-priority packets as a function of the bit error rate of the point-to-point. Parameter setting: Fraction of high-priority packets: 0.5; Average packet rate: 0.5 (packets/s) Bit-error-rate = vary between 1*10-5 and 9*10-5 in steps of 1*10-5; Simulation time = 60 minutes; Seed values: 239; Results:

Figure 28 Task 3 simulation result

Conclusions: 1) In total, the average end-to-end delay for both high-priority and low-priority packets increases as the bit error rate increases, even if there are some waves exist in the above polygonal lines. 2) The delay of high-priority packets is always lower than the value of low-priority packets.

30

Modeling and simulation of a point-to-point protocol

Analysis of the conclusions: 1) Because of the increase of the bit error rate of the P2P link, more packets transmitted with wrong sequence number, so more packets need retransmission, which finally makes the delay become longer. 2) With higher priority, the packets can be transmitted earlier, making the delay time shorter. D. Task 4 Purpose: Determine the average end-to-end delay for low-priority packets as a function of the bit error rate of the point-to-point and the fraction of high-priority packets. Parameter setting: Fraction of high-priority packets: vary between 0.1 and 0.9 in steps of 0.2; Average packet rate: 0.5 (packets/s) Bit-error-rate = vary between 1*10-5 and 9*10-5 in steps of 1*10-5; Simulation time =6, 60 and 600 minutes; Seed values: 128; Results:

Simulation time = 6 minutes

Figure 29 Task 4 simulation result for 6 minutes

31

Modeling and simulation of a point-to-point protocol

Simulation time = 60 minutes

Figure 30 Task 4 simulation result for 60 minutes

Simulation time = 600 minutes

Figure 31 Task 4 simulation result for 600 minutes

Conclusions: 1) In total, the average end-to-end delay for low-priority packets increases as the bit error rate increases, even if there are some waves exist in the above polygonal lines. 2) As the fraction of high-priority packets increases, the end-to-end delay for low-priority packets increases. 3) The longer the simulation time is, the more explicit the result is. Analysis of the conclusions: The analysis of the conclusions 1) and 2) above can be found in Task 3 and Task 1 respectively. For conclusion 3), we can consider it in the following way:

32

Modeling and simulation of a point-to-point protocol

The longer the simulation time is, the more the statistic values can be obtained, the more typical the average number of the results is. So when the simulation time become longer, the conclusion becomes more explicit.

33