11/12/24, 3:51 AM NetSim_Experiment_Manual

Experiments Manual

The information contained in this document represents the current view of TETCOS LLP on the issues discussed as of the date of publication. Because TETCOS LLP
must respond to changing market conditions, it should not be interpreted to be a commitment on the part of TETCOS LLP, and TETCOS LLP cannot guarantee the
accuracy of any information presented after the date of publication.

This manual is for informational purposes only. TETCOS LLP MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.

Warning! DO NOT COPY

Copyright in the whole and every part of this manual belongs to TETCOS LLPand may not be used, sold, transferred, copied or reproduced in whole or in part in any
manner or in any media to any person, without the prior written consent of TETCOS LLP. If you use this manual you do so at your own risk and on the understanding
that TETCOS LLPshall not be liable for any loss or damage of any kind.

TETCOS LLP may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as
expressly provided in any written license agreement from TETCOS LLP, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people,
places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place, or
event is intended or should be inferred.

Rev 13.0 (V), Feb 2021, TETCOS LLP. All rights reserved.
All trademarks are property of their respective owner.

Contact us at
TETCOS LLP

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 1/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

# 214, 39th A Cross, 7th Main, 5th Block Jayanagar,

Bangalore - 560 041, Karnataka, INDIA. Phone: +91 80 26630624
E-Mail: sales@tetcos.com
Visit: www.tetcos.com

LIST OF EXPERIMENTS

1 Introduction to NetSim

2 Understand Measures of Network Performance: Throughput and Delay

3 Throughput and Bottleneck Server Analysis

4 Delay and Little’s Law

5 Understand working of ARP, and IP Forwarding within a LAN and across a router

6 Simulate and study the spanning tree protocol

7 Introduction to TCP connection management

8 Reliable data transfer with TCP

9 Mathematical Modelling of TCP Throughput Performance

10 Study how throughput and error of a Wireless LAN network changes as the distance between the Access Point and the wireless nodes is varied

11 WiFi: UDP Download Throughput

12 How many downloads can a Wi-Fi access point simultaneously handle?

13 TCP Congestion Control Algorithms

14 Multi-AP Wi-Fi Networks: Channel Allocation

15 Plot the characteristic curve of throughput versus offered traffic for a Pure and Slotted ALOHA system

16 Study the working and routing table formation of Interior routing protocols, i.e. Routing Information Protocol (RIP) and Open Shortest Path First (OSPF)

17 M/D/1 and M/G/1 Queues

18 Wi-Fi Multimedia Extension (IEEE 802.11 EDCA)

19 Cyber physical systems (CPS) and IoT – An Introduction

20 One Hop IoT Network over IEEE 802.15.4

21 IoT – Multi-Hop Sensor-Sink Path

22 Performance Evaluation of a Star Topology IoT Network

23 Study how call blocking probability varies as the load on a GSM network is continuously increased

24 Study the 802.15.4 Superframe Structure and analyze the effect of Superframe order on throughput

25 Understand the working of OSPF

26 Understand the working of basic networking commands (Ping, Route Add/Delete/Print, ACL)

27 To analyze how the allocation of frequency spectrum to the Incumbent (Primary) and CR CPE (Secondary User) affects throughput

28 Simulate and study 5G Handover procedure

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 2/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
29 Understanding VLAN operation in L2 and L3 Switches

30 Understanding Access and Trunk Links in VLANs

31 Understanding Public IP Address & NAT (Network Address Translation)

32 Understand the events involved in NetSim DES (Discrete Event Simulator) in simulating the flow of one packet from a Wired node to a Wireless node

33 Understand the working of TCP BIC Congestion control algorithm, simulate and plot the TCP congestion window

34 Simulating Link Failure

1 Introduction to NetSim
1.1 Introduction to network simulation with NetSim, NetSim feature list and NetSim Simulation environment
NetSim is a network simulation tool that allows you to create network scenarios, model traffic, design protocols and analyze network performance. Users can study the

behavior of a network by test combinations of network parameters. The various network technologies covered in NetSim include:

§ Internetworks - Ethernet, WLAN, IP, TCP

§ Legacy Networks - Aloha, Slotted Aloha

§ Cellular Networks - GSM, CDMA

§ Mobile Adhoc Networks - DSR, AODV, OLSR, ZRP

§ Wireless Sensor Networks - 802.15.4

§ Internet of Things - 6LoWPAN gateway, 802.15.4 MAC / PHY, RPL

§ Cognitive Radio Networks - 802.22

§ Long-Term Evolution Networks – LTE

§ Software Defined Networking

§ Advanced Routing and Switching - VLAN, IGMP, PIM, L3 Switch, ACL and NAT

§ 5G NR mmWave – LTE NR

NetSim home screen will appear as shown below see Figure 1‑1.

Figure 1‑1: NetSim Home Screen

Network Design Window: NetSim design window or the GUI see Figure 1‑2, enables users to model a network comprising of network devices like switches, routers,
nodes, etc., connect them through links, and model application traffic to flow through the network. The network devices shown are specific to the network technologies

chosen by the user.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 3/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 1‑2: Network Design Window

Description:

1. File - In order to save the network scenario before or after running the simulation into the current workspace,

§ Click on File à Save to save the simulation inside the current workspace. Users can specify their own Experiment Name and Description (Optional).

§ Click on File à Save As to save an already saved simulation in a different name after performing required modifications to it.

§ Click on Close, to close the design window or GUI. It will take you to the home screen of NetSim.

2. Settings - Go to Settings à Grid/Map Settings and choose the type of environment. Here we have chosen the Grid/Map in the form of a Grid. Map option can be
used for specific cases like while designing VANET scenarios.

3. Help - Help option allows the users to access all the help features.

§ About NetSim – Assists the users with basic information like,

Which version of NetSim is used and whether it is a 32-bit build or 64-bit build?

What kind of License is being used? Whether Floating or Node Locked?

§ Video Tutorials – Assists the users by directing them to our dedicated YouTube Channel “TETCOS”, where we have lots of video presentations ranging from
short to long, covering different versions of NetSim up to the latest release.

§ Answers/FAQ – Assists the user by directing them to our “NetSim Support Portal”, where one can find a well-structured “Knowledge Base”, consisting of
answers or solutions to all the commonest queries which a new user can go through.

§ Raise a Support Ticket – Assists the user by directing them to our “NetSim Support Portal”, where one can “Submit a ticket” or in other words raise his/her

query, which reaches our dedicated Helpdesk and due support will be provided to the user.

§ User Manual – Assists the user with the usability of the entire tool and its features. It highly facilitates a new user with lots of key information about NetSim.

§ Source Code Help – Assists the user with a structured documentation for “NetSim Source Code Help”, which helps the users who are doing their R&D using

NetSim with a structured code documentation consisting of more than 5000 pages with very much ease of navigation from one part of the document to
another.

§ Open Source Code – Assists the user to open the entire source codes of NetSim protocol libraries in Visual Studio, where one can start initiating the

debugging process or performing modifications to existing code or adding new lines of code. Visual Studio Community Edition is a highly recommended IDE
to our users who are using the R&D Version of NetSim.

§ Experiments – Assists the user with separate links provided for 30+ different experiments covering almost all the network technologies present in NetSim.

§ Technology Libraries – Assists the user by directing them to a folder comprising of individual technology library files comprising all the components present in
NetSim.

Below the menu options, the entire region constitutes the Ribbon/Toolbar using which the following actions can be performed:

§ Click and drop network devices and right click to edit properties

§ Click on Wired/Wireless links to connect the devices to one another. It automatically detects whether to use a Wired/Wireless link based on the devices we are
trying to connect

§ Click on Application to configure different types of applications and generate traffic

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 4/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ Click on Plots, Packet Trace, and Event Trace and click on the enable check box option which appears in their respective windows to generate additional
metrics to further analyze the network performance.

§ Click on Run to perform the simulation and specify the simulation time in seconds.

§ Next to Run, we have View Animation and View Results options. Both the options remain hidden before we run the simulation or if the respective windows are
already open.

§ Display Settings option is mainly used to display various parameters like Device Name, IP, etc., to provide a better understanding especially during the design
and animation.

Results Window: Upon completion of simulation, Network statistics or network performance metrics reported in the form of graphs and tables. The report includes

metrics like throughput, simulation time, packets generated, packets dropped, collision counts etc. see Figure 1‑3 and Figure 1‑4.

Figure 1‑3: Results Window

Figure 1‑4: Application Throughput Plot

Description:

1. Below Simulation Results, clicking on a particular metrics will display the respective metrics window.

2. Clicking on links in a particular metrics will display the plot in a separate window

3. Enabling Detailed View by clicking on it will display the remaining properties

4. Clicking on Restore to Original View will get back to the original view

5. Click on Open Packet Trace / Open Event Trace to open the additional metrics which provide in depth analysis on each Packets / Events.

Packet Animation Window: When we click on run simulation, we have the option to record / play & record animation. If this is enabled, users can view the animation

during the run time or upon completion of the simulation see Figure 1‑5, users can see the flow of packets through the network. Along with this, more than 25+ fields of
packet information is available as a table at the bottom. This table contains all the fields recorded in the packet trace. In addition, animation options are available for
viewing different graphs, IP Addresses, Node movement etc.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 5/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 1‑5: Packet Animation Window

Description
1. Click on Play to view the animation. You can Pause the animation at any interval and Play again.

2. Click on Stop to stop the animation. Now click on Play to start the animation from the beginning.

3. Next to that we also have speed controllers to increase/decrease Simulation Time and Animation Speed

4. View More option enables the user to view Plots, Throughputs, and IP Tables during the animation

5. Table Filters are used to filter the packet information’s shown in the below table during simulation as per user requirement

6. While setting more than one application, it is differentiated using different color indications

7. Packets are indicated using different color combinations say, blue color indicates control packets, green color indicates data packets and red color indicates error
packets.

1.2 How does a user create and save an experiment in workspace?

To create an experiment, select New Simulation-> <Any Network> in the NetSim Home Screen Figure 1‑6.

Figure 1‑6: NetSim Home Screen

Create a network and save the experiment by clicking on File->Save button on the top left.

A save popup window appears which contains Experiment Name, Folder Name, Workspace path and Description see Figure 1‑7.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 6/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 1‑7: NetSim Save Window

Specify the Experiment Name and Description (Optional) and then click on Save. The workspace path is non-editable. Hence all the experiments will be saved in the
default workspace

path. After specifying the Experiment Name click on Save.

In our example we saved with the name MANET and this experiment can be found in the default workspace path see below Figure 1‑8.

Figure 1‑8: NetSim Default Workspace Path

Users can also see the saved experiments in Your work menu shown below Figure 1‑9.

Figure 1‑9: Your Work Menu

“Save As” option is also available to save the current experiment with a different name.

1.3 Typical sequence of steps to do experiments in this manual

The typical steps involved in doing experiments in NetSim are

§ Network Set up: Drag and drop devices, and connect them using wired or wireless links

§ Configure Properties: Configure device, protocol or link properties by right clicking on the device or link and modifying parameters in the properties window.

§ Model Traffic: Click on the Application icon present on the ribbon and set traffic flows.

§ Enable Trace/Plots (optional): Click on packet trace, event trace and Plots to enable. Packet trace logs packet flow, event trace logs each event (NetSim is a discrete

event simulator) and the Plots button enables charting of various throughputs over time.

§ Save/Save As/Open/Edit: Click on File à Save / File à Save As to save the experiments in the current workspace. Saved experiments can then opened from NetSim
home screen to run the simulation or to modify the parameters and again run the simulation.

§ View Animation/View Results: Visualize through the animator to understand working and to analyze results and draw inferences.

NOTE: Example Configuration files for all experiments would available where NetSim has been installed. This directory is
(<NetSim_Install_Directory>\Docs\Sample_Configuration\NetSim_Experiment_Manual)

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 7/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

2 Understand Measures of Network Performance: Throughput and Delay

2.1 Introduction
The two main performance measures of a network are:

§ Throughput: how many bits per second are going through the network

§ Delay: how long does it take a bit from one end to the other

These are two orthogonal concepts, and one could think of it as width of a pipe and length of a pipe through with data flows.

2.1.1 Throughput

In general terms, throughput is the rate of production or the rate at which something is processed. When used in the context of communication networks, such as
Ethernet or packet

radio, throughput or network throughput is the rate of successful message delivery over a communication channel.

Throughput is related to other quantities like bandwidth or data-rate of a link. A link can have a certain "nominal" bandwidth or data-rate to send data at, however, all of it
may not be

used all the time to send useful bits. You may also have packet losses and retransmissions. Throughput measures the number of useful bits delivered at the receiver and
is different

from but related to the individual link data rates.

The throughput of a network is limited by the link with the slowest throughput along the path, the bottleneck link. You cannot pump data faster than the rate of the slowest
link. Note

that the bottleneck link need not always be the link with the slowest nominal data-rate. Sometimes a high-speed link may be shared by several flows, causing each flow

to receive a

small share, thus becoming the bottleneck. In other cases, you may not always be able to send at the bottleneck rate, because your protocol may have other delays, like
waiting for

ACKs. So, while instantaneous throughput can be the bottleneck link rate, average throughput may be lower. The way to compute average throughput is always: see the
data sent

over a period of time and get the ratio. A file of size takes units of time to be transferred. Average throughput is .

2.1.2 Delay

The end-to-end delay in a path is sum of delays on all links and intermediate nodes. There are components to delay.

When a packet leaves a node, it first experiences transmission delay. That is, all the bits of a packet that have to be put out on the link. If a link can transmit data at R

bits/s, a packet of size B bits will require seconds to be just put out there.

Next is propagation delay. That is, the bits have to propagate at the speed of waves in the transmission medium to reach the other end. This delay depends on the length

of the wire and is usually only significant for long distance links. If is the distance the wave has to travel is is the speed in the medium, the propagation delay is .

The speed of light is m/s in free space and hence a radio wave takes 1 microsec to traverse a distance of 300 metres. The speed of light in copper is around

, and it would take about 10 to travel a 2-meter-long wire.

If propagation delay is less than the transmission delay, then the first bit of the packet would have reached the other end point before the sender finishes putting all bits

on the wire. Hence the limiting factor is really how fast the link is. On the other hand, if propagation delay is greater than transmission delay, as is the case for long
distance links, then the first bit reaches the other end point much after the last bit has been sent.

Next, once the packet arrives at the other end point, it must be processed by the switch or router. This processing delay could involve looking up routing tables,

computations of header checksums etc. Again, this is usually not a significant component with today's high-speed hardware.

Once an intermediate point processes the packet and decides which link to send it on, the packet may potentially be queued until the next link becomes free. This delay
is called the queueing delay. This is the most unpredictable part of the delay, as it depends on traffic sent by other nodes. A large branch of study called Queueing theory
is devoted to modelling and understanding this delay under various conditions. Internet traffic is often bursty, and hence queueing delays occur even if the aggregate

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 8/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
traffic is less than the capacity of the links on an average. That is, suppose incoming packets arrive at an aggregate rate of L bits/s and link rate is R bits/s, then as long

as , it appears that there should be no queueing. However, packets don’t arrive in an equally spaced fashion, and the arrival pattern is often random. In such cases,

the queueing delay maybe high even if In fact, queueing delay increases quite steeply as approaches 1. It is approximately equal to . Usually, network
designers try to keep this ratio well below 1.

Once the packet gets out of the queue and gets ready for transmission, the cycle begins again with the transmission delay on the next link. So we add one of each of the

4 delays for every link traversed. Some switches can also start transmission even before reception fully completes. But most often, switches today are store-and-forward.
That is, they wait for entire packet to arrive, then start forwarding. Once a queue is full, it may also drop packets, leading to losses. Losses can also occur due to
transmission errors on the wire. This is more common in wireless links; wired links are pretty reliable.

2.2 NetSim Simulation Setup

Open NetSim and click Examples > Experiments > Understanding-Measure-of-Network-Performance-Throughput-and-Delay

Figure 2‑1: Experiments List

2.3 Part-1: Throughput Analysis

2.3.1 Without packet acknowledgement (UDP)

Sample 1: Consider a 125 KB file that needs to be sent through a network path. To explore the case where there are no packet acknowledgements we use the UDP
transport protocol The bottleneck bandwidth of the path is 1 Mbps. The one-way delay between sender and receiver is 20 µs. Suppose the sender continuously sends
data at the bottleneck rate, and no packets are lost and there are no retransmissions.

It will take 1 second to send the file and average throughput is 1 Mbps, which is the bottleneck bandwidth.

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 2‑2.

Figure 2‑2: A WAN network architecture

The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Router, and 2 Wired Node in the “Internetworks” Network Library.

Step 2: Right click on Wired link and select Properties, BER is set to 0, and Propagation Delay is set to 20µs. For link id 2 Link Speed is set to 1 Mbps.

Step 3: Right click on the Application Flow App1 FTP and select Properties or click on the Application icon present in the top ribbon/toolbar.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 9/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
A FTP Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with File Size remaining 125000Bytes and Inter Arrival Time remaining
1s.

Transport Protocol is set to UDP instead of TCP.

Step 4: Enable the plots and click on Run simulation. The simulation time is set to 100 seconds

2.3.2 With Packet Acknowledgement (TCP)

Sample 2: Suppose the sender needs to wait for an ACK after sending every TCP traffic of 1 KB packet. Assume ACK also takes 20 ms to come back. Now, the sender

can send 1 KB in . Thus, the average throughput ( is

Notice that the average throughput is one-fifth of what it was before, with the new ACK requirement. And the time taken to send the file will be 5 times larger, i.e 5
seconds. You can also compute 5 seconds as follows: 1 KB takes 40 ms, so 125 KB takes

The following set of procedures were done to generate this sample:

Step 1: Right click on Wired link and select Properties, BER is set to 0, and Propagation Delay is set to 40µs. For link id 2 Link Speed is set to 1 Mbps.

Step 2: Right click on the Application Flow App1 FTP and select Properties or click on the Application icon present in the top ribbon/toolbar.

A FTP Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with File Size remaining 125000Bytes and Inter Arrival Time remaining
5s.

Transport Protocol is set to TCP.

Step 3: Enable the plots and click on Run simulation. The simulation time is set to 100 seconds.

2.3.3 Output

Sample 1:

Figure 2‑3: Application Throughput for Sample 1

Sample 2:

Figure 2‑4: Application Throughput for Sample 2

2.4 Part - 2: Delay Analysis

2.4.1 Procedure

Sample 1: Consider the above A--S--B problem. Suppose A wants to send a 1MB file to B. A will divide the 1MB file into 1480-byte (standard UDP packet size) packets.

To these packets a 54-byte header is added. This makes the total packet size as 1534B or . A packet of size 12,272 bits would take 12,272 µs of
time to be transmitted over a 1Mbps (mega bit per second) link. Next, let us compute end-to-end delays. For now, let's ignore propagation and processing delays, as

they are small.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 10/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

A sends first 1534-byte packet in 12.27 and 1054-bytes packet in 8.43 . While S forwards this packet to B, A can send the next packet to S (switches can send
packets on one port while receiving them on another port.).

Thus, A takes 8.29 second to send all the packets to S. And a similar amount of time is taken by S to send the file to B. Therefore the total time to send the file from A to
B would be

This is now simulated in NetSim. The GUI open the configuration file corresponding to this experiment as shown below Figure 2‑5

Figure 2‑5: A LAN network

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 L2 Switch, and 2 Wired Node in the “Internetworks” Network Library.

Step 2: Right click on Wired link and select Properties, Link Speed is set to 1 Mbps, BER is set to 0, and Propagation Delay is set to 0µs.

Step 3: Right click on the Application Flow App1 FTP and select Properties or click on the Application icon present in the top ribbon/toolbar.

A FTP Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with File Size remaining 1000000Bytes and Inter Arrival Time remaining
100s.

Transport Protocol is set to UDP instead of TCP.

Step 4: Enable the packet trace and plots. Click on Run simulation. The simulation time is set to 100 seconds.

2.4.2 Output

Sample 1: In packet trace we can see only one file is generated from source to Destination, the file is divided into packets. Filter the packet type as FTP to calculate

End to end delay = PHY_LAYER_END_TIME - PHY_LAYER_ARRIVAL_TIME

Sending 1 MB file on 1 Mbps link should take 8.29s and the same is seen in the packet trace. Then it takes another 8.29s to go from the switch to then node, or 16.58s

total see Figure 2‑6.

Figure 2‑6: End to End Delay from Packet Trace

3 Throughput and Bottleneck Server Analysis

3.1 Introduction
An important measure of quality of a network is the maximum throughput available to an application process (we will also call it a flow) in the network. Throughput is

commonly defined as the rate of transfer of application payload through the network, and is often computed as

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 11/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
3.1.1 A Single Flow Scenario

Figure 3‑1: A flow passing through a link of fixed capacity .

Application throughput depends on a lot of factors including the nature of the application, transport protocol, queueing and scheduling policies at the intermediate

routers, MAC protocol and PHY parameters of the links along the route, as well as the dynamic link and traffic profile in the network. A key and a fundamental aspect of

the network that limits or determines application throughput is the capacity of the constituent links (capacity may be defined at MAC/PHY layer). Consider a flow

passing through a link with fixed capacity bps. Trivially, the amount of application bytes transferred via the link over a duration of T seconds is upper bounded by

bits. Hence,

The upper bound is nearly achievable if the flow can generate sufficient input traffic to the link. Here, we would like to note that the actual throughput may be slightly less

than the link capacity due to overheads in the communication protocols.

Figure 3‑2: A single flow passing through a series of links. The link with the least capacity will be identified as the bottleneck link for the flow

If a flow passes through multiple links (in series), then, the application throughput will be limited by the link with the least capacity among them, i.e.,

The link may be identified as the bottleneck link for the flow . Typically, a server or a link that determines the performance of a flow is called as the

bottleneck server or bottleneck link for the flow. In the case where a single flow passes through multiple links in series, the link will limit the maximum

throughput achievable and is the bottleneck link for the flow . A noticeable characteristic of the bottleneck link is queue (of packets of the flow) build-up at the bottleneck
server. The queue tends to increase with the input flow rate and is known to grow unbounded as the input flow rate matches or exceeds the bottleneck link capacity.

Figure 3‑3: Approximation of a network using bottleneck server technique

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 12/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
It is a common and a useful technique to reduce a network into a bottleneck link (from the perspective of a flow(s)) to study throughput and queue buildup. For example,

a network with two links (in series) can be approximated by a single link of capacity as illustrated in Figure 3. Such analysis is commonly known as

bottleneck server analysis. Single server queueing models such as M/M/1, M/G/1, etc can provide tremendous insights on the flow and network performance with the
bottleneck server analysis.
3.1.2 Multiple Flow Scenario

Figure 3‑4: Two flows and passing through a link of capacity

Consider a scenario where multiple flows compete for the network resources. Suppose that the flows interact at some link buffer/server, say , and compete for capacity.

In such scenarios, the link capacity is shared among the competing flows and it is quite possible that the link can become the bottleneck link for the flows (limiting

throughput). Here again, the queue tends to increase with the combined input flow rate and will grow unbounded as the combined input flow rate matches or exceeds the
bottleneck link capacity. A plausible bound of throughput in this case is (under nicer assumptions on the competing flows)

3.2 NetSim Simulation Setup

Open NetSim and click Examples > Experiments > Throughput-and-Bottleneck-Server-Analysis

Figure 3‑5: Experiments List

3.3 Part-1: A Single Flow Scenarios

We will study a simple network setup with a single flow illustrated in Figure 3‑6to review the definition of a bottleneck link and the maximum application throughput
achievable in the network. An application process at Wired Node 1 seeks to transfer data to an application process at Wired_Node_ 2. We consider a custom traffic

generation process (at the application) that generates data packets of constant length (say, L bits) with i,i,d. inter-arrival times (say, with average inter-arrival time

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 13/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

seconds). The application traffic generation rate in this setup is bits per second. We prefer to minimize the communication overheads and hence, will use UDP for data
transfer between the application processes.

In this setup, we will vary the traffic generation rate by varying the average inter-arrival time and review the average queue at the different links, packet loss rate and
the application throughput.

3.3.1 Procedure

We will simulate the network setup illustrated in Figure 3‑6with the configuration parameters listed in detail in Table 3‑1to study the single flow scenario.
NetSim UI displays the configuration file corresponding to this experiment as shown below:

Figure 3‑6: A client and a server network architecture with a single flow
The following set of procedures were done to generate this sample

Step 1: Drop two wired nodes and two routers onto the simulation environment. The wired nodes and the routers are connected with wired links as shown in (See Figure
3‑6).

Step 2: Click the Application icon to configure a custom application between the two wired nodes. In the Application configuration dialog box (see Figure 3‑7), select
Application Type as CUSTOM, Source ID as 1 (to indicate Wired_Node_1), Destination ID as 2 (to indicate Wired_Node_2) and Transport Protocol as UDP. In the
PACKET SIZE tab, select Distribution as CONSTANT and Value as 1460 bytes. In the INTER ARRIVAL TIME tab, select Distribution as EXPONENTIAL and Mean as

11680 microseconds.

Figure 3‑7: Application configuration dialog box

Step 3: The properties of the wired nodes are left to the default values.

Step 4: Right-click the link ID (of a wired link) and select Properties to access the link’s properties dialog box (see Figure 3‑8). Set Max Uplink Speed andMax

Downlink Speed to 10 Mbps for link 2 (the backbone link connecting the routers) and 1000 Mbps for links 1 and 3 (the access link connecting the Wired_Nodes and the
routers). Set Uplink BER and Downlink BER as 0 for links 1, 2 and 3. Set Uplink_Propagation Delay and Downlink_Propagation_Delay as 0 microseconds for the
two-access links 1 and 3 and 100 microseconds for the backbone link 2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 14/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 3‑8: Link Properties dialog box

Step 5: Right-click Router 3 icon and select Properties to access the link’s properties dialog box (see Figure 3‑9). In the INTERFACE 2 (WAN) tab, select the
NETWORK LAYER properties, set Buffer size (MB) to 8.

Figure 3‑9: Router Properties dialog box

Step 6: Click on Packet Trace option and select the Enable Packet Trace check box. Packet Trace can be used for packet level analysis and Enable Plots in GUI.
Step 7: Click on Run icon to access the Run Simulation dialog box (see Figure 3‑10) and set the Simulation Time to 100 seconds in the Simulation Configuration tab.

Now, run the simulation.

Figure 3‑10: Run Simulation dialog box

Step 8: Now, repeat the simulation with different average inter-arrival times (such as 5840 µs, 3893 µs, 2920 µs, 2336 µs and so on). We vary the input flow rate by
varying the average inter-arrival time. This should permit us to identify the bottleneck link and the maximum achievable throughput.

The detailed list of network configuration parameters are presented in (See Table 3‑1).

Parameter Value
LINK PARAMETERS

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 15/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Wired Link Speed (access link) 1000 Mbps
Wired Link Speed (backbone link) 10 Mbps
Wired Link BER 0
Wired Link Propagation Delay (access link) 0
Wired Link Propagation Delay (backbone link) 100 µs
APPLICATION PARAMETERS
Application Custom
Source ID 1
Destination ID 2
Transport Protocol UDP
Packet Size – Value 1460 bytes
Packet Size – Distribution Constant
Inter Arrival Time – Mean AIAT (µs) Table 3‑2
Inter Arrival Time – Distribution Exponential
ROUTER PARAMETERS
Buffer Size 8
MISCELLANEOUS
Simulation Time 100 Sec
Packet Trace Enabled
Plots Enabled
Table 3‑1: Detailed Network Parameters

3.3.2 Performance Measure

In Table 3‑2, we report the flow average inter-arrival time v and the corresponding application traffic generation rate, input flow rate (at the physical layer), average queue
at the three buffers (of Wired_Node_1, Router_3 and Router_4), average throughput (over the simulation time) and packet loss rate (computed at the destination).

Given the average inter-arrival time v and the application payload size L bits (here, 1460×8 = 11680 bits), we have,

where the packet overheads of 54 bytes is computed as . Let as denote the instantaneous

queue at link at time . Then, the average queue at link is computed as

where, is the simulation time. The average throughput of the flow is computed as

The packet loss rate is defined as the fraction of application data lost (here, due to buffer overflow at the bottleneck server).

3.3.2.1 Average Queue Computation from Packet Trace

§ Open Packet Trace file using the Open Packet Trace option available in the Simulation Results window.

§ Click on below highlighted icon to create new Pivot Table.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 16/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 3‑11: Packet Trace

§ Click on Insert on Top ribbon Select Pivot Table.

Figure 3‑12: Top Ribbon

§ Then select packet trace and press Ctrl + A Select ok

Figure 3‑13: Packet Trace Pivot Table

§ Then we will get blank Pivot table.

Figure 3‑14: Blank Pivot Table

§ Packet ID drag and Drop into Values field for 2 times, CONTROL PACKET TYPE/APP NAME, TRANSMITTER ID, RECEIVER ID into Filter field,
NW_LAYER_ARRIVAL_TIME(US) to Rows field see Figure 3‑15.

§ Change Sum of PACKET ID -> Values Field Settings ->Select Count -> ok for bothValues field, CONTROL PACKET TYPE to APP1 CUSTOM, TRANSMITTER
ID toRouter_3 and RECEIVER ID to Router 4

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 17/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 3‑15: Adding fields into Filter, Columns, Rows and Values

§ Right click on first value of Row Labels ->Group ->Select By value as 1000000.

§ Go to Values field under left click on Count of PACKET ID2 ->Values Field Settings-> click on show values as -> Running total in-> click on OK

§ Again, create one more Pivot Table, Click on Insert on Top ribbon Select Pivot Table.

§ Then select packet trace and press Ctrl + A Select ok

§ Then we will get blank Pivot table see Figure 3‑16.

§ Packet ID drag and Drop into Values field for 2 times, CONTROL PACKET TYPE/APP NAME, TRANSMITTER ID, RECEIVER ID into Filter field,

PHY_LAYER_ARRIVAL_TIME(US) to Rows field see Figure 3‑16,

§ Change Sum of PACKET ID -> Values Field Settings ->Select Count -> ok for bothValues field, CONTROL PACKET TYPE to APP1 CUSTOM, TRANSMITTER
ID toRouter_3 and RECEIVER ID to Router 4

§ Right click on first value of Row Labels for second Pivot Table->Group ->Select By value as 1000000.

Figure 3‑16: Create one more Pivot Table and Add All Fields

§ Go to Values field under left click on Count of PACKET ID ->Values Field Settings-> click on show values as -> Running total in-> click on OK

§ Calculate the average queue by taking the mean of the number of packets in queue at every time interval during the simulation.

§ The difference between the count of PACKET ID2 (Column C) and count of PACKET ID2 (Column G), Note down the average value for difference see Figure
3‑17

Figure 3‑17: Average Packets in Queue

3.3.3 Results

In Table 3‑2, we report the flow average inter-arrival time (AIAT) and the corresponding application traffic generation rate (TGR), input flow rate, average queue at the
three buffers (of Wired_Node_1, Router_3 and Router_4), average throughput and packet loss rate.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 18/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Average queue (in pkts)
TGR Input
AIAT Packet
Flow Average
Wired Router Loss
Rate Router4 Throughput
Node 1 3 Rate (in
(in (in (Link (in Mbps)
(in µs) (Link (Link percent)
Mbps) Mbps) 3)
1) 2)
11680 1 1.037 0 0 0 0.999925 0
5840 2 2.074 0 0.02 0 1.998214 0
3893 3.0003 3.1112 0 0.04 0 2.999307 0
2920 4 4.1479 0 0.11 0 3.996429 0
2336 5 5.1849 0 0.26 0 5.009435 0
1947 5.999 6.2209 0 0.43 0 6.000016 0.01
1669 6.9982 7.257 0 0.9 0 7.004262 0
1460 8 8.2959 0 1.92 0 8.028131 0
1298 8.9985 9.3313 0 5.26 0 9.009718 0.01
1284 9.0966 9.433 0 6.92 0 9.107013 0.01
1270 9.1969 9.537 0 7.98 0 9.209563 0.01
1256 9.2994 9.6433 0 7.88 0 9.314683 0
1243 9.3966 9.7442 0 11.48 0 9.416182 0.01
1229 9.5037 9.8552 0 16.26 0 9.520718 0.02
1217 9.5974 9.9523 0 25.64 0 9.616027 0.01
1204 9.701 10.0598 0 42.88 0 9.717994 0.05
1192 9.7987 10.1611 0 90.86 0 9.796133 0.26
1180 9.8983 10.2644 0 436.41 0 9.807696 1.15
1168 10 10.3699 0 847.65 0 9.808981 2.09
1062 10.9981 11.4049 0 3876.87 0 9.811667 11.00
973 12.0041 12.4481 0 4593.67 0 9.811667 18.53
898 13.0067 13.4878 0 4859.68 0 9.811667 24.75
834 14.0048 14.5228 0 5000.57 0 9.811667 30.09
779 14.9936 15.5481 0 5085.05 0 9.811667 34.75
Table 3‑2: Average queue, throughput and loss rate as a function of traffic generation rate

We can infer the following from Table 3‑2.

§ The input flow rate is slightly larger than the application traffic generation rate. This is due to the overheads in communication.

§ There is queue buildup at Router 3 (Link 2) as the input flow rate increases. So, Link 2 is the bottleneck link for the flow.

§ As the input flow rate increases, the average queue increases at the (bottleneck) server at Router 3. The traffic generation rate matches the application throughput

(with nearly zero packet loss rate) when the input flow rate is less than the capacity of the link

§ As the input flow rate reaches or exceeds the link capacity, the average queue at the (bottleneck) server at Router 3 increases unbounded (limited by the buffer
size) and the packet loss rate increases as well.

For the sake of the readers, we have made the following plots for clarity. In Figure 3‑18, we plot application throughput as a function of the traffic generation rate. We
note that the application throughput saturates as the traffic generate rate (in fact, the input flow rate) gets closer to the link capacity. The maximum application
throughput achievable in the setup is 9.81 Mbps (for a bottleneck link with capacity 10 Mbps).

Figure 3‑18: Application throughput as a function of the traffic generation rate

Figure 3‑19, we plot the queue evolution at the buffers of Links 1 and 2 for two different input flow rates. We note that the buffer occupancy is a stochastic process and is

a function of the input flow rate and the link capacity as well.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 19/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

a) At Wired Node 1 for TGR = 8 Mbps b) At Router 3 for TGR = 8 Mbps

c) At Wired Node 1 for TGR = 9.5037 Mbps d) At Router 3 for TGR = 9.5037 Mbps

Figure 3‑19: Queue evolution at Wired Node 1 (Link 1) and Router 3 (Link 2) for two different traffic generation rates

In Figure 3‑20, we plot the average queue at the bottleneck link 2 (at Router 3) as a function of the traffic generation rate. We note that the average queue increases

gradually before it increases unboundedly near the link capacity.

Figure 3‑20: Average queue (in packets) at the bottleneck link 2 (at Router 3) as a function of the traffic generation rate

3.3.3.1 Bottleneck Server Analysis as M/G/1 Queue

Let us now analyze the network by focusing on the flow and the bottleneck link (Link 2). Consider a single flow (with average inter-arrival time v) into a bottleneck link

(with capacity C). Let us the denote the input flow rate in packet arrivals per second as , where . Let us also denote the service rate of the bottleneck server

in packets served per second as , where . Then,

denotes the offered load to the server. When , also denotes (approximately) the fraction of time the server is busy serving packets (i.e., denotes link utilization).

When , then the link is barely utilized. When , then the link is said to be overloaded or saturated (and the buffer will grow unbounded). The interesting regime

is when .

Suppose that the application packet inter-arrival time is i.i.d. with exponential distribution. From the M/G/1 queue analysis (in fact, M/D/1 queue analysis), we know that

the average queue at the link buffer (assuming large buffer size) must be

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 20/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

where, is the offered load. In Figure 3‑20, we also plot the average queue from (1) (from the bottleneck analysis) and compare it with the average queue from the
simulation. You will notice that the bottleneck link analysis predicts the average queue (from simulation) very well.

An interesting fact is that the average queue depends on and only as .

3.4 Part - 2: Two Flow Scenario

We will consider a simple network setup with two flows illustrated in Figure 3‑21to review the definition of a bottleneck link and the maximum application throughput
achievable in the network. An application process at Wired_Node_1 seeks to transfer data to an application process at Wired_Node_2. Also, an application process at
Wired_Node_3 seeks to transfer data to an application process at Wired_Node_4. The two flows interact at the buffer of Router_ 5 (Link 3) and compete for link capacity.

We will again consider custom traffic generation process (at the application processes) that generates data packets of constant length (L bits) with i.i.d. inter-arrival times

(with average inter-arrival time seconds) with a common distribution. The application traffic generation rate in this setup is bits per second (for either application).

In this setup, we will vary the traffic generation rate of the two sources (by identically varying the average inter-arrival time v) and review the average queue at the

different links, application throughput (s) and packet loss rate (s).

3.4.1 Procedure

We will simulate the network setup illustrated in Figure 3‑21 with the configuration parameters listed in detail in Table 3‑1 to study the two flow scenario. We will assume

identical configuration parameters for the access links and the two application processes.

Figure 3‑21: Client and server network architecture with two flows

Step 1: Right-click the link ID (of a wired link) and select Properties to access the link’s properties dialog box. Set Max Uplink Speed and Max Downlink Speed to 10
Mbps for link 3 (the backbone link connecting the routers) and 1000 Mbps for links 1,2,4, 5 (the access link connecting the Wired Nodes and the routers). Set Uplink
BER and Downlink BER as 0 for all links. Set Uplink Propogation Delay and Downlink Propogation Delay as 0 microseconds for links 1,2,4 and 5 and 100 microseconds

for the backbone link 3.

Step 2: Enable Plots and Packet trace in NetSim GUI.

Step 3: Simulation time is 100 sec for all samples.

3.4.2 Results

In Table 3‑3, we report the common flow average inter-arrival time (AIAT) and the corresponding application traffic generation rate (TGR), input flow rate, combined input
flow rate, average queue at the buffers (of Wired_Node_1, Wired_Node_3 and Router_5), average throughput(s) and packet loss rate(s).

TGR Input Average queue Packet Loss Rate

Average Throughput
AIAT Combined
Flow (in Mbps)
(in pkts) (in percent)
Input Flow
Rate
Rate (in
(in (in WiredNode WiredNode Router App1 App2 App1 App2
(in µs) Mbps)
Mbps) Mbps) 1 3 5 Custom Custom Custom Custom

11680 1 1.037 2.074 0 0 0.03 0.999925 1.002728 0 0

5840 2 2.074 4.148 0 0 0.16 1.998214 2.006624 0 0

3893 3.0003 3.1112 6.2224 0 0 0.32 2.999307 3.001410 0 0

2920 4 4.1479 8.2958 0 0 1.99 3.996312 4.018504 0 0

2336 5 5.1849 10.3698 0 0 847.19 4.903614 4.907469 2.12 2.10

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 21/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
1947 5.999 6.2209 12.4418 0 0 4607.12 4.896606 4.915061 18.38 18.38

1669 6.9982 7.257 14.514 0 0 5009.33 4.896373 4.915294 30.10 30.00

1460 8 8.2959 16.5918 0 0 5150.91 4.906418 4.905250 38.88 38.78

1298 8.9985 9.3313 18.6626 0 0 5222.86 4.904782 4.906885 45.56 45.52

1168 10 10.3699 20.7398 0 0 5265.95 4.920317 4.891350 50.88 51.16

Table 3‑3: Average queue, throughput(s) packet loss rate(s) as a function of the traffic generation

We can infer the following from Table 3‑3.

1. There is queue buildup at Router_5 (Link 3) as the combined input flow rate increases. So, Link 3 is the bottleneck link for the two flows.

2. The traffic generation rate matches the application throughput(s) (with nearly zero packet loss rate) when the combined input flow rate is less than the capacity of
the bottleneck link.

3. As the combined input flow rate reaches or exceeds the bottleneck link capacity, the average queue at the (bottleneck) server at Router 5 increases unbounded
(limited by the buffer size) and the packet loss rate increases as well.

4. The two flows share the available link capacity and see a maximum application throughput of 4.9 Mbps (half of bottleneck link capacity 10 Mbps).

3.5 Useful Exercises

1. Redo the single flow experiment with constant inter-arrival time for the application process. Comment on average queue evolution and maximum throughput at

the links.

2. Redo the single flow experiment with small buffer size (8 KBytes) at the bottleneck link 2. Compute the average queue evolution at the bottleneck link and the
average throughput of the flow as a function of traffic generation rate. Compare it with the case when the buffer size in 8 MB.

3. Redo the single flow experiment with a bottleneck link capacity of 100 Mbps. Evaluate the average queue as a function of the traffic generation rate. Now, plot the
average queue as a function of the offered load and compare it with the case of bottleneck link with 10 Mbps capacity (studied in the report). Comment.

4 Delay and Little’s Law

4.1 Introduction
Delay is another important measure of quality of a network, very relevant for real-time applications. The application processes concern over different types of delay -
connection establishment delay, session response delay, end-to-end packet delay, jitter, etc. In this experiment, we will review the most basic and fundamental measure
of delay, known as end-to-end packet delay in the network. The end-to-end packet delay denotes the sojourn time of a packet in the network and is computed as

follows. Let and denote the time of arrival of packet into the network (into the transport layer at the source node) and time of departure of the packet from the

network (from the transport layer at the destination node), respectively. Then, the sojourn time of the packet i is computed as ( ) seconds. A useful measure of
delay of a flow is the average end-to-end delay of all the packets in the flow, and is computed as

where, N is the count of packets in the flow.

A packet may encounter delay at different layers (and nodes) in the network. The transport layer at the end hosts may delay packets to control flow rate and congestion

in the network. At the network layer (at the end hosts and at the intermediate routers), the packets may be delayed due to queues in the buffers. In every link (along the
route), the packets see channel access delay and switching/forwarding delay at the data link layer, and packet transmission delay and propagation delay at the physical
layer. In addition, the packets may encounter processing delay (due to hardware restrictions). It is a common practice to group the various components of the delay

under the following four categories: queueing delay (caused due to congestion in the network), transmission delay (caused due to channel access and transmission
over the channel), propagation delay and processing delay. We will assume zero processing delay and define packet delay as

We would like to note that, in many scenarios, the propagation delay and transmission delay are relatively constant in comparison with the queueing delay. This permits
us (including applications and algorithms) to use packet delay to estimate congestion (indicated by the queueing delay) in the network.

4.1.1 Little’s Law

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 22/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
The average end-to-end packet delay in the network is related to the average number of packets in the network. Little’s law states that the average number of packets
in the network is equal to the average arrival rate of packets into the network multiplied by the average end-to-end delay in the network, i.e.,

Likewise, the average queueing delay in a buffer is also related to the average number of packets in the queue via Little’s law.

The following figure illustrates the basic idea behind Little’s law. In Figure 4‑1a, we plot the arrival process (thick black line) and the departure process (thick red

line) of a queue as a function of time. We have also indicated the time of arrivals and time of departures of the four packets in Figure 4‑1a. In Figure 4‑1b, we plot

the queue process as a function of time, and in Figure 4‑1c, we plot the waiting time of the four packets in the network. From the figures, we

can note that the area under the queue process is the same as the sum of the waiting time of the four packets. Now, the average number of packets in the queue ( ),

if we consider a duration of ten seconds for the experiment) is equal to the product of the average arrival rate of packets and the average delay in the queue .

Figure 4‑1: Illustration of Little’s law in a queue.

In Experiment 3 (Throughput and Bottleneck Server Analysis), we noted that bottleneck server analysis can provide tremendous insights on the flow and network
performance. Using M/G/1 analysis of the bottleneck server and Little’s law, we can analyze queueing delay at the bottleneck server and predict end-to-end packet delay

as well (assuming constant transmission times and propagation delays).

4.2 NetSim Simulation Setup

Open NetSim and click Examples > Experiments > Delay-and-Littles-Law

Figure 4‑2: Experiments List

4.3 Part-1: A Single Flow Scenario

We will study a simple network setup with a single flow illustrated in Figure 4‑3 to review end to end packet delay in a network as a function of network traffic. An

application process at Wired Node 1 seeks to transfer data to an application process at Wired_Node_2. We will consider a custom traffic generation process (at the

application) that generates data packets of constant length (say, L bits) with i.i.d. inter-arrival times (say, with average inter-arrival time seconds). The application traffic

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 23/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

generation rate in this setup is bits per second. We prefer to minimize communication overheads (including delay at the transport layer) and hence, will use UDP for
data transfer between the application processes

In this setup, we will vary the traffic generation rate by varying the average inter-arrival time , and review the average queue at the different links, average
queueing delay at the different links and end-to-end packet delay

4.3.1 Procedure

We will simulate the network setup illustrated in Figure 4‑3 with the configuration parameters listed in detail in Table 4‑1 to study the single flow scenario.

NetSim UI displays the configuration file corresponding to this experiment as shown below:

Figure 4‑3: A client and a server network architecture with a single flow.

The following set of procedures were done to generate this sample:

Step 1: Drop two wired nodes and two routers onto the simulation environment. The wired nodes and the routers are connected with wired links as shown in (See Figure

4‑3).

Step 2: Click the Application icon to configure a custom application between the two wired nodes. In the Application configuration dialog box (see Figure 4‑4), select
Application Type as CUSTOM, Source ID as 1 (to indicate Wired_Node_1), Destination ID as 2 (to indicate Wired_Node_2) and Transport Protocol as UDP. In the

PACKET SIZE tab, select Distribution as CONSTANT and Value as 1460 bytes. In the INTER ARRIVAL TIME tab, select Distribution as EXPONENTIAL and Mean as
11680 microseconds.

Figure 4‑4: Application configuration dialog box

Step 3: The properties of the wired nodes are left to the default values.

Step 4: Right-click the link ID (of a wired link) and select Properties to access the link’s properties dialog box (see Figure 4‑5). Set Max Uplink Speed andMax
Downlink Speed to 10 Mbps for link 2 (the backbone link connecting the routers) and 1000 Mbps for links 1 and 3 (the access link connecting the Wired_Nodes and the
routers). Set Uplink BER and Downlink BER as 0 for links 1, 2 and 3. Set Uplink_Propagation Delay andDownlink_Propagation_Delay as 0 microseconds for the
two-access links 1 and 3 and 10 milliseconds for the backbone link 2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 24/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 4‑5: Link Properties dialog box

Step 5: Right-click Router 3 icon and select Properties to access the link’s properties dialog box (see Figure 4‑6). In the INTERFACE 2 (WAN) tab, select the

NETWORK LAYER properties, set Buffer size (MB) to 8.

Figure 4‑6: Router Properties dialog box

Step 6: Click on Packet Trace option and select the Enable Packet Trace check box. Packet Trace can be used for packet level analysis

Step 7: Click on Run icon to access the Run Simulation dialog box (see Figure 4‑7) and set the Simulation Time to 100 seconds in the Simulation Configuration tab.
Now, run the simulation.

Figure 4‑7: Run Simulation dialog box

Step 8: Now, repeat the simulation with different average inter-arrival times (such as 5840 µs, 3893 µs, 2920 µs, 2336 µs and so on). We vary the input flow rate by
varying the average inter-arrival time. This should permit us to identify the bottleneck link and the maximum achievable throughput.

The detailed list of network configuration parameters is presented in (See Table 4‑1).

Parameter Value
LINK PARAMETERS
Wired Link Speed (access link) 1000 Mbps
Wired Link Speed (backbone link) 10 Mbps

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 25/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Wired Link BER 0
Wired Link Propagation Delay 0
(access link)
Wired Link Propagation Delay 10 milliseconds
(backbone link)
APPLICATION PARAMETERS
Application Custom
Source ID 1
Destination ID 2
Transport Protocol UDP
Packet Size – Value 1460 bytes
Packet Size – Distribution Constant
Inter Arrival Time – Mean AIAT (µs) Table 4‑2
Inter Arrival Time – Distribution Exponential
ROUTER PARAMETERS
Buffer Size 8
MISCELLANEOUS
Simulation Time 100 Sec
Packet Trace Enabled
Plots Enabled
Table 4‑1: Detailed Network Parameters

4.3.2 Performance Measure

In Table 4‑2 and Table 4‑3, we report the flow average inter-arrival time v and the corresponding application traffic generation rate, input flow rate (at the physical layer),
average queue and delay of packets in the network and in the buffers, and packet loss rate.

Given the average inter-arrival time and the application payload size L bits (here, 1460×8 = 11680 bits), we have,

where the packet overheads of 54 bytes is computed as .

Let as denote the instantaneous queue at link at time . Then, the average queue at link is computed as

where, T is the simulation time. And, let denote the instantaneous number of packets in the network at time . Then, the average number of packets in the network

is computed as

Let and denote the time of arrival of a packet into the link (the corresponding router) and the time of departure of the packet from the link (the corresponding

router), respectively. Then, the average queueing delay at the link (the corresponding router) is computed as

where N is the count of packets in the flow. Let ai and di denote the time of arrival of a packet i into the network (into the transport layer at the source node) and time of

departure of the packet i from the network (from the transport layer at the destination node), respectively. Then, the end-to-end delay of the packet is computed as

seconds, and the average end to end delay of the packets in the flow is computed as

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 26/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
4.3.2.1 Average Queue Computation from Packet Trace
§ Open Packet Trace file using the Open Packet Trace option available in the Simulation Results window.

§ In the Packet Trace, filter the data packets using the column CONTROL PACKET TYPE/APP NAME and the option App1 CUSTOM (see Figure 4‑8).

Figure 4‑8: Filter the data packets in Packet Trace by selecting App1 CUSTOM.

§ Now, to compute the average queue in Link 2, we will select TRANSMITTER_ID as ROUTER-3 and RECEIVER_ID as ROUTER-4. This filters all the successful

packets from Router 3 to Router 4.

§ The columns NW_LAYER_ARRIVAL_TIME(US) and PHY_LAYER_ARRIVAL TIME(US) correspond to the arrival time and departure time of the packets in the
buffer at Link 2, respectively (see Figure 4‑9).

§ You may now count the number of packets arrivals (departures) into (from) the buffer upto time using the NW_LAYER_ARRIVAL_TIME(US)
(PHY_LAYER_ARRIVAL TIME(US)) column. The difference between the number of arrivals and the number of departures gives us the number of packets in the
queue at any time.

Figure 4‑9: Packet arrival and departure times in the link buffer

§ Calculate the average queue by taking the mean of the number of packets in queue at every time interval during the simulation.
§ The difference between the PHY LAYER ARRIVAL TIME(US) and the NW LAYER ARRIVAL TIME(US) will give us the delay of a packet in the link (see Figure

4‑10).

Figure 4‑10: Queuing Delay

§ Now, calculate the average queuing delay by taking the mean of the queueing delay of all the packets (see Figure 4‑10)
4.3.2.2 Network Delay Computation from Packet Trace
§ Open Packet Trace file using the Open Packet Trace option available in the Simulation Results window

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 27/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ In the Packet Trace, filter the data packets using the column CONTROL PACKET TYPE/APP NAME and the option App1 CUSTOM (see Figure 4‑8).
§ Now, we will select the RECEIVER ID as NODE-2. This filters all the successful packets in the network that reached Wired Node 2

§ The columns APP LAYER ARRIVAL TIME(US) and PHY LAYER END TIME(US) correspond to the arrival time and departure time of the packets in the network
respectively.
§ You may now count the number of arrivals (departures) into (from) the network upto time t using the APP LAYER ARRIVAL TIME(US) (PHY LAYER END

TIME(US)) column. The difference between the number of arrivals and the number of departures gives us the number of packets in the network at any time.
§ Calculate the average number of packets in the network by taking the mean of the number of packets in network at every time interval during the simulation.
§ Packet Delay at a per packet level can be calculated using the columns Application Layer Arrival Time and Physical Layer End Time in the packet trace as:

End-to-End Delay = PHY LAYER END TIME(US) – APP LAYER ARRIVAL TIME(US)
§ Calculate the average end-to-end packet delay by taking the mean of the difference between Phy Layer End Time and App Layer Arrival Time columns.
Note: To calculate average number of packets in queue refer the experiment on Throughput and Bottleneck Server Analysis.

4.3.3 Results

In Table 4‑2, we report the flow average inter-arrival time (AIAT) and the corresponding application traffic generation rate (TGR), input flow rate (at the physical layer),
average number of packets in the system, end-to-end packet delay in the network and packet loss rate.
TGR Input
AIAT
Arrival Avg no of End-to-End Packet
Flow
Rate (in packets Packet Delay Loss Rate
Rate
Pkts/sec) in system (in µs) (in percent)
(in µs) (in Mbps)
(in Mbps)
11680 1 1.037 86 0.97 11282.188 0.01
5840 2 2.074 171 1.94 11367.905 0.01
3893 3.0003 3.1112 257 2.94 11474.118 0.01
2920 4 4.1479 342 3.98 11621.000 0.02
2336 5 5.1849 428 5.06 11833.877 0.01
1947 5.999 6.2209 514 6.24 12142.376 0.01
1669 6.9982 7.257 599 7.58 12664.759 0.01
1460 8 8.2959 685 9.48 13846.543 0.01
1298 8.9985 9.3313 770 13.73 17840.278 0.02
1284 9.0966 9.433 779 14.73 18917.465 0.02
1270 9.1969 9.537 787 15.98 20318.735 0.02
1256 9.2994 9.6433 796 17.74 22299.341 0.01
1243 9.3966 9.7442 805 20.31 25243.577 0.01
1229 9.5037 9.8552 814 25.77 31677.196 0.03
1217 9.5974 9.9523 822 35.06 42660.631 0.02
1204 9.701 10.0598 831 51.87 62466.981 0.06
1192 9.7987 10.1611 839 101.21 120958.109 0.268
1180 9.8983 10.2644 847 442.71 528771.961 1.152
1168 10 10.3699 856 856.98 1022677.359 2.105
1062 10.9981 11.4049 942 3876.87 4624821.867 11.011
973 12.0041 12.4481 1028 4588.84 5479885.160 18.541
898 13.0067 13.4878 1114 4859.68 5797795.877 24.758
834 14.0048 14.5228 1199 4998.91 5964568.493 30.100
779 14.9936 15.5481 1284 5081.93 6066291.390 34.756

Table 4‑2: Packet arrival rate, average number of packets in the system, end-to-end delay and packet loss rate.

Calculation

Calculation done for sample 1

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 28/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

End to End packet delay in , Convert into

Therefore

We can infer the following from Table 4‑2.

§ The average end-to-end packet delay (between the source and the destination) is bounded below by the sum of the packet transmission durations and the
propagation delays of the constituent links (2 × 12 + 1211 + 10000 microseconds).

§ As the input flow rate increases, the packet delay increases as well (due to congestion and queueing in the intermediate routers). As the input flow rate matches or

exceeds the bottleneck link capacity, the end-to-end packet delay increases unbounded (limited by the buffer size).

§ The average number of packets in the network can be found to be equal to the product of the average end-to-end packet delay and the average input flow rate into
the network. This is a validation of the Little’s law. In cases where the packet loss rate is positive, the arrival rate is to be multiplied by (1 - packet loss rate).

In Table 4‑3, we report the average queue and average queueing delay at the intermediate routers (Wired Node 1, Router 3 and Router 4) and the average end-to-
end packet delay as a function of the input flow rate.

Input Flow Arrival End-to-End

Rate Rate (in Avg no of packets in Queue Average Queueing Delay (in µs) Packet Delay

(in Mbps) Pkts/sec) (in µs)

Router
Node 1 Router 3 Node 1 Router 3 Router 4
4

1.037 86 0 0 0 0.008 67.55 0 11282.188

2.074 171 0 0 0 0.015 153.26 0 11367.905
3.1112 257 0 0.08 0 0.021 259.47 0 11474.118
4.1479 342 0 0.13 0 0.029 406.35 0 11621.00
5.1849 428 0 0.26 0 0.035 619.21 0 11833.87
6.2209 514 0 0.45 0 0.046 927.70 0 12142.376
7.257 599 0 0.92 0 0.054 1450.08 0 12664.759
8.2959 685 0 1.82 0 0.062 2631.85 0 13846.543
9.3313 770 0 5.14 0 0.070 6625.58 0 17840.278
9.433 779 0 6.86 0 0.070 7702.77 0 18917.465
9.537 787 0 7.98 0 0.071 9104.04 0 20318.73
9.6433 796 0 7.82 0 0.071 11084.64 0 22299.341
9.7442 805 0 10.96 0 0.073 14028.88 0 25243.577
9.8552 814 0 16.12 0 0.073 20462.49 0 31677.196
9.9523 822 0 25.73 0 0.073 31445.93 0 42660.631
10.0598 831 0 42.86 0 0.074 51252.28 0 62466.981
10.1611 839 0 91.08 0 0.074 109743.41 0 120958.109
10.2644 847 0 434 0 0.076 517557.26 0 528771.961
10.3699 856 0 849.15 0 0.077 1011462.65 0 1022677.359
11.4049 942 0 3873.87 0 0.085 4613607.16 0 4624821.867
12.4481 1028 0 4593.12 0 0.093 5468670.46 0 5479885.160
13.4878 1114 0 4859.15 0 0.099 5786581.18 0 5797795.877
14.5228 1199 0 5000.13 0 0.106 5953353.81 0 5964568.493
15.5481 1284 0 5084.63 0 0.113 6055076.71 0 6066291.390

Table 4‑3: Average queue and average queueing delay in the intermediate buffers and end-to-end packet delay

We can infer the following from Table 4‑3.

§ There is queue buildup as well as queueing delay at Router_3 (Link 2) as the input flow rate increases. Clearly, link 2 is the bottleneck link where the packets see
large queueing delay.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 29/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ As the input flow rate matches or exceeds the bottleneck link capacity, the average queueing delay at the (bottleneck) server increases unbounded. Here, we note
that the maximum queueing delay is limited by the buffer size (8 MB) and link capacity (10 Mbps), and an upper bounded is

§ The average number of packets in a queue can be found to be equal to the product of the average queueing delay and the average input flow rate into the network.

This is again a validation of the Little’s law. In cases where the packet loss rate is positive, the arrival rate is to be multiplied by

§ The average end-to-end packet delay can be found to be equal to the sum of the packet transmission delays (12.112µs (link 1), 1211µs (link 2), 12.112 µs (link3)),
propagation delay (10000 µs) and the average queueing delay in the three links.

For the sake of the readers, we have made the following plots for clarity. In Figure 4‑11, we plot the average end-to-end packet delay as a function of the traffic

generation rate. We note that the average packet delay increases unbounded as the traffic generation rate matches or exceeds the bottleneck link capacity.

a) Linear Scale b) Log Scale

Figure 4‑11: Average end-to-end packet delay as a function of the traffic generation rate.

In Figure 4‑12, we plot the queueing delay experienced by few packets at the buffers of Links 1 and 2 for two different input flow rates. We note that the packet delay is a
stochastic process and is a function of the input flow rate and the link capacity as well.

a) At Wired Node 1 for TGR = 8 Mbps b) At Router 3 for TGR = 8 Mbps

c) At Wired Node 1 for TGR = 9.5037 Mbps d) At Router 3 for TGR = 9.5037 Mbps

Figure 4‑12: Queueing Delay of packets at Wired_Node_1 (Link 1) and Router_3 (Link 2) for two different traffic generation rates

4.3.3.1 Bottleneck Server Analysis as M/G/1 Queue

Suppose that the application packet inter-arrival time is i.i.d. with exponential distribution. From the M/G/1 queue analysis (in fact, M/D/1 queue analysis), we know that

the average queueing delay at the link buffer (assuming large buffer size) must be

where is the offered load to the link, is the input flow rate in packet arrivals per second and is the service rate of the link in packets served per second. Notice that

the average queueing delay increases unbounded as .

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 30/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 4‑13: Average queueing delay (in seconds) at the bottleneck link 2 (at Router 3) Average queueing delay (in seconds) at the bottleneck link 2 (at Router 3) as a function of the

offered load.

Figure 4‑13 we plot the average queueing delay (from simulation) and from (1) (from the bottleneck analysis) as a function of offered load . Clearly, the bottleneck link

analysis predicts the average queue (from simulation) very well. Also, we note from (1) that the network performance depends on and as only.

5 Understand working of ARP, and IP Forwarding within a LAN and across a

router
5.1 Theory
In a network architecture different layers have their own addressing scheme. This helps the different layers in being largely independent. Application layer uses host
names, network layer uses IP addresses and the link layer uses MAC addresses. Whenever a source node wants to send an IP datagram to a destination node, it needs

to know the address of the destination. Since there are both IP addresses and MAC addresses, there needs to be a translation between them. This translation is handled
by the Address Resolution Protocol (ARP). In IP network, IP routing involves the determination of suitable path for a network packet from a source to its destination. If the
destination address is not on the local network, routers forward the packets to the next adjacent network.

(Reference: A good reference for this topic is Section 5.4.1: Link Layer Addressing and ARP, of the book, Computer Networking, A Top-Down Approach, 6th Edition by Kurose and Ross)

5.2 ARP protocol Description

1. ARP module in the sending host takes any IP address as input and returns the corresponding MAC address.

2. First the sender constructs a special packet called an ARP packet, which contains several fields including the sending and receiving IP and MAC addresses.

3. Both ARP request and response packets have the same format.

4. The purpose of the ARP request packet is to query all the other hosts and routers on the subnet to determine the MAC address corresponding to the IP address
that is being resolved.

5. The sender broadcasts the ARP request packet, which is received by all the hosts in the subnet.

6. Each node checks if its IP address matches the destination IP address in the ARP packet.

7. The one with the match sends back to the querying host a response ARP packet with the desired mapping.

8. Each host and router has an ARP table in its memory, which contains mapping of IP addresses to MAC addresses.

9. The ARP table also contains a Time-to-live (TTL) value, which indicates when each mapping will be deleted from the table.

5.3 ARP Frame Format

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 31/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 5‑1: ARP Frame Format

The ARP message format is designed to accommodate layer two and layer three addresses of various sizes. This diagram shows the most common implementation,
which uses 32 bits for the layer three (“Protocol”) addresses, and 48 bits for the layer two hardware addresses.

5.4 IP Forwarding Description

1. Every router has a forwarding table that maps the destination addresses (or portions of the destination addresses) to that router’s outbound links.

2. A router forwards a packet by examining the value of a field in the arriving packet’s header, and then using this header value to index into the router’s forwarding

table.

3. The value stored in the forwarding table entry for that header indicates the router’s outgoing link interface to which that packet is to be forwarded.

4. Depending on the network-layer protocol, the header value could be the destination address of the packet or an indication of the connection to which the packet

belongs.

5. ARP operates when a host wants to send a datagram to another host on the same subnet.

6. When sending a Datagram off the subnet, the datagram must first be sent to the first-hop router on the path to the final destination. The MAC address of the

router interface is acquired using ARP.

7. The router determines the interface on which the datagram is to be forwarded by consulting its forwarding table.

8. Router obtains the MAC address of the destination node using ARP.

9. The router sends the packet into the respective subnet from the interface that was identified using the forwarding table.

5.5 Network Set up

Open NetSim and click Examples > Experiments > Working-of-ARP-and-IP-Forwarding-within-a-LAN-and-across-a-router > Sample-1 see Figure 5‑2.

Figure 5‑2: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure5‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 32/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 5‑3: Application flow within a LAN

5.6 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 3 Wired Nodes, 2 L2 Switches, and 1 Router in the “Internetworks” Network Library.

Step 2: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining

20000µs.

Transport Protocol is set to UDP instead of TCP. If set to TCP, the ARP table will get updated due to the transmission of TCP control packets thereby eliminating the need
for ARP to resolve addresses.

Step 3: Packet Trace is enabled in the NetSim GUI, and hence we can view the ARP Request and ARP Reply packets exchanged initially, before transmission of the data
packets.

Step 4: Enable the plots and click on Run simulation. The simulation time is set to 10 seconds. In the “Static ARP Configuration” tab, Static ARP is set to disable see

Figure 5‑4.

Figure 5‑4: Static ARP Configuration Window

Click on Accept and then click on OK.

If Static ARP is enabled, then NetSim will automatically create an ARP table for each node. To see the working of the ARP protocol users should disable Static ARP.

By doing so, ARP request would be sent to the destination to find out the destinations MAC Address.

5.7 Output – I
Once the simulation is complete, to view the packet trace file, click on “Open Packet Trace” option present in the left-hand-side of the Results Dashboard.

Figure 5‑5: Open Packet Trace

NODE 1 will send ARP_REQUEST to SWITCH-4, SWITCH-4 sends this to ROUTER-6, and SWITCH-4 also sends this to NODE-2. ARP-REPLY is sent by the NODE-2
to SWITCH -4, and in-turn SWITCH-4 sends it to NODE-1.

5.8 Inference I

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 33/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Intra-LAN-IP-forwarding:

ARP PROTOCOL- WORKING:

Figure 5‑6: Intra LAN IP Forwarding

NODE-1 broadcasts ARP_Request, which is then broadcasted by SWITCH-4. NODE-2 sends the ARP_Reply to NODE-1 via SWITCH-4. After this step, datagrams are
transmitted from NODE-1 to NODE-2. Notice the DESTINATION_ID column for ARP_Request type packets, which indicates Broadcast-0.

>Sample-2:

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 5‑7.

Figure 5‑7: Application flow across a WAN

5.9 Procedure
The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in the NetSim GUI comprising of 3 Wired Nodes, 2 L2 Switches, and 1 Router.

Step 2: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 1 i.e. Source to Wired Node 3 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining
20000µs.

Transport Protocol is set to UDP instead of TCP. If set to TCP, the ARP table will get updated due to the transmission of TCP control packets thereby eliminating the need
for ARP to resolve addresses.

Step 3: Packet Trace is enabled in the NetSim GUI, and hence we can view the ARP Request and ARP Reply packets exchanged initially, before transmission of the data

packets.

Step 4: Enable the plots and click on Run simulation. The simulation time is set to 10 seconds. In the “Static ARP Configuration” tab, Static ARP is set to
disable.

5.10 Output – II
Once the simulation is complete, to view the packet trace file, click on “Open Packet Trace” option present in the left-hand-side of the Results Dashboard.

Figure 5‑8: Open Packet Trace

NODE 1 will send ARP_REQUEST to SWITCH-4, SWITCH-4 sends this to ROUTER-6, and SWITCH-4 also sends this to NODE-2. ARP-REPLY is sent by the

ROUTER-6 to SWITCH -4, and in-turn SWITCH-4 sends it to NODE-1. Again ROUTER-6 will send ARP_REQUEST to SWITCH-5, SWITCH-5 sends this to NODE-3.
ARP_REPLY is sent by NODE-3 to SWITCH-5 and in-turn SWITCH-5 sends it to ROUTER-6.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 34/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
The IP forwarding table formed in the router can be accessed from the IP_Forwarding_Table list present in the Simulation Results window as shown below:

Figure 5‑9: IP Forwarding Table

Click on Detailed View checkbox to view the additional fields as indicated above.

Router forwards packets intended to the subnet 11.2.0.0 to the interface with the IP 11.2.1.1 based on the first entry in its routing table.

5.11 Inference II
Across-Router-IP-forwarding
ARP PROTOCOL- WORKING

Figure 5‑10: Across Router IP Forwarding

NODE-1 transmits ARP_Request which is further broadcasted by SWITCH-4. ROUTER-6 sends ARP_Reply to NODE-1 which goes through SWITCH-4. Then NODE-1
starts sending datagrams to NODE-3. If router has the MAC address of NODE-3 in its ARP table, then ARP ends here and router starts forwarding the datagrams to

NODE-3 by consulting its forwarding table. In the other case, Router sends ARP_Request to appropriate subnet and after getting the MAC address of NODE-3, it then
forwards the datagrams to NODE-3 using its forwarding table.

6 Simulate and study the spanning tree protocol

6.1 Introduction
Spanning Tree Protocol (STP) is a link management protocol. Using the spanning tree algorithm, STP provides path redundancy while preventing undesirable loops in
a network that are created by multiple active paths between stations. Loops occur when there are alternate routes between hosts. To establish path redundancy, STP
creates a tree that spans all of the switches in an extended network, forcing redundant paths into a standby, or blocked state. STP allows only one active path at a time

between any two network devices (this prevents the loops) but establishes the redundant links as a backup if the initial link should fail. Without spanning tree in place, it
is possible that both connections may simultaneously live, which could result in an endless loop of traffic on the LAN.

(Reference: A good reference for this topic is Section 3.1.4: Bridges and LAN switches, of the book, Computer Networks, 5th Edition by Peterson and Davie)

6.2 Network Setup

Open NetSim and click Examples > Experiments > Simulate-and-study-the-spanning-tree-protocol > Sample-1 as shown below Figure 6‑1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 35/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 6‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 6‑2.

Figure 6‑2: A network with a loop

Note: At least three L2 Switches are required in the network to analyze the spanning tree formation.

6.3 Procedure
Step 1: A network scenario is designed in the NetSim GUI comprising of 3 Wired Nodes and 3 L2 Switches in the “Internetworks” Network Library.

Step 2: Go to L2 Switch 1 Properties. In the Interface 1 (ETHERNET) > Datalink Layer, “Switch Priority” is set to 2. Similarly, for the other interfaces of L2 Switch 1,

Switch Priority is set to 2.

Step 3: Go to L2 Switch 2 Properties. In the Interface 1 (ETHERNET) > Datalink Layer, “Switch Priority” is set to 1. Similarly, for the other interfaces of L2 Switch 2,
Switch Priority is set to 1.

Step 4: Go to L2 Switch 3 Properties. In the Interface 1 (ETHERNET) > Datalink Layer, “Switch Priority” is set to 3. Similarly, for the other interfaces of L2 Switch 3,
Switch Priority is set to 3.

L2_Switch
L2_Switch 1 L2_Switch 2 L2_Switch 3
Properties

Switch Priority 2 1 3

Table 6‑1: Switch Priorities for Sample 1

NOTE:Switch Priority is set to all the 3 L2 Switches and Switch Priority has to be changed for all the interfaces of L2 Switch.

Switch Priority is interpreted as the weights associated with each interface of a L2 Switch. A higher value indicates a higher priority.

Step 5: Right click on the Application Flow “App1 CUSTOM” and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from Wired Node 4 i.e. Source to Wired Node 5 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time

remaining 20000µs. Additionally, the “Start Time” parameter is set to 1 second while configuring the application see Figure 6‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 36/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 6‑3: Application Configuring Window

Note: Wired Node 6 is not generating traffic to any other nodes.

Here, Wired Node 4 is sending data to Wired Node 5 and the node properties are set to default.

Step 6: Enable the plots and click on Run simulation. The simulation time is set to 10 seconds.

> Sample-2:

The following changes in settings are done from the previous sample:

In Sample 2, the “Switch Priority” of all the 3 L2 Switches are changed as follows Table 6‑2:

L2_Switch Properties L2_Switch 1 L2_Switch 2 L2_Switch 3

Switch Priority 1 2 3

Table 6‑2: Switch Priorities for Sample 2

6.4 Output
In the NetSim Design Window, click on Display Settings > Spanning Tree check box see Figure 6‑4.

Sample 1:

Figure 6‑4: NetSim Design Window - Display Setting for Sample 1

Go to NetSim Packet Animation Window and click on Play button. We can notice that, after the exchange of control packets, the data packets take the following path.
Wired Node 4 > L2 Switch 1 > L2 Switch 2 > L2 Switch 3 > Wired Node 5.

Sample 2:

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 37/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 6‑5: NetSim Design Window - Display Setting for Sample 2

Go to NetSim Packet Animation window and click on Play button. We can notice that, after the exchange of control packets, the data packets take the following path.
Wired Node 4 > L2 Switch 1 > L2 Switch 3 > Wired Node 5.

Go to Simulation Results window, In the left-hand-side of the Results Dashboard, click on the arrow pointer of Switch MAC address table to obtain the Switch MAC
address table list of all the L2 Switches.

For each L2 Switch, a Switch MAC Address Table containing the MAC address entries see Figure 6‑6, the port that is used for reaching it, along with the type of entry can

be obtained at the end of Simulation.

Figure 6‑6: MAC Address Table

6.5 Inference
Each L2 Switch has an ID which is a combination of its Lowest MAC address and priority. The Spanning tree algorithm selects the L2 Switch with the smallest ID as the
root node of the Spanning Tree. The root node forward frames out over all its ports. In the other L2 Switches, the ports that have the least cost of reaching the root switch
are set as Forward Ports and the remaining are set as Blocked Ports. In the Sample 1, L2_Switch 2 was assigned least priority and was selected as a Root Switch.

The green line indicates the forward path and the red line indicates the blocked path. The frame from Wired Node 4 should take the path through the L2_Switch 1, 2 and
3 to reach the Wired Node 5. In the Sample 2, L2_Switch 1 was assigned least priority and selected as a Root switch. In this case, the frame from Wired Node 4 takes
the path through the L2_Switch 1 and 3 to reach the destination Wired Node 5.

7 Introduction to TCP connection management

7.1 Introduction
When an application process in a client host seeks a reliable data connection with a process in another host (say, server), the client-side TCP then proceeds to establish
a TCP connection with the TCP at the server side. A TCP connection is a point-to-point, full-duplex logical connection with resources allocated only in the end hosts. The

TCP connection between the client and the server is established in the following manner and is illustrated in Figure 7‑1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 38/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
1. The TCP at the client side first sends a special TCP segment, called the SYN packet, to the TCP at the server side.

2. Upon receiving the SYN packet, the server allocates TCP buffer and variables to the connection. Also, the server sends a connection-granted segment, called the

SYN-ACK packet, to the TCP at the client side.

3. Upon receiving the SYN-ACK segment, the client also allocates buffers and variables to the connection. The client then acknowledges the server’s connection
granted segment with an ACK of its own.

This connection establishment procedure is often referred to as the three-way handshake. The special TCP segments can be identified by the values in the fields SYN,
ACK and FIN in the TCP header (see Figure 7‑2). We also note that the TCP connection is uniquely identified by the source and destination port numbers (see Figure
7‑2) exchanged during TCP connection establishment and the source and destination IP addresses.

Once a TCP connection is established, the application processes can send data to each other. The TCP connection can be terminated by either of the two processes.
Suppose that the client application process seeks to terminate the connection. Then, the following handshake ensures that the TCP connection is torn down.

1. The TCP at the client side sends a special TCP segment, called the FIN packet, to the TCP at the server side.

2. When the server receives the FIN segment, it sends the client an acknowledgement segment in return and its own FIN segment to terminate the full-duplex
connection.

3. Finally, the client acknowledges the FIN-ACK segment (from the server) with an ACK of its own. At this point, all the resources (i.e., buffers and variables) in the

two hosts are deallocated.

During the life of a TCP connection, the TCP protocol running in each host makes transitions through various TCP states. Figure 7‑1illustrates the typical TCP states
visited by the client and the server during connection establishment and data communication.

TCP is defined in RFCs 793, 1122, 7323 and, 2018. A recommended text book reference for TCP is Chapter 3: Transport layer, of Computer Networking: A top-down
approach, by James Kurose and Keith Ross (Pearson).

Figure 7‑1: TCP connection establishment between a client and a server

Figure 7‑2: TCP Header

7.2 Network Setup

Open NetSim and click Examples > Experiments > Introduction-to-TCP-connection-management > Sample-1 as shown below Figure 7‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 39/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 7‑3: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 7‑4

Figure 7‑4: An FTP application between a client and a server connected in a network

7.3 Procedure
The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 2 Routers in the “Internetworks” Network Library.

Step 2: In the General Properties of Wired Node 1 i.e. Source, Wireshark Capture is set to Online. Transport Layer properties Congestion plot is set to true.

Note:Accept default properties for Routers as well as the Links.

Step 3: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. Set Max Uplink Speed and Max Downlink Speed to 10 Mbps. Set

Uplink BER and Downlink BER to 0. Set Uplink Propagation Delay and Downlink Propagation Delay as 100 microseconds for the links 1 and 3 (between the Wired
Node’s and the routers). Set Uplink Propagation Delay and Downlink Propagation Delay as 50000 microseconds for the backbone link connecting the routers, i.e., 2.

Step 4: Right click on the Application Flow App1 FTP and select Properties or click on the Application icon present in the top ribbon/toolbar.

An FTP Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with File Size set to 14600 Bytes and File Inter Arrival Time set to 10
Seconds.

Step 5: Click on Display Settings > Device IP check box in the NetSim GUI to view the network topology along with the IP address.

Step 6: Enable the plots and click on Run simulation. The simulation time is set to 10 seconds.

7.4 Output
We have enabled Wireshark capture in Wired Node 1. The PCAP file is generated at the end of the simulation and is shown in Figure 7‑5.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 40/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 7‑5: Wireshark Packet capture at Wired_Node_1

1. The 3-way handshake of TCP connection establishment and TCP connection termination is observed in the packet capture (Figure 7‑5).

2. Data is transferred only after the TCP connection is established.

3. We can access the packet header details of the TCP segments (SYN, SYN-ACK, FIN, FINACK) in Wireshark.

8 Reliable data transfer with TCP

8.1 Introduction
TCP provides reliable data transfer service to the application processes even when the underlying network service (IP service) is unreliable (loses, corrupts, garbles or
duplicates packets). TCP uses checksum, sequence numbers, acknowledgements, timers and retransmission to ensure correct and in order delivery of data to the

application processes.

TCP views the data stream from the client application process as an ordered stream of bytes. TCP will grab chunks of this data (stored temporarily in the TCP send
buffer), add its own header and pass it on to the network layer. A key field of the TCP header is the sequence number which indicates the position of the first byte of the
TCP data segment in the data stream. The sequence number will allow the TCP receiver to identify segment losses, duplicate packets and to ensure correct delivery of

the data stream to the server application process.

When a server receives a TCP segment, it acknowledges the same with an ACK segment (the segment carrying the acknowledgement has the ACK bit set to 1) and also
conveys the sequence number of the first missing byte in the application data stream, in the acknowledgement number field of the TCP header. All acknowledgements

are cumulative, hence, all missing and out-of-order TCP segments will result in duplicate acknowledgements for the corresponding TCP segments.

TCP sender relies on sequence numbering and acknowledgements to ensure reliable transfer of the data stream. In the event of a timeout (no acknowledgement is
received before the timer expires) or triple duplicate acknowledgements (multiple ACK segments indicate a lost or missing TCP segment) for a TCP segment, the TCP

sender will retransmit the segment until the TCP segment is acknowledged (at least cumulatively). In Figure 8‑1, we illustrate retransmission by the TCP sender after a
timeout for acknowledgement.

Figure 8‑1: An illustration of TCP retransmission with timeout. The segment with sequence number 4381 is lost in the network. The TCP client retransmits the segment after a timeout

event.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 41/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

8.2 Network Setup

We will seek a simple file transfer with TCP over a lossy link to study reliable data transfer with TCP. We will simulate the network setup illustrated in Figure 8‑3 with the
configuration parameters listed in detail in Table 1 to study reliable data transfer with TCP connection.

Open NetSim and click Examples > Experiments > Reliable-data-transfer-with-TCP > Sample-1 as shown below Figure 8‑2.

Figure 8‑2: Experiment List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 8‑3.

Figure 8‑3: FTP application between a client and a server

8.3 Procedure
The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 2 Routers in the “Internetworks” Network Library.

Step 2: In the General Properties of Wired Node 1 i.e. Source and Wired Node 2 i.e. Destination, Wireshark Capture is set to Online. Transport Layer properties

Congestion plot is set to true.

Note:Accept default properties for Routers as well as the Links.

Step 3: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. Set Max Uplink Speed and Max Downlink Speed to 10 Mbps. Set

Uplink BER and Downlink BER to 0. Set Uplink Propagation Delay and Downlink Propagation Delay as 100 microseconds for the links 1 and 3 (between the Wired
Node’s and the routers). Set Uplink Propagation Delay and Downlink Propagation Delay as 50000 microseconds and Uplink BER and Downlink BER to 0.00001 for the
backbone link connecting the routers, i.e., 2.

Step 4: Right click on the Application Flow App1 FTP and select Properties or click on the Application icon present in the top ribbon/toolbar.

An FTP Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with File Size set to 14600 Bytes and File Inter Arrival Time set to 20
Seconds.

Step 5: Click on Display Settings > Device IP check box in the NetSim GUI to view the network topology along with the IP address.

Step 6: Enable the plots and click on Run simulation. The simulation time is set to 20 seconds.

8.4 Output

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 42/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
We aimed to transfer a file of size 14600 bytes (i.e., 10 packets, each of size 1460 bytes) with TCP over a lossy link. In Figure 8‑4, we report the application metrics data
for FTP which indicates that the complete file was transferred.

Figure 8‑4: Application Metrics table for FTP

We have enabled Wireshark Capture in Wired Node 1 and Wired Node 2. The PCAP files are generated at the end of the simulation and are shown in Figure 8‑5 and
Figure 8‑6.

Figure 8‑5: PCAP file at Wired Node 1. TCP ensures reliable data transfer using timeout, duplicate ACKs and retransmissions

Figure 8‑6: PCAP file at Wired Node 2

8.5 Inference
1. From Figure 8‑5 and Figure 8‑6, we note that the packets with sequence number 2961, 5921, and 8881 are lost in the network.

2. After receiving three duplicate ACKs (in lines 13, 14 of Figure 8‑5), TCP retransmits the lost packet with sequence number 2691 (in line 15 of Figure 8‑5). After a
timeout (see lines 17, 21, 22 and 23, lines 25 and 26), TCP retransmits the lost packet with sequence numbers 5921 and 8881.

3. TCP connection is terminated only after the complete file transfer is acknowledged.

9 Mathematical Modelling of TCP Throughput Performance

9.1 Introduction
The average throughput performance of additive-increase multiplicative-decrease TCP congestion control algorithms have been studied in a variety of network
scenarios. In the regime of large RTT, the average throughput performance of the TCP congestion control algorithms can be approximated by the ratio of the

average congestion window cwnd and RTT.

9.1.1 Loss-less Network

In a loss-less network, we can expect the TCP congestion window cwnd to quickly increase to the maximum value of 64 KB (without TCP scaling). In such a case,

the long-term average throughput of TCP can be approximated as

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 43/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

9.1.2 Lossy Network

We refer to an exercise in Chapter 3 of Computer Networking: A top-down approach, by Kurose and Ross for the setup. Consider a TCP connection over a lossy
link with packet error rate p. In a period of time between two packet losses, the congestion window may be approximated to increase from an average value of
W/2 to W (see Figure 9‑8 for motivation). In such a scenario, the throughput can be approximated to vary from W/2/RTT to W/RTT (in the cycle between two

packet losses). Under such assumptions, we can then show that the loss rate (fraction of packets lost) must be equal to

and the average throughput is then approximately,

9.2 Network Setup

We will seek a large file transfer with TCP over a loss-less and lossy link to study long-term average throughput performance of the TCP congestion control algorithm.
We will simulate the network setup illustrated in Figure 9‑2 with the two (loss-less and lossy) configuration parameters listed in detail in Table 1 to study the throughput
performance of TCP New Reno.

Open NetSim and click Examples > Experiments > Mathematical-model-of-TCP-throughput-performance > Sample-1 as shown below Figure 9‑1.

Figure 9‑1: Experiment List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 9‑2.

Figure 9‑2: Network Topology

9.3 Procedure
Sample 1

The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 2 Routers in the “Internetworks” Network Library.

Step 2: In the General Properties of Wired Node 1 i.e. Source, Wireshark Capture is set to Online. Transport Layer properties Congestion plot is set to true.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 44/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Note: Accept default properties for Routers as well as the Links.

Step 3: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. Set Max Uplink Speed and Max Downlink Speed to 10 Mbps. Set

Uplink BER and Downlink BER to 0. Set Uplink Propagation Delay and Downlink Propagation Delay as 100 microseconds for the links 1 and 3 (between the Wired
Node’s and the routers). Set Uplink Propagation Delay and Downlink Propagation Delay as 50000 microseconds for the backbone link connecting the routers, i.e., 2.

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

An CBR Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with Packet Size set to 1460 Bytes and Inter Arrival Time set to 1168
microseconds.

Step 5: Click on Display Settings > Device IP check box in the NetSim GUI to view the network topology along with the IP address.

Step 6: Click on Plots icon and select the Enable Plots checkbox. This enables us to view the throughput plot of the application App1 CBR.

Step 7: Click on Run simulation. The simulation time is set to 100 seconds. In the “Static ARP Configuration” tab, Static ARP is set to disable.

Sample 2

Step 1: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. Set Max Uplink Speed and Max Downlink Speed to 10 Mbps. Set
Uplink BER and Downlink BER to 0. Set Uplink Propagation Delay and Downlink Propagation Delay as 100 microseconds for the links 1 and 3 (between the Wired
Node’s and the routers). Set Uplink Propagation Delay and Downlink Propagation Delay as 50000 microseconds and Uplink BER and Downlink BER to 0.0000001 for

the backbone link connecting the routers, i.e., 2.

Step 2: Click on Run simulation. The simulation time is set to 100 seconds. In the “Static ARP Configuration” tab, Static ARP is set to disable.

9.4 Output
In Figure 9‑3, we report the application metrics data for data transfer over a loss-less link (Sample-1).

Figure 9‑3: Application Metrics with BER = 0

In Figure 9‑4, we report the plot of long-term average throughput of the TCP connection over the loss-less link.

Figure 9‑4: Long-term average throughput of TCP New Reno over a loss-less link

We have enabled Wireshark Capture in the Wired Node 1. The PCAP file is generated at the end of the simulation. From the PCAP file, the congestion window
evolution graph can be obtained as follows. In Wireshark, select any data packet with a left click, then, go to Statistics > TCP Stream Graphs > Window Scaling
>Select Switch Direction. In Figure 9‑5, we report the congestion window evolution of TCP New Reno over the loss-less link.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 45/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 9‑5: Congestion window evolution with TCP New Reno over a loss-less link.

In Figure 9‑6, we report the application metrics data for data transfer over a lossy link (Sample-2).

Figure 9‑6: Application Metrics when

In Figure 9‑7, we report the plot of long-term average throughput of the TCP connection over the lossy link.

Figure 9‑7: Throughput graph

In Figure 9‑8, we report the congestion window evolution of TCP New Reno over the lossy link.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 46/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 9‑8: Congestion window evolution with TCP New Reno over a lossy link

9.5 Observations and Inference

1. In Figure 9‑5, we notice that the congestion window of TCP (over the loss-less link) increases monotonically to 64 KB and remains there forever. So, a block of 64
KBs of data is transferred over a round-trip time (RTT) of approximately 100 milliseconds. Hence, a good approximation of the TCP throughput over the loss-less

link is

We note that the observed long-term average throughput (see Figure 9‑3) is approximately equal to the above computed value.

2. In Figure 9‑8, for the lossy link with , we report the congestion window evolution with New Reno congestion control algorithm. The approximate
throughput of the TCP New Reno congestion control algorithm for a packet error rate p, TCP segment size MSS and round-trip time RTT

where the packet error rate p can be computed from the bit error rate ( ) and the PHY layer packet length (1500 bytes, see packet trace) as

We note that the observed long-term average throughput (see Figure 9‑6) is approximately equal to the above computed value.

10 Study how throughput and error of a Wireless LAN network changes as

the distance between the Access Point and the wireless nodes is varied
10.1 Introduction
In this experiment we will study the physical layer standard for IEEE 802.11b WiFi. A physical layer standard (abbreviated as PHY standard) defines the mechanism by
which logical information bits are transmitted over the wireless channel that has been allotted to the WiFi system. WiFi systems are confined to working in an

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 47/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
approximately 80MHz bandwidth in the 2.4GHz ISM band. Within this bandwidth, any particular WiFi Access Point (AP) must choose to work in one of 13 channels, each
of nominal bandwidth 22MHz. In this experiment, we aim to study how the packet error performance of an IEEE 802.11b AP-STA connection varies as the distance

between the AP and the STA varies.

10.2 Background
The IEEE 802.11b standard defines 4 digital modulation schemes for such channels. All are based on Direct Sequence Spread Spectrum (DSSS) with a chipping rate of
11 million chips per second (11 Mcps). An 11 chip Barker code yields 1 million symbols per second (1 Msps). These symbols are Differential Phase Shift Keying
modulated to get 1 bit per symbol, thereby yielding 1 Mbps, and Quarternary Differential Phased Keying modulated to get 2 bits per symbol, thereby yielding 2 Mbps. In

order to get 5.5 Mbps and 11 Mbps, each symbol is made from 8 chips, so that the symbol rate is 1.375 Msps. A technique called Complementary Code Keying (CCK)
then provides 4 bits per symbol, yielding 5.5 Mbps, and 8 bits per symbol, which yields 11 Mbps.

A simple qualitative fact is that, for a given signal to noise ratio at the receiver, as the modulation scheme attempts to send more bits per second, the bit error probability

increases. This happens because, as the bit rate increases, the bit sequences that the receiver needs to distinguish between become closely packed, so that bit errors
become harder to resolve. The signal to noise ratio (SNR) at the receiver depends on the transmission power, the attenuation of power from the transmitter to the
receiver, and noise power.

Where is the noise power spectral density (W/Hz) and is the system bandwidth (nominally 22 MHz). The noise power works out to approximately dBm. The

received power is obtained by subtracting the path-loss, between the transmitter and the receiver, from the transmitted power (e.g., dBm, would

arise from a transmit power of 1 mW). A simple expression for path-loss is given by

where is the path loss at the “reference” distance of 1m, is the path-loss exponent and is the distance between the transmitter and the receiver. It may be noted

that this deterministic expression ignores random phenomena such as “shadowing” and “fading.”

As increases, the received power decreases; e.g., doubling the distance reduced the received power by approximately , since . Typical values of ,

indoors, could be 3 to 5, resulting in 9 dB to 15 dB additional path loss for doubling the value of .

10.3 Network Setup

Open NetSim and click Examples > Experiments > Impact-of-distance-on-Wifi-throughput-and-error > Sample-1 as shown below Figure 10‑1.

Figure 10‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 10‑2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 48/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 10‑2: WiFi Network Scenario

10.4 Procedure
The following set of procedures were done to generate this sample.

Step 1: A network scenario is created in NetSim GUI comprising of 1 Wired Node, 1 Router, 1 Access Point and 1 Wireless Node in the “Internetworks” Network
Library.

Step 2: In the Destination Node, i.e. Wireless Node 4, the Interface 1 (WIRELESS) > Physical Layer, Protocol Standard is set to IEEE802.11b and in the Interface 1

(WIRELESS) > Datalink Layer, Rate Adaptation is set to False.

Step 3: The position of the Wireless Node and the Access Point in the grid environment is set according to the values given in the below see Table 10‑1.

Wireless Node 4
Access Point
Properties
X/Lon 200 200
Y/Lat 130 100
Table 10‑1: Device Positions

Step 4: Right click on Wirelessnode and AccessPoint, select Properties and select DCF as the Medium Access Protocol in the DATALINK_LAYER of INTERFACE_1

Step 5: Right-click the link ID (of a wired/wireless link) and select Properties to access the link’s properties. The parameters are set according to the values given in the
below see Table 10‑1/Table 10‑2.

Wired Link Properties

Max Uplink Speed (Mbps) 100

Max Downlink Speed (Mbps) 100

Uplink BER 0.0000001

Downlink BER 0.0000001

Uplink Propagation Delay (µs) 5

Downlink Propagation Delay
5
(µs)
Table 10‑2: Wired link Properties

Wireless Link Properties

Channel Characteristics Path Loss Only

Path Loss Model Log Distance

Path Loss Exponent 3

Table 10‑3: Wireless Link Properties

Step 6: Right click on App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 2 i.e. Source to Wireless Node 4 i.e. Destination with Packet Size set to 1450 Bytes and Inter Arrival Time set to 770
µs. It is set such that, the Generation Rate equals to 15 Mbps.

Transport Protocol is set to UDP instead of TCP.

Step 7: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the packet information is available for the users to
perform packet level analysis.

Step 8: Enable the plots and run simulation for 10sec.

Similarly do the other samples by varying the distance between Access Point and Wireless Node as 60, 85, 90, 100, 110, 115, 180, 260, 360, 400, 420, 440, 460, 480,
up to 500 m.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 49/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

10.5 Output
Note down the values of Data rate and Throughput for all the samples and compare them with IEEE standards Phy rate can be calculated from packet trace by using the
formula given below

192 microseconds is the approximate preamble time for 802.11b

Calculate PHY rate for all the data packets coming from Access Point to Wireless node. For doing this please refer section 8.5.1 How to set filters to NetSim Packet
Trace file from NetSim’s User Manual. Filter Packet Type to CBR, Transmitter to Access Point and Receiver to Wireless node.

Since where PER is packet error rate, PL is packet length in bits and BER is bit error rate, we get

On tabulating the results, you would seeTable 10‑4.

802.11b
PHY rate in
Application Packet error
Distance Mbps Packets Packets
Throughput probability
(m) (Channel Transmitted Errored
(Mbps)
capacity)
30 11 5.93 5110 0 0
60 11 5.93 5110 0 0
85 11 5.83 5099 70 0.0137
90 11 5.55 5058 276 0.0545
100 5.5 3.79 3266 0 0
110 5.5 3.79 3266 0 0
115 5.5 3.64 3253 117 0.036
180 2 1.68 1445 0 0
260 2 1.68 1445 0 0
360 2 1.67 1445 7 0.004
400 2 1.48 1436 163 0.113
420 1 0.89 769 0 0
440 1 0.89 769 0 0
460 1 0.89 769 0 0
480 1 0.89 769 0 0
500 0 0 0 0 0

Table 10‑4: PHY rate, Application throughput, packet transmitted/errored and packet error probability vs. distance

Figure 10‑3: Data Rate vs. Distance

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 50/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 10‑4: Application Throughput vs. Distance

Figure 10‑5: Packet Error Probability vs. Distance

Note: All the above plots highly depend upon the placement of nodes in the simulation environment. So, note that even if the placement is slightly different, the same set of values will not be got but one

would notice a similar trend.

10.6 Inference
We notice that as the distance increases, the 802.11b PHY rate (channel capacity decreases) decreases. This is because the underlying data rate depends on the
received power at the receiver.

RF losses are directly proportional to distance to the power of path loss exponent. As RF propagation losses increase, the received power decreases.

We can see that the rate drops from 11 Mbps to 5.5 Mbps at around 95m, and then to 2 Mbps at 175 m and to 1 Mbps at 415 m (in this case the path loss exponent is
set to 3.0). We also notice how the packet error rate increases with distance, then when the data rate changes (a lower modulation scheme is chosen), the error rate

drops. This happens for all the transitions i.e. 11 to 5.5, 5.5 to 2 and from 2 to 1 Mbps. One must note that WLAN involves ACK packets after data transmission. These
additional packet transmission lead to reduced Application throughput of 5.9 Mbps (at lower distances) even though the PHY layer data rate is 11 Mbps and the error
rates is almost NIL. The application throughput is dependent on the PHY rate and the channel error rate, and one can notice it drops / rise accordingly.

11 WiFi: UDP Download Throughput

11.1 The Setup and Motivation
The most basic packet transfer service offered by the Internet is called the “datagram” service, in which a series of packets are transmitted to a receiver without any
packet loss recovery, flow control, or congestion control. The Internet’s UDP protocol implements the datagram service. In this experiment we will study the performance

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 51/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
of UDP transfers from a server on a wireline local area network to WiFi Stations (STA), via WiFi Access Points (AP). The schematic of the network that we will be
simulating in NetSim is shown in the figure below Figure 11‑1.

Figure 11‑1: Network topology and application flow from server to STA via a single AP

The server, which contains the data that needs to be transferred to the STAs (say, laptops), is connected by a 100 Mbps switched Ethernet link to an Ethernet switch,

which is, in turn, connected to the WiFi APs. Each AP is associated (i.e., connected) at 11 Mbps to a single STA. The objective is to transfer a large number of packets
(say, constituting a video) from the server to each of the STAs, the packet stream to each of the STAs being different (e.g., each STA is receiving a different video from
the server). In this experiment, we are interested in studying the limitation that the WiFi link places on the data transfers. We assume that the server transmits the

packets at a high enough rate so that the queues at the APs fill up, and the rate of the UDP transfers is, therefore, governed by the WiFi link. It may be noted that, in
practice, there will be a flow control mechanism between each STA and the server, that will control the rate at which the server releases packets, in order to prevent
buffer overflow at the APs.

In this setting, this experiment will ask one precise question. With the buffers at the AP full, at what rate will the WiFi protocol transfer the packets from the APs to the
STAs over the wireless link. We will study two cases:

1. A single AP and a single STA: Since there is only one transmitter in this wireless network (namely, the AP), there is no contention, and the rate of packet transfer

over the link will be governed by the basic overheads in the protocol, such as the interframe spacings, packet header overheads, transmit-receive turn-around
times, and acknowledgement times. We will begin by a simple calculation (essentially timing book-keeping) that will predict the UDP throughput, and then we will
verify our calculation using the NetSim simulator.

2. Multiple APs and one STA for each AP: This is the more common situation (for example neighboring apartments in a building, each with one AP and one laptop,
all drawing data from the Internet service provider). The performance of such a system depends on the wireless propagation path-loss between the various APs.
A predictive analysis is difficult in the general case. For deriving some insight, we will study the case where all the APs are close to each other, and thus exactly

one transmission from AP to an STA can be successful at any time. If two or more APs transmit together, then all the transmissions are not successful. Even in
this case, the analysis mathematically complex and is available in, Anurag Kumar, D. Manjunath and Joy Kuri. 2008: Wireless Networking. Sec 7.4

11.2 Predicting the UDP Throughput

11.2.1 One AP and one STA

As stated above, in the setup described, the AP queue is full. Thus, after a packet is completely transmitted over the wireless link, immediately the process for

transmitting the next packet starts. This is illustrated by the upper part of the figure below, where the successive packets from the AP are shown as being sent back-to-
back. The time taken to send a packet is, however, not just the time to clock out the physical bits corresponding to the packet over the Wi-Fi medium. After the
completion of a packet transfer, the AP’s Wi-Fi transmitter waits for a Distributed Coordination Function Inter-Frame Space (DIFS), followed by a backoff that is chosen

randomly between 1 and 32 slots. Upon the completion of the backoff, the packet transmission starts. Each packet carries physical layer overheads, MAC layer
overheads, and IP overheads. After the transmission of the packet, there is a Short Inter-Frame Space (SIFS), which gives time to the receiver (namely, the STA) to
transition from the listening mode to the transmit mode. After the SIFS, the STA sends back a MAC acknowledgement (ACK). This completes the transmission of one

UDP packet from the AP to the STA. Immediately, the process for sending the next packet can start. The details of the various timings involved in sending a single UDP
packet are shown in the lower part of the figure below Figure 11‑2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 52/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 11‑2: Detailed view of transmission of a single packet in WiFi involving single AP-STA

In this experiment, the payload in each packet is the same (1450 Bytes). Since the packets are sent back to back, and the state of the system is identical at the
beginning of each packet transmission, the throughput (in Mbps) is computed by the following simple (and intuitive) relation.

11.2.1.1 Without RTS / CTS

Where

11.2.1.2 With RTS/CTS

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 53/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

11.2.2 Multiple APs (near each other) and one STA per AP

Since the AP queues are full, on the WiFi medium the packet transmission can still be viewed as being back-to-back as shown in the upper part of the figure below

Figure 11‑3. However, since there are multiple contending AP-STA links, there are two differences between this figure and the one shown above (for the single AP and

single STA case Figure 11‑2).

Figure 11‑3: Detailed view of transmission of a single packet in WiFi involving Multiple AP-STA

a. Within each transmission period, there is now a “backoffs and collisions” period, where in the figure above we only showed a “backoff” period. Access to the
channel is by contention, collision, and backoff, and this “backoffs and collisions” duration is the time taken to select one transmitting AP.

b. The other difference is that, after each “backoffs and collisions” period, any one AP-STA pair “wins” the contention, and the corresponding AP can then send a
packet. It turns out that the contention mechanism is such that each of the AP-STA pairs can succeed with equal probability, independent of the pair that has
previously been successful. Thus, if there are, say, 5 AP-STA pairs, then each successful packet transmission will be from any of these pairs with a probability of

0.2.

With reference to the figure above, note that, all the APs are contending to send their packets to their respective STAs, and the “Backoffs and Collisions” time is due to all

the APs. However, finally, only one packet transmission succeeds. We will attribute all the contention overheads to the successful transmission of this packet. Thus, we
will call the time duration from the beginning of a DIFS until the end of the ACK for the transmitted packet as the “effective” time taken to transmit that packet on the
wireless medium. The average of these effective packet transmission times can be called the “Average time per Packet.”

With this discussion, and the upper part of the figure above, it follows that the following expression still holds

We observe from the figure that the average time per packet will be larger than when there is a single AP-STA pair. Hence, the total UDP throughput will be smaller when

there are multiple AP-STA pairs (since the “Application Payload in the Packet” is the same in both cases.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 54/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Having obtained the total throughput over all the AP-STA pairs in this manner, by the fact that each packet transmission is with equal probability from any of the AP-STA

pairs, the UDP throughput for each AP-STA pair (for pairs) is just of the total throughput.

11.3 Network Setup

Open NetSim and click Examples > Experiments > WiFi-UDP-Download-Throughput > Part-1 > Without-RTS-CTS as shown below Figure 11‑4.

Figure 11‑4: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 11‑5.

Figure 11‑5: A single AP-STA Without RTS/CTS

11.4 Procedure
11.4.1 Part-1: Without RTS/CTS

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 1 Wireless Node, 1 L2 Switch, and 1 Access Point in the “Internetworks” Network

Library.

Step 2: In the Interface Wireless > Physical Layer Properties of Wireless Node 5, Protocol Standard is set to IEEE 802.11b. In the Interface Wireless > Data Link Layer
Properties of Wireless Node and Access Point, RTS Threshold is set to 3000. Medium Access Protocol is set to DCF for all nodes.

Step 3: In the Wired Link Properties, Bit Error Rate and Propagation Delay is set to 0 for both the links.

Step 4: In the Wireless Link Properties, Channel Characteristics is set to NO PATH LOSS.

Step 5: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar. A CBR Application is

generated from Wired Node 4 i.e. Source to Wireless Node 5 i.e. Destination with Packet Size set to 1450 Bytes and Inter Arrival Time set to 116µs. Transport Protocol is
set to UDP.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 100 Mbps. Generation Rate can be calculated using the formula:

Step 6: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

11.4.1.1 Part-1: With RTS/CTS

The following changes in settings are done from the previous sample:

Step 1: In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 1000.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 55/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Step 2: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

11.4.2 Part-2: Without RTS/CTS: 2APs

The following changes in settings are done from the previous sample Figure 11‑6.

Figure 11‑6: Multiple AP-STA Without RTS/CTS

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 2 Wireless Node, 1 L2 Switch, and 2 Access Points in the “Internetworks” Network
Library.

Step 2: In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 3000. Medium Access Protocol is set to DCF
for all nodes.

Step 3: Two CBR applications are generated from Wired Node 1 i.e. Source to Wireless Node 4 and Wireless Node 6 i.e. Destination with a Generation Rate of 10

Mbps.

Step 4: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

Similarly, the subsequent samples are carried out with 3, 4, and 5 Access Points and Wireless Nodes.

11.4.3 Part-2: With RTS/CTS: 2APs

The following changes in settings are done from the previous sample:

Step 1: In the Interface Wireless > Data Link Layer Properties of Wireless Node and Access Point, RTS Threshold is set to 1000. Medium Access Protocol is set to DCF

for all nodes.

Step 2: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

Similarly, the subsequent samples are carried out with 3, 4, and 5 Access Points and Wireless Nodes.

11.5 Output I
After running simulation, check throughput in Application metrics as shown in the below screenshot Figure 11‑7.

Figure 11‑7: Results for single AP-STA

Predicted Throughput Simulated

Sample
(Mbps) Throughput (Mbps)
1 (Without RTS/CTS) 5.89 5.92

2 (With RTS/CTS) 4.45 4.39

Table 11‑1: UDP throughput for a single AP-STA, with and without RTS/CTS

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 56/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

11.6 Output II
After running simulation, check throughput in Application metrics as shown in the below screenshot:

Figure 11‑8: Results for Multiple AP-STA

Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) with Throughput (Mbps) with
Sample
with 2 APs with 3 APs 4 Aps 5 APs
App 1: 1.25
App 1:1.58
App 1: 2.12 App 2: 1.21
App 1: 3.14 App 2:1.54
1 (Without App 2: 1.97 App 3: 1.19
App 2: 3.02 App 3:1.52
RTS/CTS) App 3: 2.09 App 4: 1.19
Total: 6.16 App 4:1.48
Total: 6.18 App 5: 1.24
Total: 6.12
Total: 6.08
App 1: 1.01
App 1: 1.21
App 1: 1.58 App 2: 0.90
App 1: 2.34 App 2: 1.18
2 (With App 2: 1.49 App 3: 0.93
App 2: 2.25 App 3: 1.15
RTS/CTS) App 3: 1.58 App 4: 0.92
Total: 4.59 App 4: 1.12
Total: 4.65 App 5: 0.94
Total: 4.66
Total: 4.70
Table 11‑2: UDP throughput for 2, 3, 4, and 5 AP-STA pairs, with and without RTS/CTS

11.7 Discussion
Table 11‑1shows the AP-STA UDP throughput (predicted and simulated) for a single AP-STA. Table 11‑2shows the UDP throughputs for 2, 3, 4, and 5 AP-STA pairs; the
total throughput is shown along with the individual AP-STA throughputs. We can make the following observations, along with explanations (as bulleted comments) for the

observations.

1. The UDP throughput with RTS/CTS turned off is larger than when RTS/CTS is used.

§ The reduction in throughput with RTS/CTS is due the RTS/CTS overheads. The RTS/CTS mechanism aims at alerting “hidden” nodes that a transmission is

about to start and can reduce collisions if there are hidden nodes. Since in this experiment all node can directly hear each other’s transmissions, the Basic
Access mode suffices, whereas RTS/CTS only adds overhead.

2. The UDP throughput increases slightly with two AP-STA pairs than with just one.

§ With just one AP-STA pair, there is wastage of time due to backoffs, even when there is no possibility of contention. When one more AP-STA is added some
of this wastage is compensated by two APs attempting, with the possibility that one of them might finish its backoff early and grab the channel, thus
reducing the backoff overhead. There is, of course, the additional time wasted due to collisions, but the balance between these two opposing phenomena

is such that there is a small gain in throughput.

3. Further increase in the number AP-STA pairs leads to a decrease in throughput, but the decrease is small.

§ The IEEE 802.11 Distributed Coordination Function (DCF) manages the sharing of the WiFi channel in a distributed manner. If there was a centralised

scheduler than each AP could be scheduled by turn, without any backoff and collision overheads, and the total throughput would have been just that due

to sending UDP packets back-to-back: Mbps. Thus, the total throughput with DCF is smaller than if the UDP packets were being sent back-
to-back, about 6 Mbps rather than 8.95 Mbps. However, DCF implements an adaptive attempt rate mechanism, which causes nodes to attempt less

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 57/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
aggressively as the number of contending nodes increases. It is this mechanism that prevents the total throughput from dropping steeply as the number of
AP-STA pairs increases.

4. The total throughput is distributed roughly equally between the AP-STA pairs.

§ This is another feature of DCF. The contending nodes obtain fair access at the packet level, i.e., each successful packet is from any of the contending
nodes with equal probability. The down-side of this feature is that if an AP-STA is using long packets, then that UDP flow will get a larger throughput. In

this experiment, all the AP-STA UDP flows are using the same packet lengths.

12 How many downloads can a Wi-Fi access point simultaneously handle?

12.1 Motivation
Wi-Fi has become the system of choice for access to Internet services inside buildings, offices, malls, airports, etc. In order to obtain access to the Internet over Wi-Fi a

user connects his/her mobile device (a laptop or a cellphone, for example) to a nearby Wi-Fi access point (AP). A popular use of such a connection is to download a
document, or a music file; in such an application, the user’s desire is to download the file as quickly as possible, i.e., to get a high throughput during the download. It is a
common experience that as the number of users connected to an AP increases, the throughput obtained by all the users decreases, thereby increasing the time taken to

download their files. The following question can be asked in this context.

If during the download, a user expects to get a throughput of at least bytes per second, what is the maximum number of users (say, up to which the throughput

[1]
obtained by every user is at least We can say that is the capacity of this simple Wi-Fi network for the Quality of Service (QoS) objective .

12.2 Objective

In this experiment we will learn how to obtain in a simple WiFi network where the packet loss due to channel errors is 0. In this process we will understand some

interesting facts about how WiFi networks perform when doing file transfers.

12.3 Theory
In NetSim, we will set up a network comprising a server that carries a large number of large files that the users would like to download into their mobile devices. The

server is connected to a Wi-Fi AP, with the IEEE 802.11b version of the protocol, via an Ethernet switch. Several mobile devices (say, ) are associated with the AP,
each downloading one of the files in the server. The Ethernet speed is 100Mbps, whereas the mobile devices are connected to the AP at 11Mbps, which is one of the

IEEE 802.11b speeds.

We observe, from the above description, that the file transfer throughputs will be limited by the wireless links between the AP and the mobile devices (since the Ethernet
speed is much larger than the Wi-Fi channel speed). There are two interacting mechanisms that will govern the throughputs that the individual users will get:

1. The Wi-Fi medium access control (MAC) determines how the mobile devices obtain access to the wireless medium. There is one instance of the WiFi MAC at
each of the mobile devices.

2. The end-to-end protocol, TCP, controls the sharing of the wireless bandwidth between the ongoing file transfers. In our experiment, there will be one instance of

TCP between the server and each of the mobile devices.

For simplicity, the default implementation of TCP in NetSim does not implement the delayed ACK mechanism. This implies that a TCP receiver returns an ACK for every
received packet. In the system that we are simulating, the server is the transmitter for all the TCP connections, and each user’s mobile device is the corresponding

receiver.

Suppose, each of the TCP connection transmits one packet to its corresponding mobile device; then each mobile device will have to return an ACK. For this to

happen, the AP must send packets, and each of the mobile devices must send back ACKs. Thus, for the file transfers to progress, the AP needs to packets for

each packet (i.e., ACK) returned by each mobile device. We conclude that, in steady state, the AP must send as many packets as all the mobile devices send, thus
requiring equal channel access to the AP as to all the mobile devices together.

At this point, it is important to recall that when several nodes (say, an AP and associated mobile devices) contend for the channel, the WiFi medium access control

provides fair access at the packet level, i.e., each contending device has an equal chance of succeeding in transmitting a packet over the channel. Now consider the

system that we have set up in this present experiment. There are mobile devices associated with one AP. Suppose, for example, of them ( all have a

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 58/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

packet to transmit (and none other has a packet). By the fair access property of the WiFi MAC, each of these nodes, along with the AP, has an equal probability of

successfully transmitting. It follows, by the packet level fair access property, that each node will have a probability of of succeeding in transmitting its packet. If this

situation continues, the channel access ratio to the AP will be inadequate and the equal channel access argued in the previous paragraph will be violated. It follows from
this that, on the average, roughly only one mobile device will have an ACK packet in it; the AP will contend with one other node, thus getting half the packet transmission
opportunities.

With the just two nodes contending, the collision probability is small (~ 0.06) and the probability of packet discard is negligibly small. Thus, the TCP window for every

transfer will grow to the maximum window size. The entire window worth of TCP data packets for the sessions will be in the AP buffer, except for a very small number
of packets (averaging to about 1) which will appear as ACKs in the mobile devices.

It follows that, in steady state, the system will look like two contending WiFi nodes, one with TCP data packets and the other with TCP ACK packets. This will be the case
no matter how many downloading mobile devices there are. The total throughput can be obtained by setting up the model of two saturated nodes, one with TCP data
packets, and the other with TCP ACK packets. The data packets of all the TCP connections will be randomly ordered in the AP buffer, so that the head-of-the-line packet

will belong to any particular mobile device with probability This throughput is shared equally between the mobile devices.

Now suppose that the TCP data packet throughput with the two-node model is . Then

where the denotes the largest integer less than or equal to Use NetSim to verify that for an 11Mbps Wi-Fi speed, with RTS/CTS enabled the total TCP throughput

is 3.4 Mbps. If , then In this example, if the download throughput obtained by each of them will be but if one more

downloading device is added then each will get a throughput less than . We say that the capacity of this network for a target throughput of is 5.

12.4 Procedure
Open NetSim and click Examples > Experiments > How-many-downloads-can-a-Wi-Fi-access-point-simultaneously-handle? > Sample-1 as shown below Figure

12‑1.

Figure 12‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment Figure 12‑2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 59/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 12‑2: WiFi Network with Single TCP Download

12.5 Procedure
The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in the NetSim GUI comprising of 1 Wired Node, 1 Wireless Node, 1 Access Point, and 1 Router in the “Internetworks” Network
Library.

Step 2: In the Interface (WIRELESS) > Data Link Layer Properties of Wireless Node 4 and Access Point, Short Retry Limit was set to 7, Long Retry Limit was set to 4

and RTS Threshold was set to 1000 bytes. Medium-Access-Protocol is set to DCF Figure 12‑3.

Figure 12‑3: Data Link Layer Properties

Step 3: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. The Link Properties are set according to the values given in the below
Table 12‑1.

Wired Link

Max Uplink Speed (Mbps) 100

Max Downlink Speed (Mbps) 100

Uplink BER 0

Downlink BER 0

Uplink Propagation Delay (µs) 0

Downlink Propagation Delay
0
(µs)

Wireless Link
Channel
No path loss
Characteristics
Table 12‑1: Detailed Wired/Wireless Links Properties

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 60/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Step 4: Right click on App1 FTP and select Properties or click on the Application icon present in the top ribbon/toolbar.

An FTP Application is generated from Wired Node 2 i.e. Source to Wireless Node 4 i.e. Destination with File Size set to 10,000,000 Bytes and Inter Arrival Time set to 20

s.

Step 5: Enable the plots, run the Simulation for 15 Seconds and note down the throughput.

Sample 2:

The following changes in settings are done from the previous sample:

Step 1: The number of Wireless Nodes is increased to 5 and FTP applications are generated from Wired Node 2 to each of the Wireless Nodes as shown below Figure
12‑4.

No. of wireless nodes = 5

Figure 12‑4: WiFi Network with Multiple TCP Download

Properties App1 App2 App3 App4 App5

Application
FTP FTP FTP FTP FTP
Type
Source Id 2 2 2 2 2

Destination Id 4 5 6 7 8
File size
10,000,000 10,000,000 10,000,000 10,000,000 10,000,000
(Bytes)
File Inter
20 s 20 s 20 s 20 s 20 s
arrival time

Table 12‑2: Detailed Application properties

Step 2: Enable the plots, run the Simulation for 15 Seconds and note down the throughput.

NOTE:Follow the same procedure for next samples with wireless nodes 10, 15, 20, 25 and note down the sum of throughputs for all applications.

12.6 Measurements and Output

Aggregated download throughput with different values of N (wireless nodes) is shown below Table 12‑3.

Sample Number of Sum of throughputs Throughput Per

Number Devices (Mbps) Device (Mbps)
1 1 3.39 3.39
2 5 3.40 0.68
3 10 3.18 0.32
4 15 3.23 0.21
5 20 3.24 0.16
6 25 3.26 0.13
Table 12‑3: Aggregated download throughput for different number of wireless nodes

NOTE:In the referred paper we see that, the throughput value for 11 Mbps WLAN is 3.8 Mbps. Please note that this is the aggregate PHY throughput of the AP. However, in NetSim, we are

calculating the total Application throughput.

To derive the PHY layer throughput from the APP layer throughput, we need to add overheads of all layers Table 12‑4.

Layer Overhead (Bytes)

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 61/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Transport Layer 20
Network Layer 20
MAC Layer 40
PHY layer 48µs = (11*48)/8 = 66
Total Overhead 146
Table 12‑4: Overhead of different layers

12.7 Inference
We see that as the number of devices increase the aggregate (combined) throughput remains constant whereas the throughput per user decreases.

As discussed earlier, our goal was to identify that if during the download, a user expects to get a throughput of at least bytes per second, what is the maximum number

of users (say, ?

If we set to be 650 Kbps, then we see that from the output table that the maximum number of users who can simultaneously download files is 5

12.8 Reference Documents

1. Analytical models for capacity estimation of IEEE 802.11 WLANs using DCF for internet applications. George Kuriakose, Sri Harsha, Anurag Kumar, Vinod Sharma

13 TCP Congestion Control Algorithms

13.1 Introduction
A key component of TCP is end-to-end congestion control algorithm. The TCP congestion control algorithm limits the rate at which the sender sends traffic into the
network based on the perceived network congestion. The TCP congestion control algorithm at the sender maintains a variable called congestion window, commonly
referred as cwnd, that limits the amount of unacknowledged data in the network. The congestion window is adapted based on the network conditions and this affects the

sender’s transmission rate. The TCP sender reacts to congestion and other network conditions based on new acknowledgements, duplicate acknowledgements and
timeouts. The TCP congestion control algorithms describe the precise manner in which TCP adapts cwnd with the different events.

The TCP congestion control algorithm has three major phases (a) slow-start, (b) congestion avoidance, and (c) fast recovery. In slow-start, TCP is aggressive and

increases cwnd by one MSS with every new acknowledgement. In congestion avoidance, TCP is cautious and increases the cwnd by one MSS per round-trip time.
Slow-start and congestion avoidance are mandatory components of all TCP congestion control algorithms. In the event of a packet loss (inferred by timeout or triple
duplicate acknowledgements), the TCP congestion control algorithm reduces the congestion window to 1 (e.g., Old Tahoe, Tahoe) or by half (e.g., New Reno). In fast

recovery, TCP seeks to recover from intermittent packet losses while maintaining a high congestion window. The new versions of TCP, including TCP New Reno,
incorporate fast recovery as well. Figure 13‑1 presents a simplified view of the TCP New Reno congestion control algorithm highlighting slow-start, congestion avoidance
and fast recovery phases.

TCP congestion control algorithm is often referred to as additive-increase multiplicative-decrease (AIMD) form of congestion control. The AIMD congestion control
algorithm often leads to a “saw tooth” evolution of the congestion window (with linear increase of the congestion window during bandwidth probing and a multiplicative
decrease in the event of packet losses), see Figure 13‑6.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 62/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Figure 13‑1: A simplified view of FSM of the TCP New Reno congestion control algorithm

13.2 Network Setup

We will seek a large file transfer with TCP over a lossy link to study the TCP congestion control algorithms. We will simulate the network setup illustrated in Figure 13‑3
with the configuration parameters listed in detail in steps to study the working of TCP congestion control algorithms.

Open NetSim and click Examples > Experiments > TCP-congestion-control-algorithms > Old -Tahoe as shown below Figure 13‑2.

Figure 13‑2: Experiments list

NetSim UI displays the configuration file corresponding to this experiment as shown below:

Figure 13‑3: Network Topology in this experiment

13.3 Procedure
Old -Tahoe

The following set of procedures were done to generate this sample.

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 2 Routers in the “Internetworks” Network Library.

Step 2: In the Source Node, i.e. Wired Node 1, in the TRANSPORT LAYER Properties, Congestion Control Algorithm is set to OLD TAHOE. Congestion plot is set to
TRUE.

Step 3: In the General Properties of Wired Node 1 i.e. Source, Wireshark Capture is set to Online.

Note: Accept default properties for Routers as well as the Links Properties should be changed.

Step 4: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. Set Max Uplink Speed and Max Downlink Speed to 10 Mbps. Set
Uplink BER and Downlink BER to 0. Set Uplink Propagation Delay and Downlink Propagation Delay as 100 microseconds for the links 1 and 3 (between the Wired

Node’s and the routers). Set Uplink Propagation Delay and Downlink Propagation Delay as 50000 microseconds and Uplink BER and Downlink BER to 0.0000001 for
the backbone link connecting the routers, i.e., 2.

Step 5: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

An CBR Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with Packet Size set to 1460 Bytes and File Inter Arrival Time set to
1168 microseconds.

Step 6: Click on Display Settings > Device IP check box in the NetSim GUI to view the network topology along with the IP address.

Step 7: Click on Plots icon and select the Enable Plots checkbox. This enables us to view the throughput plot of the application App1 CBR.

Step 8: Click on Run simulation. The simulation time is set to 20 seconds. In the “Static ARP Configuration” tab, Static ARP is set to disable.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 63/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Tahoe

Step 1: In the Source Node, i.e. Wired Node 1, in the TRANSPORT LAYER Properties, Congestion Control Algorithm is set to TAHOE. Congestion plot is set to TRUE.

Step 2: Click on Run simulation. The simulation time is set to 20 seconds. In the “Static ARP Configuration” tab, Static ARP is set to disable.

New Reno

Step 1: In the Source Node, i.e. Wired Node 1, in the TRANSPORT LAYER Properties, Congestion Control Algorithm is set to NEW RENO. Congestion plot is set to

TRUE.

Step 2: Click on Run simulation. The simulation time is set to 20 seconds. In the “Static ARP Configuration” tab, Static ARP is set to disable.

13.4 Output
We have enabled Wireshark Capture in the Wired Node 1. The PCAP file is generated at the end of the simulation. From the PCAP file, the congestion window evolution
graph can be obtained as follows. In Wireshark, select any data packet with a left click, then, go to Statistics > TCP Stream Graphs > Window Scaling > Select

Switch Direction.

The congestion window evolution for Old Tahoe, Tahoe and New Reno congestion control algorithms are presented in Figure 13‑4, Figure 13‑5, and Figure 13‑6,
respectively.

Table 13‑1 shows the throughput values of different congestion control algorithms (obtained from the Application Metrics).

Figure 13‑4: Congestion window evolution with TCP Old Tahoe. We note that Old Tahoe infers packet loss only with timeouts, and updates the slow-start threshold ssthresh and

congestion window cwnd as ssthresh = cwnd/2 and cwnd = 1

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 64/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Figure 13‑5: Congestion window evolution with TCP Tahoe. We note that Tahoe infers packet loss with timeout and triple duplicate acknowledgements, and updates the slow-start

threshold ssthresh and congestion window cwnd as ssthresh = cwnd/2 and cwnd = 1

Figure 13‑6: Congestion window evolution with TCP New Reno. We note that New Reno infers packet loss with timeout and triple duplicate acknowledgements, and updates the slow-

start threshold ssthresh and congestion window cwnd as ssthresh = cwnd/2 and cwnd = ssthresh + 3MSS (in the event of triple duplicate acknowledgements).

Congestion Control Algorithm Throughput

Old Tahoe 3.52 Mbps
Tahoe 3.03 Mbps
New Reno 4.13 Mbps

Table 13‑1: Long-term average throughput of the different TCP congestion control algorithms

13.5 Observations and Inference

1. We can observe slow start, congestion avoidance, timeout, fast retransmit and recovery phases in the Figure 13‑4, Figure 13‑5, and Figure 13‑6. In Figure 13‑4, we
note that Old Tahoe employs timeout, slow-start and congestion avoidance for congestion control. In Figure 13‑5, we note that Tahoe employs fast retransmit,
slow-start and congestion avoidance for congestion control. In Figure 13‑6, we note that New Reno employs fast retransmit and recovery, congestion avoidance

and slow-start for congestion control.

2. We note that TCP New Reno reports a higher long term average throughput (in comparison with Old Tahoe and Tahoe, see Table 13‑1) as it employs fast
retransmit and recovery to recover from packet losses.

14 Multi-AP Wi-Fi Networks: Channel Allocation

14.1 Introduction
A single Wi-Fi Access Point (AP) can connect laptops and other devices that are a few meters distance from the AP, the actual coverage depending on the propagation
characteristics of the building in which the Wi-Fi network is deployed. Thus, for large office buildings, apartment complexes, etc., a single AP does not suffice, and

multiple APs need to be installed, each covering a part of the building. We will focus on 2.4GHz and 5GHz systems. In each of these systems the available bandwidth is
organized into channels, with each AP being assigned to one of the channels. For example, 2.4GHz Wi-Fi systems operate in the band 2401MHz to 2495MHz, which
has 14 overlapping channels each of 22MHz. There are 3 nonoverlapping channels, namely, Channels 1, 6, and 11, which are centered at 2412MHz, 2437MHz, and

2462MHz. Evidently, if neighboring APs are assigned to the same channel or overlapping channels they will interfere, thereby leading to poor performance. On the other
hand, since there are only three nonoverlapping channels, some care must be taken in assigning channels to APs so that nearby APs have nonoverlapping channels,
whereas APs that are far apart can use the same or overlapping channels.

In this experiment we will understand some basic issues that arise in multi-AP networks, particularly with attention to channel allocation to the APs.

14.2 Network Setup

Open NetSim and click Examples > Experiments > Multi-AP-Wi-Fi-Networks-Channel-Allocation as shown below Figure 14‑1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 65/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 14‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 14‑2.

APs on the same channel:

Figure 14‑2: Multiple APs-WiFi Networks with APs on same Channel - Sample 1

Sample1: The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 1 L2 Switch, 3 Wireless Nodes and 3 Access Points in the “Internetworks” Network
Library.

Step 2: The device positions are set as per the table given below Table 14‑1.

General Properties
Device Name X / Lon Y / Lat
AP_1 15 5
AP_2 15 10
AP_3 15 15
Wireless_Node_6 20 5
Wireless_Node_7 20 10
Wireless_Node_8 20 15
Table 14‑1: Device positions for APs-STA - Sample 1

Step 3: In the INTERFACE (WIRELESS) > PHYSICAL LAYER Properties of all the Wireless Nodes and Access Points, the Protocol Standard is set to IEEE 802.11 b. In

the INTERFACE (WIRELESS) > DATALINK LAYER Properties of all the Wireless Nodes and Access Points, Medium Access Protocol is set to DCF

Step 4: Right-click the link ID (of a wired link) and select Properties to access the link’s properties. For all the Wired Links, Bit Error Rate and Propagation Delay is set to
0.

Step 5: The Wireless Link Properties are set according to the values given in the below Table 14‑2.

Channel Characteristics PATH LOSS ONLY

Path Loss Model LOG DISTANCE
Path Loss Exponent 3.5
Table 14‑2: Wireless Link Properties

Step 6: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 66/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
A CBR Application is generated from Wired Node 1 i.e. Source to Wireless Node 6 i.e. Destination with Packet Size set to 1460 Bytes and Inter Arrival Time set to
1168µs.

Transport Protocol is set to UDP instead of TCP.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 10 Mbps. Generation Rate can be calculated using the formula:

Similarly, two more CBR applications are generated.

Step 8: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

Sample2: The following changes in settings are done from the previous sample:

Step 1: Before we start designing the network scenario, the Grid Length is set to 1000 meters. This can be set by choosing the Menu Option Settings > Grid/ Map >
Grid from the GUI.

Step 2: From the previous sample, we have removed App2 CBR (i.e. from Wired Node1 to Wireless Node7), set distance between the other 2 Access Points (AP 1 and

AP 3) as 400m and distance between APs and Wireless nodes as 10m as shown below Figure 14‑3.

Figure 14‑3: Multiple APs-WiFi Networks with APs on same Channel Sample 2

Step 3: The device positions are set according to the table given below Table 14‑3.

General Properties
Device Name X / Lon Y / Lat
AP_1 400 0
AP_2 400 200
AP_3 400 400
Wireless_Node_6 410 0
Wireless_Node_7 410 200
Wireless_Node_8 410 400
Table 14‑3: Device positions for APs-STA - Sample 2

Step 4: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

Sample3: The following changes in settings are done from the previous sample:

Step 1: The distance between the Access Points (AP 1 and AP 3) is set to 400m and distance between APs and Wireless nodes as 10m as shown below Figure 14‑4.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 67/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Figure 14‑4: Multiple APs-WiFi Networks with APs on same Channel Sample 3

Step 2: The device positions are set according to the table given below Table 14‑4.

General Properties
Device Name X / Lon Y / Lat
AP_1 400 0
AP_2 400 200
AP_3 400 400
Wireless_Node_6 410 0
Wireless_Node_7 410 200
Wireless_Node_8 410 400
Table 14‑4: Device positions for APs-STA - Sample 3

Step 3: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

Sample4: The following changes in settings are done from the previous sample:

Step 1: From the previous sample, we have removed App1 CBR (i.e. from Wired Node 1 to Wireless Node 6), set distance between the other 2 Access Points (AP 2 and
AP 3) as 200m and distance between APs and Wireless nodes as 10m as shown below Figure 14‑5.

Figure 14‑5: Multiple APs-WiFi Networks with APs on same Channel Sample 4

Step 2: The device positions are set according to the table given below Table 14‑5.

General Properties
Device Name X / Lon Y / Lat
AP_1 400 0
AP_2 400 200
AP_3 400 400
Wireless_Node_6 410 0
Wireless_Node_7 410 200
Wireless_Node_8 410 400
Table 14‑5: Device positions for APs-STA - Sample 4

Step 3: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

Sample5: The following changes in settings are done from the previous sample:

Step 1: From Sample 3, we have removed first and third applications as shown below Figure 14‑6.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 68/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 14‑6: Multiple APs-WiFi Networks with APs on same Channel Sample 5

Step 2: The device positions are set according to the table given below Table 14‑6.

General Properties
Device Name X / Lon Y / Lat
AP_1 400 0
AP_2 400 200
AP_3 400 400
Wireless_Node_6 410 0
Wireless_Node_7 410 200
Wireless_Node_8 410 400
Table 14‑6: Device positions for APs-STA - Sample 5

Step 3: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

APs in different channel:

The following changes in settings are done from the previous sample:

Step 1: From Sample 3, we have changed standard channel to 11_2462 under INTERFACE (WIRELESS) > DATALINK LAYER Properties of AP 2.

Step 2: Plots are enabled in NetSim GUI. Run the Simulation for 10 Seconds and note down the throughput.

14.3 Output
After running simulation, check throughput in Application metrics as shown in the below screenshot Figure 14‑7.

Figure 14‑7: Application Metrics Table in Result window

Throughput (Mbps)
Sample
AP_1 AP_2 AP_3
All APs on the same channel
1 2.02 2.13 2.01
2 5.94 N/A 5.92
3 5.42 0.63 5.41
4 N/A 3.29 3.26
5 N/A 5.92 N/A
Each AP on a different nonoverlapping channel
1 5.94 5.92 5.92

Table 14‑7: Throughput for APs on same and different Channels

NOTE:Please refer “Wi-Fi UDP Download Throughput” experiment for theoretical WLAN throughput calculations in NetSim Experiment Manual.

14.4 Discussion

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 69/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
We recall that each AP is associated with one station (STA; e.g., a laptop). All the APs are connected to the same server which is sending separate UDP packet streams
to each of the STAs via the corresponding AP. The packet transmission rate from the server is large enough so that the AP queue in permanently backlogged, i.e., the

rate at which the server transmits packets is larger than the rate at which the AP can empty the packet queue.

14.4.1 All APs on the same channel

Case 1: All the APs and their associated STAs are close together, so that all devices (APs and STAs) can sense every other device.

§ The table shows that all the AP-STA links achieve the same UDP throughput. This is because all the AP-STA links are equivalent (since all interfere with each
other), and only one can be active at one time. The throughput for this scenario can be predicted from the analysis in Section 7.4 of the book Wireless Networking
by Anurag Kumar, D. Manjunath and Joy Kuri

Case 2: AP1 and AP3 are close to their associated STAs but are 400m apart. The link from AP2 to its STA is half-way between the other two APs, and is not carrying any
traffic.

§ The table shows that both the links from AP1 and AP3 to their respective STAs carry the same throughput, of 5.94Mbps and 5.92Mbps. These are also the

throughputs that each link would have if the other was not present, indicating that the two links are far enough apart that they do not interfere.

Case 3: This is the same scenario as Case 2, but the AP2-STA link is now carrying traffic

§ We find that, in comparison with Case2, the AP1-STA and AP3-STA carry slightly lower throughputs of about 5.4Mbps, whereas the AP2-STA link carries a small

throughput of 0.63Mbps. Comparing Cases 1 and 3 we conclude that in these networks there can be severe unfairness depending on the relative placement of
the AP-STA links. In Case 1, all the links could sense each other, and each got a fair chance. In Case 3, we have what is called the “link-in-the-middle problem.”
The AP2-STA link is close enough to interfere with the AP1-STA link and the AP3-STA link, whereas the AP1-STA link and the AP3-STA link do not “see” each

other. The AP2-STA link competes with the links on either side, whereas the other links compete only with the link in the centre, which thereby gets suppressed in
favour of the outer links.

Case 4: Here we stop the traffic to AP1 but send the traffic to the AP2-STA link and the AP3-STA link.

§ The two active links interfere with each other, but the situation is symmetric between them (unlike in Case 3), and they obtain equal throughput. Again, the
throughput obtained by these two links can be predicted by the analysis mentioned earlier in this section.

Case 5: Now we send traffic only to AP2

§ The throughput is now 5.92Mbps, since the AP2-STA link can transmit without interference; there are no collisions. The reason that this throughput is less than the
sum of the two throughputs in Case 4 is that the single link acting by itself, with all the attendant overheads, is unable to occupy the channel fully.

14.4.2 Each AP on a different nonoverlapping channel

There is only one case here. Having observed the various situations that arose in the previous subsection when all the APs are on the same channel, now we consider
the case where all the AP-STA pairs are each on a different nonoverlapping channel. As expected, every AP-STA pair gets the same throughput as when they are alone
on the network.

15 Plot the characteristic curve of throughput versus offered traffic for a Pure
and Slotted ALOHA system
NOTE: NetSim Academic supports a maximum of 100 nodes and hence this experiment can only be done partially with NetSim Academic. NetSim Standard/Pro would be required to simulate

all the configurations.

15.1 Theory

ALOHA provides a wireless data network. It is a multiple access protocol (this protocol is for allocating a multiple access channel). There are two main versions of

ALOHA: pure and slotted. They differ with respect to whether or not time is divided up into discrete slots into which all frames must fit.

15.1.1 Pure ALOHA

In pure Aloha, time is continuous. In Pure ALOHA, users transmit whenever they have data to be sent. There will be collisions and the colliding frames will be damaged.
Senders need some way to find out if this is the case. If the frame was destroyed, the sender just waits a random amount of time and sends it again. The waiting time

must be random or the same frames will collide over and over, in lockstep. Systems in which multiple users share a common channel in a way that can lead to conflicts
are known as contention systems.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 70/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

The probability of no other traffic being initiated during the entire vulnerable period is given by which leads to S= where, S (frames per frame time) is the
mean of the Poisson distribution with which frames are being generated. For reasonable throughput S should lie between 0 and 0.5.

G is the mean of the Poisson distribution followed by the transmission attempts per frame time, old and new combined. Old frames mean those frames that have
previously suffered collisions.

The maximum throughput occurs at G = 0.5, with S = 1/2e, which is about 0.184. In other words, the best we can hope for is a channel utilization of 18%.This result is

not very encouraging, but with everyone transmitting at will, we could hardly have expected a 100% success rate.

15.1.2 Slotted ALOHA

In slotted Aloha, time is divided up into discrete intervals, each interval corresponding to one frame. In Slotted ALOHA, a computer is required to wait for the beginning of

the next slot in order to send the next packet. The probability of no other traffic being initiated during the entire vulnerable period is given by which leads to S =

where, S (frames per frame time) is the mean of the Poisson distribution with which frames are being generated. For reasonable throughput S should lie
between 0 and 1.

G is the mean of the Poisson distribution followed by the transmission attempts per frame time, old and new combined. Old frames mean those frames that have
previously suffered collisions.

It is easy to note that Slotted ALOHA peaks at G = 1, with a throughput of or about 0.368.

15.2 Calculations used in NetSim to obtain the plot between S and G

Using NetSim, the attempts per packet time (G) can be calculated as follows;

Where, G = Attempts per packet time

ST = Simulation time (in second)

The throughput (in Mbps) per packet time can be obtained as follows:

Where, S = Throughput per packet time

ST = Simulation time (in second)

In the following experiment, we have taken packet size=1460 (Data Size) + 28 (Overheads) = 1488 bytes.

Bandwidth is 10 Mbps and hence, packet time comes as 1.2 milliseconds.

(Reference: A good reference for this topic is Section 4.2.1: ALOHA, of the book, Computer Networking, 5th Edition by Tanenbaum and Wetherall)

15.3 Network Set Up

Part-1 Slotted aloha

Open NetSim and click Examples > Experiments > Throughput-versus-load-for-Pure-and-Slotted-Aloha as shown below Figure 15‑1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 71/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 15‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 15‑2.

Figure 15‑2: Network topology for Pure aloha experiment

Sample Inputs

Input for Sample 1:

Step 1: Drop 10 nodes (i.e. 9 Nodes are generating traffic.)

Node 2, 3, 4, 5, 6, 7, 8, 9, and 10 generates traffic. The properties of Nodes 2, 3, 4, 5, 6, 7, 8, 9, and 10 which transmits data to Node 1 are given in the below table.

Step 2: Wireless Node Properties:

Wireless Node Properties

Interface1_Wireless (PHYSICAL_LAYER)
Data Rate (Mbps) 10
Interface1_Wireless (DATALINK_LAYER)
Retry_Limit 0
MAC_Buffer FALSE
Slot Length(µs) 1200
Table 15‑1: Wireless Node Properties

(Note: Slot Length(µs) parameter present only in Slotted Aloha à Wireless Node Properties à Interface_1 (Wireless))

Step 3: In Adhoc Link Properties, channel characteristics is set as No Path Loss.

Step 4: Application Properties:

§ Right click on the Application Flow “App1 CUSTOM” and select Properties or click on the Application icon present in the top ribbon/toolbar. The properties are set
according to the values given in the below Table 15‑2.

Application_1 Properties
Application Method Unicast
Application Type Custom
Source_Id 2
Destination_Id 1
Transport Protocol UDP
Packet Size Distribution Constant

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 72/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Value (Bytes) 1460
Distribution Exponential
Inter Arrival Time
Packet Inter Arrival Time (µs) 200000

Table 15‑2: For Application_1 Properties

§ Similarly create 8 more application, i.e. Source_Id as 3, 4, 5, 6, 7, 8, 9 and Destination_Id as 1, set Packet Size and Inter Arrival Time as shown in above table.

Step 5: Plots are enabled in NetSim GUI.

Step 6: Simulation Time- 10 Seconds

Note: Obtain the values of Total Number of Packets Transmitted and Collided from the results window of NetSim.

Input for Sample2:

Step 1: Drop 20 nodes (i.e. 19 Nodes are generating traffic.)

Nodes 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, and 20 transmit data to Node 1.

Continue the experiment by increasing the number of nodes generating traffic as 29, 39, 49, 59, 69, 79, 89, 99, 109, 119, 129, 139, 149, 159, 169, 179, 189 and 199
nodes.

Part-2 - Slotted Aloha

Input for Sample1:
Step 1: Drop 20 nodes (i.e. 19 Nodes are generating traffic.)

Nodes 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, and 20 transmit data to Node 1 and set properties for nodes and application as mentioned above.

Continue the experiment by increasing the number of nodes generating traffic as 39, 59, 79, 99, 119, 139, 159, 179, 199, 219, 239, 259, 279, 299, 319, 339, 359, 379,
and 399 nodes.

15.4 Output
Comparison Table: The values of Total Number of Packets Transmitted and Collided obtained from the network statistics after running NetSim simulation are provided

in the table below along with Throughput per packet time& Number of Packets Transmitted per packet time

Pure Aloha

Total number
of Packets Packets per
Number of Total Number of
Total number of Success Throughput packet time
nodes number of Packets
Packets (Packets per packet theoretical
generating Packets Transmitted per
Transmitted Transmitted- time(G)
traffic Collided packet time(S)
Packets (S = )

Collided)

9 494 60 434 0.05928 0.05208 0.05265

19 978 187 791 0.11736 0.09492 0.09281
29 1482 415 1067 0.17784 0.12804 0.12461
39 1991 700 1291 0.23892 0.15492 0.14816
49 2443 1056 1387 0.29316 0.16644 0.16311
59 2907 1429 1478 0.34884 0.17736 0.17363
69 3434 1874 1560 0.4122 0.19212 0.18075
79 3964 2377 1587 0.47568 0.19044 0.18371
89 4468 2909 1559 0.53616 0.18792 0.18348
99 4998 3468 1530 0.59976 0.1836 0.18073
109 5538 4073 1465 0.66456 0.1758 0.17592
119 6023 4574 1449 0.72276 0.17388 0.1703
129 6503 5102 1401 0.78036 0.16812 0.16386
139 6992 5650 1342 0.83904 0.16104 0.15668
149 7481 6208 1273 0.89772 0.15276 0.14907
159 7998 6787 1211 0.95976 0.14532 0.14078
169 8507 7341 1166 1.02084 0.13992 0.13252
179 9008 7924 1084 1.08096 0.13008 0.12442

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 73/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
189 9486 8483 1003 1.13832 0.12036 0.11682
199 10025 9093 932 1.203 0.11184 0.10848
Table 15‑3: Total No. of Packets Transmitted and Collided obtained from the network, Throughput per packet time& Number of Packets Transmitted per packet time etc for Pure Aloha

Slotted Aloha
Total number
Total of Packets Number of Packets per
Number of Total
number Success Throughput Packets packet time
nodes number of
of (Packets per packet Transmitted theoretical
generating Packets
Packets Transmitted- time(G) per packet
traffic Transmitted
Collided Packets time(S) (S = )

Collided)

19 974 111 863 0.11688 0.10356 0.10399

39 1981 407 1574 0.23772 0.18888 0.18742
59 2893 891 2002 0.34716 0.24024 0.24534
79 3946 1504 2442 0.47352 0.29304 0.29491
99 4976 2286 2690 0.59712 0.3228 0.32865
119 5996 3144 2852 0.71952 0.34224 0.3504
139 6961 3999 2962 0.83532 0.35544 0.36231
159 7967 4974 2993 0.95652 0.35904 0.36752
179 8969 5994 2975 1.07628 0.357 0.36686
199 9983 7042 2941 1.19796 0.35292 0.36156
219 10926 8011 2915 1.31112 0.3498 0.35337
239 11928 9073 2855 1.43136 0.3426 0.34207
259 12969 10224 2745 1.55628 0.3294 0.32825
279 13916 11266 2650 1.66992 0.318 0.31438
299 14945 12430 2515 1.7934 0.3018 0.29841
319 15967 13592 2375 1.91604 0.285 0.28202
339 17011 14765 2246 2.04132 0.26952 0.26508
359 17977 15895 2082 2.15724 0.24984 0.24947
379 18983 17010 1973 2.27796 0.23676 0.23348
399 19987 18146 1841 2.39844 0.22092 0.21792
Table 15‑4: Total No. of Packets Transmitted and Collided obtained from the network, Throughput per packet time& Number of Packets Transmitted per packet time etc for Slotted Aloha

Thus, the following characteristic plot for the Pure ALOHA and Slotted ALOHA is obtained, which matches the theoretical results.

Figure 15‑3: Throughput per packet time vs. Packet Transmitted per packet time

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 74/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 15‑4: Throughput per packet time vs Packet Transmitted per packet time

16 Study the working and routing table formation of Interior routing

protocols, i.e. Routing Information Protocol (RIP) and Open Shortest Path

First (OSPF)
16.1 Introduction
16.1.1 RIP

RIP is intended to allow hosts and gateways to exchange information for computing routes through an IP-based network. RIP is a distance vector protocol which is

based on Bellman-Ford algorithm. This algorithm has been used for routing computation in the network.

Distance vector algorithms are based on the exchange of only a small amount of information using RIP messages.

Each entity (router or host) that participates in the routing protocol is assumed to keep information about all of the destinations within the system. Generally, information

about all entities connected to one network is summarized by a single entry, which describes the route to all destinations on that network. This summarization is possible
because as far as IP is concerned, routing within a network is invisible. Each entry in this routing database includes the next router to which datagram’s destined for the
entity should be sent. In addition, it includes a "metric" measuring the total distance to the entity.

Distance is a somewhat generalized concept, which may cover the time delay in getting messages to the entity, the dollar cost of sending messages to it, etc. Distance
vector algorithms get their name from the fact that it is possible to compute optimal routes when the only information exchanged is the list of these distances.
Furthermore, information is only exchanged among entities that are adjacent, that is, entities that share a common network.

16.1.2 OSPF

In OSPF, the Packets are transmitted through the shortest path between the source and destination.

OSPF allows administrator to assign a cost for passing through a link. The total cost of a particular route is equal to the sum of the costs of all links that comprise the

route. A router chooses the route with the shortest (smallest) cost.

In OSPF, each router has a link state database which is tabular representation of the topology of the network (including cost). Using Dijkstra algorithm each router finds
the shortest path between source and destination.

16.1.3 Formation of OSPF Routing Table

1. OSPF-speaking routers send Hello packets out all OSPF-enabled interfaces. If two routers sharing a common data link agree on certain parameters specified in
their respective Hello packets, they will become neighbors.

2. Adjacencies, which can be thought of as virtual point-to-point links, are formed between some neighbors. OSPF defines several network types and several router
types. The establishment of an adjacency is determined by the types of routers exchanging Hellos and the type of network over which the Hellos are exchanged.

3. Each router sends link-state advertisements (LSAs) over all adjacencies. The LSAs describe all of the router's links, or interfaces, the router's neighbors, and the

state of the links. These links might be to stub networks (networks with no other router attached), to other OSPF routers, or to external networks (networks

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 75/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
learned from another routing process). Because of the varying types of link-state information, OSPF defines multiple LSA types.

4. Each router receiving an LSA from a neighbor records the LSA in its link-state database and sends a copy of the LSA to all of its other neighbors.

5. By flooding LSAs throughout an area, all routers will build identical link-state databases.

6. When the databases are complete, each router uses the SPF algorithm to calculate a loop-free graph describing the shortest (lowest cost) path to every known
destination, with itself as the root. This graph is the SPF tree.

7. Each router builds its route table from its SPF tree

16.2 Network Setup

Open NetSim and click Examples > Experiments > Route-table-formation-in-RIP-and-OSPF > Sample-1 as shown below Figure 16‑1.

Figure 16‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 16‑2.

Figure 16‑2: Network topology for RIP/OSPF experiments

16.3 Procedure
Sample 1:

The following are the set of procedures were done to generate this sample.

Step 1: A network scenario is designed in the NetSim GUI comprising of 2 Wired Nodes, 2 L2 Switches, and 7 Routers.

Step 2: Go to Router 1 Properties. In the Application Layer, Routing Protocol is set as RIP Figure 16‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 76/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 16‑3: Application Layer Window - Routing Protocol is set as RIP

The Router Configuration Window shown above, indicates the Routing Protocol set as RIP along with its associated parameters. The “Routing Protocol” parameter is
Global. i.e. changing in Router 1 will affect all the other Routers. So, in all the Routers, the Routing Protocol is now set as RIP.

Step 3: Right click on App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar. Transport Protocol is set to UDP.

A CUSTOM Application is generated from Wired Node 10 i.e. Source to Wired Node 11 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time
remaining 20000µs.

Step 4: Packet Trace is enabled, and hence we are able to track the route which the packets have chosen to reach the destination based on the Routing Information
Protocol that is set.

Step 5: Enable the plots and run the Simulation for 100 Seconds.

Sample 2:

The following are the set of procedures that are followed to carry out this experiment.

Step 1: A network scenario is designed in the NetSim GUI comprising of 2 Wired Nodes, 2 L2 Switches, and 7 Routers.

Step 2: Go to Router 1 Properties. In the Application Layer, Routing Protocol is set as OSPF Figure 16‑4.

Figure 16‑4: Application Layer Window - Routing Protocol is set as OSPF

The Router Configuration Window shown above, indicates the Routing Protocol set as OSPF along with its associated parameters. The “Routing Protocol” parameter is
Global. i.e. changing in Router 1 will affect all the other Routers. So, in all the Routers, the Routing Protocol is now set as OSPF.

Step 3: Right click on App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar. Transport Protocol is set to UDP.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 77/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Step 4: Go to Router 7 Properties. In both the WAN Interfaces, the Output Cost is set to 2000 Figure 16‑5.

Figure 16‑5: WAN Interfaces - Output Cost is set to 2000

The “Output Cost” parameter in the WAN Interface > Application Layer of a router indicates the cost of sending a data packet on that interface and is expressed in the
link state metric.

Step 5: Right click on App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from Wired Node 10 i.e. Source to Wired Node 11 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time
remaining 20000µs.

Additionally, the “Start Time (s)” parameter is set to 40, while configuring the application. This time is usually set to be greater than the time taken for OSPF
Convergence (i.e. Exchange of OSPF information between all the routers), and it increases as the size of the network increases.

Step 6: Packet Trace is enabled, and hence we are able to track the route which the packets have chosen to reach the destination based on the Open Shortest Path

First Routing Protocol that is set.

Step 7: Enable the plots and run the Simulation for 100 Seconds.

16.4 Output I
Go to NetSim Packet Animation window and play the animation. The route taken by the packets to reach the destination can be seen in the animation as well as in the
below table containing various fields of packet information as shown below Figure 16‑6.

Figure 16‑6: Animation window for RIP

Users can view the same in Packet Trace.

Shortest Path from Wired Node 10 to Wired Node 11 in RIP is Wired Node 10->L2 Switch 8->Router 1->Router 7->Router 6->L2 Switch 9->Wired Node 11. RIP
chooses the lower path (number of hops is less) to forward packets from source to destination, since it is based on hop count.

16.5 Output II

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 78/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Go to NetSim Packet Animation window and play the animation. The route taken by the packets to reach the destination can be seen in the animation as well as in the
below table containing various fields of packet information as shown below Figure 16‑7.

Figure 16‑7: Animation window for OSPF

Users can view the same in Packet Trace.

Shortest Path from Wired Node 10 to Wired Node 11 in OSPF (Use Packet Animation to view) Wired Node 10->L2 Switch 8->Router 1->Router 2->Router 3->Router

4->Router 5->Router 6->L2 Switch 9->Wired Node 11. OSPF chooses the above path (cost is less-5) since OSPF is based on cost.

16.6 Inference
16.6.1 RIP

In Distance vector routing, each router periodically shares its knowledge about the entire network with its neighbors. The three keys for understanding the algorithm,

1. Knowledge About The Whole Network - Router sends all of its collected knowledge about the network to its neighbors.

2. Routing Only To Neighbors - Each router periodically sends its knowledge about the network only to those routers to which it has direct links. It sends whatever
knowledge it has about the whole network through all of its ports. This information is received and kept by each neighboring router and used to update it’s own
information about the network.

3. Information Sharing At Regular Intervals - For example, every 30 seconds, each router sends its information about the whole network to its neighbors. This sharing
occurs whether or not the network has changed since the last time, information was exchanged

In NetSim the Routing Table Formation has 3 stages,

1. Initial Table: The Initial Table will show the direct connections made by each Router.

2. Intermediate Table: The Intermediate Table will have the updates of the Network in every 30 seconds

3. Final Table: The Final Table is formed when there is no update in the Network.

The data should be forwarded using Routing Table with the shortest distance.

16.6.2 OSPF

The main operation of the OSPF protocol occurs in the following consecutive stages, and leads to the convergence of the internetworks:

1. Compiling the LSDB.

2. Calculating the Shortest Path First (SPF) Tree.

3. Creating the routing table entries.

Compiling the LSDB

The LSDB is a database of all OSPF router LSAs. The LSDB is compiled by an ongoing exchange of LSAs between neighboring routers so that each router is
synchronized with its neighbor. When the Network converged, all routers have the appropriate entries in their LSDB.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 79/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Calculating the SPF Tree Using Dijkstra's Algorithm

Once the LSDB is compiled, each OSPF router performs a least cost path calculation called the Dijkstra algorithm on the information in the LSDB and creates a tree of

shortest paths to each other router and network with themselves as the root. This tree is known as the SPF Tree and contains a single, least cost path to each router and
in the Network. The least cost path calculation is performed by each router with itself as the root of the tree

Calculating the Routing Table Entries from the SPF Tree

The OSPF routing table entries are created from the SPF tree and a single entry for each network in the AS is produced. The metric for the routing table entry is the
OSPF-calculated cost, not a hop count.

If the application start time isn't changed then,

1. Packets generated before OSPF table convergence may be dropped at the gateway router.

2. The application may also stop if ICMP is enabled in the router

3. If TCP is enabled TCP may stop after the re-try limit is reached (since the SYN packets would not reach the destination)

NOTE: The device / link numbering and IP Address setting in NetSim is based on order in which in the devices are dragged & dropped, and the order in which links are connected. Hence if the

order in which a user executes these tasks is different from what is shown in the screen shots, users would notice different tables from what is shown in the screen shots.

17 M/D/1 and M/G/1 Queues

17.1 Motivation
In this simulation experiment, we will study a model that is important to understand the queuing and delay phenomena in packet communication links. Let us consider
the network shown in Figure 17‑1. Wired_Node_1 is transmitting UDP packets to Wired_Node_2 through a router. Link 1 and Link 2 are of speed 10 Mbps. The packet

lengths are 1250 bytes plus a 54 byte header, so that the time taken to transmit a packet on each 10 Mbps link is sec =1043.2 sec. In this setting, we would like

answers to the following questions:

1. We notice that the maximum rate at which these packets can be carried on a 10 Mbps link is packets per second. Can the UDP application send
packets at this rate?

2. The time taken for a UDP packet to traverse the two links is sec. Is this the time it actually takes for a UDP packet generated at
Wired_Node_1 to reach Wired_Node_2.

The answer to these questions depends on the manner in which the UDP packets are being generated at Wired_Node_1. If the UDP packets are generated at intervals

of 1043.2 sec then successive packets will enter the Link 1, just when the previous packet departs. In practice, however, the UDP packets will be generated by a live
voice or video source. Depending on the voice activity, the activity in the video scene, and the coding being used for the voice and the video, the rate of generation of
UDP packets will vary with time. Suppose two packets were generated during the time that one packet is sent out on Link 1, then one will have to wait, giving rise to

queue formation. This also underlines the need for a buffer to be placed before each link; a buffer is just some dynamic random-access memory in the link interface card
into which packets can be stored while waiting for the link to free up.

Queuing models permit us to understand the phenomenon of mismatch between the service rate (e.g., the rate at which the link can send out packets) and the rate at

which packets arrive. In the network in Figure 17‑1, looking at the UDP flow from Wired_Node_1 to Wired_Node_2, via Router 1, there are two places at which queueing
can occur. At the interface between Wired_Node_1 and Link 1, and at the interface between Router 1 and Link 2. Since the only flow of packets is from Wired_Node_1 to
Wired_Node_2, all the packets entering Link 2 are from Link 1, and these are both of the same bit rate. Link 2, therefore, cannot receive packets faster than it can serve

them and, at any time, only the packet currently in transmission will be at Link 2. On the other hand at the Wired_Node_1 to Link 1 interface, the packets are generated
directly by the application, which can be at arbitrary rates, or inter-packet times.

Suppose that, at Wired_Node_1, the application generates the successive packets such that the time intervals between the successive packets being generated are

statistically independent, and the probability distribution of the time intervals has a negative exponential density, i.e., of the form where (packets per second) is

a parameter, called the rate parameter, and (seconds) is the argument of the density. The application generates the entire packet instantaneously, i.e., all the bits of the
packet arrive from the application together, and enter the buffer at Link 1, to wait behind the other packets, in a first-in-first-out manner. The resulting random process of

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 80/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

the points at which packets enter the buffer of Link 1 is called a Poisson Process of rate packets per second. The buffer queues the packets while Link 1 serves them

with service time sec. Such a queue is called an M/D/1 queue, where the notation is to be read as follows

§ The M before the first slash (denoting “Markov”) denotes the Poisson Process of instants at which packets enter the buffer

§ The D between the two slashes (denoting “Deterministic”) denotes the fixed time taken to serve each queued packet

§ The 1 after the second slash denotes that there is just a single server (Link 1 in our example)

This way of describing a single server queueing system is called Kendall’s Notation.

In this experiment, we will understand the M/D/1 model by simulating the above described network on NetSim. The M/D/1 queueing model, however, is simple enough
that it can be mathematically analysed in substantial detail. We will summarise the results of this analysis in the next section. The simulation results from NetSim will be

compared with the analytical results.

17.2 Mathematical Analysis of the M/D/1 Queue

The M/D/1 queueing system has a random number of arrivals during any time interval. Therefore, the number of packets waiting at the buffer is also random. It is
possible to mathematically analyse the random process of the number of waiting packets. The procedure for carrying out such analysis is, however, beyond the scope of
this document. We provide the final formulas so that the simulation results from NetSim can be compared with those provided by these formulas.

As described earlier, in this chapter, the M/D/1 queue is characterized by two parameters: (packets per second), which is the arrival rate of packets into the buffer, and

(packets per second), which is the rate at which packets are removed from a nonempty queue. Note that is the service time of each packet.

Define . We note that is the average number of packets that arrive during the service time of a packet. Intuitively, it can be expected that if then

packets arrive faster than the rate at which they can be served, and the queue of packets can be expected grow without bound. When we can expect the queue to

be “stable.” When , the service rate is exactly matched with the arrival rate; due to the randomness, however, the queue can still grown without bound. The details
of this case are beyond the scope of this document.

For the arriving packet, denote the instant of arrival by the instant at which service for this packet starts as and the instant at which the packet leaves the

system as Clearly, for all the deterministic service time. Further define, for each

i.e., is called the queuing delay, i.e., time from the arrival of the packet until it starts getting transmitted, whereas is called the total delay, i.e., the time from the

arrival of the packet until its transmission is completed. Considering a large number of packets, we are interested in the average of the values i.e., the

average queueing time of the packets. Denote this average by . By mathematical analysis of the packet queue process, it can be shown that for an M/D/1 queueing
system,

Denoting by the average total time in the system (i.e., the average of ), clearly

Observe the following from the above formula:

1. As approaches 0, becomes 0. This is clear, since, when the arrival rate becomes very small, and arriving packet sees a very small queue. For arrival rate

approaching 0, packets get served immediately on arrival.

2. As increases, inreases.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 81/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

3. As approaches 1 (from values smaller than 1), the mean delay goes to

We will verify these observations in the NetSim simulation.

17.3 The Experimental Setup

The model described at the beginning of this chapter is shown in Figure 17‑1.

Figure 17‑1: A single wired node (Wired_Node_1) sending UDP packets to another wired node (Wired_Node_2) through a router (Router 3). The packet interarrival times at
Wired_Node_1 are exponentially distributed, and packets are all of the same length, i.e., 1250 bytes plus UDP/IP header.

Open NetSim and Click on Examples > Experiments > MD1-and-MG1-Queues > Sample-1 as shown below Figure 17‑2.

Figure 17‑2: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown above:

17.4 Procedure

Sample 1:

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 1 Router in the “Internetworks” Network Library.

Step 2: Link Properties are set as per the table given below Table 17‑1.

Link Properties Link 1 Link 2

Uplink Speed (Mbps) 10 10
Downlink Speed (Mbps) 10 10
Uplink BER 0 0
Downlink BER 0 0
Uplink Propagation Delay (μs) 0 0
Downlink Propagation Delay (μs) 0 0

Table 17‑1: Wired link properties

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 82/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Step 3: Right click on the Application Flow App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination. Transport Protocol is set to UDP with Packet Size set to 1250 Bytes

and Inter Arrival Time set to 20863 µs and distribution to Exponential.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 0.096 Mbps. Generation Rate can be calculated using the formula:

Step 4: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the packet information is available for the users to
perform packet level analysis.

Step 5: Plots are enabled in NetSim GUI. Run the Simulation for 100 Seconds.

Similarly, the other samples are created by changing the Inter Arrival Time per the formula

as per the table given below Table 17‑2.

Ρ
IAT
0.05 20863
0.1 10431
0.15 6954
0.2 5215
0.25 4172
0.3 3477
0.35 2980
0.4 2607
0.45 2318
0.5 2086
0.55 1896
0.6 1738
0.65 1604
0.7 1490
0.75 1390
0.8 1303
0.85 1227
0.9 1159
0.95 1098
Table 17‑2: Inter Arrival Time Settings

Even though the packet size at the application layer is 1250 bytes, as the packet moves down the layers, overhead is added. The overheads added in different layers are
shown in the below table and can be obtained from the packet trace:

Layer Overhead (Bytes)

Transport Layer 8
Network Layer 20
MAC layer 26
Physical Layer 0
Total 54
Table 17‑3: Overheads added to a packet as it flows down the network stack

17.5 Obtaining the Mean Queuing delay from the Simulation Output
After running the simulation, note down the “Mean Delay” in the Application Metrics within the Results Dashboard. This is the average time between the arrival of

packets into the buffer at Wired_Node_1, and their reception at Wired_Node_2.

As explained in the beginning of this chapter, for the network shown in Figure 17‑1, the end-to-end delay of a packet is the sum of the queueing delay at the buffer
between the wired-node and Link_1, the transmission time on Link_1, and the transmission time on Link_2 (there being no queueing delay between the Router and

Link_2). It follows that

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 83/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

17.6 Output Table

Sample ρ
Mean Delay Queuing Delay ( (Simulation)
Queuing Delay (Theory)
1 0.05 47.93 2112.87 26.47 27.45
2 0.10 95.86 2144.01 57.61 57.96
3 0.15 143.79 2178.86 92.46 92.05
4 0.20 191.72 2218.09 131.69 130.40
5 0.25 239.65 2259.11 172.71 173.87
6 0.30 287.58 2309.49 223.09 223.54
7 0.35 335.51 2365.74 279.34 280.86
8 0.40 383.44 2435.65 349.25 347.73
9 0.45 431.37 2513.79 427.39 426.76
10 0.50 479.30 2608.38 521.98 521.60
11 0.55 527.22 2721.59 635.19 637.51
12 0.60 575.15 2864.88 778.48 782.40
13 0.65 623.08 3052.84 966.44 968.68
14 0.70 671.01 3304.58 1218.18 1217.07
15 0.75 718.94 3633.66 1547.26 1564.80
16 0.80 766.87 4160.39 2073.99 2086.40
17 0.85 814.80 5115.95 3029.55 2955.73
18 0.90 862.73 6967.16 4880.76 4694.39
19 0.95 910.66 12382.98 10296.58 9910.39
Table 17‑4: Mean Delay, Queueing delay from Simulation and Queueing delay from analysis

17.7 Advanced Topic: The M/G/1 Queue

In Section 17.1, we introduced the M/D/1 queue. Successive packets were generated instantly at exponentially distributed time intervals (i.e., at the points of a Poisson
process); this gave the “M” in the notation. The packets were all of fixed length; this gave the “D” in the notation. Such a model was motivated by the transmission of

packetized voice over a fixed bit rate wireline link. The voice samples are packetised into constant length UDP packets. For example, typically, 20ms of voice samples
would make up a packet, which would be emitted at the instant that the 20ms worth of voice samples are collected. A voice source that is a part of a conversation would
have listening periods, and “silence” periods between words and sentences. Thus, the intervals between emission instants of successive UDP packets would be

random. A simple model for these random intervals is that they are exponentially distributed, and independent from packet to packet. This, formally, is called the Poisson
point process. With exponentially distributed (and independent) inter-arrival times, and fixed length packets we obtain the M/D/1 model. On the other hand, some
applications, such as video, generate unequal length packets. Video frames could be encoded into packets. To reduce the number of bits being transmitted, if there is not

much change in a frame, as compared to the previous one, then the frame is encoded into a small number of bits; on the other hand if there is a large change then a
large number of bits would need to be used to encode the new information in the frame. This motivates variable packet sizes. Let us suppose that, from such an

application, the packets arrive at the points of a Poisson process of rate , and that the randomly varying packet transmission times can be modelled as independent and

identically distributed random variables, with mean and second moment , i.e., variance Such a model is denoted by M/G/1, where M
denotes the Poisson arrival process, and G (“general”) the “generally” distributed service times. Recall the notation M/D/1 (from earlier in this section), where the D
denoted fixed (or “deterministic”) service times. Evidently, the M/D/1 model is a special case of the M/G/1 model.

Again, as defined earlier in this section, let denote the mean queueing delay in the M/G/1 system. Mathematical analysis of the M/G/1 queue yields the following

formula for

where, as before, This formula is called the Pollacek-Khinchine formula or P-K formula, after the researchers who first obtained it. Denoting the variance of the

service time by the P-K formula can also be written as

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 84/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Applying this formula to the M/D/1 queue, we have Substituting this in the M/G/1 formula, we obtain

which, with , is exactly the M/D/1 mean queuing delay formula displayed earlier in this section.

17.8 A NetSim Exercise Utilising the M/G/1 Queue

In this section we demonstrate the use of the M/G/1 queueing model in the context of the network setup shown in Figure 17‑1. The application generates exponentially

distributed data segment with mean bits, i.e., successive data segment lengths are sampled independently from an exponential distribution with rate parameter . Note
that, since packets are integer multiples of bits, the exponential distribution will only serve as an approximation. These data segments are then packetised by adding a

constant length header of length bits. The packet generation instants form a Poisson process of rate Let us denote the link speed by Let us denote the random
data segment length by X and the packet transmission time by B, so that

Denoting the mean of by , we have

Further, since is a constant,

These can now be substituted in the P-K formula to obtain the mean delay in the buffer between Node 1 and Link 1.

We set the mean packet size to 100B or 800 bits, the header length = 54B or 432 bits and 5000

For a 10Mbps link, the service rate

Using the Pollaczek–Khinchine (PK) formula, the waiting time for a M/G/1 queuing system is

Where is the variance of the service time distribution S. Note that

where is the mean service time of the exponential random variable (100B packets and not 154B)

Hence substituting into the PK formula, one gets

By simulation the queuing delay is 60.5 .

The queuing delay is not available in the NetSim results dashboard. It can be got from the packet trace. It is the average of (PHY_layer_Arrival_time - APP_layer_arrival
time) for packets being sent from Node_1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 85/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

18 Wi-Fi Multimedia Extension (IEEE 802.11 EDCA)

18.1 Introduction
In this experiment, we will study an enhancement to WiFi that enables APs and STAs to handle various packet flows in such a way so as to provide differentiated quality

of service (QoS) to these flows. In the original WiFi standard (IEEE 802.11 DCF), every device in the network has one output buffer (queue) for all packets to be
transmitted onto the wireless channel. The consequence of this would be that a packet stream with strict delivery constraints and another will relatively loose delivery
objectives are queued in the same output buffer at every device. Each such queue is scheduled by the DCF CSMA/CA (see the experiment “WiFi: UDP Download

Throughput”), and when a queue gets its transmission opportunity the first (head-of-the-line (HOL)) packet is transmitted. This might result in packets with strict delivery
constraints being kept waiting, while other, less urgent, packets get transmitted.

For example, an interactive voice call might have 200 byte packets being transmitted periodically, with a period of 20 ms. Ideally, for perfect voice playout at the receiver,

this voice stream must arrive exactly as it was transmitted: every 200 byte packet must arrive, and with the gaps of 20 ms intact. If the voice packets are delayed
excessively, or if the delay is highly variable, the playout is affected and voice quality (and speaker interaction) is affected. On the other hand, TCP controlled file
transfers can adapt to network delay and delay variability. Evidently, the solution is to create multiple output buffers in each device, of different transmit priorities, queue

the more urgent packets in higher priority buffers, and create a mechanism for preferential transmission of the packets with tighter QoS requirements.

In this experiment we will study the EDCAF mechanism, an extension to DCF, which implements service differentiation in WiFi.

18.2 EDCAF: Access Categories

In the year 2005, the standard IEEE 802.11e (EDCAF-Enhanced Distributed Channel Access Function) was introduced, with the above issues in mind. In EDCAF, there
are four Access Categories (AC0, AC1, AC2, and AC3), with AC3 being the highest priority and AC0 being the lowest. The assignment of application usage to these ACs

was.

Access Category Application Example

AC0 Background Background print job
AC1 Best Effort TCP File Transfer
AC2 Video Video Conference Video
AC3 Voice Video Conference Voice

Table 18‑1: EDCA 4 access categories for 802.11 both AP and STA

Now, if a device (an AP or a STA) is sending interactive voice packets then these packets can be queued in the AC3 buffer of the device, whereas packets of a

simultaneous TCP file transfer can be queued in the AC1 buffer. The human brain is less sensitive to video packet losses, and delays in the rendering of video frames
(than the human hearing system is of voice corruption), hence video is given a priority between voice and TCP. The lowest category, AC0, can be used for any
application whose packets need to just be delivered, without any well-defined quality of service; for example, a low urgency bulk printing service.

Having created buffers into which the various priority packets are queued, a mechanism is needed to schedule transmissions from these buffers so that service
differentiation is achieved. Ideally, strict priority service could be enforced, i.e., assuming that there is only AC3 and AC2 traffic in the network, if any device has an
nonempty AC3 buffer, all packets from AC3 category should be served before any AC2 traffic is served. Further, ideally, the video and the TCP file transfers could have

been assigned a guaranteed service rate, to meet their QoS requirements. Such strict priorities and guaranteed service would belong to the concept of Integrated
Services. However, the IEEE 802.11 wireless access mechanism is distributed, and there is no central entity that has the instantaneous state of all the buffers in all the
devices. Hence, strict priority or a guaranteed service rate is not possible to. Instead, the IEEE 802.11 series of standards adopted EDCAF (an extension to DCF) for

scheduling the service of the access category queues at the contending devices. The EDCAF mechanism achieves Differentiated Services. How does the MAC layer in
a device know which access category buffer to queue a packet in? This is achieved by the corresponding application using the DSCP (Differentiated Service Code Point)
field in the IPV4 header to indicate the Differentiated Services class of the packet. The MAC layer of the device would have a table that maps the DSCP value to the

access category.

18.3 EDCAF: Service Differentiation Mechanisms

We begin by recalling how the basic EDCF works, since EDCAF is built as an extension of EDCF. In EDCF, after handling the HOL packet in its (single) buffer (which
could result in the packet being transmitted successfully or discarded (due to exceeding the maximum number of reattempts)), a device waits for DIFS, samples an initial
back-off for the next packet in the buffer, and begins to count down (at slot boundaries) until the back-off counter reaches zero, at which instant the first attempt for the

next packet is made. A collision leads to a new back-off being sampled from a distribution with a larger mean. All nodes behave in exactly the same manner, thus getting
opportunities to transmit packets whenever their back-off counters reach zero. Thus, all devices (STAs and APs) have the same behavior (statistically), and there is no
service differentiation.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 86/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Now consider an AP with AC3 packets to be transmitted (say, voice), and an STA with AC1 packets (say, TCP). After the AP transmits a voice packets, in EDCAF, the

AP’s MAC waits for AIFS3 (Arbitration Inter Frame Space for Category 3) which is 2 slots, and samples a back-off from a uniform distribution over 1 slot to slots. On

the other hand, at this point the STA waits for AIFS1, which is 3 slots. In addition, after a TCP packet has been transmitted (or dropped) the STA samples a back-off for

the next packet from a uniform distribution over 1 slot to slots. Thus, the HOL packet waiting in the AC3 buffer has two advantages over the HOL packet waiting in the
AC1 buffer:

i. The back-off counter of the AC3 category starts counting down one slot earlier than the AC1 category.

ii. The back-off counters are smaller for AC3 than for AC1.

These two mechanisms conspire to differentiate the wireless access service in favour of AC3. Note that we do not get strict priority. For example, if a voice packet has
been transmitted by the AP, and after AIFS3, the back-off sampled is 3 slots, whereas the residual back-off of the TCP transfer (at the STA) was 2 slots, then the TCP
packet will be transmitted next. However, the service differentiation is significant as the simulation results from NetSim will demonstrate later in this chapter. The following

is the table of all EDCAF parameters as specified by the standard.

Access Category CWmin CWmax AIFSN

Max TXOP ( )
Background (AC_BK) 31 1023 7 3264
Best Effort (AC_BE) 31 1023 3 3264
Video (AC_VI) 15 31 2 6016
Voice (AC_VO) 7 15 2 3264

Table 18‑2: EDCA access parameters for 802.11 b for both AP and STA

18.4 The Experimental Plan

§ Voice over DCF: We first want to understand the limitation when carrying interactive voice over DCF.

o With this in mind, we will set up several full-duplex voice calls between several STAs and the wired network, one such call for each STA. Each full-duplex
voice call will be modelled by a periodic stream of 200 byte UDP packets (160B voice plus 40B of UDP/IP headers), generated at 20 ms intervals, from

the STA to the wired network, and another such, independent stream from the wired network to the STA. We will increase the number of STAs, thereby
increasing the number full-duplex voice calls, and will determine the number of calls that can be handled.

o Then we will add on TCP controlled file transfer from the wired network to another STA. Due to reasons explained earlier in this chapter, the voice

performance should degrade, leading to fewer calls being possible to handle along with the TCP transfer.

§ Voice over EDCAF: Next we repeat the above two experiments with the EDCAF mechanism enabled. We should find that it is possible to maintain a substantial
number of voice conversations even while running the TCP file transfer. Next we will study what happens if the number of TCP file transfers is increased, the
question being whether the number of voice conversations that can be handled gets affected.

18.5 Simulation Experiments to Study IEEE 802.11 EDCAF

Open NetSim and click Examples > Experiments > Wi-Fi-WME-802-11e-QoS-EDCA as shown below Figure 18‑1.

Figure 18‑1: Experiments List

Case 1: DCF with full-duplex voice calls only

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 87/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Network Scenario

Figure 18‑2: DCF with full-duplex voice calls only

Network Setup
§ AP and STA operate in DCF.
§ There is no error in all wired and wireless links

Applications
§ Two-way UDP voice calls from Node to Wireless_Node_i, with i being incremented. Each voice call in NetSim is modelled as 2 one-way voice applications. The
voice modelling option in NetSim UI currently allows transfer in one direction only. Hence, we model a two-way voice call as 2 one-way voice applications.

o and . represent wireless node , while represents the wired node or remote host.
o Each voice call runs G.711 at 64 Kbps.
Case 2: DCF with full-duplex voice calls and a single TCP download

Network Scenario

Figure 18‑3: DCF with full-duplex voice calls and a single TCP download
Network Setup
§ AP and STA operate in DCF
§ There is no error in all wired and wireless links

Applications

§ TCP full buffer (or saturated case) download from to . The saturation is generated by using a CBR application with Packet Size of 1460 B and Inter packet

arrival time of 1000 . Since this generation rate is higher than the Wi-fi link it rate as a saturated (full buffer) TCP flow is achieved. The reason for emulating a

TCP download using a CBR session, is that a TCP file download would take a longer time to simulate.

§ Voice calls from to with being incremented. Two-way UDP voice calls from Node to Wireless_Node_i. Each voice call in NetSim is modelled as 2 one-
way voice applications

o and . represent wireless node , while represents the wired node or remote host.

o Each voice call runs G.711 at 64 Kbps.

Case 3: EDCAF with full-duplex voice calls only

Network Scenario

Figure 18‑4: EDCAF with full-duplex voice calls only

Network Setup

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 88/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ AP and STA operate in EDCAF, with EDCAF parameters set per reference paper
§ There is no error in all wired and wireless links

Applications
§ Two-way UDP voice calls from Node to Wireless_Node_i, with i being incremented. Each voice call in NetSim is modelled as 2 one-way voice applications. The
voice modelling option in NetSim UI currently allows transfer in one direction only. Hence, we model a two-way voice call as 2 one-way voice applications.

o and . represent wireless node , while represents the wired node or remote host.
o Each voice call runs G.711 at 64 Kbps.
Case 4: EDCAF with full-duplex voice calls and a single TCP download

Network Scenario

Figure 18‑5: EDCAF with full-duplex voice calls and a single TCP download
Network Setup
§ AP and STA operate in EDCAF, with EDCAF parameters set per reference paper. In the AP, TCP would be queued in AC_BE while Voice packets would be queued
in AC_VO.

§ There is no error in all wired and wireless links

Applications

§ TCP full buffer (or saturated case) download from to . The saturation is generated by using a CBR application with Packet Size of 1460 B and Inter packet

arrival time of 1000 . Since this generation rate is higher than the Wi-fi link it rate as a saturated (full buffer) TCP flow is achieved.

§ Voice calls from to with being incremented. Two-way UDP voice calls from Node to Wireless_Node_i. Each voice call in NetSim is modelled as 2 one-
way voice applications

o and . represent wireless node , while represents the wired node or remote host.
o Each voice call runs G.711 at 64 Kbps
Case 5: EDCAF with full-duplex voice calls and multiple TCP downloads

Network Scenario

Figure 18‑6: EDCAF with full-duplex voice calls and multiple TCP downloads
Network Setup
§ AP and STA operate in EDCAF mode
§ There is no error in all wired and wireless links

Applications

§ 10 TCP downloads from to through

o TCP full buffer (or saturated case) download from . The saturation is generated by using a CBR application with Packet Size of 1460 B and Inter

packet arrival time of 1000 . Since this generation rate is higher than the Wi-fi link it rate as a saturated (full buffer) TCP flow is achieved.

§ UDP Voice calls from to with i being incremented

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 89/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ Each voice call in NetSim is modelled as 2 one-way voice applications

o and . represent wireless node , while represents the wired node or remote host.

o Each G.711 at 64 Kbps.

18.6 Simulation Results

Case 1: DCF with full-duplex voice calls only

§ Tabulated separately for applications going and . represent wireless node , while represents the wired node or remote host.

§ A mean delay of 20,000 is considered as a threshold.

§ For the case this threshold is crossed at 11 calls

§ For the case this threshold is crossed at 20 calls

No of voice calls Mean Delay Mean Delay Voice

Voice
1 1181.64 1119.24
2 2417.94 1666.23
3 3737.10 2117.73
4 5089.30 2558.37
5 6433.89 3000.71
6 7808.15 3426.20
7 9159.53 3929.14
8 10544.23 4383.35
9 12026.21 4851.28
10 13879.48 5459.24
11 4571867.59 6308.80
12 12197132.38 6889.13
13 18832275.60 7408.73
14 24246265.61 8200.14
15 29106781.12 9032.72
16 33825893.09 10071.78
17 37129900.58 11548.87
18 40666670.30 14032.98
19 43206845.02 16694.24
20 45890755.08 28593.24
21 45778456.09 74205.13
22 45570258.85 1517955.44

Table 18‑3: DCF with full-duplex voice calls only and

* Mean Delay Voice = Average of delay of all the applications going

Case 2: DCF with full-duplex voice calls and single TCP download

§ Tabulated separately for applications going and . represent wireless node , while represents the wired node or remote host.

§ A mean delay of 20,000 is considered as a threshold.

§ For the case this threshold is crossed at 1 call itself

Mean Delay Mean Delay
No of TCP No of voice Voice Voice
Connections calls

1 95704.39 2977.85
1
2 140275.69 3320.34

Table 18‑4: DCF with full-duplex voice calls and single TCP download and

Case 3: EDCAF with full-duplex voice calls

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 90/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

§ Tabulated separately for applications going and . represent wireless node , while represents the wired node or remote host.

§ A mean delay of 20,000 is considered as a threshold.

§ For the case this threshold is crossed at 13 calls

§ For the case this threshold is crossed at 21 calls

No of voice calls Mean Delay Mean Delay Voice

Voice
1 1000.70 704.67
2 1720.33 1575.46
3 2460.83 2464.80
4 3231.18 3356.51
5 4084.78 4274.84
6 5092.33 5068.09
7 5985.39 5936.53
8 7083.65 6648.27
9 8193.41 7373.58
10 9226.28 8115.11
11 10508.87 8671.12
12 11697.42 9477.25
13 460068.57 12297.35
14 495197.84 12778.37
15 498731.77 13294.44
16 499873.05 13932.10
17 498605.48 14600.35
18 497835.90 15401.32
19 494160.35 16329.19
20 488004.13 17798.12
21 492066.02 20362.62

Table 18‑5: EDCAF with full-duplex voice calls and

Case 4: EDCAF with full-duplex voice calls and single TCP download

§ Tabulated separately for applications going and . represent wireless node , while represents the wired node or remote host.

§ A mean delay of 20,000 is considered as a threshold.

§ For the case this threshold is crossed at 13 calls

No of TCP No of Voice Mean Delay Mean Delay
Connections calls Voice Voice

1 1643.79 1846.09
2 2556.46 2877.60
3 3384.93 3735.75
1 4 4245.55 4614.23
5 5240.15 5456.84
6 6392.43 6221.13
7 7495.18 6921.69
8 8587.71 7605.80
9 9706.95 8334.68
10 10905.77 9004.00
11 12372.39 9759.22
12 18327.87 11032.25
13 485918.40 12289.42
14 495651.53 12800.99

Table 18‑6: EDCAF with full-duplex voice calls and single TCP download and

Case 5: EDCAF with full-duplex voice calls and multiple TCP downloads

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 91/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

§ Tabulated separately for applications going and . represent wireless node , while represents the wired node or remote host.

§ A mean delay of 20,000 is considered as a threshold.

§ For the case this threshold is crossed at 13 calls

No of TCP No of voice Mean Delay Mean delay
Connections calls Voice Voice

→
1 1675.83 1841.49
2 2607.92 2837.06
3 3410.97 3749.06
10 4 4232.94 4625.14
5 5278.15 5461.30
6 6424.54 6197.22
7 7573.05 6966.70
8 8720.54 7630.33
9 9876.57 8308.63
10 11070.64 9003.63
11 12753.59 9850.23
12 18795.31 11159.34
13 475632.93 12308.13
14 496716.61 12765.60

Table 18‑7: EDCAF with full-duplex voice calls and multiple TCP downloads

and →

18.7 Discussion of the Simulation Results

Results for DCF

1. Observations

§ Only voice calls: With one voice conversation, the mean packet delay for the wired-to-wireless (downlink) direction (i.e., these packets queue in the AP) is

1.18161 ms, whereas in the wireless-to-wired (uplink) direction (i.e., these packets queue in the STA) the mean packet delay is 1.11924 ms (we will,
henceforth, report these delays in milliseconds and round-off to two decimal places). These mean delays increase as the number of voice conversations
increase. We notice that with 10 conversations the downlink mean packet delay is 13.69 ms, whereas the uplink packet delay is 5.47 ms. An increase of

one more call results in the downlink mean packet delay becoming 4027.85 ms and the uplink mean packet delay being 6.28 ms.

§ One TCP download to one STA from a wired node and increasing number of full-duplex voice calls: With just one voice call the mean delay is 116.00 ms in
the downlink and 3.18 ms in the uplink. These values should be compared with 1.18 ms and 1.12 ms, respectively. Thus, with just one TCP connection, a

single voice call experiences substantially larger mean delay.

2. Discussion

§ With increasing number of voice calls (without any simultaneous TCP download) the dramatic change in the downlink delay, when the number of voice calls

is increased from 10 to 11 is due to the downlink queue becoming unstable, i.e., the arrival rate of bits exceeds the rate at which the DCF wireless access
mechanism can service the bits queued at the AP. The sudden transition from low delays to very high delays is typical of a queue going a stable regime to
an unstable regime.

§ It is interesting to note that at this transition point, the uplink delays have not increased as dramatically. In fact, in the uplink direction the transition from
stability to instability appears in going from 22 calls to 23 calls. This difference in the downlink and uplink directions is because all the downlink voice
packet streams are handled at one queue (the AP’s WiFi buffer), with one contention process, whereas each uplink voice packet stream has its own buffer

with its own contention process. If all the uplink voice streams had also been from one STA then the same phenomenon would have been observed in
both directions.

§ Next, we saw that with a single downlink TCP transfer the downlink mean delay of a single voice call is almost 100 times that without TCP. This occurs

because the TCP transfer over a the local area network builds up a large window, most of which resides in the AP buffer. The TCP file transfer packets are
large (about 1500 bytes). A single voice stream generates 200 byte packets at 20 ms intervals. The downlink voice packets see a very large buffer, due to
the TCP packets queued in the AP buffer. It may be noted here, that with this kind of delay, even a single interactive voice call will not be supported.

Results for EDCAF

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 92/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
1. Observations

§ With voice calls alone the transition in downlink delay occurs in going from 12 to 13 calls.

§ With TCP downloads (1 or 10 downloads) the transition in downlink voice packet delay does not change as compared to without TCP

2. Discussion

§ EDCAF creates different buffers for voice and for TCP file transfers (AC3 and AC1, respectively). The service differentiation mechanism between these

buffers is described earlier in this chapter. The experimental results show that voices call performance is not seriously affected by the TCP controlled file
transfers.

§ As before, and for the same reasons, the voice capacity is limited by the service rendered to the AP buffers.

19 Cyber physical systems (CPS) and IoT – An Introduction

19.1 Introduction
Cyber Physical Systems (CPS) are systems that link the physical world (e.g., through sensors or actuators) with the virtual world of information processing. This does
not just mean the convergence. Many systems can be categorized as CPS. Let us consider the example of a smart grids. On the demand side the various domestic

appliances (of end users) constitute the physical components, and data of demand load are collected by smart meters. These smart meters connect the physical world to
cyber space. The demand load data is transferred via two-way communication channels that are used to measure and control the physical components. On the cyber
(cloud) side computations are carried out by the objectives of utility maximization and cost minimization. Based on this a suitable real-time electricity price is calculated.

Internet of Things (IoT) is a network of physical devices, vehicles, buildings and other items embedded with electronics, software, sensors, actuators, and network
connectivity that enable these objects to collect and exchange data. The IoT network allows objects to be sensed and/or controlled remotely across existing network
infrastructure, creating opportunities for more direct integration of the physical world into computer-based systems, and resulting in improved efficiency, accuracy and

economic benefit.

IoT is the platform on which cyber physical systems run.

Figure 19‑1: IOT Network Components and the TCP/IP stack running in the network devices

19.2 Components of IoT

1. Sensors: Sensors are used to detect physical phenomena such as light, heat, pressure, temperature, humidity etc. Sensors are regarded as a revolutionary
information gathering method to build the information and communication system which will greatly improve the reliability and efficiency of infrastructure systems. It
follows IPv6 addressing system. IP addresses are the backbone to the entire IoT ecosystem. IPv6’s huge increase in address space is an important factor in

the development of the Internet of Things.

2. LowPAN Gateway: These are the Gateways to Internet for all the things/devices that we want to interact with. Gateway help to bridge the internal network of sensor
nodes with the external Internet i.e., it will collect the data from sensors and transmitting it to the internet infrastructure. A 6LowPAN Gateway will have 2 interfaces,

one is Zigbee interface connected to sensors (follows 802.15.4 MAC and PHY) and the other is WAN interface connected to ROUTER.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 93/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 19‑2: The 6LowPAN Gateway’s TCP/IP Stack at the wired and wireless Interfaces

6LoWPAN is an acronym of IPv6 over Low Power Wireless Personal Area Network. The 6LoWPAN concept originated from the idea that "the Internet Protocol should be
applied even to the smallest devices, and that low-power devices with limited processing capabilities should be able to participate in the Internet of Things.

19.3 Network Setup

Open NetSim and click Examples > Experiments > Introduction-to-cyber-physical-systems-(CPS)-and-IoT as shown below Figure 19‑3.

Figure 19‑3: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 19‑4.

Sample 1:

Figure 19‑4: Scenario for Sample 1

19.4 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 4 Wireless Sensors, 1 Gateway, 1 Router, and 1 Wired Node in the “Internet of Things” Network

Library.

Step 2: Before we actually designed this network, in the Fast Config Window containing inputs for Grid/ Map Settings and Sensor Placement, the Grid Length and
Side Length were set to 500 and 250 meters respectively, instead of the default 100 and 50 meters and we have chosen Manually Via Click and Drop option.

Step 3: The Ad hoc Link is used to link all the Sensors and the Gateway in an ad hoc basis.

The Ad hoc link properties is set to NO PATHLOSS for the channel characteristics.

Step 4: Right click on the Application Flow App1 Sensor App and select Properties or click on the Application icon present in the top ribbon/toolbar.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 94/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
A Sensor Application is generated from Wireless Sensor 2 i.e. Source to Wired Node 7 i.e. Destination with Packet Size remaining 50 Bytes and Inter Arrival Time
remaining 1000000 µs.

Step 5: Enable the packet trace and plots. Run the Simulation for 100 Seconds.

19.5 Output

Figure 19‑5: Animation Window

Sample 2:

Figure 19‑6: Scenario for Sample 2

The following changes in settings are done from the previous sample:

Step 1: We have only one Sensor and the Sensor Application is generated between that Sensor and the Wired Node.

Step 2: Enable the plots and run the Simulation for 10 Seconds.

19.6 Output
Users can understand how the IP addresses are changing from IPv6 to IPv4 and vice versa with the help of packet trace file Figure 19‑7.

After simulation, open packet trace and filter PACKET_TYPE to Sensing and observe the columns SOURCE_IP, DESTINATION_IP, GATEWAY_IP and NEXT_HOP_IP

SOURCE_IP – source node IP

DESTINATION_IP – gateway IP/destination IP

GATEWAY_IP – IP of the device which is transmitting a packet

NEXT_HOP_IP – IP of the next hop

1. Sensor and 6_LOWPAN_Gateways 1st interface follows IPv6 addressing.

2. 6_LOWPAN_Gateways 2nd interface, Router and Wired Node follows IPv4 addressing.

3. From the screenshot below, users can identify the changing of IP addresses from source to destination.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 95/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 19‑7: Screen short of packet trace showing IP addresses are changing from IPv6 to IPv4 and vice versa

20 One Hop IoT Network over IEEE 802.15.4

20.1 Introduction
The concept of Cyber Physical Systems (CPS) over the Internet of Things (IoT) was explained in Experiment 19: Introduction and working of IoT. In most situations, due

to the practical difficulty of laying copper or optical cables to connect sensors and actuators, digital wireless communication has to be used. In such applications, since
the energy available in the sensor and actuator devices is small, there is a need for keeping costs low, and the communication performance requirement (in terms of
throughput and delay is limited) several wireless technologies have been developed, with the IEEE 802.15.4 standard being one of the early ones.

The IEEE Standard 802.15.4 defines PHY and MAC protocols for low-data-rate, low-power, and low-complexity short-range radio frequency (RF) digital transmissions.

In this experiment, we will study the simplest IEEE 802.15.4 network with one wireless node transmitting packets to an IEEE 802.15.4 receiver, from where the packets
are carried over a high speed wireline network to a compute server (where the sensor data would be analyzed).

20.2 The IEEE 802.15.4 PHY and MAC

We will study the IEEE 802.15.4 standard that works in the 2.4 GHz ISM band, in which there is an 80 MHz band on which 16 channels are defined, each of 2 MHz, with

a channel separation of 5 MHz. Each IEEE 802.15.4 network works in one of these 2 MHz channels, utilizing spread spectrum communication over a chip-stream of 2

million chips per second. In this chip-stream, 32 successive chips constitute one symbol, thereby yielding 62,500 symbols per second (62.5 Ksps;

Here, we observe that a symbol duration is sec. Binary signaling (OQPSK) is used over the chips, yielding possible sequences over a 32 chip

symbol. Of these sequences, 16 are selected to encode 4 bits ( The sequences are selected so as to increase the probability of decoding in spite of symbol

error. Thus, with 62.5 Ksps and 4 bits per symbol, the IEEE 802.15.4 PHY provides a raw bit rate of Kbps.

Having described the IEEE 802.15.4 PHY, we now turn to the MAC, i.e., the protocol for sharing the bit rate of an IEEE 802.15.4 shared digital link. A version of the

CSMA/CA mechanism is used for multiple access. When a node has a data packet to send, it initiates a random back-off with the first back-off period being sampled

uniformly from to , where is a standard parameter. The back-off period is in slots, where a slot equals 20 symbol times, or
sec. The node then performs a Clear Channel Assessment (CCA) to determine whether the channel is idle. A CCA essentially involves the node listening over 8 symbols

times, and integrating its received power. If the result exceeds a threshold, it is concluded that the channel is busy and CCA fails. If the CCA succeeds, the node does a
Rx-to-Tx turn-around, which takes 12 symbol times and starts transmitting on the channel. The failure of the CCA starts a new back-off process with the back-off
exponent raised by one, i.e., to macminBE+1, provided it is less than the maximum back-off value, macmaxBE. The maximum number of successive CCA failures for the
same packet is governed by macMaxCSMABackoffs; if this limit is exceeded the packet is discarded at the MAC layer. The standard allows the inclusion of

acknowledgements (ACKs) which are sent by the intended receivers on a successful packet reception. Once the packet is received, the receiver performs a Rx-to-Tx
turnaround, which is again 12 symbol times, and sends a 22-symbol fixed size ACK packet. A successful transmission is followed by an InterFrameSpace (IFS) before
sending another packet.

The IEEE 802.15.4 can operate either in a beacon enabled or a nonbeacon enabled mode. In the beacon enabled mode, the PAN coordinator works with time slots
defined through a superframe structure (see Figure 20‑1). This permits a synchronous operation of the network. Each superframe has active and inactive portions. The
PAN Coordinator interacts with the network only during the active portion. The active portion is composed of three parts: a beacon, a contention access period (CAP),

and a contention free period (CFP). The active portion starts with the transmission of a beacon and a CAP commences immediately after the beacon. All frames, except
acknowledgment frames and any data frame that immediately follows the acknowledgment of a data request command (as would happen following a data request from a
node to the PAN coordinator), transmitted in the CAP, must use a slotted CSMA/CA mechanism to access the channel.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 96/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 20‑1: The IEEE 802.15.4 Frame Structure

When a transmitted packet collides or is corrupted by the PHY layer noise, the ACK packet is not generated which the transmitter interprets as packet delivery failure.

The node reattempts the same packet for a maximum of aMaxFrameRetries times before discarding it at the MAC layer. After transmitting a packet, the node turns to
Rx-mode and waits for the ACK. The macAckWaitDuration determines the maximum amount of time a node must wait to receive the ACK before declaring that the
packet (or the ACK) has collided. The default values of macminBE, macmaxBE, macMaxCSMABackoffs, and aMaxFrameRetries are 3, 5, 4, and 3.

20.3 Objectives of the Experiment

In Section 20.2, we saw that the IEEE 802.15.4 PHY provides a bit rate of 250 Kbps, which has to be shared among the nodes sharing the 2 MHz channel on which this

network runs. In the simulation experiment, the packets will have an effective length of 109 bytes (109 B = 872 bits). Thus, over a 250 Kbps link, the maximum packet

transmission rate is packets per second. We notice, however, from the protocol description in Section 20.2, that due to the medium access control,
before each packet is transmitted the nodes must contend for the transmission opportunity. This will reduce the actual packet transmission rate well below 286.7.

In this experiment, just one node will send packets to a receiver. Since there is no contention (there being only one transmitter) there is no need for medium access
control, and packets could be sent back to back. However, the MAC protocol is always present, even with one node, and we would like to study the maximum possible
rate at which a node can send back to back packets, when it is the only transmitter in the network. Evidently, since there is no uncertainty due to contention from other

nodes, the overhead between the packets can be calculated from the protocol description in Section 20.2. This has been done in Section 20.6.

This analysis will provide the maximum possible rate at which a node can send packets over the IEEE 802.15.4 channel. Then in Section 20.7, we compare the
throughput obtained from the simulation with that obtained from the analysis. In the simulation, in order to ensure that the node sends at the maximum possible rate, the

packet queue at the transmitting node never empties out. This is ensured by inserting packets into the transmitting node queue at a rate higher than the node can
possibly transmit.

20.4 NetSim Simulation Setup

Open NetSim and click Examples > Experiments > One-Hop-IoT-Network-over-IEEE-802.15.4 as shown below Figure 20‑2.

Figure 20‑2: Experiments List

Sample 1:

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 20‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 97/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 20‑3: One Hop IoT Network topology

20.5 Simulation Procedure

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wireless Sensors, a 6 LOWPAN Gateway, 1 Router, and 1 Wired Node.

Step 2: In the Interface Zigbee > Data Link Layer of Wireless Sensor 1, Ack Request is set to Enable and Max Frame Retries is set to 7. It will automatically be set for
Wireless Sensor 2, since the above parameters are Global.

Step 3: In the Interface Zigbee > Data Link Layer of 6 LOWPAN Gateway, Beacon Mode is set to Disable by default.

Step 4: The Ad hoc link properties are set to NO PATHLOSS for the channel characteristics.

Step 5: Right click on the Application Flow App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A Custom Application is set from Wireless Sensor 1 i.e. Source to Wired Node 5 i.e. Destination. Transport Protocol is set to UDP with Packet Size set to 70 Bytes and
Inter Arrival Time set to 4000 µs. The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 140 Kbps. Generation Rate can be
calculated using the formula:

NOTE: If the size of the packet at the Physical layer is greater than 127 bytes, the packet gets fragmented. Taking into account the various overheads added at different layers (which are

mentioned below), the packet size at the application layer should be less than 80 bytes.

Step 6: Plots are enabled in NetSim GUI.

Run simulation for 10 Seconds and note down the throughput.

Similarly, do the other samples by increasing the simulation time to 50, 100, and 200 Seconds respectively and note down the throughputs.

20.6 Analysis of Maximum Throughput

We have set the Application layer payload as 70 bytes in the Packet Size and when the packet reaches the Physical Layer, various other headers gets added like Table

20‑1.

App layer Payload 70 bytes

Transport Layer Header 8 bytes
Network Layer Header 20 bytes
MAC Header 5 bytes
PHY Header (includes Preamble, and
6 bytes
Start Packet Delimiter)
Packet Size 109 bytes
Table 20‑1: Overheads added to a packet as it flows down the network stack

By default, NetSim uses Unslotted CSMA/CA and so, the packet transmission happens after a Random Back Off, CCA, and Turn-Around-Time and is followed by Turn-

Around-Time and ACK Packet and each of them occupies specific time set by the IEEE 802.15.4 standard as per the timing diagram shown below Figure 20‑4.

Figure 20‑4: Zigbee timing diagram

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 98/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
From IEEE standard, each slot has 20 Symbols in it and each symbol takes 16µs for transmission.

Symbol Time 16 µs

Slot Time 0.32 ms

20 *

Random Backoff Average 1.12 ms

3.5 *

CCA 0.128 ms
0.4 *

Turn-around-Time 0.192 ms
0.6 *

Packet Transmission Time 3.488 ms

10.9 *

Turn-around-Time 0.192 ms
0.6 *

ACK Packet Time 0.192 ms

0.6 *

Total Time 5.312 ms

16.6 *
Table 20‑2: Symbol times as per IEEE standard

20.7 Comparison of Simulation and Calculation

Throughput from simulation 104.74 kbps
Throughput from analysis 105.42 kbps
Table 20‑3: Results comparison form simulation and theoretical analysis

Throughput from theoretical analysis matches the results of NetSim’s discrete event simulation. The slight difference in throughput is due to two facts:

§ The average of random numbers generated for backoff need not be exactly 3.5 as the simulation is run for short time.

§ In the packet trace one can notice that there are OSPF and AODV control packets (required for the route setup process) that sent over the network. The data
transmissions occur only after the control packet transmissions are completed.

As we go on increasing the simulation time, the throughput value obtained from simulation approaches the theoretical value as can be seen from the table below Table

20‑4.

Simulation Time
Sample Throughput (kbps)
(sec)
1 10 103.60
2 50 104.62
3 100 104.57
4 200 104.69

Table 20‑4: Throughput comparison with different simulation times

21 IoT – Multi-Hop Sensor-Sink Path

NOTE: It is recommended to carry out this experiment in Standard Version of NetSim.

21.1 Introduction
The Internet provides the communication infrastructure for connecting computers, computing devices, and people. The Internet is itself an interconnection of a very large
number of interconnected packet networks, all using the same packet networking protocol. The Internet of Things will be an extension of the Internet with sub-networks

that will serve to connect “things” among themselves and with the larger Internet. For example, a farmer can deploy moisture sensors around the farm so that irrigation
can be done only when necessary, thereby resulting in substantial water savings. Measurements from the sensors have to be communicated to a computer in the
Internet, where inference and decision-making algorithms can advise the farmer as to required irrigation actions.

Farms could be very large, from a few acres to hundreds of acres. If the communication is entirely wireless, a moisture sensor might have to communicate with a sink
that is 100s of meters away. As the distance between a transmitter and a receiver increases, the power of the signal received at the receiver decreases, eventually
making it difficult for the signal processing algorithms at the receiver to decode the transmitted bits in the presence of the ever-present thermal noise. Also, for a large

farm there would need to be a large number of moisture sensors; many of them might transmit together, leading to collisions and interference.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 99/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

21.2 Theory
The problem of increasing distance between the transmitter and the receiver is solved by placing packet routers between the sensors and the sink. There could even be
multiple routers on the path from the sensor to the sink, the routers being placed so that any intermediate link is short enough to permit reliable communication (at the
available power levels). We say that there is a multi-hop path from a sensor to the sink.

By introducing routers, we observe that we have a system with sensors, routers, and a sink; in general, there could be multiple sinks interconnected on a separate edge
network. We note here that a sensor, on the path from another sensor to the sink, can also serve the role of a router. Nodes whose sole purpose is to forward packets
might also need to be deployed.

The problem of collision and interference between multiple transmission is solved by overlaying the systems of sensors, routers, and sinks with a scheduler which
determines (preferably in a distributed manner) which transmitters should transmit their packets to which of their receivers.

Figure 21‑1: Data from Sensor A to Sink I takes the path A-B-D-I while data from sensor C to Sink I takes the path C-D-I

In this experiment, we will use NetSim Simulator to study the motivation for the introduction of packet routers, and to understand the performance issues that arise. We
will understand the answers to questions such as:

1. How does packet error rate degrade as the sensor-sink distance increases?

2. How far can a sensor be from a sink before a router needs to be introduced?

3. A router will help to keep the signal-to-noise ratio at the desired levels, but is there any adverse implication of introducing a router?

21.3 Network Setup

Open NetSim and click Examples > Experiments > IoT–Multi-Hop-Sensor-Sink-Path > Part-1 > Sample-1 as shown below Figure 21‑2.

Figure 21‑2: Experiments List

21.4 Part 1 – Packet Delivery Rate vs. Distance

In this part, we perform a simulation to understand, “How the distance between the source and sink impacts the received signal strength (at the destination) and
in turn the packet error rate?” We will assume a well-established path-loss model under which, as the distance varies, the received signal strength (in dBm) varies

linearly. For a given transmit power (say 0dBm), at a certain reference distance (say 1m) the received power is dBm, and decreases beyond this point as

for a transmitter-receiver distance of . This is called a power-law path loss model, since in mW the power decreases as the power of the distance .

The value of is 2 for free space path loss and varies from 2 to 5 in the case of outdoor or indoor propagation. Values of are obtained by carrying out experimental
propagation studies.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 100/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Sample 1

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 21‑3.

Figure 21‑3: Network topology for Sample 1

21.4.1 Procedure

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in the NetSim GUI comprising of a WSN Sink and 1 Wireless Sensor in Wireless Sensor Networks.

Note: NetSim currently supports a maximum of only one device as WSN Sink.

Step 2: Before we actually designed this network, in the Fast Config Window containing inputs for Grid Settings and Sensor Placement, the Grid Length and Side

Length were set to 500 meters respectively, instead of the default 50 meters and we have chosen Manually Via Click and Drop option.

Step 3: The distance between the WSN Sink and Wireless Sensor is 5 meters.

Step 4: Go to Network Layer properties of Wireless Sensor 2, the Routing Protocol is set as AODV.

Note: The Routing Protocol parameter is Global. i.e. It will automatically be set to AODV in WSN Sink.

Step 5: In the Interface Zigbee > Data Link Layer of Wireless Sensor 2, Ack Request is set to Enable and Max Frame Retries is set to 4. Similarly, it is set for WSN
Sink 1.

Step 6: In the Interface Zigbee > Physical Layer of Wireless Sensor 2, Transmitter Power is set to 1mW, Reference Distance is set to 1m, Receiver Sensitivity is set
to -105dBm, and ED Threshold is set to -115dBm.

Step 7: Right click on the Application Flow App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from Wireless Sensor 2 i.e. Source to WSN Sink 1 i.e. Destination with Transport Protocol set to UDP, Packet Size set to 70 Bytes
and Inter Arrival Time set to 4000 µs.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 140 Kbps. Generation Rate can be calculated using the formula:

Step 8: The following procedures were followed to set Static IP:

Go to Network Layer properties of Wireless Sensor 2 Figure 21‑4, Click on Configure Static Route IP.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 101/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 21‑4: Network layer properties window

Static IP Routing Dialogue box gets open.

Enter the Network Destination, Gateway, Subnet Mask, Metrics, and Interface ID. Click on Add.

You will find the entry added to the below Static IP Routing Table as shown below.

Click on OK.

Figure 21‑5: Static Route Configuration Window

Step 9: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the packet information is available for the users to
perform packet level analysis. Enable the plots from NtSim GUI.

Note: Before we click on Run simulation, user need to modify the code as per the “Procedure to log RSSI and BER” given below.

NOTE: The following changes need to be done manually by the user inorder to carry out this experiment.

Procedure to log RSSI and BER (Possible in Standard / Pro Versions only):

RSSI and BER in ZigBee project can be logged into a text file. The following code changes are required to log these parameters into a txt file.

§ Go to NetSim Home page and click on Your work.

§ Click on Workspace Options and then click on Open Code and open the codes in Visual Studio. Set Win32 or x64 according to the NetSim build which you are
using.

NOTE: We recommend Visual Studio Community Edition 2017 or Higher.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 102/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ Go to the Zigbee Project in the Solution Explorer. Open 802_15_4.c file and add the follwing lines of code highlighted in red, inside the fn_NetSim_Zigbee_init()
function as shown below:

_declspec (dllexport) int fn_NetSim_Zigbee_Init(struct stru_NetSim_Network *NETWORK_Formal, \

NetSim_EVENTDETAILS *pstruEventDetails_Formal, char *pszAppPath_Formal, \

char *pszWritePath_Formal, int nVersion_Type, void **fnPointer)

{
FILE* fp;

pstruEventDetails = pstruEventDetails_Formal;
NETWORK = NETWORK_Formal;
pszAppPath = pszAppPath_Formal;

pszIOPath = pszWritePath_Formal;

//RSSI BER SNR LOG

fp = fopen("ZIGBEE_BER_LOG.txt", "w+");
if (fp)
{

fprintf(fp, "PACKET_ID,\tTRANSMITTER,\t\tRECEIVER,\tRX_POWER(dBm),\tTOTAL_RX_POWER(dBm),\tBER");
fclose(fp);
}

//RSSI BER SNR LOG

fn_NetSim_Zigbee_Init_F(NETWORK_Formal, pstruEventDetails_Formal, pszAppPath_Formal, \
pszWritePath_Formal, nVersion_Type, fnPointer);

return 0;
}
§ Add the lines of code highlighted in red inside the fn_NetSim_Zigbee_Run() function under PHYSICAL_IN_EVENT as shown below:

case PHYSICAL_IN_EVENT:
{
NetSim_PACKET *pstruPacket;

PACKET_STATUS nPacketStatus;
double SNR;
double dBER;

FILE* fp;
pstruPacket = pstruEventDetails->pPacket;
if (pstruPacket->nReceiverId && pstruPacket->nReceiverId != pstruEventDetails->nDeviceId)
{

fnNetSimError("Different device packet received..");

assert(false);
return 0;

}
if (!ZIGBEE_CHANGERADIOSTATE(pstruEventDetails->nDeviceId, WSN_PHY(pstruEventDetails->nDeviceId)->nRadioState, RX_ON_IDLE))
return 0;

if (WSN_PHY(pstruEventDetails->nDeviceId)->dTotalReceivedPower - GET_RX_POWER_mw(pstruPacket->nTransmitterId, pstruPacket->nReceiverId,

pstruEventDetails->dEventTime) >= WSN_PHY(pstruEventDetails->nDeviceId)->dReceiverSensivity)
pstruPacket->nPacketStatus = PacketStatus_Collided;

nPacketStatus = pstruPacket->nPacketStatus;
ZIGBEE_SINR(&SNR,
WSN_PHY(pstruEventDetails->nDeviceId)->dTotalReceivedPower,

GET_RX_POWER_mw(pstruPacket->nTransmitterId, pstruPacket->nReceiverId, pstruEventDetails->dEventTime));

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 103/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

dBER = fn_NetSim_Zigbee_CalculateBER(SNR);

//RSSI BER SNR LOG

double rxpwr = MW_TO_DBM(WSN_PHY(pstruEventDetails->nDeviceId)->dTotalReceivedPower);
double total_rxpwr = GET_RX_POWER_dbm(pstruPacket->nTransmitterId, pstruPacket->nReceiverId, pstruEventDetails->dEventTime);

fp = fopen("ZIGBEE_BER_LOG.txt", "a+");
if (fp)
{

fprintf(fp, "\n%lld,\t\t%s,\t%s,\t%lf,\t%lf,\t\t%lf", pstruPacket->nPacketId,

DEVICE_NAME(pstruPacket->nTransmitterId),
DEVICE_NAME(pstruPacket->nReceiverId),

rxpwr, total_rxpwr, dBER);

fclose(fp);
}

//RSSI BER SNR LOG

if (fn_NetSim_Packet_DecideError(dBER, pstruEventDetails->dPacketSize))
§ Right click on the ZigBee project in the solution explorer and click on rebuild.

§ After the Zigbee project is rebuild successful, go back to the network scenario.

Step 10: Enable the plots and run the simulation for 10 Seconds. Once the simulation is complete, it will generate a text file named ZIGBEE_BER_LOG.txt containing
RSSI and BER in the binary folder of NetSim. i.e. <NetSim Install Directory>/bin.

21.4.2 Output

RSSI, PER, BER vs. Distance (path-loss: linear in log-distance, with )

PLR
RSSI (dBm)
Distance(m) BER PER (after MAC
(pathloss model)
retransmissions*)
5 -64.51 0.00 0 0
10 -75.04 0.00 0 0
15 -81.20 0.00 0 0
20 -85.58 0.00 0 0
25 -88.97 0.00 0 0
30 -91.74 0.00 0 0
35 -94.08 0.000005 0.0051 0
40 -96.11 0.000229 0.2076 0
45 -97.90 0.002175 0.8905 0.447
50 -99.51 0.008861 0.9999 1
55 -100.95 0.022370 1 1
60 -102.28 0.042390 1 1
65 -103.49 0.067026 1 1
70 -104.62 0.094075 1 1
75 - - - -
80 - - - -
Table 21‑1: RSSI, PER, BER from ZIGBEE_BER_LOG.txt vs. Distance

* The IEEE 802.15.4 MAC implements a retransmission scheme that attempts to recover errored packets by retransmission. If all the retransmission attempts are also

errored, the packet is lost.

The table above reports the RSSI (Received Signal Strength), BER (Bit Error Rate), and Packet Error Rate (PER), and the Packet Loss Rate (PLR) as the distance

between the sensor to the sink is increased from 5m to 50m with path loss exponent . We see that the BER is 0 until a received power of about -92dBm. At a

distance of 35m the received power is -94 dBm, and we notice a small BER of . As the distance is increased further the BER continues to grow and at 45m the

BER is about , yielding and Here is obtained from the following formula (which assumes independent bit errors across a
packet)

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 104/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Where,

The in the above table has been obtained from NetSim, which implements the details of the IEEE 802.15.4 MAC acknowledgement and reattempt mechanism. This

mechanism is complex, involving a MAC acknowledgement, time-outs, and multiple reattempts. Analysis of the therefore, is not straightforward. Assuming that the

probability of MAC acknowledgement error is small (since it is a small packet), the can be approximated as , where is the maximum number of times a
packet can be retransmitted.

Steps to calculate Packet Loss Rate

§ Open Packet Trace from the Results Dashboard. Filter the PACKET TYPE column as Custom and note down the packet id of the last packet sent from the
PACKET ID column.

Figure 21‑6: Packet Trace

This represents the total number of packets sent by the source.

§ Note down the Packets Received from the Application Metrics in the Results Dashboard Figure 21‑7.

Figure 21‑7: Application metrics table in Result Dashboard

This represents the total number of packets received at the destination.

§ Calculate the total number of Lost Packets and PLR as follows:

For the above case,

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 105/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
21.4.3 Inference

It is clear that Internet applications, such as banking and reliable file transfer, require that all the transmitted data is received with accuracy. The Internet achieves

this, in spite of unreliable communication media (no medium is reliable) by various protocols above the network layer. Many IoT applications, however, can work

with less than packet delivery without affecting the application. Take, for example, the farm moisture sensing application mentioned in the introduction. The
moisture levels vary slowly; if one measurement is lost, the next received measurement might suffice for the decision-making algorithm. This sort of thinking also permits

the IoT applications to utilize cheap, low power devices, making the IoT concept practical and affordable.

With the above discussion in mind, let us say that the application under consideration requires a measurement delivery rate of at least . Examining the table above,

we conclude that the sensor-sink distance must not be more than meters. Thus, even a acre farm would require multi-hopping to connect sensors to a

sink at the edge of the farm.

In Part 2 of this experiment we will study the placement of a single router between the sensor and the sink, so as to increase the sensor-sink distance beyond meters.

21.5 Part 2 – Reaching a Longer Distance by Multihopping

Sample1

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 21‑8.

Figure 21‑8: Network topology for Sample 1

21.5.1 Procedure

The following changes in settings are done from the previous sample:

Step 1: The distance between the WSN Sink and Wireless Sensor is 40 meters.

Step 2: In the Interface Zigbee > Data Link Layer of Wireless Sensor 2, Ack Request is set to Enable and Max Frame Retries is set to 3.

Step 3: The Ad hoc Link properties are set as follows Figure 21‑9.

Figure 21‑9: Wireless Link properties

Step 4: Right click on the Application Flow App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from Wireless Sensor 2 i.e. Source to WSN Sink 1 i.e. Destination with Packet Size set to 70 Bytes and Inter Arrival Time set to
100000 µs.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 5.6 Kbps. Generation Rate can be calculated using the formula:

Step 5: Enable the plots and run the Simulation for 100 Seconds. Once the simulation is complete, note down the Packet Generated value and Throughput value from

the Application Metrics.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 106/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Note down the Packet Received, Packet Errored, and Packet Collided from the Link Metrics.

Sample-2

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 21‑10.

Figure 21‑10: Network topology for Sample 2

21.5.2 Procedure

The following changes in settings are done from the previous sample:

Step 1: One more Wireless Sensor is added to this network. The distance between Wireless Sensor 2 and Wireless Sensor 3 is 40 meters and the distance between
Wireless Sensor 3 and the WSN Sink is 40 meters.

Step 2: The following procedures were followed to set Static IP:

Go to Network Layer properties of Wireless Sensor 2 Figure 21‑11, Click on Configure Static Route IP.

Figure 21‑11: Network layer properties window

Static IP Routing Dialogue box gets open.

Enter the Network Destination, Gateway, Subnet Mask, Metrics, and Interface ID. Click on Add.
You will find the entry added to the below Static IP Routing Table as shown below:
Click on OK.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 107/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 21‑12: Static Route configuration for Wireless Sensor 2

Similarly, Static IP is set for Wireless Sensor 3 as shown below Figure 21‑13.

Figure 21‑13: Static Route configuration for Wireless Sensor 3

Step 3: Enable the plots and run the Simulation for 100 Seconds. Once the simulation is complete, note down the Packet Generated value and Throughput value from

the Application Metrics.

Note down the Packet Received, Packet Errored, and Packet Collided from the Link Metrics Table 21‑2.

21.5.3 Output

Mean
Packets Packet
Source-Sink Packets Packets Packets Delay
Errored Loss PLR
Distance (m) Generated Received Collided
(PHY) (MAC)

Direct
sensor- 40 1000 1012 244 0 0 0 6514.45
sink link
Router
80
between
(router at 1000 1015 540 0 0 0 14239.94
sensor and
midpoint)
sink
Table 21‑2: Packet Generated/Received/Errored/Collided and Mean delay from result dashboard

NOTE: Packet loss (PHY) is the number of packets that were received in error and then recovered by retransmission. Packets received is slightly higher than packets generated on account of

retransmissions of successful packets in case of ACK errors.

21.5.4 Inference

In Part 1 of this experiment we learnt that if the sensor device uses a transmit power of 0dBm, then for one-hop communication to the sink, the sensor-sink distance
cannot exceed 40m. If the sensor-sink distance needs to exceed 40m (see the example discussed earlier), there are two options:

1. The transmit power can be increased. There is, however, a maximum transmit power for a given device. Wireless transceivers based on the CC 2420 have a
maximum power of 0dBm (i.e., about 1 mW), whereas the CC 2520 IEEE 802.15.4 transceiver provides maximum transmit power of 5dBm (i.e., about 3 mW).
Thus, given that there is always a maximum transmit power, there will always be a limit on the maximum sensor-sink distance.

2. Routers can be introduced between the sensor and the sink, so that packets from the sensor to the sink follow a multihop path. A router is a device that will have
the same transceiver as a sensor but its microcontroller will run a program that will allow it to forward packets that it receives. Note that a sensor device can also
be programmed to serve as a router. Thus, in IOT networks, sensor devices themselves serve as routers.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 108/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
In this part of the experiment we study the option of introducing a router between a sensor and the sink to increase the sensor-sink distance. We will compare the
performance of two networks, one with the sensor communicating with a sink at the distance of 40m, and another with the sensor-sink distance being 80m, with a sensor

at the mid-point between the sensor and the sink.

Part 2, Sample 1 simulates a one hop network with a sensor-sink distance of 40m. We recall from Part 1 that, with the transceiver model implemented in NetSim, 40m is
the longest one hop distance possible for 100% packet delivery rate. In sample 2, To study the usefulness of routing we will set up network with a sensor-sink distance of

80m with a packet router at the midpoint between the sensor and the sink.

The measurement process at the sensor is such that one measurement (i.e., one packet) is generated every 100ms. The objective is to deliver these measurements to
the sink with 100% delivery probability. From Part 1 of this experiment we know that a single hop of 80m will not provide the desired packet delivery performance.

The Table at the beginning of this section shows the results. We see that both networks are able to provide a packet delivery probability of 100%. It is clear, however, that
since the second network has two hops, each packet needs to be transmitted twice, hence the mean delay between a measurement being generated and it being
received at the sink is doubled. Thus, the longer sensor-sink distance is being achieved, for the same delivery rate, at an increased delivery delay.

The following points may be noted from the table:

1. The number of packets lost due to PHY errors. The packet delivery rate is 100% despite these losses since the MAC layer re-transmission mechanism is able to
recover all lost packets.

2. There are no collisions. Since both the links (sensor-router and router-sink) use the same channel and there is no co-ordination between them, it is possible, in
general for sensor-router and router-sink transmissions to collide. This is probable when the measurement rate is large, leading to simultaneously nonempty
queues at the sensor and router. In this experiment we kept the measurement rate small such that the sensor queue is empty when the router is transmitting and

vice versa. This avoids any collisions.

22 Performance Evaluation of a Star Topology IoT Network

22.1 Introduction
In IOT experiments 20 and 21 we studied a single IoT device connected to a sink (either directly or via IEEE 802.15.4 routers). Such a situation would arise in practice,

when, for example, in a large campus, a ground level water reservoir has a water level sensor, and this sensor is connected wirelessly to the campus wireline network.
Emerging IoT applications will require several devices, in close proximity, all making measurements on a physical system (e.g., a civil structure, or an industrial
machine). All the measurements would need to be sent to a computer connected to the infrastructure for analysis and inferencing. With such a scenario in mind, in this

experiment, we will study the performance of several IEEE 802.15.4 devices each connected by a single wireless link to a sink. This would be called a “star topology” as
the sensors can be seen as the spikes of a “star.”

We will set up the experiment such that every sensor can sense the transmissions from any other sensor to the sink. Since there is only one receiver, only one

successful transmission can take place at any time. The IEEE 802.15.4 CSMA/CA multiple access control will take care of the coordination between the sensor
transmissions. In this setting, we will conduct a saturation throughput analysis. The IoT communication buffers of the IEEE 802.15.4 devices will always be nonempty, so
that as soon as a packet is transmitted, another packet is ready to be sent. This will provide an understanding of how the network performs under very heavy loading.

For this scenario we will compare results from NetSim simulations against mathematical analyses.

Details of the IEEE 802.15.4 PHY and MAC have been provided in the earlier IOT experiments 20 and 21, and their understanding must be reviewed before proceeding
further with this experiment. In this experiment, all packets are transferred in a single hop from and IoT device to the sink. Hence, there are no routers, and no routing to

be defined.

22.2 NetSim Simulation Setup

Open NetSim and click Examples > Experiments > IOT-Star-Topology > Sample-1 as shown below Figure 22‑1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 109/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 22‑1: Experiments List

The simulation scenario consists of n nodes distributed uniformly around a sink (PAN coordinator) at the center. In NetSim the nodes associate with the PAN coordinator
at the start of the simulation. CBR traffic is initiated simultaneously from all the nodes. The CBR packet size is kept as 10 bytes to which 20 bytes of IP header, 7 bytes of

MAC header and 6 bytes of PHY header are added. To ensure saturation, the CBR traffic interval is kept very small; each node’s buffer receives packets at intervals of 5
ms

22.3 Procedure
Sample 1
NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 22‑2.

Figure 22‑2: Star Topology for sample 1

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 SinkNode, and 1 wireless sensor in the “WSN” Network Library. Distance between the SinkNode
and Wireless Sensor is set to 8m.

Step 2: Right click on Adhoc link and select Properties, Channel Characteristics is set to No_Pathloss

Step 3: Right click on Wireless sensor properties in the network layer the static route is configured as shown below Table 22‑1.

Network Gateway SubnetMask Metrics Interface ID

Destination
11.1.1.0 11.1.1.1 255.255.255.0 1 1
Table 22‑1: Static route for Wireless sensor

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wireless Sensor 2 i.e. Source to Sink Node 1 i.e. Destination with Packet Size remaining 10Bytes and Inter Arrival Time remaining
5000µs. Start time is set to 5s.

Transport Protocol is set to UDP instead of TCP.

Step 5: Plots are enabled in NetSim GUI. Click on Run simulation. The simulation time is set to 100 seconds

Increase wireless sensor count to 2, 3, and 4 with the same above properties to design Sample 2, 3, and 4.

Sample 5: NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 22‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 110/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 22‑3: Star Topology for sample 5

The following set of procedures were done to generate this sample:

Step 1: Right click on Wireless sensors properties in the network layer the static route is configured as shown below Table 22‑2.

Network Gateway SubnetMask Metrics Interface ID

Destination

11.1.1.0 11.1.1.1 255.255.255.0 1 1

Table 22‑2: Static route for Wireless sensors

Step 2: Click on the Application icon present in the top ribbon/toolbar. The following application properties is set shown in below Table 22‑3.

App 1 App 2 App 3 App 4 App 5

Application CBR CBR CBR CBR CBR
Source ID 2 3 4 5 6
Destination ID 1 1 1 1 1
Start time 5s 5s 5s 5s 5s
Transport protocol UDP UDP UDP UDP UDP
Packet Size 10bytes 10bytes 10bytes 10bytes 10bytes
Inter-Arrival Time 5000 μs 5000 μs 5000 μs 5000 μs 5000 μs
Table 22‑3: Detailed Application properties

Step 5: Plots are enabled in NetSim GUI. Click on Run simulation. The simulation time is set to 100 seconds.

Increase wireless sensor count to 10, 15, 20, 25, 30, 35, 40, and 45 with the same above properties to design Sample 6, 7, 8, 9, 10, 11, 12, and 13.

22.4 Output
The aggregate throughput of the system can be got by adding up the individual throughput of the applications. NetSim outputs the results in units of kilobits per second

(kbps). Since the packet size is we convert per the formula

Number of Aggregate Aggregate

Nodes Throughput (Kbps) Throughput (pkts/s)

1 16.0 200

2 23.0 287.5

3 22.6 282.5

4 22.3 278.75

5 21.8 272.5

10 18.6 232.5

15 15.3 191.25

20 12.3 153.75

25 10.0 125

30 7.8 97.5

35 6.2 77.5

40 4.9 61.25

45 3.7 46.25

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 111/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Table 22‑4: Aggregate throughput for Star topology scenario

Figure 22‑4: Plot of Aggregated throughput (packets/s) vs Number of Nodes

22.5 Discussion
In Figure 22‑4 we plot the throughput in packets per second versus the number of IoT devices in the star topology network. We make the following observations:

1. Notice that the throughput for a single saturated node is 200 packets per second, which is just the single hop throughput from a single saturated node, when the

packet payload is 10 bytes. When a node is by itself, even though there is no contention, still the node goes through a backoff after every transmission. This
backoff is a waste and ends up lowering the throughput as compared to if the node knew it was the only one in the network and sent packets back to back.

2. When there are two nodes, the total throughput increases to 287.5 packets per second. This might look anomalous. In a contention network, how can the

throughput increase with more nodes? The reason can be found in the discussion of the previous observation. Adding another node helps fill up the time wasted
due to redundant backoffs, thereby increasing throughput.

3. Adding yet another node results in the throughput dropping to 282.5 packets per second, as the advantage gained with 2 nodes (as compared to 1 node) is lost

due to more collisions.

4. From there on as the number of nodes increases the throughput drops rapidly to about 100 packets per second for about 30 nodes.

5. The above behaviour must be compared with a Experiment 9 where several IEEE 802.11 STAs, with saturated queues, were transmitting packets to an AP. The

throughput increased from 1 STA to 2 STAs, dropped a little as the number of STAs increased and then flattened out. On the other hand, in IEEE 802.15.4 the
throughput drops rapidly with increasing number of STAs. Both IEEE 802.11 and IEEE 802.15.4 have CSMA/CA MACs. However, the adaptation in IEEE 802.11
results in rapid reduction in per-node attempt rate, thus limiting the drop in throughput due to high collisions. On the other hand, in IEEE 802.15.4, the per-node

attempt rate flattens out as the number of nodes is increased, leading to high collisions, and lower throughput. We note, however, that IoT networks essentially
gather measurements from the sensor nodes, and the measurement rates in most applications are quite small.

22.6 References
1. Chandramani Kishore Singh, Anurag Kumar. P. M. Ameer (2007). Performance evaluation of an IEEE 802.15.4 sensor network with a star topology. Wireless
Netw (2008) 14:543–568.

23 Study how call blocking probability varies as the load on a GSM network is
continuously increased
23.1 Network Setup
Open NetSim and click Examples > Experiments > Impact-of-load-on-call-blocking-probability-in-GSM as shown below Figure 23‑1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 112/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 23‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 23‑2.

Figure 23‑2: GSM network topology

23.2 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 4 Mobile Stations, 1 MSC, and 1 Base Station in the “Cellular Networks” Network Library.

Step 2: Ensure all the Mobile Stations are placed within the range of Base Station.

Step 3: In the Interface GSM > Data Link Layer Properties of MSC 2, Uplink BW Min and Uplink BW Max are set to 890 MHz and 890.2 MHz respectively Figure 23‑3.

Figure 23‑3: Data Link Layer Properties

Step 4: Right click on the Application Flow App1 ERLANG CALL and select Properties or click on the Application icon present in the top ribbon/toolbar.

The applications are set as per the below Table 23‑1:

Application Properties Application 1 Application2

Application type Erlang_call Erlang_call
Source_Id 3 5
Destination_Id 4 6

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 113/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Call
Duration_ Distribution Exponential Exponential
Duration(s) 60 60
Inter Arrival Time (sec) 10 10
IAT_ Distribution Exponential Exponential
Codec Custom Custom
Inter Arrival Time distribution Constant Constant
Packet Distribution Constant Constant
Service Type CBR CBR
Packet Size 33 33
Inter Arrival Time (µs) 20000 20000
Table 23‑1: Detailed Application Properties

Step 5: Plots are enabled in NetSim GUI. Run the Simulation for 100 Seconds.

The following changes in settings are done from the previous sample:

Step 1: In the next sample, increase the number of Mobile Stations by 2 and add one more application between them.

Step 2: Plots are enabled in NetSim GUI. Run the Simulation for 100 Seconds.

The following changes in settings are done from the previous sample:

Step 1: Similarly, increase the number of Mobile Stations by 2 up to 20 and set properties for different Samples by adding an application every time and changing
Source ID and Destination ID.

Step 2: Plots are enabled in NetSim GUI. Run the Simulation for 100 Seconds.

23.3 Output
To view the output, go to the Cellular Metrics. In MS metrics, take sum of call blocking probability (It is the as ratio of Total call blocked to Total call generated).

Comparison Charts

Figure 23‑4: Plot of Call Blocking Probability vs. Sample Number

*** All the above plots highly depend upon the placement of Mobile station in the simulation environment. So, note that even if the placement is slightly different the same
set of values will not be got but one would notice a similar trend.

23.4 Inference
When the number of MS is increased from 4 to 20 the call blocking probability increases from 0 to 3.46. As we increase the number of mobile stations more calls are

generated. This increases the traffic load on the system & more calls generated implies more channel requests arrive at the base station but the number of channels is
fixed. So when the base station does not find any free channel the call is blocked. An additional observation is that the call blocking is zero until 8 MS. This is because
the number of channels is sufficient to handle all call that 6 MS may generate. Only after this the base station does not find free channels and blocks calls.

24 Study the 802.15.4 Superframe Structure and analyze the effect of

Superframe order on throughput
24.1 Introduction

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 114/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
A coordinator in a PAN can optionally bound its channel time using a Superframe structure which is bound by beacon frames and can have an active portion and an
inactive portion. The coordinator enters a low-power (sleep) mode during the inactive portion.

The structure of this Superframe is described by the values of macBeaconOrder and macSuperframeOrder. The MAC PIB attribute macBeaconOrder, describes the
interval at which the coordinator shall transmit its beacon frames. The value of macBeaconOrder, BO, and the beacon interval, BI, are related as follows:

For 0 ≤ BO ≤ 14, BI = aBaseSuperframeDuration * 2BO symbols.

If BO = 15, the coordinator shall not transmit beacon frames except when requested to do so, such as on receipt of a beacon request command. The value of
macSuperframeOrder, SO shall be ignored if BO = 15.

An example of a Superframe structure is shown in following Figure 24‑1.

Figure 24‑1: An example of the Super Frame structure

Theoretical Analysis

From the above Superframe structure,

If Superframe Order (SO) is same as Beacon Order (BO) then there will be no inactive period and the entire Superframe can be used for packet transmissions.

If BO=10, SO=9 half of the Superframe is inactive and so only half of Superframe duration is available for packet transmission. If BO=10, SO=8 then (3/4)th of the

Superframe is inactive and so nodes have only (1/4)th of the Superframe time for transmitting packets and so we expect throughput to approximately drop by half of the
throughput obtained when SO=9.

Percentage of inactive and active periods in Superframe for different Superframe Orders is given below Table 24‑1.

Super
Beacon Active part of Inactive part of Throughput
Frame
Order (BO) Superframe(%) Superframe (%) estimated (%)
Order (SO)
10 10 100 0 > 200% of T
Say T = 21.07
10 9 50 50 (Got from
simulation)
10 8 25 75 50 % T
10 7 12.5 87.5 25 % T
10 6 6.25 93.75 12.5 % of T
10 5 3.125 96.875 6.25 % of T
10 4 1.5625 98.4375 3.12% of T
10 3 0.78125 99.21875 1.56 % of T
Table 24‑1: Inactive and active periods in Superframe for different Superframe

We expect throughput to vary in the active part of the Superframe as sensors can transmit a packet only in the active portion.

24.2 Network Setup

Open NetSim and click Examples > Experiments > 802.15.4-Superframe-and-effect-of-Superframe-order-on-throughput as shown below Figure 24‑2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 115/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 24‑2: Experiments List

Sample 1

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 24‑3.

Figure 24‑3: Network Topology in this experiment

24.3 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wireless Sensors and a WSN Sink in the “Wireless Sensor Networks” Network Library.

Step 2: Before we actually designed this network, in the Fast Config Window containing inputs for Grid Settings and Sensor Placement, the Grid Length and Side
Length were set to 500 and 250 meters respectively, instead of the default 100 and 50 meters and we have chosen Manually Via Click and Drop option.

Step 3: The Ad hoc Link is used to link the Sensors and the Gateway in an ad hoc basis.

The Ad hoc link properties is set to NO PATHLOSS for the channel characteristics.

Step 4: In the Interface Zigbee > Data Link Layer of WSN Sink, Beacon Mode is set to Enable and Beacon Order and Super Frame Order is set to 10 respectively.

Step 5: Right click on the Application Flow App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from Wireless Sensor 1 i.e. Source to Wireless Sensor 2 i.e. Destination with Packet Size set to 25 Bytes and Inter Arrival Time set
to 3000 µs.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 67 Kbps. Generation Rate can be calculated using the formula:

Step 6: Plots are enabled in NetSim GUI. Run the Simulation for 30 Seconds and note down the Throughput value.

Similarly, run the other samples by varying the Super Frame Order to 9, 8, 7, 6, 5, and 4 and note down the throughput values.

24.4 Output
The following are the throughputs obtained from the simulation for different Super Frame Orders Table 24‑2.
Super Frame Order Throughput (Kbps)
10 41.63
9 21.07
8 10.5

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 116/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
7 5.25
6 2.63
5 1.30
4 0.62
Table 24‑2: Different Super Frame Orders vs. throughputs

To obtain throughput from simulation, payload transmitted values will be obtained from Link metrics and calculated using following formula:

Figure 24‑4: Plot of Super Frame Order with Simulated Throughput vs. theoretical analysis

Comparison Chart: All the above plots highly depend upon the placement of Sensor in the simulation environment. So, note that even if the placement is slightly

different the same set of values will not be got but one would notice a similar trend.

24.5 Inference
From the comparison chart both the simulation and theoretical throughputs match except for the case with no inactive period. A sensor will be idle if the last packet in its
queue is transmitted. If a packet is generated in inactive period then the packet has to wait in the queue till the next Superframe so sensor has packets waiting in its
queue and so it cannot be idle in the next Superframe, but if there is no inactive period then there might be no packets waiting in the queue and so sensor can be idle

resulting in lesser throughput.

25 Understand the working of OSPF

25.1 Objective
To understand the working of OSPF and Shortest Path First (SPF) tree creation.

25.2 Theory
OSPF

Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) standardized by the Internet Engineering Task Force (IETF) and commonly used in large
Enterprise networks. OSPF is a link-state routing protocol providing fast convergence and excellent scalability. Like all link-state protocols, OSPF is very efficient in its
use of network bandwidth.

Shortest path First Algorithm

OSPF uses a shorted path first algorithm in order to build and calculate the shortest path to all known destinations. The shortest path is calculated with the use of the
Dijkstra algorithm. The algorithm by itself is quite complicated. This is a very high level, simplified way of looking at the various steps of the algorithm:

§ Upon initialization or due to any change in routing information, a router generates a link-state advertisement. This advertisement represents the collection of all link-
states on that router.

§ All routers exchange link-states by means of flooding. Each router that receives a link-state update should store a copy in its link-state database and then

propagate the update to other routers.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 117/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ After the database of each router is completed, the router calculates a Shortest Path Tree to all destinations. The router uses the Dijkstra algorithm in order to
calculate the shortest path tree. The destinations, the associated cost and the next hop to reach those destinations form the IP routing table.

§ In case no changes in the OSPF network occur, such as cost of a link or a network being added or deleted, OSPF should be very quiet. Any changes that occur are
communicated through link-state packets, and the Dijkstra algorithm is recalculated in order to find the shortest path.

The algorithm places each router at the root of a tree and calculates the shortest path to each destination based on the cumulative cost required to reach that

destination. Each router will have its own view of the topology even though all the routers will build a shortest path tree using the same link-state database.

Example

Refer Pg. no.18 from OSPF RFC 2328 (https://tools.ietf.org/html/rfc2328#section-2.3)

The below network shows a sample map of an Autonomous System

Figure 25‑1: Sample maps of an Autonomous system

A cost is associated with the output side of each router interface. This cost is configurable by the system administrator. The lower the cost, the more likely the interface is to

The directed graph resulting from the above network is depicted in the following table. Arcs are labelled with the cost of the corresponding router output interface. Arcs hav

FROM

RT RT RT
RT1 RT2 RT3 RT4 RT5 RT6 RT7 RT8 RT9 N3 N6 N8 N9
10 11 12

RT1 0

RT2 0

RT3 6 0
TO

RT4 8 0

RT5 8 6 6

RT6 8 7

RT7 6 0

RT8 0

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 118/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

RT9 0

RT10 7 0 0

RT11 0 0

RT12 0

N1 3

N2 3

N3 1 1 1 1

N4 2

N5

N6 1 1 1

N7 4

N8 3 2

N9 1 1 1

N10 2

N11 3

N12 8 2

N13 8

N14 8

N15 9

H1 10

Table 25‑1: Directed graph

A router generates its routing table from the above directed graph by calculating a tree of shortest paths with the router itself as root. Obviously, the shortest-path tree depe

Figure 25‑2: SPF tree for Router 6

Routing Table

The IP forwarding table formed in the routers and nodes can be accessed from the IP_Forwarding_Table list present in the Simulation Results window
as shown below:

Node-8: As shown in the below screenshot, Nose-8 has only one interface with IP 11.7.1.2 and its network address is 11.7.0.0 since its network mask is 255.255.0.0. The

first entry represents the router forwards packets intended to the subnet 11.7.0.0 to the interface with the IP 11.7.1.2. 239.12.14.5 is the multicast Group address and

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 119/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
224.0.0.1 is the address for all multicast routersThe IP forwarding table formed in the routers and nodes can be accessed from the
IP_Forwarding_Table list present in the Simulation Results window as shown below:

The tree gives the entire path to any destination network or host. However, only the next hop to the destination is used in the forwarding process. Note also that the best
route to any router has also been calculated. For the processing of external data, we note the next hop and distance to any router advertising external routes. The
resulting routing table for Router RT6 is shown in the following table

Destination Next hop Distance

N1 RT3 10

N2 RT3 10

N3 RT3 7

N4 RT3 8

N6 RT10 8

N7 RT10 12

N8 RT10 10

N9 RT10 11

N10 RT10 13

N11 RT10 14

H1 RT10 21

RT5 RT5 6

RT7 RT10 8

N12 RT10 10

N13 RT5 14

N14 RT5 14

N15 RT10 17

Table 25‑2: Routing Table for RT6

Distance calculation

Router6 has 3 interfaces i.e. RT3, RT5 and RT10. The distance obtained is 10 for destination N1 via RT3 interface. The packets from Router6 would reach N1 via RT3,

N3 and RT1. The cost assigned to routers in this path is 6+1+3 = 10 (cost can be seen in SPF tree for Router6). This is how distance is calculated.

25.3 Network Setup

Open NetSim and click on Examples > Experiments > Understand-the-working-of-OSPF > Sample-1 as shown below Figure 25‑3.

Figure 25‑3: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 25‑4.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 120/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 25‑4: Network topology showing IP Addresses in each Router interface and in end nodes

The above network was created in NetSim and it is similar to the network as per the OSPF RFC 2328 (Refer Pg. no. 19 - https://tools.ietf.org/html/rfc2328#page-23)

25.4 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 3 Wired Nodes and 27 Routers in the “Internetworks” Network Library.

Step 2: The Output Cost for all the Routers in the network is set as per the network shown in Figure 25‑5.

Figure 25‑5: Output Cost is set to 1 in WAN interface

Step 3: Packet Trace is enabled in the NetSim GUI, and hence we are able to track the route which the packets have chosen to reach the destination based on the
Output Cost that is set.

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar. A CBR Application is

generated from Wired Node 30 i.e. Source to Wired Node 27 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining 20000µs.
Additionally, the “Start Time(s)” parameter is set to 30, while configuring the application. This time is usually set to be greater than the time taken for OSPF Convergence
(i.e. Exchange of OSPF information between all the routers), and it increases as the size of the network increases.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 121/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

25.5 Output
The following image is a depiction of the shortest path first tree created in NetSim. This is for representational purposes and cannot be opened in NetSim. The blue color n

Figure 25‑6: SPF tree for Router 6

NOTE: NetSim, does not implement Link type3 (Link to Stub Network). Hence users would notice a slight difference between the SPF trees of RFC and NetSim.

The IP forwarding table formed in the routers can be accessed from the IP_Forwarding_Table list present in the Simulation Results window as shown below Figure 25‑7.

a) b)

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 122/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

d)
c)

Figure 25‑7: IP Forwarding Tables in Result Dashboard for RT 6

In this network, Router6 has 3 interfaces with IP’s 11.7.1.1, 11.6.1.2 and 11.17.1.1 and its network addresses are 11.7.0.0, 11.6.0.0 and 11.17.0.0 since its network mask
is 255.255.0.0

From the above screenshot, the router forwards packets intended to the subnet:

§ 11.1.1.2, 11.2.1.2, 11.3.1.2, 11.3.1.1, 11.4.1.1 via interface 11.7.1.1 with cost 7 (6+1)

§ Similarly 11.23.1.1, 11.4.1.2, 11.1.1.1, 11.2.1.1, 11.23.1.2 via interface 11.7.1.1 with cost 8 (6+1+1)

§ 11.15.1.1, 11.9.1.2, 11.10.1.1, 11.15.1.2 via interface 11.17.1.1 with cost 8 (7+1)

§ 11.9.1.1, 11.10.1.2 via interface 11.17.1.1 with cost 9 (7+1+1)

§ 11.29.1.2, 11.29.1.1 and 11.14.1.2 via interface 11.17.1.1 with cost 10 (7+3)

§ 11.24.1.2, 11.24.1.1 via interface 11.17.1.1 with cost 10 (7+1+2)

§ 11.18.1.2, 11.18.1.1, 11.19.1.2 and 11.19.1.1 via interface 11.7.1.1 with cost 10 (6+1+3)

§ 11.13.1.2, 11.11.1.1, 11.12.1.1, and 11.13.1.1 via interface 11.17.1.1 with cost 11 (7+3+1)

§ 11.8.1.1 via interface 11.6.1.2 with cost 12 (6+6)

§ 11.11.1.2 and 11.12.1.2 via interface 11.17.1.1 with cost 12 (7+3+1+1)

§ 11.17.1.2 via interface 11.17.1.1 with cost 12 (7+5)

§ 11.26.1.1 and 11.26.1.2 via interface 11.17.1.1 with cost 12 (7+1+4)

§ 11.14.1.1 via interface 11.17.1.1 with cost 12 (7+3+2)

§ 11.6.1.1 via interface 11.6.1.2 with cost 13 (7+6)

§ 11.27.1.1 and 11.27.1.2 via interface 11.17.1.1 with cost 13 (7+3+1+2)

§ 11.7.1.2 via interface 11.7.1.1 with cost 14 (8+6)

§ 11.5.1.2 via interface 11.6.1.2 with cost 14 (6+8)

§ 11.20.1.2, 11.20.1.1, 11.21.1.1, 11.21.1.2, 11.22.1.1, 11.22.1.2 via interface 11.6.1.2 with cost 14 (8+6)

§ 11.28.1.2 via interface 11.17.1.1 with cost 14 (7+1+6)

§ 11.28.1.1 via interface 11.17.1.1 with cost 14 (7+3+1+3)

§ 11.25.1.1, 11.25.1.2 via interface 11.17.1.1 with cost 17 (7+1+9)

§ 11.5.1.1 via interface 11.7.1.1 with cost 15 (6+1+8)

We are thus able to simulate the exact example as provided in the RFC and report that SPF Tree obtained and the routing costs match the analysis provided in the RFC.

26 Understand the working of basic networking commands (Ping, Route

Add/Delete/Print, ACL)
https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 123/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

26.1 Theory
NetSim allows users to interact with the simulation at runtime via a socket or through a file. User Interactions make simulation more realistic by allowing command
execution to view/modify certain device parameters during runtime.

Ping Command

§ The ping command is one of the most often used networking utilities for troubleshooting network problems

§ You can use the ping command to test the availability of a networking device (usually a computer) on a network

§ When you ping a device, you send that device a short message, which it then sends back (the echo)

§ If you receive a reply then the device is in the Network, if you don’t, then the device is faulty, disconnected, switched off, or incorrectly configured.

Route Commands

You can use the route commands to view, add and delete routes in IP routing tables

§ route print: In order to view the entire contents of the IP routing table

§ route delete: In order to delete all routes in the IP routing table

§ route add: In order to add a static TCP/IP route to the IP routing table

ACL Configuration

Routers provide basic traffic filtering capabilities, such as blocking the Internet traffic with access control lists (ACLs). An ACL is a sequential list of Permit or Deny
statements that apply to addresses or upper-layer protocols. These lists tell the router what types of packets to: PERMIT or DENY. When using an access-list to filter

traffic, a PERMIT statement is used to “allow” traffic, while a DENY statement is used to “block” traffic.

26.2 Network setup

Open NetSim and click Examples > Experiments > Basic-networking-commands-Ping-Route-Add/Delete/Print-and-ACL > Sample-1 as shown below Figure 26‑1.

Figure 26‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 26‑2.

Figure 26‑2: Network topology in the sample scenario

26.3 Procedure

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 124/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
The following set of procedures were done to generate this sample:
Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 3 Routers in the “Internetworks” Network Library.

Step 2: In the Network Layer properties of Wired Node 1, “ICMP Status” is set as TRUE.
Similarly, ICMP Status is set as TRUE for all the devices as shown Figure 26‑3.

Figure 26‑3: Network Layer properties of Wired Node 1

Step 3: In the General properties of Wired Node 1, Wireshark Capture is set as Online.

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.
A CBR Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining
20000µs. Transport Protocol is set to UDP.

Additionally, the “Start Time(s)” parameter is set to 30, while configuring the application. This time is usually set to be greater than the time taken for OSPF
Convergence (i.e. Exchange of OSPF information between all the routers), and it increases as the size of the network increases.
Step 5: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the packet information is available for the users to

perform packet level analysis. Plots are enabled in NetSim GUI.

Step 6: Click on Run Simulation. Simulation Time is set to 300 Seconds and in the Runtime Interaction tab Figure 26‑4, Interactive Simulation is set to True.

Figure 26‑4: Runtime Interaction window

NOTE: It is recommended to specify a longer simulation time to ensure that there is sufficient time for the user to execute the various commands and see the effect of that before the

Simulation ends.

Click on Accept and then click on OK.

§ Simulation (NetSimCore.exe) will start running and will display a message “waiting for first client to connect” as shown below Figure 26‑5.

Figure 26‑5: Waiting for first client to connect

§ Go back to the network scenario. Click on “Display Settings” in the top ribbon/toolbar and select the “Device IP” checkbox inorder to display the IP address of all
the devices. Now, Right click on Router 3 or any other Router and select “NetSim Console” option as shown Figure 26‑6.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 125/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 26‑6: Select NetSim Console

§ Now Client (NetSimCLI.exe) will start running and it will try to establish a connection with NetSimCore.exe. After the connection is established, the following will be

displayed Figure 26‑7.

Figure 26‑7: Connection established

§ After this the command line interface can be used to execute all the supported commands.

26.4 Network Commands

Ping Command

§ You can use the ping command with an IP address or Device name

§ ICMP_Status should be set as True in all nodes for ping to work

Ping <IP address> e.g. ping 11.4.1.2

Ping <Node Name> e.g. ping Wired_Node_2

Figure 26‑8: Pinging Wired_Node_2

Route Commands

§ In order to view the entire contents of the IP routing table, use following command route print

route print

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 126/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 26‑9: IP routing table

§ You’ll see the routing table entries with network destinations and the gateways to which packets are forwarded, when they are headed to that destination. Unless

you’ve already added static routes to the table, everything you see here is dynamically generated

§ In order to delete a route in the IP routing table you’ll type a command using the following syntax

route delete destination_network

§ So, to delete the route with destination network 11.5.1.2, all we’d have to do is type this command

route delete 11.5.1.2

§ To check whether route has been deleted or not check again using route print command

§ To add a static route to the table, you’ll type a command using the following syntax

route ADD destination_network MASK subnet_mask gateway_ip metric_cost interface

§ So, for example, if you wanted to add a route specifying that all traffic bound for the 11.5.1.2 subnet went to a gateway at 11.5.1.1

route ADD 11.5.1.2 MASK 255.255.0.0 11.5.1.1 METRIC 100 IF 2

§ If you were to use the route print command to look at the table now, you’d see your new static route.

Figure 26‑10: Route delete/ Route add

NOTE: Entry added in IP table by routing protocol continuously gets updated. If a user tries to remove a route via route delete command, there is always a chance that routing protocol will re-

enter this entry again. Users can use ACL / Static route to override the routing protocol entry if required.

ACL Configuration

Commands to configure ACL

§ To view ACL syntax: acl print

§ Before using ACL, we must first verify whether ACL option enabled. A common way to enable ACL is to use command: ACL Enable

§ Enter configuration mode of ACL: aclconfig

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 127/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
§ To view ACL Table: Print

§ To exit from ACL configuration: exit

§ To disable ACL: ACL Disable (use this command after exit from ACL Configuration)

To view ACL usage syntax use: acl print

[PERMIT, DENY] [INBOUND, OUTBOUND, BOTH] PROTO SRC DEST SPORT DPORT IFID

Step to Configure ACL

§ To create a new rule in the ACL use command as shown below to block UDP packet in Interface 2 and Interface 3 of Router 3.

§ Application properties à Transport Protocol à UDP as shown Figure 26‑11

Figure 26‑11: Application properties window

§ Use the command as follows Figure 26‑12.

NetSim>acl enable

ACL is enable

NetSim>aclconfig

ROUTER_3/ACLCONFIG>acl print

Usage: [PERMIT, DENY] [INBOUND, OUTBOUND, BOTH] PROTO SRC DEST SPORT DPORT IFID

ROUTER_3/ACLCONFIG>DENY BOTH UDP ANY ANY 0 0 2

OK!

ROUTER_3/ACLCONFIG>DENY BOTH UDP ANY ANY 0 0 3

OK!

ROUTER_3/ACLCONFIG>print

DENY BOTH UDP ANY/0 ANY/0 0 0 2

DENY BOTH UDP ANY/0 ANY/0 0 0 3

ROUTER_3/ACLCONFIG>exit

NetSim>acl disable

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 128/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
ACL is disable

NetSim>

Figure 26‑12: ACL Configuration command

Ping Command Results

Go to the Results Dashboard and click on “Open Packet Trace” option present in the Left-Hand-Side of the window and do the following:

Filter Control Packet Type/App Name to ICMP EchoRequest and ICMP EchoReply as shown Figure 26‑13.

Figure 26‑13: Packet Trace - ICMP Control Packets

In Wireshark, apply filter as ICMP. we can see the ping request and reply packets in Wireshark as shown Figure 26‑14.

Figure 26‑14: ICMP Control packets in Wireshark

ACL Results

The impact of ACL rule applied over the simulation traffic can be observed in the IP Metrics Table in the simulation results window. In Router 3, the number of packets

blocked by firewall has been shown below Figure 26‑15.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 129/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 26‑15: IP Metrics Table in result window

NOTE:Number of packets blocked may vary based on the time at which ACL is configured.

Users can also observe this in Packet Animation before and after the Packets are blocked as shown below Figure 26‑16/Figure 26‑17.

Figure 26‑16: In Animation Window before applying ACL rules see the packet flow

Figure 26‑17: In Animation Window after applying ACL rules see the packet flow
§ Check Packet animation window whether packets has been blocked in Router_3 or not after entering ACL command to deny UDP traffic

§ Before applying ACL rule there is packet flow from Wired_Node_1 to Wired_Node_2

§ After applying ACL rule Packet flows up to Router_3 only

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 130/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

27 To analyze how the allocation of frequency spectrum to the Incumbent

(Primary) and CR CPE (Secondary User) affects throughput

27.1 Introduction
An important component of the cognitive radio concept is the ability to measure, sense, learn, and be aware of the parameters related to the radio channel
characteristics, availability of spectrum and power, radio’s operating environment, user requirements and applications, available networks (infrastructures) and nodes,

local policies and other operating restrictions.

NetSim simulator models IEEE 802.22 Cognitive Radio per the theory explained below.

A spectrum hole has been defined as a band of frequencies assigned to a primary user, but at a particular time and specific geographic location, the band is not being

utilized by that user. Cognitive Radio was proposed as the means to promote the efficient use of spectrum by exploiting the existence of spectrum holes.

Figure 27‑1: Spectrum holes are used by SU for its transmission scheme is often referred to as opportunistic spectrum access (OSA)

These spectrum holes are used by the SU for its transmission. This scheme is often referred to as opportunistic spectrum access (OSA). No concurrent transmission of
the PU and the SU is allowed. The SU must vacate the channel as soon as the PU reappears, which leads to the forced termination of the SU connection (if there is no
other available channel for the SU). Since the SU has no control over the resource availability, the transmission of the SU is blocked when the channel is occupied by the

PU. The forced termination and blocking of a SU connection is shown in the below figure. The forced termination probability and blocking probability are the key
parameters which determine the throughput of the SU, and thus its viable existence. The forced termination depends on the traffic behavior of the PUs and the SUs (e.g.
arrival rates, service time etc.). In the case of multiple SU groups with different traffic statistics, the forced termination and blocking probabilities lead to unfairness among

the SU groups.

Figure 27‑2: Illustration of forced termination and blocking of a SU connection

Performance metrics

The different parameters used to analyze the performance are explained as follows:

§ Throughput: It is the rate of successfully transmitted data packets in unit time in the network during the simulation.

§ Spectral Efficiency: It refers to the information rate that can be transmitted over a given bandwidth in a specific communication system. It is a measure of how
efficiently a limited frequency spectrum is utilized by the physical layer protocol, and sometimes by the media access control protocol.

27.2 Network Setup

Open NetSim and click on Examples > Experiments > Cognitive-Radio-Impact-of-frequency-allocation-to-PU-and-SU-on-throughput > Sample-1 as shown below

Figure 27‑3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 131/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 27‑3: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 27‑4.

Figure 27‑4: Frequency allocation to PU and SU network topology

27.3 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Base Station and 2 CR CPE’s in the “Cognitive Radio” Network Library.

Step 2: The device positions are set as follows Table 27‑1.

Base Station 1 CR CPE 2 CR CPE 3

X/Lat 100 100 120

Y/Lon 100 120 100
Table 27‑1: Device positions

Step 3: In the Interface Cognitive Radio > Datalink Layer > Incumbment1, the following are set as shown below Figure 27‑5.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 132/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 27‑5: Datalink Layer properties window

Step 4: In the Interface Cognitive Radio > Physical Layer, the Min Frequency and Max Frequency parameters are set to 54 and 60 MHz respectively.

Step 5: Right click on the Application Flow App1 CUSTOM and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CUSTOM Application is generated from CR CPE 2 i.e. Source to CR CPE 3 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining
20000µs.

Step 6: Enable the plots and run the Simulation for 100 Seconds.

Sample 2

The following changes in settings are done from the previous sample:

Step 1: In the Interface Cognitive Radio > Physical Layer, the Min Frequency and Max Frequency parameters are set to 54 and 90 MHz respectively.

Step 2: Enable the plots and run the Simulation for 100 Seconds.

27.4 Output
Once after the simulation is complete, go to the Results Dashboard and check the “Application Metrics” Table. Throughput of the application will be 0.

In the Left-Hand-Side of the Results Dashboard Figure 27‑6/Figure 27‑7, click on the arrow pointer indicating “CR Metrics”, from the drop down select the “Channel
Metrics” which gives you the Spectral Efficiency.

Sample 1

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 133/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 27‑6: Results of Sample 1

Sample 2

Figure 27‑7: Results of Sample 2

27.5 Inference
In both the samples, the Secondary User (CR-CPE) lies within the operational region of Primary User (Incumbent), hence the frequency spectrum used by operational
Primary User (Incumbent) will not be used by Secondary User (CR-CPE). Also the Operational Interval under Incumbent is set to zero, i.e., the Incumbent will

continuously use the channel allocated to it.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 134/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
In the first sample, both the Primary User (Incumbent) and the Secondary User (CR-CPE) has been allocated the same channel (frequency band of 54 - 60 MHz). As
Incumbent will continuously use the channel allocated to it, so there will be no Spectrum Hole, hence the secondary user will not be able to transmit any data in an

opportunistic manner. Therefore, the throughput of the application in the CR-CPE and the spectral efficiency is almost equal to zero.

In the second sample, the Primary User (Incumbent) has been allocated frequency band of 54 - 60 MHz and the Secondary User (CR-CPE) has been allocated the
frequency band of 54 - 90 MHz Incumbent will continuously use the channel allocated to it, but the rest channels will remain free i.e. there will be Spectrum Hole, which

the CR-CPE will utilize to transmit data.

NOTE: The results are highly dependent on position/velocity/ traffic etc. Any modifications with the above-mentioned input parameters will change the final output result.

28 Simulate and study 5G Handover procedure

28.1 Introduction
The handover logic of NetSim 5G library is based on the Strongest Adjacent Cell Handover Algorithm (Ref: Handover within 3GPP LTE: Design Principles and
Performance. Konstantinos Dimou. Ericcson Research). The algorithm enables each UE to connect to that gNB which provides the highest Reference Signal Received
Power (RSRP). Therefore a handover occurs the moment a better gNB (adjacent cell has offset stronger RSRP, measured as SNR in NetSim) is detected.

This algorithm is similar to 38.331, 5.5.4.4 Event A3 wherein Neighbor cell’s RSRP becomes Offset better than serving cell’s RSRP. Note that in NetSim report-type
is periodical and not eventTrigerred since NetSim is a discrete event simulator and not a continuous time simulator.

This algorithm is susceptible to ping-pong handovers; continuous handovers between the serving and adjacent cells on account of changes in RSRP due mobility and

shadow-fading. At one instant the adjacent cell's RSRP could be higher and the very next it could be the original serving cell's RSRP, and so on.

To solve this problem the algorithm uses:

a) Hysteresis (Hand-over-margin, HOM) which adds a RSRP threshold (Adjacent_cell_RSRP - Serving_cell_RSRP > Hand-over-margin or hysteresis), and

b) Time-to-trigger (TTT) which adds a time threshold

This HOM is part of NetSim implementation while TTT can be implemented as a custom project in NetSim.

28.2 Network Setup

Open NetSim and click Examples > Experiments > 5G-Handover-procedure as shown below Figure 28‑1.

Figure 28‑1: Experiments List

28.3 Part-I
NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 28‑2.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 135/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 28‑2: Scenario for studying 5G handover

28.3.1 Procedure

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 5G-Core devices, 2 gNBs, and 2 UEs in the “5G NR” Network Library.

Step 2: The device positions are set as per the table given below Table 28‑1.

gNB 7 gNB 8 UE 9 UE 10
X Co-ordinate 500 4500 500 4500
Y Co-ordinate 1500 1500 3000 3000
Table 28‑1: Device positions

Step 3: In the General Properties of UE 9 and UE 10, set Mobility Model as File Based Mobility.

Step 4: Right click on the gNB 7 and select Properties, the following is set Figure 28‑3.

Interface(5G_RAN) Properties
CA_Type Single Band
CA_Configuration n78
CA_Count 1
Numerology 0
Channel Bandwidth(MHz) 10
PRB Count 52
MCS Table QAM64
CQI Table Table 1
X_Overhead XOH0
DL UL Ratio 4:1
Pathloss Model 3GPPTR38.901-7.4.1
Outdoor Scenario Urban Macro
LOS_NLOS_Selection User_Defined
LOS Probability 1
Shadow Fading Model None
Fast Fading Model None
O2I Building Penetration Model LOW_LOSS_MODEL
Additional Loss Model None
Table 28‑2 : gNB > 5G_RAN Interface Properties

Similarly, it is set for gNB 8.

Step 5: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from UE 9 i.e. Source to UE 10 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining 20000µs. QOS is
set to UGS.

Additionally, the “Start Time(s)” parameter is set to 40, while configuring the application.

File Based Mobility:

In File Based Mobility, users can write their own custom mobility models and define the movement of the mobile users. Create a mobility.txt file for UE’s involved in
mobility with each step equal to 0.5 sec with distance 50 m.

The NetSim Mobility File (mobility.txt) format is as follows:

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 136/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
#Initial position of the UE 9

$node_(8) set X_ 500.0

$node_(8) set Y_ 3000.0

$node_(8) set Z_ 0.0

#Initial position of the UE 10

$node_(9) set X_ 4500.0

$node_(9) set Y_ 3000.0

$node_(9) set Z_ 0.0

#Positions of the UE 9 at specific time

$time 0.0 "$node_(8) 500.0 3000.0 0.0"

$time 0.5 "$node_(8) 1000.0 3000.0 0.0"

$time 1.0 "$node_(8) 1050.0 3000.0 0.0"

$time 1.5 "$node_(8) 1100.0 3000.0 0.0"

$time 2.0 "$node_(8) 1150.0 3000.0 0.0"

$time 2.5 "$node_(8) 1200.0 3000.0 0.0"

$time 3.0 "$node_(8) 1250.0 3000.0 0.0"

$time 3.5 "$node_(8) 1300.0 3000.0 0.0"

$time 4.0 "$node_(8) 1350.0 3000.0 0.0"

$time 4.5 "$node_(8) 1400.0 3000.0 0.0"

$time 5.0 "$node_(8) 1450.0 3000.0 0.0"

$time 5.5 "$node_(8) 1500.0 3000.0 0.0"

$time 6.0 "$node_(8) 1550.0 3000.0 0.0"

$time 6.5 "$node_(8) 1600.0 3000.0 0.0"

$time 7.0 "$node_(8) 1650.0 3000.0 0.0"

$time 7.5 "$node_(8) 1700.0 3000.0 0.0"

$time 8.0 "$node_(8) 1750.0 3000.0 0.0"

$time 8.5 "$node_(8) 1800.0 3000.0 0.0"

$time 9.0 "$node_(8) 1850.0 3000.0 0.0"

$time 9.5 "$node_(8) 1900.0 3000.0 0.0"

$time 10.0 "$node_(8) 1950.0 3000.0 0.0"

$time 10.5 "$node_(8) 2000.0 3000.0 0.0"

$time 11.0 "$node_(8) 2050.0 3000.0 0.0"

$time 11.5 "$node_(8) 2100.0 3000.0 0.0"

$time 12.0 "$node_(8) 2150.0 3000.0 0.0"

$time 12.5 "$node_(8) 2200.0 3000.0 0.0"

$time 13.0 "$node_(8) 2250.0 3000.0 0.0"

$time 13.5 "$node_(8) 2300.0 3000.0 0.0"

$time 14.0 "$node_(8) 2350.0 3000.0 0.0"

$time 14.5 "$node_(8) 2400.0 3000.0 0.0"

$time 15.0 "$node_(8) 2450.0 3000.0 0.0"

$time 15.5 "$node_(8) 2500.0 3000.0 0.0"

$time 16.0 "$node_(8) 2550.0 3000.0 0.0"

$time 16.5 "$node_(8) 2600.0 3000.0 0.0"

$time 17.0 "$node_(8) 2650.0 3000.0 0.0"

$time 17.5 "$node_(8) 2700.0 3000.0 0.0"

$time 18.0 "$node_(8) 2750.0 3000.0 0.0"

$time 18.5 "$node_(8) 2800.0 3000.0 0.0"

$time 19.0 "$node_(8) 2850.0 3000.0 0.0"

$time 19.5 "$node_(8) 2900.0 3000.0 0.0"

$time 20.0 "$node_(8) 2950.0 3000.0 0.0"

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 137/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
$time 20.5 "$node_(8) 3000.0 3000.0 0.0"

$time 21.0 "$node_(8) 3050.0 3000.0 0.0"

$time 22.0 "$node_(8) 3100.0 3000.0 0.0"

$time 23.0 "$node_(8) 3150.0 3000.0 0.0"

$time 24.0 "$node_(8) 3200.0 3000.0 0.0"

$time 25.0 "$node_(8) 3250.0 3000.0 0.0"

$time 26.0 "$node_(8) 3300.0 3000.0 0.0"

$time 27.0 "$node_(8) 3350.0 3000.0 0.0"

$time 28.0 "$node_(8) 3400.0 3000.0 0.0"

$time 29.0 "$node_(8) 3450.0 3000.0 0.0"

$time 30.0 "$node_(8) 3500.0 3000.0 0.0"

$time 31.0 "$node_(8) 3550.0 3000.0 0.0"

$time 32.0 "$node_(8) 3600.0 3000.0 0.0"

$time 33.0 "$node_(8) 3650.0 3000.0 0.0"

$time 34.0 "$node_(8) 3700.0 3000.0 0.0"

$time 35.0 "$node_(8) 3750.0 3000.0 0.0"

$time 36.0 "$node_(8) 3800.0 3000.0 0.0"

$time 37.0 "$node_(8) 3850.0 3000.0 0.0"

$time 38.0 "$node_(8) 3900.0 3000.0 0.0"

$time 39.0 "$node_(8) 3950.0 3000.0 0.0"

$time 40.0 "$node_(8) 4000.0 3000.0 0.0"

Step 6: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the packet information is available for the users to
perform packet level analysis. Plots is enabled in NetSim GUI.

Step 7: The log file can enable per the information provided section 3.15 5G-NR technology library document.

Step 8: Run the Simulation for 50 Seconds.

28.3.2 Results and Discussion

28.3.2.1 Handover Signaling

Figure 28‑3: Control packet flow in the 5G handover process

The packet flow depicted above can be observed from the packet trace

1. UE will send the UE_MEASUREMENT_REPORT every 120 ms to the connected gNB

2. The initial UE- gNB connection and UE association with the core takes place by transferring the RRC and Registration, session request response packets.

3. As Per the configured file-based mobility, UE 9 moves towards gNB 8.

4. After 18.6 s gNB 7sends the HANDOVER REQUEST to gNB 8.

5. gNB 8 sends back HANDOVER REQUEST ACK to gNB 7.

6. After receiving HANDOVER REQUEST ACK from gNB 8, gNB 7 sends the HANDOVER COMMAND to UE 9

7. After the HANDOVER COMMAND packet is transferred to the UE, the target gNB will send the PATH SWITCH packet to the AMF via Switch 5

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 138/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
8. When the AMF receives the PATH SWITCH packet, it sends MODIFY BEARER REQUEST to the SMF

9. The SMF on receiving the MODIFY BEARER REQUEST provides an acknowledgement to the AMF

10. On receiving the MODIFY BEARER RESPONSE from the SMF, AMF acknowledges the Path switch request sent by the target gNB by sending the PATH
SWITCH ACK packet back to the target gNB via Switch 5

11. The target gNB sends CONTEXT RELEASE to source gNB, and the source gNB sends back CONTEXT RELEASE ACK to target gNB. The context release

request and ack packets are sent between the source and target gNB via Switch 6.

12. RRC Reconfiguration will take place between target gNB and UE 9

13. The UE 9 will start sending the UE MEASUREMENT REPORT to gNB 8

Figure 28‑4: Screen shot of NetSim packet trace file showing the control packets involved in handover. Some columns have been hidden before the last column

28.3.2.2 Plot of SNR vs. Time

Figure 28‑5: Plot of DL SNR (at UE_3 from gNB1 and gNB2) vs time. The handover process shown in Figure 28‑3 .commences when Adj_cell_SNR > Serving_cell_SNR +

Hand_over_Margin

This plot can be got from the LTENRLog file. However, it would involve a fair amount of time and effort. Users can analyze the log file and see

§ Time 15.60s when the SNR from gNB7 is 12.74dB and the SNR from gNB8 is 12.74dB. This represents the point where the two curves intersect.

§ Time 18s when the SNR from gNB7 is 11.38dB and the SNR from gNB8 is 14.15dB. This represents the point where Adj cell RSRP is greater than serving cell
RSRP by Hand-over-margin (HOM) of 3dB.

28.4 Part-II: Throughput and delay variation during handover

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 28‑7.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 139/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Figure 28‑6: Network scenario for handover study

28.4.1 Procedure:

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 2 gNBs, 5G Core, 1 Router, 1 Wired Node and 2 UEs in the “5G NR” Network Library.

Step 2: The device positions are set as per the table given below Table 28‑3.

gNB 7 gNB 8 UE 9 UE 10
X Co-ordinate 500 4500 500 4500
Y Co-ordinate 500 500 1000 1000
Table 28‑3: Device positions

Step 3: Right click on the gNB 9 and select Properties, the following is set.

Interface(5G_RAN) Properties
CA_Type Single Band
CA_Configuration n78
CA_Count 1
Numerology 0
Channel Bandwidth (MHz) 10
PRB Count 52
MCS Table QAM64
CQI Table Table 1
X_Overhead XOH0
DL UL Ratio 4:1
Pathloss Model 3GPPTR38.901-7.4.1
Outdoor Scenario Urban Macro
LOS_NLOS Selection User_Defined
LOS Probability 1
Shadow Fading Model None
Fast Fading Model None
O2I Building Penetration Model LOW_LOSS_MODEL
Additional Loss Model None
Table 28‑4: gNB > Interface(5G_RAN) Properties Setting

Similarly, it is set for gNB 8.

Step 4: The Tx_Antenna_Count was set to 2 and Rx_Antenna_Count was set to 1 in gNB > Interface (5G_RAN) > Physical Layer.

Step 5: The Tx_Antenna_Count was set to 1 and Rx_Antenna_Count was set to 2 in UE > Interface (5G_RAN) > Physical Layer.

Step 6: In the General Properties of UE 9 and UE 10, set Mobility Model as File Based Mobility.

Step 7: The BER and propagation delay was set to zero in all the wired links.

Step 8: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 12 i.e. Source to UE 9 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining 233.6µs.

QOS is set to BE.

Additionally, the “Start Time(s)” parameter is set to 1, while configuring the application.

File Based Mobility:

In File Based Mobility, users can write their own custom mobility models and define the movement of the mobile users. Create a mobility.txt file for UE’s involved in
mobility with each step equal to 0.5 sec with distance 50 m.

The NetSim Mobility File (mobility.txt) format is as follows:

The NetSim Mobility File (mobility.txt) format is as follows:

#Initial position of the UE 9

$node_(8) set X_ 500.0

$node_(8) set Y_ 1000.0

$node_(8) set Z_ 0.0

#Initial position of the UE 10

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 140/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
$node_(9) set X_ 4500.0

$node_(9) set Y_ 1000.0

$node_(9) set Z_ 0.0

#Positions of the UE 9 at specific time

$time 0.0 "$node_(8) 500.0 1000.0 0.0"

$time 0.5 "$node_(8) 750.0 1250.0 0.0"

$time 1.0 "$node_(8) 1000.0 1500.0 0.0"

$time 1.5 "$node_(8) 1250.0 1750.0 0.0"

$time 2.0 "$node_(8) 1500.0 2000.0 0.0"

$time 2.5 "$node_(8) 1750.0 2250.0 0.0"

$time 3.0 "$node_(8) 2000.0 2500.0 0.0"

$time 3.5 "$node_(8) 2250.0 2750.0 0.0"

$time 4.0 "$node_(8) 2500.0 3000.0 0.0"

$time 4.5 "$node_(8) 2750.0 2750.0 0.0"

$time 5.0 "$node_(8) 3250.0 2250.0 0.0"

$time 5.5 "$node_(8) 3500.0 2000.0 0.0"

$time 6.0 "$node_(8) 3750.0 1750.0 0.0"

$time 6.5 "$node_(8) 4000.0 1500.0 0.0"

$time 7.0 "$node_(8) 4250.0 1250.0 0.0"

$time 7.5 "$node_(8) 4500.0 500.0 0.0"

Step 9: Packet Trace and Event Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the packet information is available for
the users to perform packet level analysis. Plots is enabled in NetSim GUI.

Step 10: The log file can enable per the information provided in section 3.15 5G NR technology library document.

Step 11: Run the Simulation for 12 Seconds.

28.4.2 Computing delay and throughput

28.4.2.1 Delay computation from Event Traces

NOTE: Follow the article link given below, to generate pivot table for large Packet Trace and Event Trace files

How to generate pivot reports for large packet trace and event trace files?

1. Open Event Trace after simulation.

2. Goto Insert option at the top ribbon of the trace window and select Pivot Tables.

3. In the window which arises, you can see Table_1. Click on OK.

4. This will create a new sheet with Pivot Table as shown below Figure 28‑7.

Figure 28‑7: Blank Pivot Table

5. Now drag and drop Packet_Id to Rows field. Similarly, drag and drop the following: Event_Type to Columns field, Event_Time to Values field as shown Figure
28‑8.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 141/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 28‑8: Adding fields into Columns, Rows and Values

6. Now in the Pivot table formed, filter Event_Type to APPLICATION_IN and APPLICATION_OUT as shown Figure 28‑9.

Figure 28‑9: Event Type filtered to APPLICATION_IN and APPLICATION_OUT to calculate delay

7. In the Values field in the Pivot Table Fields, Click on Sum of Event Time (US) and select Value Field Settings as shown Figure 28‑10.

Figure 28‑10: Value Field Settings to Sum of Event Time

8. Select Show Values As option and filter it to Difference From as shown Figure 28‑11.

Figure 28‑11: Select Show Values as Difference From

9. In the Base field, select Event_Type and in the Base_item field select APPLICATION_OUT and click on OK. This will provide the end-to-end delay in the pivot
table.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 142/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 28‑12: Select Base field to Event Type and Base item to APPLICATION OUT

10. Now ignore the negative readings in the Delay values(Figure 28‑13) obtained and use these values to plot the Delay vs Time (APPLICATION_IN) graph.

Figure 28‑13: Ignore the negative values in the Delay

11. In the Event trace window, filter the Event Type to APPLICATION_IN and use the Event Time thus obtained as the x-axis of the plot.

Figure 28‑14: Event Trace

28.4.3 Results and Discussion

UDP Throughput Plot

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 143/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 28‑15: Plot of Throughput vs. Time

The application starts at 1s. The generation rate is 50 Mbps and we see the network is able to handle this load, and the throughput is equal to the generation rate. We

then observe that the throughput starts dropping from 3s onwards because the UE is moving away from the gNB. As it moves as the SNR falls, and therefore a lower
MCS is chosen leading to reduced throughput. At 4s there is a further drop in throughput and then a small final dip at 5s. The time the handover occurs is 5.04 sec. At
this point we see the throughput starts increasing once UE attaches to gNB2. The throughput for a short period of time is greater than 50 Mbps because of the

transmission of queued packets in the network.

UDP Delay Plot

Figure 28‑16: Plot of Delay vs. Time

Since the application starts at 1s, the UDP plot begins at 1000 ms. The initial UDP delay is , and hence the curve is seen as close to 0 on the Y axis. We then see

that the packet delay starts increasing as the UE moves away from the gNB. The peak delay experienced shoots up to 1100ms at 5s when the handover occurs.

Once the handover is complete the delay starts reducing and returns to

29 Understanding VLAN operation in L2 and L3 Switches

29.1 Introduction to VLAN
VLAN is called as virtual local area network, used in Switches and it operates at Layer 2 and Layer 3. A VLAN is a group of hosts which communicate as if they were
attached to the same broadcast domain, regardless of their physical Location.

For example, all workstations and servers used by a particular workgroup team can be connected to the same VLAN, regardless of their physical connections to the

network or the fact that they might be intermingled with other teams. VLANs have the same attributes as physical LANs, but you can group end stations even if they are
not physically located on the same LAN Segment.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 144/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 29‑1: Virtual local area network (VLAN)

A VLAN behaves just like a LAN in all respects but with additional flexibility. By using VLAN technology, it is possible to subdivide a single physical switch into several
logical switches. VLANs are implemented by using the appropriate switch configuration commands to create the VLANs and assign specific switch interfaces to the

desired VLAN.

Switches implement VLANs by adding a VLAN tag to the Ethernet frames as they enter the switch. The VLAN tag contains the VLAN ID and other information, which is
determined by the interface from which the frame enters the switch. The switch uses VLAN tags to ensure that each Ethernet frame is confined to the VLAN to which it
belongs based on the VLAN ID contained in the VLAN tag. The VLAN tags are removed as the frames exit the switch on the way to their destination.

Any port can belong to a VLAN, and unicast, broadcast, and multicast packets are forwarded and flooded only to end stations in that VLAN. Each VLAN is considered a
logical network. Packets destined for stations that do not belong to the VLAN must be forwarded through a router.

In the below screenshot, the stations in the development department are assigned to one VLAN, the stations in the marketing department are assigned to another VLAN,

and the stations in the testing department are assigned to another VLAN.

Figure 29‑2: Hosts in one VLAN need to communicate with hosts in another VLAN This is known as Inter-VLAN routing.

VLANs divide broadcast domains in a LAN environment. Whenever hosts in one VLAN need to communicate with hosts in another VLAN, the traffic must be routed
between them. This is known as Inter-VLAN routing. This can be possible by using L3 Switch.

What is a layer 3 switch?

Layer 3 switch (also known as a multi-layer switch) is a multi-functional device that have the same functionality like a layer 2 switch, but behaves like a router when
necessary. It’s generally faster than a router due to its hardware based routing functions, but it’s also more expensive than a normal switch.

29.2 Network setup

Open NetSim and click Examples > Experiments > Understanding-VLAN-operation-in-L2-and-L3-Switches > Sample-1 as shown below

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 145/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 29‑3: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 29‑4.

Figure 29‑4: Intra-VLAN Network topology

29.3 Procedure
Sample 1: Intra-VLAN

Intra-VLAN is a mechanism in which hosts in same VLAN can communicate to each other.

The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 3 Wired Nodes and 1 L2 Switch in the “Internetworks” Network Library.

Step 2:L2 Switch 1 Properties are configured as follows Table 29‑1.

Switch 1

Interface ID VLAN Status VLAN ID VLAN Port Type

Interface_1 TRUE 2 Access _Port

Interface_2 TRUE 2 Access _Port
Interface_3 TRUE 3 Access _Port

Table 29‑1: L2 Switch 1 Properties

In all the INTERFACE (ETHERNET) > DATALINK LAYER Properties of L2 Switch 1, “VLAN Status” is set to TRUE.

Figure 29‑5: DATALINK LAYER Properties of L2 Switch 1

Now click on “Configure VLAN” option and the VLAN 2 fields are entered as shown below Figure 29‑6.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 146/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 29‑6: VLAN Configure window

To add a new entry after entering the required fields, click on the ADD button.

Figure 29‑7: Configuring VLAN Properties in VLAN 2

To configure another VLAN, click on the “+” symbol located in the top.

Figure 29‑8: Configuring VLAN Properties inS VLAN 3

And then we can add the entry to it.

Step 3: Enable the plots and run simulation for 10 Seconds and observe the throughputs.

Sample 2: Inter-VLAN

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 147/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 29‑9.

Figure 29‑9: Inter-VLAN Network topology

The following set of procedures were done to generate this sample:
Step 1: A network scenario is designed in NetSim GUI comprising of 5 Wired Nodes and 1 L3 Switch in the “Internetworks” Network Library.
Step 2: The Wired Node properties are set as per the below Table 29‑2.
Wired Wired Wired Wired Wired
Node2 Node3 Node4 Node5 Node6
Node
I/f1_Ethernet I/f1_Ethernet I/f1_Ethernet I/f1_Ethernet I/f1_Ethernet
IP
10.0.0.4 10.1.0.4 11.2.0.4 11.3.0.4 11.4.0.4
Address
Default
10.0.0.3 10.1.0.3 11.2.0.3 11.3.0.3 11.4.0.3
Gateway
Table 29‑2: Wired Node properties

Step 3:The L3 Switch 1 Properties are set as per the below table:

I/f1_Ethernet I/f2_Ethernet I/f3_Ethernet I/f4_Ethernet I/f5_Ethernet

L3
Switch IP Address IP Address IP Address IP Address IP Address

L3
Switch 10.0.0.3 10.1.0.3 11.2.0.3 11.3.0.3 11.4.0.3
1
Table 29‑3: L3 Switch 1 Properties

L3 Switch 1
Interface ID VLAN Status VLAN ID VLAN Port Type
Interface_1 TRUE 2 Access _Port
Interface_2 TRUE 2 Access _Port
Interface_3 TRUE 3 Access _Port
Interface_4 TRUE 3 Access _Port
Interface_5 TRUE 3 Access _Port
Table 29‑4: VLAN configurations Properties

The VLAN configurations done are shown as follows:

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 148/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Figure 29‑10: Configuring VLAN Properties in VLAN 2

Figure 29‑11: Configuring VLAN Properties in VLAN 3

Step 3: Plots are enabled in NetSim GUI. Run simulation for 10 seconds and observe the throughputs.

29.4 Output and Inference: I

Throughput (Mbps)
Application 1 0.58
Application 2 0
Table 29‑5: Results Comparison

The throughput for 2nd application is zero because the source and destination is in different VLANs, thereby traffic flow or communication between 2 VLANs using

Layer2 switch is not possible. To overcome this problem, an L3 switch is used.

29.5 Output and Inference: II

Throughput (Mbps)
Application 1 0.58
Application 2 0.58
Application 3 0.58
Table 29‑6: Results Comparison

In this case, application1 is in VLAN2, application2 is in VLAN3 and application 3 is in between VLAN2 and VLAN3. From the above results, the throughput for

application 3 (different VLANs) is non zero, because of using L3 switch. So, communication between 2 VLANs is possible using L3 Switch.

30 Understanding Access and Trunk Links in VLANs

30.1 Theory
The links connecting the end devices are called access links. These are the links usually carrying the Data VLAN information. The link between the switches is

called trunk link. It carries packets from all the VLANs.

Figure 30‑1: Understanding Access and Trunk Links in VLANs

Access link

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 149/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Access link connection is the connection where switch port is connected with a device that has a standardized Ethernet NIC. Standard NIC only understand IEEE 802.3
or Ethernet II frames. Access link connection can only be assigned with single VLAN. That means all devices connected to this port will be in same broadcast domain.

For example twenty users are connected to a hub, and we connect that hub with an access link port on switch, then all of these users belong to same VLAN. If we want
to keep ten users in another VLAN, then we need to plug in those ten users to another hub and then connect it with another access link port on switch.

Trunk link

Trunk link connection is the connection where switch port is connected with a device that is capable to understand multiple VLANs. Usually trunk link connection is used
to connect two switches. A VLAN can span anywhere in network, and that can happen due to trunk link connection. Trunking allows us to send or receive VLAN
information across the network. To support trunking, original Ethernet frame is modified to carry VLAN information.

30.2 Network Setup

Open NetSim and click Examples > Experiments > Understanding-Access-and-Trunk-Links-in-VLANs as shown below Figure 30‑2.

Figure 30‑2: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 30‑3.

Figure 30‑3: Network Topology in this experiment

30.3 Procedure
The following set of procedures were done to generate this sample:
Step 1: A network scenario is designed in NetSim GUI comprising of 4 Wired Nodes and 2 L2 Switches in the “Internetworks” Network Library.
Step 2: In the INTERFACE (ETHERNET) > NETWORK LAYER Properties, set the following Table 30‑1.
Wired Node 3 Wired Node 4 Wired Node 5 Wired Node 6
Node
I/f1_Ethernet I/f1_Ethernet I/f1_Ethernet I/f1_Ethernet
192.168.1.3 192.168.1.4 192.168.2.3 192.168.2.4
IP Address

Default 192.168.1.1 192.168.1.2 192.168.2.1 192.168.2.2

Gateway
Subnet
255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0
Mask
Table 30‑1: Network Layer Properties

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 150/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
NOTE: The subnet mask of all L3 Switch interfaces is set to 255.255.255.0
Step 3:L3 Switch 1 and L3 Switch 2 properties are set as follows:

I/f1_Ethernet I/f2_Ethernet I/f3_Ethernet

Switch
IP Address IP Address IP Address
L3 Switch 1 192.168.1.1 192.168.3.1 192.168.2.1

192.168.1.2 192.168.3.2 192.168.2.2

L3 Switch 2
Table 30‑2: L3 Switch 1 and L3 Switch 2 properties

Figure 30‑4: Datalink layer properties window

L3 Switch 1
VLAN Port
Interface ID VLAN Status VLAN ID
Type
Interface_1 TRUE 2 Access _Port
Interface_2 TRUE 1 Trunk _Port
Interface_3 TRUE 3 Access _Port
Table 30‑3: VLAN Properties for L3 Switch 1

L3 Switch 2
VLAN Port
Interface ID VLAN Status VLAN ID
Type
Interface_1 TRUE 2 Access _Port
Interface_2 TRUE 1 Trunk _Port
Interface_3 TRUE 3 Access _Port
Table 30‑4: VLAN Properties for L3 Switch 2

Step 4: In the INTERFACE (ETHERNET) > DATALINK LAYER Properties of L3 Switch 1, Click on “Configure VLAN” to view the properties for VLAN 2 set as per the
screenshot shown below Figure 30‑5.

Figure 30‑5: Configuring VLAN Properties in VLAN 2

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 151/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Properties for VLAN 3 is set as per the below screenshot Figure 30‑6.

Figure 30‑6: Configuring VLAN Properties in VLAN 3

After setting the properties of VLAN2 and VLAN3 click on OK.

Step 5: In the NETWORK LAYER Properties of L3 Switch 1, Click on “Configure Static Route IP” to set static route as per the screenshot shown below Figure 30‑7.

Figure 30‑7: Select Configure Static Route IP

Set the properties in Static Route IP window as per the screenshot below and click on Add.

Click on OK

Figure 30‑8: Configure Static route in Static Route IP window

NOTE: Transport Protocol is set to UDP in Application properties.

Step 6: Enable the plots and run simulation for 10 seconds and observe the throughput.

30.4 Output

Throughput (Mbps)
Application 1 0.58

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 152/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Application 2 0.58
Table 30‑5: Results Comparison

The above results conclude that trunking allows us to send or receive any VLAN information across the network.

31 Understanding Public IP Address & NAT (Network Address Translation)

31.1 Theory
31.1.1 Public Address

A public IP address is assigned to every computer that connects to the Internet where each IP is unique. Hence there cannot exist two computers with the same public IP
address all over the Internet. This addressing scheme makes it possible for the computers to “find each other” online and exchange information. User has no control over

the IP address (public) that is assigned to the computer. The public IP address is assigned to the computer by the Internet Service Provider as soon as the computer is
connected to the Internet gateway.

31.1.2 Private Address

An IP address is considered private if the IP number falls within one of the IP address ranges reserved for private networks such as a Local Area Network (LAN). The
Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks (local networks):

Class Starting IP address Ending IP address No. of hosts

A 10.0.0.0 10.255.255.255 16,777,216

B 172.16.0.0 172.31.255.255 1,048,576

C 192.168.0.0 192.168.255.255 65,536

Table 31‑1: Private IP address table

Private IP addresses are used for numbering the computers in a private network including home, school and business LANs in airports and hotels which makes it
possible for the computers in the network to communicate with each other. For example, if a network A consists of 30 computers each of them can be given an IP starting

from 192.168.0.1 to 192.168.0.30.

Devices with private IP addresses cannot connect directly to the Internet. Likewise, computers outside the local network cannot connect directly to a device with a private
IP. It is possible to interconnect two private networks with the help of a router or a similar device that supports Network Address Translation.

If the private network is connected to the Internet (through an Internet connection via ISP) then each computer will have a private IP as well as a public IP. Private IP is
used for communication within the network whereas the public IP is used for communication over the Internet.

31.1.3 Network address translation (NAT)

A NAT (Network Address Translation or Network Address Translator) is the virtualization of Internet Protocol (IP) addresses. NAT helps to improve security and decrease
the number of IP addresses an organization needs.

A device that is configured with NAT will have at least one interface to the inside network and one to the outside network. In a typical environment, NAT is configured at

the exit device between a stub domain (inside network) and the backbone. When a packet leaves the domain, NAT translates the locally significant source address into a
globally unique address. When a packet enters the domain, NAT translates the globally unique destination address into a local address. If more than one exit point
exists, each NAT must have the same translation table. NAT can be configured to advertise to the outside world only one address for the entire network. This ability

provides additional security by effectively hiding the entire internal network behind that one address. If NAT cannot allocate an address because it has run out of
addresses, it drops the packet and sends an Internet Control Message Protocol (ICMP) host unreachable packet to the destination.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 153/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 31‑1: NAT implementation

NAT is secure since it hides network from the Internet. All communications from internal private network are handled by the NAT device, which will ensure all the
appropriate translations are performed and provide a flawless connection between internal devices and the Internet.

In the above figure, a simple network of 4 hosts and one router that connects this network to the Internet. All hosts in the network have a private Class C IP Address,

including the router's private interface (192.168.0.1), while the public interface that's connected to the Internet has a real IP Address (203.31.220.134). This is the IP
address the Internet sees as all internal IP addresses are hidden.

31.2 Network Setup

Open NetSim and click Examples > Experiments > Understanding-Public-IP-Address-and-NAT-(Network-Address-Translation) > Sample-1 as shown below
Figure 31‑2.

Figure 31‑2: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 31‑3.

Figure 31‑3: Application flow between different LAN

31.3 Procedure
The following set of procedures were done to generate this sample:

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 154/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Step 1: A network scenario is designed in NetSim GUI comprising of 6 Wired Nodes, 2 L2 Switches, and 4 Routers in the “Internetworks” Network Library.

Step 2: In the INTERFACE (ETHERNET) > NETWORK LAYER of the Wired Nodes, the IP Address and the Subnet Mask are set as per the table given below Table 31‑2.

Wired Node IP address Subnet mask

7 10.0.0.2 255.0.0.0
8 10.0.0.3 255.0.0.0
9 10.0.0.4 255.0.0.0
10 172.16.0.2 255.255.0.0
11 172.16.0.3 255.255.0.0
12 172.16.0.4 255.255.0.0
Table 31‑2: IP Address and the Subnet mask for Wired nodes

Step 3: The IP Address and the Subnet Mask in Routers are set as per the table given below Table 31‑3.

Router Interface IP address Subnet mask

Interface_2(WAN) 11.1.1.1 255.0.0.0

Router 1
Interface_1(Ethernet) 10.0.0.1 255.0.0.0
Interface_1(WAN) 11.1.1.2 255.0.0.0
Router 2
Interface_2(WAN) 12.1.1.1 255.0.0.0
Router 3 Interface_1(WAN) 12.1.1.2 255.0.0.0
Interface_2(WAN) 13.1.1.2 255.0.0.0
Router 4 Interface_1(WAN) 13.1.1.1 255.0.0.0
Interface_2(Ethernet) 172.16.0.1 255.255.0.0
Table 31‑3: IP Address and the Subnet Mask for Routers

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 7 i.e. Source to Wired Node 10 i.e. Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining
20000µs.

Additionally, the “Start Time(s)” parameter is set to 50(Figure 31‑4), while configuring the application. This time is usually set to be greater than the time taken for OSPF
Convergence (i.e. Exchange of OSPF information between all the routers), and it increases as the size of the network increases.

Figure 31‑4: Application Properties Window

Step 5: Packet Trace is enabled, and hence we are able to track the route which the packets have chosen to reach the destination.

Step 6: Enable the plots and run the Simulation for 100 Seconds.

31.4 Output
After simulation open Packet Trace and filter Packet ID to 1.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 155/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 31‑5: Packet Trace

SOURCE_IP – source node IP (Node)

DESTINATION_IP – gateway IP/ destination IP (Router/ Node)

GATEWAY_IP – IP of the device which is transmitting a packet (Router/ Node)

NEXT_HOP_IP – IP of the next hop (Router/ Node)

Source node 7 (10.0.0.2) wouldn’t know how to route to the destination and hence its default gateway is Router 1 with interface IP (10.0.0.1). So, the first line in the
above screenshot specifies packet flow from Source Node 7 to L2 Switch 6 with SOURCE_IP (10.0.0.2), DESTINATION_IP (10.0.0.1), GATEWAY_IP (10.0.0.2) and
NEXT_HOP_IP (10.0.0.1). Since Switch is Layer2 device there is no change in the IPs in second line. Third line specifies the packet flow from Router 1 to Router 2 with

SOURCE_IP (10.0.0.2), DESTINATION_IP (13.1.1.1- IP of the router connected to destination. Since OSPF is running, the router is looks up the route to its destination
from routing table), GATEWAY_IP (11.1.1.1) and NEXT_HOP_IP (11.1.1.2) and so on.

32 Understand the events involved in NetSim DES (Discrete Event Simulator)

in simulating the flow of one packet from a Wired node to a Wireless node
32.1 Theory
NetSim’s Network Stack forms the core of NetSim and its architectural aspects are diagrammatically explained below. Network Stack accepts inputs from the end-user in

the form of Configuration file and the data flows as packets from one layer to another layer in the Network Stack. All packets, when transferred between devices move up
and down the stack, and all events in NetSim fall under one of these ten categories of events, namely, Physical IN, Data Link IN, Network IN, Transport IN,
Application IN, Application Out, Transport OUT, Network OUT, Data Link OUT and Physical OUT. The IN events occur when the packets are entering a device

while the OUT events occur while the packet is leaving a device.

Figure 32‑1: Flow of one packet from a Wired node to a Wireless node

Every device in NetSim has an instance of the Network Stack shown above. Switches & Access points have a 2 layer stack, while routers have a 3 layer stack. End-
nodes have a 5 layer stack.

The protocol engines are called based on the layer at which the protocols operate. For example, TCP is called during execution of Transport IN or Transport OUT events,

while 802.11b WLAN is called during execution of MAC IN, MAC OUT, PHY IN and PHY OUT events.

When these protocols are in operation they in turn generate events for NetSim's discrete event engine to process. These are known as SUB EVENTS. All SUB EVENTS,
fall into one of the above 10 types of EVENTS.

Each event gets added in the Simulation kernel by the protocol operating at the particular layer of the Network Stack. The required sub events are passed into the
Simulation kernel. These sub events are then fetched by the Network Stack in order to execute the functionality of each protocol. At the end of Simulation, Network Stack
writes trace files and the Metrics files that assist the user in analyzing the performance metrics and statistical analysis.

Event Trace

The event trace records every single event along with associated information such as time stamp, event ID, event type etc. in a text file or .csv file which can be stored at
a user defined location.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 156/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

32.2 Network Setup

Open NetSim and click Examples> Experiments > Advanced:Simulation-events-in-NetSim-for-transmitting-one-packet > Sample-1 as shown below Figure 32‑2.

Figure 32‑2: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 32‑3.

Figure 32‑3: Application flow between wired node to wireless node

32.3 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 1 Wired Node, 1 Wireless Node, 1 Router, and 1 Access Point in the “Internetworks” Network
Library.

Step 2: The device positions are set as per the below Table 32‑1.

Device Positions
Access Point 2 Wired Node 4 Wireless Node 1 Router 3
X / Lon 150 250 100 200
Y / Lat 50 100 100 50
Table 32‑1: Devices Positions

Step 3: Right-click the link ID (of the wireless link) and select Properties to access the link’s properties. The “Channel Characteristics” is set to NO PATHLOSS.

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 4 i.e. Source to Wireless Node 1 i.e. Destination with Packet Size remaining 1460 Bytes and Inter Arrival Time
remaining 20000µs.

Transport Protocol is set to UDP instead of TCP.

Step 5: Event Trace is enabled in NetSim GUI. At the end of the simulation, a very large .csv file is containing all the TCP IN and OUT EVENTS is available for the
users.

Note: Event trace is only available only in NetSim Standard and Pro versions.

32.4 Output
Once the simulation is complete, go to the Results Dashboard and in the left-hand-side of the window, click on the "Open Event Trace" Option. An Event trace file

similar to the following opens in Excel as shown below:

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 157/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 32‑4: Event trace

We start from the APPLICATION_OUT event of the first packet, which happens in the Wired Node and end with the MAC_IN event of the WLAN_ACK packet which

reaches the Wired Node. Events in the event trace are logged with respect to the time of occurrence due to which, event id may not be in order.

32.4.1 Events Involved

Events are listed in the following format:

[EVENT_TYPE, EVENT_TIME, PROTOCOL, EVENT_NO, SUBEVENT_TYPE]

[APP_OUT, 20000, APP, 6, -]
[TRNS_OUT, 20000, UDP, 7, -]

[NW_OUT, 20000, IPV4, 9, -]

[MAC_OUT, 20000, ETH, 10, -]
[MAC_OUT, 20000, ETH, 11, CS]

[MAC_OUT, 20000.96, ETH, 12, IFG]

[PHY_OUT, 20000.96, ETH, 13, -]
[PHY_OUT, 20122.08, ETH, 14, PHY_SENSE]

[PHY_IN, 20127.08, ETH, 15, -]

[MAC_IN, 20127.08, ETH, 16, -]
[NW_IN, 20127.08, IPV4, 17, -]

[NW_OUT, 20127.08, IPV4, 18, -]

[MAC_OUT, 20127.08, ETH, 19, -]
[MAC_OUT, 20127.08, ETH, 20, CS]

[MAC_OUT, 20128.04, ETH, 21, IFG]

[PHY_OUT, 20128.04, ETH, 22, -]
[PHY_OUT, 20249.16, ETH, 23, PHY_SENSE]

[PHY_IN, 20254.16, ETH, 24, -]

[MAC_IN, 20254.16, ETH, 25, -]
[MAC_OUT, 20254.16, WLAN, 26, -]

[MAC_OUT, 20254.16, WLAN, 27, DIFS_END]

[MAC_OUT, 20304.16, WLAN, 28, BACKOFF]
[MAC_OUT, 20324.16, WLAN, 29, BACKOFF]

[MAC_OUT, 20344.16, WLAN, 30, BACKOFF]

[MAC_OUT, 20364.16, WLAN, 31, BACKOFF]
[PHY_OUT, 20364.16, WLAN, 32, -]

[TIMER, 21668.16, WLAN, 35, UPDATE_DEVICE_STATUS]

[PHY_IN, 21668.4, WLAN, 33, -]
[MAC_IN, 21668.4, WLAN, 36, RECEIVE_MPDU]

[NW_IN, 21668.4, IPV4, 37, -]

[MAC_OUT, 21668.4, WLAN, 38, SEND_ACK]
[TRNS_IN, 21668.4, UDP, 39, -]

[APP_IN, 21668.4, APP, 41, -]

[PHY_OUT, 21678.4, WLAN, 40, -]
[TIMER, 21982.4, WLAN, 43, UPDATE_DEVICE]

[PHY_IN, 21982.63, WLAN, 42, -]

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 158/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
[MAC_IN, 21982.63, WLAN, 44, RECEIVE_ACK]
[TIMER, 21985, WLAN, 34, ACK_TIMEOUT]

Event Flow Diagram for one packet from Wired Node to Wireless Node

Figure 32‑5: Event Flow Diagram for one packet from Wired Node to Wireless Node
For Example

MAC_OUT in the Access Point involves sub events like CS, DIFS_END and BACKOFF. As you can see in the trace file shown below, CS happens at event time
20254.16. Adding DIFS time of 50µs to this will give DIFS_END sub event at 20304.16. Further it is followed by three backoffs each of 20 µs, at event time 20314.16,
20324.16, 20344.16 respectively.

Figure 32‑6: Sub events like CS, DIFS_END and BACKOFF event times

In this manner the event trace can be used to understand the flow of events in NetSim Discrete Event Simulator.

32.5 Discussion

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 159/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
In NetSim each event occurs at a particular instant in time and marks a change of state in the system. Between consecutive events, no change in the system is assumed
to occur. Thus the simulation can directly jump in time from one event to the next.

This contrasts with continuous simulation in which the simulation continuously tracks the system dynamics over time. Because discrete-event simulations do not have to
simulate every time slice, they can typically run much faster than the corresponding continuous simulation.

Understanding NetSim’s Event trace and its flow is very much helpful especially when customizing existing code and debugging to verify the correctness the modified

code. The event IDs provided in the event trace can be used to go to a specific event while debugging.

33 Understand the working of TCP BIC Congestion control algorithm,

simulate and plot the TCP congestion window

33.1 Theory
In BIC congestion control is viewed as a searching problem in which the system can give yes/no feedback through packet loss as to whether the current sending rate (or
window) is larger than the network capacity. The current minimum window can be estimated as the window size at which the flow does not see any packet loss. If the

maximum window size is known, we can apply a binary search technique to set the target window size to the midpoint of the maximum and minimum. As increasing to
the target, if it gives any packet loss, the current window can be treated as a new maximum and the reduced window size after the packet loss can be the new minimum.
The midpoint between these new values becomes a new target. Since the network incurs loss around the new maximum but did not do so around the new minimum, the

target window size must be in the middle of the two values. After reaching the target and if it gives no packet loss, then the current window size becomes a new
minimum, and a new target is calculated. This process is repeated with the updated minimum and maximum until the difference between the maximum and the minimum
falls below a preset threshold, called the minimum increment (Smin). This technique is called binary search increase.

Additive Increase

In order to ensure faster convergence and RTT-fairness, binary search increase is combined with an additive increase strategy. When the distance to the midpoint from
the current minimum is too large, increasing the window size directly to that midpoint might add too much stress to the network. When the distance from the current
window size to the target in binary search increase is larger than a prescribed maximum step, called the maximum increment (Smax) instead of increasing window

directly to that midpoint in the next RTT, we increase it by Smax until the distance becomes less than Smax, at which time window increases directly to the target. Thus,
after a large window reduction, the strategy initially increases the window linearly, and then increases logarithmically. This combination of binary search increase and
additive increase is called as binary increase. Combined with a multiplicative decrease strategy, binary increase becomes close to pure additive increase under large

windows. This is because a larger window results in a larger reduction by multiplicative decrease and therefore, a longer additive increase period. When the window size
is small, it becomes close to pure binary search increase – a shorter additive increase period.

Slow Start

After the window grows past the current maximum, the maximum is unknown. At this time, binary search sets its maximum to be a default maximum (a large constant)

and the current window size to be the minimum. So, the target midpoint can be very far. According to binary increase, if the target midpoint is very large, it increases
linearly by the maximum increment. Instead, run a “slow start” strategy to probe for a new maximum up to Smax. So if cwnd is the current window and the maximum
increment is Smax, then it increases in each RTT round in steps cwnd+1, cwnd+2, cwnd+4,,, cwnd+Smax. The rationale is that since it is likely to be at the saturation

point and also the maximum is unknown, it probes for available bandwidth in a “slow start” until it is safe to increase the window by Smax. After slow start, it switches to
binary increase.

Fast Convergence

It can be shown that under a completely synchronized loss model, binary search increase combined with multiplicative decrease converges to a fair share. Suppose
there are two flows with different window sizes, but with the same RTT. Since the larger window reduces more in multiplicative decrease (with a fixed factor β), the time

to reach the target is longer for a larger window. However, its convergence time can be very long. In binary search increase, it takes RTT rounds to

reach the maximum window after a window reduction of d. Since the window increases in a log step, the larger window and smaller window can reach back to their
respective maxima very fast almost at the same time (although the smaller window flow gets to its maximum slightly faster). Thus, the smaller window flow ends up
taking away only a small amount of bandwidth from the larger flow before the next window reduction. To remedy this behaviour, binary search increase is modified as

follows. After a window reduction, new maximum and minimum are set. Suppose these values are max_wini and min_wini for flow i (i =1, 2). If the new maximum is less
than the previous, this window is in a downward trend. Then, readjust the new maximum to be the same as the new target window (i.e. max_wini = (max_wini-
min_wini)/2), and then readjust the target. After that apply the normal binary increase. This strategy is called fast convergence.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 160/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

33.2 Network setup

Open NetSim and click Examples > Experiments > Advanced:TCP-BIC-Congestion-control-algorithm > Sample-1 as shown below Figure 33‑1.

Figure 33‑1: Experiments List

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 33‑2.

Figure 33‑2: Network topology

33.3 Procedure
The following set of procedures were done to generate this sample:

Step 1: A network scenario is designed in NetSim GUI comprising of 2 Wired Nodes and 2 Routers in the “Internetworks” Network Library.

Step 2: In the General Properties of Wired Node 3 i.e. Source, Wireshark Capture is set to Online and in the TRANSPORT LAYER Properties, Window Scaling is set as

TRUE.

Step 3: For all the devices, in the TRANSPORT LAYER Properties, Congestion Control Algorithm is set to BIC. Congestion plot is set to true.

Figure 33‑3: Transport Layer window

Step 4: The Link Properties are set according to the table given below Table 33‑1.

Link Properties Wired Link 1 Wired Link 2 Wired Link 3

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 161/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Uplink Speed (Mbps) 100 20 100

Downlink Speed (Mbps) 100 20 100

Uplink propagation delay (µs) 5 1000 5

Downlink propagation delay (µs) 5 1000 5

Uplink BER 0.00000001 0.00000001 0.00000001

Downlink BER 0.00000001 0.00000001 0.00000001

Table 33‑1: Wired Link Properties

Step 5: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 3 i.e. Source to Wired Node 4 i.e. Destination with Packet Size set to 1460 Bytes and Inter Arrival Time set to 400 µs.
Additionally, the “Start Time” parameter is set to 20 Seconds.

The Packet Size and Inter Arrival Time parameters are set such that the Generation Rate equals 140 Kbps. Generation Rate can be calculated using the formula:

Step 6: Enable the plots and click on Run simulation. The simulation time is set to 100 seconds.

33.4 Output

Figure 33‑4: Plot of Window Scaling in Wireshark Capture

Note: User need to “zoom in” to get the above plot.

Go to the Wireshark Capture window.

Click on data packet i.e. <None>. Go to Statistics à TCP Stream Graphs à Window Scaling.

Click on Switch Direction in the window scaling graph window to view the graph.

(For more guidance, refer to section - 8.7.5 Window Scaling” in user manual)

The graph shown above is a plot of Congestion Window vs Time of BIC for the scenario shown above. Each point on the graph represents the congestion window at the

time when the packet is sent. You can observe Binary Search, Additive Increase, Fast Convergence, Slow Start phases in the above graph.

34 Simulating Link Failure

34.1 Objective
To model link failure understand its impact on network performance

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 162/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

34.2 Theory
A link failure can occur due to a) faults in the physical link and b) failure of the connected port. When a link fails, packets cannot be transported. This also means that
established routes to destinations may become unavailable. In such cases, the routing protocol must recompute an alternate path around the failure.

In NetSim, only WAN links (connecting two routers) can be failed. Right click on a WAN link between two routers and the Link Properties Window is as shown below

Figure 34‑1.

Figure 34‑1: Wired Link Properties Window

Link Up Time refers to the time(s) at which the link is functional and Link Down Time refers to the time (s) at which a link fails. Click on Up_Time or Down_Time to
understand the configuration options.

NOTE: Link failure can be set only for “WAN Interfaces”.

34.3 Network Setup:

Open NetSim and click Examples > Experiments > Advanced:Simulating-Link-Failure > Sample-1 as shown below Figure 34‑2.

Figure 34‑2: Experiments List

34.3.1 Part-I

NetSim UI displays the configuration file corresponding to this experiment as shown below Figure 34‑3.

Figure 34‑3: Network Topology in this experiment

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 163/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
34.3.1.1 Procedure
Sample-1: The following set of procedures were done to generate this sample:

Step 1: In the “Internetworks” library, and a network scenario is designed in NetSim comprising of 2 Wired Nodes and 2 Routers.

Step 2: By default, Link Failure Up Time is set to 0,10,20 and Down Time is set to 5,15. This means the link is up 0-5s, 10-15s and 20s onwards, and it is down 5-10s
and 15-20s.

Step 3: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a .csv file containing all the packet information is available for performing packet level
analysis.

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 3 i.e. Source to Wired Node 4 i.e. Destination with Packet Size remaining 1460 Bytes and Inter Arrival Time remaining
20000µs.

Step 5: Transport protocol set as UDP.

Step 6: Enable the plots and run the simulation for 50 Seconds.

34.3.1.2 Output
In Sample 1,

Go to NetSim Simulation Result Window and open the Application Throughput plot. We can notice the following:

Figure 34‑4: Application Throughput plot for APP1_CBR

1. Application starts at 0 sec, and the link between Router 1 to Router 2 is active from 0-5s. We can observe 0.584 Mbps throughput in the interval of 0-5s, 10-15s
and 20s onwards.

2. The link fails in the intervals 5-10s and 15-20s. The throughput drops to 0 Mbps in these intervals.

34.3.2 Part-II

NetSim UI displays the configuration file corresponding to this experiment as shown Figure 34‑5.

Figure 34‑5: Network Topology in this experiment

34.3.2.1 Procedure
Sample-1: The following set of procedures were done to generate this sample:

Step 1: In the “Internetworks” library, and a network scenario is designed in NetSim comprising of 2 Wired Nodes and 7 Routers.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 164/166
11/12/24, 3:51 AM NetSim_Experiment_Manual
Step 2: By default, Link Failure Up Time is set to 0 and Down Time is set to 100000.

Step 3: Packet Trace is enabled in NetSim GUI. At the end of the simulation, a .csv file containing all the packet information is available for performing packet level

analysis.

Step 4: Right click on the Application Flow App1 CBR and select Properties or click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wired Node 1 i.e. Source to Wired Node 2 i.e. Destination with Packet Size remaining 1460 Bytes and Inter Arrival Time remaining

20000µs.

Additionally, the “Start Time(s)” parameter is set to 30, while configuring the application. This time is usually set to be greater than the time taken for OSPF
Convergence (i.e. exchange of OSPF information between all the routers), and it increases as the size of the network increases.

Step 5: Transport protocol set as TCP.

Step 6: Enable the plots and run the simulation for 80 Seconds.

Sample-2: The following changes in settings are done from the previous sample:

Step 1: In Link 3 Properties, Link Failure Up Time is set to 0 and Down Time is set to 50. This means that the link would fail at 50 Seconds.

Step 2: Enable the plots and run the simulation for 80 Seconds.

34.3.2.2 Output

In Sample 1,

Go to NetSim Packet Animation Window, click on Play button. We can notice the following:

§ Initially OSPF Control Packets are exchanged between all the routers.

§ Once after the exchange of control packets, the data packets are sent from the source to the destination.

§ The packets are routed to the Destination via, N1 > R3 > R4 > R5 > R9 > N2 as shown below Figure 34‑6.

Figure 34‑6: Animation window for sample 1

In Sample2

§ We create a Link Failure in Link 3, between Router 4 and Router 5 at 50s.

§ Since the packets are not able to reach the destination, the routing protocol recomputes an alternate path to the Destination.

§ This can be observed in the Packet Trace.

§ Go to the Results Dashboard and click on Open Packet Trace option present in the Left-Hand-Side of the window and do the following:

§ Filter Control Packet Type/App Name to APP1 CBR and Transmitter ID to Router 3.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 165/166
11/12/24, 3:51 AM NetSim_Experiment_Manual

Figure 34‑7: Packet Trace

§ We can notice that packets are changing its route from,

N1 > R3 > R4 > R5 > R9 > N2 toN1 > R3 > R6 > R7 > R8 > R9 > N2 at 50 s of simulation time, since the link between R4 and R5 fails at 50 s.

Users can also observe this in Packet animation before and after the Link Failure as shown below Figure 34‑8/Figure 34‑9.

Figure 34‑8: Packet animation window before Link Failure showing packet flow for Sample 2

Figure 34‑9: Packet animation window after Link Failure showing packet flow for Sample 2

[1]
It may be noted that the term capacity has several connotations in communications. Our use of the word here must not be confused with the notion of information theoretic capacity of
a communication channel.

https://www.tetcos.com/documentation/NetSim/v13/NetSim-Experiments-Manual/index.htm#t=NetSim_Experiment_Manual.htm 166/166