Internetworks

Internetworks

Introduction#

The Internetworks library in NetSim supports various protocols across all the layers of the TCP/IP network stack. These include Ethernet, Address Resolution Protocol (ARP), Wireless LAN – 802.11 a / b / g / n / ac / p and e (EDCA), Internet Protocol (IP), Transmission Control Protocol (TCP), Virtual LAN (VLAN), User Datagram Protocol (UDP), and routing protocols such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF) and Internet Group Management Protocol (IGMP).

An internetwork is generally a collection of two or more networks (typically LANs and WLANs) which are interconnected to form a larger network. All networks in an Internetwork have a unique network address. Routers interconnect different networks.

Users can use the following devices to design Internetworks: wireless node, wired node, switch, router, and access point (AP). Wired nodes (term for computers, servers etc.) connect via wired link to switches or routers, and wireless nodes connect via wireless links to Access Points (APs). Multiple links terminate at a switch/router, which enables connectivity between them. Many switches/routers are present in an internetwork to connect all the end-nodes. The end-nodes provide and consume useful information via applications like data, voice, video etc.

Figure ‑: A typical Internetworks scenario in NetSim

Figure ‑: The Result dashboard and the Plots window shown in NetSim after completion of a simulation

Simulation GUI#

Open NetSim and click New Simulation à Internetworks as shown Figure 2‑1.

Figure ‑: NetSim Home Screen

Create Scenario#

Internetworks come with a palette of various devices like L2 Switch, L3 Switch, Router, Wired Node, Wireless Node, and AP (Access Point).

Devices specific to NetSim Internetworks Library#

Wired node: A Wired node can be an end-node or for a server. It is a 5-layer device that can be connected to a switch and router. It supports only 1 Ethernet interface and has its own IP and MAC Addresses.
Wireless Nodes: A Wireless node can be an end-node or a server. It is a 5-layer wireless device that can be connected to an Access point. It supports only 1 Wireless interface and has its own IP and MAC Addresses.
L2 Switch: Switch is a layer-2 device that uses the devices MAC address to make forwarding decisions. It does not have an IP address.
Router: Router is a layer-3 device and supports a maximum of 24 interfaces each of which has its own IP address.
Access point: Access point (AP) is a layer-2 wireless device working per 802.11 Wi-Fi protocol. It can be connected to wireless nodes via wireless links and to a router or a switch via a wired link.

Figure ‑: Internetworks Device Palette in GUI

Click and drop into environment #

Add a Wired Node or Wireless Node: In the toolbar, click the Node > Wired_Node icon (or) Node >Wireless_Node icon, and place the device in the grid.
Add a Router: In the toolbar, click on the Router icon and place the Router in the grid.
Add a L2 Switch or L3 Switch: In the toolbar, click on Switch > L2_Switch icon (or) Switch > L3_Switch icon and place the device in the grid.
Add an Access Point: In the toolbar, click on the Access Point icon and place the Access Point in the grid
Connect the devices by using Wired/Wireless Links present in the top ribbon/toolbar. Click on the first device and then click on the second device. A link will get formed between the two devices.
Configure an application as follows:

Click the application icon on the top ribbon/toolbar.
Specify the source and destination devices.
Specify other application parameters per your model.

Figure ‑: Top Ribbon/Toolbar

Multiple applications can be generated by using add button in Application properties. Set the values and click on OK button. Detailed information on Application properties is available in section 6 of NetSim User Manual.
Right-click on any device (Router, Access_Point, L2_Switch, Wireless_Node, Wired_
Node etc) and set the parameters.

Figure ‑: Device Properties

Interface_Wireless’ Physical Layer and DataLink Layer parameters are local but in Physical layer Standerd parameter is global. To set the same parameter value in all devices, ensure that you accordingly update the parameter values in all other devices (Access_Point or Wireless_Node) manually as the parameter change does not propagate to the other devices since it is local.

Figure ‑: MAC properties of Access Point

Figure ‑: PHY Layer properties of Access Point

Link Properties#

Right click on the link and click on properties to set link properties. Note that when simulating Internetworks if the link propagation delay is set too high then the applications may not see any throughput since it would take too long for OSPF to converge, and furthermore, TCP may also timeout (since max RTO is 3s).

Figure ‑: Link Properties

Enable Packet Trace, Event Trace & Plots (Optional)#

Click Packet Trace / Event Trace icon in the tool bar and click on OK button. For detailed help, please refer sections 8.1, 8.4 and 8.5 of the User Manual. Select Plots icon for enabling Plots and click on OK button see Figure 2‑8.

Figure ‑: Packet Trace, Event Trace & Plots options on top ribbon

Run Simulation#

Click on the Run Simulation icon on the top ribbon/toolbar. For detailed help, please refer sections 3.2.7 of the User Manual.

Figure ‑: Run Simulation on top ribbon

Set the Simulation Time and click on OK button.

Figure ‑: Run Simulation window

Model Features#

WLAN 802.11#

NetSim implements the 802.11 MAC and the 802.11 PHY abstracted at a packet-level. We start with the 3 types of nodes supported in 802.11 Wi-Fi.

Wireless Nodes (Internetworks) or STAs. In Internetworks APs and > Wireless nodes (STAs) are associated based on the connecting > wireless link
Wi-Fi Access Points (Internetworks) or APs. Every STA in the WLAN > associates with exactly one AP. Each AP, along with its associated > STAs, define a cell. Each cell operates on a specific channel.
Standalone Wireless nodes (Mobile Adhoc networks).

The MAC Layer features:

RTS/CTS/DATA/ACK transmissions.
Packet queuing, aggregation, transmission, and retransmission.
802.11 EDCA.

The PHY layer implements:
RF propagation (documented separately).
Received power based on propagation model.
Interference and signal to interference noise (SINR) calculation.
MCS (and in turn PHY Rate) setting based on RSS and rate adaptation > algorithms.
BER calculation and packet error modelling.

Figure ‑: NetSim’s Wi-Fi design window, the results dashboard, and the plots window

WLAN standards supported in NetSim#

802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11e (EDCA) and 802.11p are the WLAN standards available in NetSim. The operating frequencies and bandwidths are given in the Table 3‑1.

WLAN standard	Frequency (GHz)	Bandwidth (MHz)
802.11 a	5	20
802.11 b	2.4	20
802.11 g	2.4	20
802.11 n	2.4, 5	20, 40
802.11 ac	5	20, 40, 80, 160

Table ‑: WLAN standards supported in NetSim

802.11 p and WAVE are described in the VANET Technology library documentation.

The 2.4 GHz Channels#

The following channel numbers are well-defined for 2.4GHz standards:

Channel Number	Center Frequency (MHz)
1	2412
2	2417
3	2422
4	2427
5	2432
6	2437
7	2442
8	2447
9	2452
10	2457
11	2462
12	2467
13	2472
14	2484

Table 3‑2: 2.4 GHz Wi-Fi Channels per IEEE Std 802.11g-2003, 802.11-2012

Channels 1 through 14 are used in 802.11b, while channels 1 through 13 are used in 802.11g/n.

The 5 GHz Channels#

The following channel numbers are defined for 802.11a/n/ac.

Channel Number	Center Frequency (MHz)
36	5180
40	5200
44	5220
48	5240
52	5260
56	5280
60	5300
64	5320
100	5500
104	5520
108	5540
112	5560
116	5580
120	5600
124	5620
128	5640
132	5660
136	5680
140	5700
144	5720
149	5745
153	5765
157	5785
161	5805
165	5825
169	5845
173	5865
177	5885

Table 3‑3: 5GHz Wi-Fi Channels per IEEE Std 802.11a -1999, 802.11n -2009, 802.11ac -2013

The 5.9 GHz Channels#

Channel Number	Center Frequency (MHz)
100	5500
104	5520
108	5540
112	5560
116	5580
120	5600
124	5620
128	5640
132	5660
136	5680
140	5700
171	5855
172	5860
173	5865
174	5870
175	5875
176	5880
177	5885
178	5890
179	5895
180	5900
181	5905
182	5910
183	5915
184	5920

Table ‑: 5.9 GHz Wi-Fi Channels per IEEE Std 802.11p-2010

Channel Numbering#

The standard method to denote 5 GHz channels has been to always use the 20 MHz center channel frequencies for both 20 MHz and 40 MHz wide channels. The following are the channel numbers of the non-overlapping channels for 802.11ac in NetSim:

20MHz: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, > 124, 128, 132, 136, 140, 144, 149, 153, 157, 161, 165, 169, 173, > 177
40MHz: 36, 44, 52, 60,100, 108, 116, 124, 132, 140, 149, 157, 165, > 173
80MHz: 36, 52, 100, 116, 132, 149, 165
160MHz: 36, 100, 149

WLAN PHY Rate in NetSim#

WLAN Standard	Frequency (GHz)	Bandwidth (MHz)	MIMO streams	PHY rate (Mbps)
a	5	20	N/A	6, 9, 12, 18, 24, 36, 48, 54
b	2.4	22	N/A	1, 2, 5.5, 11
g	2.4	20	N/A	6, 9, 12, 18, 24, 36, 48, 54
n	2.4, 5	20	4	Up to 288.8
		40		Up to 600
ac	5	20	8	Up to 346.8
		40		Up to 800
		80		Up to 1733.2
		160		Up to 3466.8

Table ‑: WLAN PHY Rates in NetSim

SIFS, Slot Time, CW Min, and CW Max settings#

Sub Std.	b (20MHz)
SIFS	10
Slot Time	20
CW Min	31
CW Max	1023

Table ‑: DSSS PHY characteristics (IEEE-Std-802.11-2020 -Page no -2762)

Sub Std.	a	g	p
Bandwidth	20MHz	20MHz	10MHz	20MHz
SIFS	16	16	32	16
Slot Time	9	9	13	9
CW Min	15	15	15	15
CW Max	1023	1023	1023	1023

Table ‑: OFDM PHY characteristics (IEEE-Std-802.11-2020 -Page no -2846)

Sub Std.	n
Frequency Band	2.4MHz	5
SIFS	10	16
Slot Time	20	9
CW Min	15	15
CW Max	1023	1023

Table 3‑8: HT PHY characteristics (IEEE-Std-802.11-2020 -Page no -2951) and MIMO PHY characteristics (IEEE-Std-802.11n-2009 -Page no -335)

Sub Std.	ac (5GHz)
SIFS	16
Slot Time	9
CW Min	15
CW Max	1023

Table 3‑9: Slot time in IEEE-Std-802.11-2020 -Page no -3094 and IEEE-Std-802.11ac-2013-Page no -297

PHY Implementation#

NetSim is a packet level simulator for simulating the performance of end-to-end applications over various packet transport technologies. NetSim can scale to simulating networks with 100s of end-systems, routers, switches, etc. NetSim provides estimates of the statistics of application-level performance metrics such as throughput, delay, packet-loss, and statistics of network-level processes such as buffer occupancy, collision probabilities, etc.

In order to achieve scalable, network simulation, that can execute in reasonable time on desktop level computers, in all networking technologies the details of the physical layer techniques have been abstracted up to the point that bit-error probabilities can be obtained from which packet error probabilities are obtained.

NetSim does not implement any of the digital communication functionalities of the PHY layer. For the purpose of PHY layer simulation, the particular modulation and coding scheme, along with the transmit power, path loss, noise, and interference, yields the bit rate and the bit error rate by using well-known formulas or tables for the particular PHY layer being used. User would need to use a PHY Layer/RF/Link Level simulator for simulating various digital communication and link level functionalities. Typically, these simulators will simulate just one transmitter-receiver pair, rather than a network.

Generally, in NetSim, the PHY layer parameters available for the user to modify are Channel Bandwidth, Channel Centre Frequency, Transmit-power, Receiver-sensitivity, Antenna-gains, and the Modulation-and-Coding-Scheme. When simulating standard protocols, these parameters can only be chosen from a standard-defined set. NetSim also has standard models for radio pathloss; the parameters of these pathloss models can also be set.

PHY States#

The PHY radio states implemented in NetSim 802.11 are RX_ON_IDLE, RX_ON_BUSY, TRX_ON_BUSY.

RX_ON_IDLE: This is the default radio state
RX_ON_BUSY: This state is set at receiver radio when the reception of data begins. Upon completion of reception it changes to RX_ON_IDLE
TRX_ON_BUSY: This state is set at the transmitter radio at the start of frame transmission. Upon completion of transmission, it changes to RX_ON_IDLE
A node in back off slots can be considered as equivalent to CCA busy. In NetSim, the radio state continues to be in RX_ON_IDLE
SLEEP state is not implemented since NetSim 802.11 does not currently implement power save mode.

802.11 implementation details#

Packets arriving from the NETWORK Layer gets queued up in an access buffer from which they are sorted according to their priority per 802.11 EDCA. An event MAC_OUT with SubEvent CS (Carrier Sense – CSMA) is added to check if the medium is free

Figure ‑: Packets transmission form Network layer to Mac Layer and how queued up in an access buffer

During CS, if the medium is free, then the NAV is checked. This occurs if the RTS/CTS mechanism is enabled which can be done so by adjusting the RTS Threshold. If the Present_Time > NAV, then an Event MAC_OUT with SubEvent DIFS End added at the time Present_Time + DIFS time.

Figure ‑: Event and SubEvent in Mac layer

The medium is checked at the end of DIFS time period and a random time BackOff is calculated based on the Contention Window (CW). An Event MAC_OUT with SubEvent BackOff is added at time Present_Time + BackOff Time.

Once BackOff is successful, NetSim starts the transmission process wherein it gets the aggregated frames from the QOS buffer and stores it in the Retransmit buffer. If the A-MPDU size is > RTS Threshold, then it enables RTS/CTS mechanism which is an optional feature.

Figure ‑: Event and SubEvent in Mac layer and Phy layer

NetSim sends the packet by calling the PHY_OUT Event with SubEvent AMPDU_Frame. Note that the implementation of A-MPDU is in the form of a linked list.

Whenever a packet is transmitted, the medium is made busy and a Timer Event with SubEvent Update Device Status is added at the transmission end time to set the medium again as idle.

Figure ‑: Event and SubEvent in Phy layer

Events PHY_OUT SubEvent AMPDU_SubFrame, Timer Event SubEvent Update Device Status and Event PHY_IN SubEvent AMPDU_SubFrame are added in succession for each MPDU (Subframe of the aggregated frame). This is done for collision calculations. If two stations start transmission simultaneously, then some of the SubFrames may collide. Only those collided SubFrames will be retransmitted again. The same logic is followed for an Errored packet. However, if the PHY header (the first packet) is errored or collided, the entire A-MPDU is resent.

At the receiver, the device de-aggregates the frame in the MAC Layer and generates a block ACK which is sent to the transmitter. If the receiver is an intermediate node, the de-aggregated frames are added to the access buffer of the receiver in addition to the packets which arrive from Network layer. If the receiver is the destination, then the received packets are sent to the Network layer. At the transmitter side, when the device receives the block acknowledgement, it retransmits only those packets which are errored. The rest of the packets are deleted from the retransmit buffer. This is done till all packets are transmitted successfully or a retransmit limit is reached after which next set of frames are aggregated to be sent.

802.11ac MAC and PHY Layer Implementation#

Improvements in 802.11ac compared to 802.11n

Feature	802.11n	802.11ac
Spatial Streams	Up to 4 streams	Up to 8 streams
MIMO	Single User MIMO	Multi-User MIMO
Channel Bandwidth	20 and 40 MHz	20, 40, 80 and 160 MHz (optional)
Modulation	BPSK, QPSK, 16QAM and 64QAM	BPSK, QPSK, 16QAM, 64QAM and 256QAM (optional)
Max Aggregated Packet Size	65536 octets	1048576 octets

Table ‑: Feature Comparison between 802.11ac to 802.11n

MAC layer improvements include only the increment of number of aggregated frames from 1 to 64. The MCS index for different modulation and coding rates are as follows:

MCS index	Modulation	Code Rate
0	BPSK	1/2
1	QPSK	1/2
2	QPSK	3/4
3	16QAM	1/2
4	16QAM	3/4
5	64QAM	2/3
6	64QAM	3/4
7	64QAM	5/6
8	256QAM	3/4
9	256QAM	5/6

Table ‑: Different Modulation schemes and Code Rates

Receiver sensitivity for different modulation schemes in 802.11ac (for a 20MHz Channel bandwidth) are as follows.

MCS Index	Receiver Sensitivity (in dBm)
0	-82
1	-79
2	-77
3	-74
4	-70
5	-66
6	-65
7	-64
8	-59
9	-57

Table ‑: MCS index vs. Receiver Sensitivity (Rx-sensitivity)

The Rx-sensitivity is then set per the above table in conjunction with Max Packet Error Rate (PER) as defined in the standard.

If users wish to apply just the Rx-sensitivity (also termed as rate dependent input level), then the calculate_rxpower_by_per() function call in the function

fn_NetSim_IEEE802_11_HTPhy_UpdateParameter() in the file IEEE802_11_HT_PHY.c can be commented.

Number of subcarriers for different channel bandwidths

PHY Standard	Subcarriers	Capacity relative to 20MHz in 802.11ac
802.11n/802.11ac 20MHz	Total 56, 52 Usable (4 pilot)	x1.0
802.11n/802.11ac 40MHz	Total 114, 108 Usable (6 pilot)	x2.1
802.11ac 80MHz	Total 242, 234 Usable (8 pilot)	x4.5
802.11ac 160MHz	Total 484, 468 Usable (16 pilot)	x9.0

Table ‑: Number of subcarriers for different channel bandwidths

With the knowledge of MCS index and bandwidth of the channel data rate is set in the following manner

Get the number subcarriers that are usable for the given bandwidth of the medium.
Get the Number of Bits per Sub Carrier (NBPSC) from selected MCS
Number of Coded Bits Per Symbol (NCBPS) = NBPSC*Number of Subcarriers
Number of Data Bits Per Symbol (NDBPS) = NCBPS*Coding Rate
Physical level Data Rate = NDBPS/Symbol Time (4micro sec for long GI and 3.6 micro sec for short GI).

MAC Aggregation in NetSim#

NetSim supports A-MPDU aggregation and does not support A-MSDU aggregation. MAC Aggregation is independent of MCS (PHY Rate) or BER. It is the PHY Rate that adapts to BER via Rate Adaptation algorithms.

In the aggregation scheme shown in Figure 3‑6, several MPDU’s (MAC Protocol Data Units) are aggregated into a single A-MPDU (Aggregated MPDU). The A-MPDUs are created before transfer to the PHY. The MAC does not wait for MPDUs to aggregate. It aggregates the frames already queued to form an A-MPDU. The maximum size of an A-MPDU is 65,535 bytes.

Figure ‑: Aggregation scheme

In 802.11n, a single block acknowledgement is sent for the entire A-MPDU. The block ack acknowledges each packet that is received. It consists of a bitmap (compressed bitmap) of 64bits or 8 bytes. This bitmap can acknowledge up to 64 packets, 1bit for each packet.

The value of a bitmap field is 1, if respective packet is received without error else it is 0. Only the error packets are resent until a retry limit is reached. The number of packets in an A-MPDU is restricted to 64 since the size of block ack bitmap is 64bits.

Figure ‑: Block Ack Control Packet

NetSim uses the parameter, Number of frames to aggregate, while the standard uses the parameter A-MPDU Length Exponent. Per standard the A-MPDU length in defned by two parameters: Max AMPDU length exponent and BLOCK ACK Bitmap. The AMPDU length in bytes is 2^{(13+MaximumAMPDULengthExponent)} − 1 .
Since NetSim doesn't model A-MSDU, a design decision was made to model A-MPDU based on Block ACK bitmap size (to indicate the received status of up to 64 frames) and therefore the parameter - Number of frames to aggregate - in the GUI
When EDCA is enabled, packet aggregation is done separately for each QoS class
NetSim ignores the padding bytes added to the MPDU
The MAC aggregates packets destined to the same receiver, irrespective of the end destination. Receiver is to be understood as the next hop in a wireless transmission.
RTS threshold is compared against the total A-MPDU size.
Aggregation functionality may be incorrectly executed if

NumberOfFramesToAggregate × PacketSize (B) > 65, 535 (B)

Signal to interference and noise ratio (SINR)#

At each receiver, in the beginning when the first packet is transmitted and every time the transmitter or receiver moves, NetSim calculates the received signal level from transmitter. The received signal level would be equal to transmit power less propagation losses. Next, NetSim calculates the interference received (at the same receiver), from all the interfering transmissions. Only co-channel interference is accounted, and adjacent channel interference is not calculated. Finally, NetSim takes the ratio of the signal level, to the sum of the total interference from other transmissions plus the thermal noise. This ratio is SINR.

Once the SINR is calculated the BER is got from the SINR-BER tables for the applicable modulation scheme. This BER is then converted to Packet-Error-Rate. Packet error (Yes/No) is determined by drawing a random number in (0, 1) and comparing against PER¹.

The same is explained diagrammatically below.

Figure ‑: Radio Tx-Rx for one transmission

* Propagation model covers path loss, fading and shadowing. The models are documented in a separate document named Propagation-Models.pdf

** Interference noise due to other transmissions within the network

Transmit Power#

The user can set a fixed transmit power via the GUI. Transmit power is a local variable; each STA and AP can be set to have different transmit powers. The transmit power can be dynamically varied by modifying the underlying 802.11 source C code.

Carrier Sense#

Transmit power less propagation losses is the received power. The propagation loss is the sum (in dB scale) of pathloss, shadowing loss and fading loss. Various propagation models are available and are detailed in the Propagation model manual. Pathloss, Fading, and Shadowing can be turned on/off in GUI.

If ReceiverSensitivity(Lowest MCS)≥ Receiver − Power ≥ ED − Threshold the medium is set to busy. Note that CSMA/CA algorithm operates according to the medium state (busy/idle).

If Received − Power > Reciver − Sensitivity (LowestMCS) then MCS is set depending on the Received power and signal is decoded. Packet error is decided by looking up the SINR-BER table for the given MCS.

These variables can also be dynamically by modifying the underlying 802.11 source C code.

Transmission Range, Carrier Sense Range, and Interference Range#

Transmission Range: The transmission range is the range within which the receiver of a signal can decode the source’s transmission correctly (when no other transmitting node’s signal interferes). This is typically smaller than the carrier-sensing range of the transmitter.
Carrier Sense Range: The carrier-sense range is the range within which the transmitter’s signal exceeds the Carrier Sense Threshold of the receiver (or another transmitter). The receiver (or another transmitter) detects the medium to be busy and does not transmit at this time.
Interference Range: The interference range (defined by the receiver) is the range within which any signal transmitted by other sources interfere with the transmission of the intended source, thereby causing a loss (marked as a collision in NetSim) at the receiver.

These three ranges are affected by the power of the transmitter. The greater the transmission power, the further a node can receive the transmission, and also the more nodes whose communication with other nodes will be affected by this transmission. The transmission range is also affected by the MCS used by the transmitter. The higher the MCS the shorter the range, and vice versa

Carrier Sense (CS) Threshold#

In NetSim (from v13.2 onwards) the Carrier sense (CS) threshold is set equal to Control rate receive sensitivity.

CSThreshold = RecieverSensitivity(ControlRate)

Users can modify the CS threshold using the variable CSRANGEDIFF which is set to 0 dB in code by default. This implies a 0 dB differential between the lowest MCS (Control rate) Receive sensitivity (which determines DecodeRange) and CS Threshold (which determines CarrierSenseRange). The value of CSRANGEDIFF can be modified by the user in NetSim Standard or Pro versions, which ship with source code. We believe the term EDThreshold used in literature is the same as CSThreshold.

If the interference signal power (sum of the Received-power from all other transmitters), measured at the transmitter, is greater than ED-Threshold, then the transmitter assumes the medium is busy. Carrier is sensed by the transmitter; all CS activity occurs at the transmitter, and not at the receiver

Transmitter’s choice of MCS#

If the rate adaptation algorithm is turned off, then the transmitter chooses MCS by comparing the RSS (calculated per the equation below) against the Receiver-Sensitivity for different MCS (per the tables in the standards). The highest possible MCS is then chosen. This means the MCS is not fixed but adapts to the received signal strength, even with rate adaption turned off in the MAC layer.

NetSim exploits the AP-STA and the STA-AP channel reciprocity. Therefore, Pathloss plus Shadow loss is identical in both directions.

RSSI = TxPower − Pathloss − ShadowLoss

Note that when computing BER (from SINR) fading loss is added to this RSSI value. Thus, fading loss is not accounted when choosing MCS, but is accounted when computing BER.

NetSim has rate adaptation algorithms which take care of selecting the right MCS for a given SINR. In the simplest algorithm for every 20 successful transmissions the rate (MCS) goes up 1 step, and for every 3 continuous failures, the rate goes down one step.

Hidden Node Behaviour#

Consider N1 and N3 transmitting to N2 whereby N1 and N3 are beyond Carrier sense (CS) range. N1 is said to be hidden from N3 and vice versa.

When N1 and N3 transmit, there are “likely” to be collisions at N2. However, collisions do not occur all the time. The CSMA/CA algorithm exponentially increases the backoff and hence after a few collisions it is possible that one of the nodes gets a low back-off number while the other draws a very high back-off number. Thus, the node with low back-off can complete transmissions (of one and even more than one packet) while the other node (with the large backoff) is still in backoff.

When N1 transmits to N2, N3 can’t hear the transmission since N3 is beyond CS. Therefore, N3 can attempt if its backoff counts down to 0. However, when N2 sends back the WLAN-ACK, N3 will hear it since N3 is within range of N2. Therefore, in NetSim, N3 will sense the medium as busy and freeze its back off when N2 is sending the WLAN ACK to N1.

In case of N2 to N1/N3 transmissions, then the reverse is true for the MAC-ACK from the nodes. When N2 sends a packet to N1 (or N3) it is within range of N3 (or N1), however, when N1 (or N3) sends back the MAC ACK there is a chance of collision with a data packet of N3 (or N1).

IEEE 802.11 e QoS and EDCA#

Quality of Service (QoS) provides you with the ability to specify parameters on multiple queues for increased throughput and better performance of differentiated wireless traffic like Voice-over-IP (VoIP), other types of audio, video, and streaming media, as well as traditional IP data over the Access Point.

QoS was introduced in 802.11e and is achieved using enhanced distributed channel access functions (EDCAFs). EDCA provides differentiated priorities to transmitted traffic, using four different access categories (ACs). With EDCA, high-priority traffic has a higher chance of being sent than low-priority traffic: a station with high priority traffic waits a little less before it sends its packet, on average, than a station with low priority traffic. This differentiation is achieved through varying the channel contention parameters i.e., the amount of time a station would sense the channel to be idle, and the length of the contention window for a backoff.

In addition, EDCA provides contention-free access to the channel for a period called a Transmit Opportunity (TXOP). A TXOP is a bounded time interval during which a station can send as many frames as possible (as long as the duration of the transmissions does not extend beyond the maximum duration of the TXOP). If a frame is too large to be transmitted in a single TXOP, it should be fragmented into smaller frames. The use of TXOPs reduces the problem of low rate stations gaining an inordinate amount of channel time in the legacy 802.11 DCF MAC. A TXOP time interval of 0 means it is limited to a single MPDU.

Figure ‑: Enhanced Distributed Channel Access (EDCA) in 802.11

NetSim categorizes application packets based on QoS class set in application properties as follows

VO: UGS and RTPS
VI: NRTPS and ERTPS
BE: BE and all control packets suck as TCP ACKs
BK: Everything else

Default EDCA Parameters#

The following tables shows the default EDCA parameters. This default parameter set is per page 899, IEEE Std 802.11-2016

Access Category	CWmin	CWmax	AIFSN	Max TXOP (μs)
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 ‑: Default EDCA access parameters for 802.11 b for both AP and STA

Access Category	CWmin	CWmax	AIFSN	Max TXOP (μs)
Background (AC_BK)	15	1023	7	2528
Best Effort (AC_BE)	15	1023	3	2528
Video (AC_VI)	7	15	2	4096
Voice (AC_VO)	3	7	2	2080

Table ‑: Default EDCA access parameters for 802.11 a / g / n / ac for both AP and STA

Access Category	CWmin	CWmax	AIFSN
Background (AC_BK)	15	1023	9
Best Effort (AC_BE)	15	1023	6
Video (AC_VI)	7	15	3
Voice (AC_VO)	3	7	2

Table ‑: Default EDCA access parameters for 802.11 p (dot11OCBActivated is true)

NOTE: The EDCA parameters can be configured by changing the Physical type parameter according to the different standard, IEEE802.11b (Medium Access Protocol à DSSS), IEEE802.11n (Medium Access Protocol à HT), IEEE802.11ac (Medium Access Protocol à VHT), IEEE802.11a and g (Medium Access Protocol à OFDMA and OCBA àFALSE), IEEE802.11p (Medium Access Protocol à OFDMA and OCBA àTRUE).

Rate Adaptation#

In NetSim (with default code), rate adaptation works as follows:

FALSE: This is similar to Receiver Based Auto Rate (RBAR) algorithm. In this, the PHY rate gets set based on the target PEP (packet error probability) for a given packet size, as given in the standard. The adaptation is termed as “FALSE” since the rate is pre-determined as per standard and there is no subsequent “adaptation”.

802.11 n/ac: Target PEP = 0.1, Packet Size: 4096 B
802.11 b: Target PEP = 0.08, Packet Size: 1024B
802.11 a/g/p: Target PEP:0.1, Packet size1000B

GENERIC: This is similar to the Auto Rate Fall Back (ARF) algorithm. In this algorithm:

Rate goes up one step for 20 consecutive packet successes

Rate goes down one step for 3 consecutive packet failures

MINSTREL: Per the minstrel rate adaptation algorithm implemented in Linux

If users, wish to set the PHY rate (MCS) by comparing the received signal strength against the Receiver minimum input sensitivity tables provided in the standards, they should comment the following line (line #38) in IEEE802_11.h, and rebuild the code

//#define _RECALCULATE_RX_SENSITIVITY_BASED_ON_PEP_

NetSim then chooses the rate at the beginning of the simulation and the rate doesn’t subsequently adapt. The receiver minimum input sensitivity levels are provided in the files

802.11b: IEEE802_11_DSSSPhy.c
802.11a, 802.11g and 802.11p: IEEE802.11_OFDMPhy.c
802.11n and 802.11ac: IEEE802_11_HTPhy.c

Selecting the different rate adaptation options would have no impact when running this modified code.

Model Limitations#

Mobility of Wireless nodes is not available in infrastructure mode (when connected via an Access Point) and is only available in Adhoc mode. Hence mobility for wireless nodes can only be set when running MANET simulations.
Authentication and encryption are not supported
While different APs can operate in different channels, all the Wireless nodes connected to one AP operate in the same channel.
No beacon generation, probing or association
RTS, CTS and ACK are always transmitted at the base rate (lowest MCS)
Roaming whereby a STA leaves serving AP to associate with target AP (usually based on RSSI/SNR)

Wi-Fi GUI Parameters#

The WLAN parameters can be accessed by right clicking on a Access Point or Wireless Node and selecting Interface Wireless Properties ->Datalink and Physical Layers

Access Point and Wireless Node Properties
Interface Wireless – Datalink Layer
Parameter	Scope	Range	Description
Rate Adaptation	Cell	False	The algorithm is similar to Receiver Based Auto Rate (RBAR) algorithm. In this, the PHY rate gets set based on the target PEP (packet error probability) for a given packet size. The adaptation is termed as “FALSE” since the rate is pre-determined as per standard and there is no subsequent “adaptation”
		Minstrel	Rate adaptation algorithm implemented in Linux
		Generic	The algorithm is similar to the Auto Rate Fall Back (ARF) algorithm. In this algorithm (i) Rate goes up one step for 20 consecutive packet successes, and (ii) Rate goes down one step after 3 consecutive packet failures
Short Retry Limit	Local	1 to 255	Determines the maximum number of transmission attempts of a frame. The length of MPDU is less than/ equal to Dot11 RTS Threshold value, made before a failure condition is indicated.
Long Retry Limit	Local	1 to 255	Determines the maximum number of transmission attempts of a frame. The length of MPDU is greater than Dot11 RTS Threshold value, made before a failure condition is indicated.
Dot11 RTS Threshold	Local	0 to 65535	The size of packets (or A-MPDU if applicable) above which RTS/CTS (Request to Send / Clear to Send) mechanism gets triggered.
MAC Address	Fixed	Auto Generated	The MAC address is a unique value associated with a network adapter. This is also known as hardware address or physical address. This is a 12-digit hexadecimal number (48 bits in length).
Buffer Size	Local	1 to 100	Buffer is the memory in a device which holds data packets temporarily. If incoming rate is higher than the outgoing rate, incoming packets are stored in the buffer. NetSim models the buffer as an egress buffer. Unit is MB.
Medium Access Protocol	Local	DCF	DCF is the process by which CSMA/CA is applied to Wi-Fi networks. DCF defines four components to ensure devices share the medium equally: Physical Carrier Sense, Virtual Carrier Sense, Random Back-off timers, and Interframe Spaces (IFS). DCF is used in non-QoS WLANs.
Medium Access Protocol	Local	EDCAF	QoS was introduced in 802.11e and is achieved using enhanced distributed channel access functions (EDCAFs). EDCA provides differentiated priorities to transmitted traffic, using four different access categories (ACs). With EDCA, high-priority traffic has a higher chance of being sent than low-priority traffic: a station with high priority traffic waits a little less before it sends its packet, on average, than a station with low priority traffic.
Physical Type	Local	DSSS	Direct Sequence Spread Spectrum. The physical type parameter is set to DSSS if the standard selected is IEEE802.11b.
		OFDM	Orthogonal Frequency Division Multiplexing is utilized as a digital multi-carrier modulation method. The physical type parameter is set to OFDM if the standard selected is IEEE802.11 a, g and p.
		HT	Operates in frequency bands 2.4GHz or 5GHz band. The physical type parameter is set to HT if the standard selected is IEEE802.11n.
		VHT	The physical type parameter is set to VHT if the standard selected is IEEE802.11ac.
OCBA Activated	Local	True or False	This parameter determines the type of standard to be chosen for the OFDM physical type. The standard is set to IEEE802.11p if OCBA is True. The standard is set to IEEE802.11a and g if OCBA is False.
BSS Type	Fixed	Auto Generated	The BSS type is fixed to Infrastructure mode. The wireless device can communicate - with each other or with a wired network - through an Access Point.
CW min (Slots)	Local	0 to 255	Specifies the initial Contention Window (CW) used by an Access Point (or STA) for a particular AC for generating a random number for the back-off.
CW max (Slots)	Local	0 to 65535	At each collision the CW is doubled. $CW_{Max}$ specifies the final maximum CW values used by an Access Point (or STA) for a particular AC for generating a random number for the back-off.
AIFSN (Slot)	Local	2 to 15	Specifies the number of slots after a SIFS duration.
Max TXOP	Local	0 to 65535	Specifies the maximum number of microseconds of an EDCA TXOP for a given AC. Unit is microseconds.
MSDU Lifetime (TU)	Local	0 to 500	Specifies the maximum duration an MSDU would be retained by the MAC before it is discarded, for a given AC. MSDU Lifetime is specified in TU.
Interface Wireless- Physical Layer
Protocol	Fixed	IEEE802.11	Defines the MAC and PHY specifications like IEEE802.11a/b/g/n/ac/p for wireless connectivity for fixed, portable and moving stations within a local area.
Connection Medium	Fixed	Auto Generated	Defines how the devices are connected or linked to each other.
Standard	Cell	IEEE802.11 a/b/g/n/ac/p	Refers to a family of specifications developed by IEEE for WLAN technology. The IEEE standards supported in NetSim are IEEE 802.11 a, b, g, n, ac and p. 802.11a provides up to 54 Mbps in 5GHz band. 802.11b provides 11 Mbps in the 2.4GHz bands. 802.11gprovides 54 Mbps transmission over short distances in the 2.4 GHz band. 802.11n adds up MIMO. 802.11ac provides support for wider channels and beamforming capabilities. 802.11p provides support to Intelligent Transportation Systems.
Transmission Type	Fixed	DSSS	The transmission type parameter is DSSS if the standard selected is IEEE802.11b.
		OFDM	The transmission type parameter is OFDM if the standard selected is IEEE802.11a, g and p.
		HT	The transmission type parameter is HT if the standard selected is IEEE802.11n.
		VHT	The transmission type parameter is VHT if the standard selected is IEEE802.11ac.
Number of Frames to Aggregate	Cell	1 to 1024 (11ac) 1 to 64 (11n)	Number of frame aggregated to form an A-MPDU. This is fixed and cannot be dynamically varied (except by modifying the code). See 3.1.12 for more information.
Transmit Power	Local	0 to 1000	Transmitted signal power. Note that the transmit power is not split among the antennas. This value is applied to each antenna in a multi-antenna transmitter. Unit is mW.
Antenna Gain	Local	0 to 1000	Unit is dBi.
Antenna Height	Local	0 to 1000	The height of antenna above the ground. Unit is m.
SIFS	Fixed	Auto Generated	The time interval required by a wireless device in between receiving a frame and responding to the frame. Unit is microseconds.
Frequency Band	Cell	2.4, 5 (Depends on the standard chosen)	Range of frequencies at which the device operates. The frequency band depends on the standard selected. Unit is GHz.
Bandwidth	Cell	20, 40, 60, 80, 160 (Depends on the standard chosen)	The bandwidth depends on the standard and the frequency band selected. Unit is MHz
CCA Mode	Fixed	Auto Generated	A mechanism to determine whether a medium is idle or not. It includes Carrier sensing and energy detection.
Slot Time	Fixed	Auto Generated	Time is quantized as slots in Wi-Fi. Unit is microseconds.
Standard Channel	Local	Depends on the standard chosen	The channel options defined in the standards. The options would also depend on the frequency band if the standard supports multiple bands.
CW Min	Fixed	Auto Generated	The minimum size of the Contention Window in units of slot time. The CW min is used by the MAC to calculate the back off time for channel access during a carrier sense.
CW Max	Fixed	Auto Generated	The maximum size of the Contention Window in units of slot time. The CW is doubled progressively when collisions occur.
Transmitting Antennas	Local	1 to 8	The number of transmit antennas. Note that power is not split among the transmit antennas but is assigned to each antenna. (The pair of Tx and Rx antenna present only for 802.11ac and 802.11n)
Receiving Antennas	Local	1 to 8	The number of receive antennas
Guard Interval	Local	400 and 800	Guard Interval is intended to avoid signal loss from multipath effect. Unit is nanoseconds.
Reference Distance d0	Local	1 to 10	Unit is m.

Table ‑: Internetworks Config Properties

IEEE802.11 Results#

IEEE802.11 performance metrics will be displayed in the results dashboard if the network scenario simulated consisted of at least one device with WLAN protocol enabled.

Parameter	Description
Device Id	It represents the Id’s of the wireless devices which supports 802.11 (WLAN)
Interface Id	It represents the interface Id’s of the wireless nodes
Frame Sent	It is the Number of frames sent by Access Point
Frame Received	It is the number of frames received by a wireless node
RTS Sent	It is the number of Request to send (RTS) packets sent by a Wireless Node. RTS/CTS frames are sent prior to transmission when the packet size exceeds RTS threshold. The access point receives the RTS and responds with a CTS frame. The station must receive a CTS frame before sending the data frame. The CTS also contains a time value that alerts other stations to hold off from accessing the medium while the station initiating the RTS transmits its data.
RTS Received	It is the number of RTS packets received by an Access Points
CTS Sent	It is the number of Clear to send (CTS) packets sent by an Access Points
CTS Received	It is the number of CTS packets received by Wireless Nodes
Successful BackOff	It is the number of successful backoffs running at a wireless node. In the IEEE 802.11 Wireless Local Area Networks (WLANs), network nodes experiencing collisions on the shared channel need to BackOff for a random period of time, which is uniformly selected from the Contention Window (CW). BackOff is a timer which is decreased as long as the medium is sensed to be idle for a DIFS, and frozen when a transmission is detected on the medium, and resumed when the channel is detected as idle again for a DIFS interval
Failed BackOff	It is the number of failed backoffs at wireless node

Table ‑: Description of IEEE 802.11 Metrics

Radio measurements log file#

NetSim IEEE802_11 Radio measurements csv log file records pathloss, shadowing loss, fading loss, transmitted power, received power, SNR, Interference Power, SINR, SNR, BER, NSS, MCS. This log file can be enabled in NetSim GUI by clicking on icon present in the tool bar as shown below.

Figure ‑: Enabling IEEE802.11 Radio Measurement logs

The IEEE802_11_RADIO_MEASUREMENTS_LOG.csv file will contain the following information:

Time in Milliseconds
Transmitter Name
Receiver Name
Distance between the Transmitter and the Receiver in meters
Packet ID
Packet Type
Control Packet Type
Transmitter Power in dBm
Total Loss in dB
Pathloss in dB
Shadowing Loss in dB
Fading Loss in dB
Received Power in dBm
Interference in dBm
SNR in dB
SINR in dB
BER
NSS
MCS

The log file can be accessed from the Simulations Results Window under the log file drop down in the left pane.

Figure ‑: IEEE802_11_RADIO_MEASUREMENTS_LOG.csv file highlighted in the Results window.

Figure ‑: IEEE802_11_RADIO_MEASUREMENTS_LOG.csv file

Implementation details and Assumptions:

The log is written during each packet received at the physical layer (PHY_IN). Hence the number of entries will be based on the number of packets received, by all nodes or specific nodes based on values present in the DEVICE_ID_LIST array.
MCS column displays the MCS index from the Phy parameters table in case of IEEE802.11 n and ac. However, it displays the index value from the Phy parameters table as nIndex-1 in case of DSSS based standards such as b and OFDM based standards such as a, g and p.
The NSS value is currently set to the minimum of transmit and receive antenna counts in the same device. For example, if Transmitting Antennas is set to 2 and receiving Antennas is set to 8 then NSS is set to 2.

Layer 2 (L2) Ethernet Switching#

Layer 2 switches have a MAC address table that contains a MAC address and port number. Switches follow this simple algorithm for forwarding packets:

When a frame is received, the switch compares the SOURCE MAC address to the MAC address table. If the SOURCE is unknown, the switch adds it to the table along with the port number the packet was received on. In this way, the switch learns the MAC address and port of every transmitting device.
The switch then compares the DESTINATION MAC address with the table. If there is an entry, the switch forwards the frame out the associated port. If there is no entry, the switch sends the packet out all its ports, except the port that the frame was received on This is termed as Flooding.
It does not learn the destination MAC until it receives a frame from that device

Spanning Tree Protocol#

NetSim ethernet switches implement Spanning tree protocol to build a loop-free logical topology. This is always enabled and cannot be disabled.

Switch Port States#

All switch ports in switches can be in one of the following states:

Blocking: A port that would cause a switching loop if it were active. No user data is sent or received over a blocking port.
Listening: The switch processes BPDUs and awaits possible new information that would cause it to return to the blocking state. It does not populate the MAC address table and it does not forward frames.
Learning: While the port does not yet forward frames, it does learn source addresses from frames received and adds them to the filtering database (switching database). It populates the MAC address table but does not forward frames.
Forwarding: A port receiving and sending data in Ethernet frames, normal operation.

It is recommended that the application start time is set to a value that is greater than the time it takes for the spanning tree protocol to complete (of the order of a 100s of milliseconds).

Model Limitations#

The spanning protocol is only run at the beginning of simulation. If a link fails, the spanning protocol is not re-run.
If applications are started prior to completion of spanning tree protocol, then the MAC table created is not updated per the spanning tree protocol.
Jumbo Frames are not supported in NetSim Ethernet Protocol

Switch: GUI Parameters#

Switch properties can be set by right clicking on a switch-->Properties--> Interface_1(ETHERNET)

Figure ‑: Data Link Layer Properties of a Switch

The properties that can be set are:

Parameter	Type *	Range	Description
MAC ADDRESS	Fixed	Auto generated	The MAC address is a unique value associated with a network adapter. This is also known as hardware address or physical address. This is a 12-digit hexadecimal number (48 bits in length).
Buffer Size (MB)	Local	1-5	Buffer is the memory in a device which holds data packets temporarily. If the transmitting port is busy, incoming packets are stored in the buffer. NetSim models the buffer as an egress buffer and the range is 1 MB to 5MB per port of the switch.
STP Status	Fixed	TRUE	Spanning Tree Protocol is set to “True” in the Switches by default.
Switch Priority	Local	1-61440	This is the priority that can be assigned to the Switch. Priority is involved in deciding the root bridge for STP.
Switch ID	Fixed	Auto generated	Each switch has a unique ID for spanning tree calculation. The ID is derived by combining the priority and MAC address. Since a switch has a MAC address for each port, the least of the MAC address of the connected ports is taken while forming the unique ID.
Spanning Tree	Fixed	IEEE802.1D	The Spanning Tree Protocol (STP) ensures a loop-free topology for any bridged Ethernet local area network. The basic function of STP is to prevent bridge loops and the broadcast radiation that results from them. STP is standardized as IEEE 802.1D. As the name suggests, it creates a spanning tree within a network of connected layer-2 bridges (typically Ethernet switches) and disables those links that are not part of the spanning tree, leaving a single active path between any two network nodes.
STP Cost	Local	0-1000	Cost used by the switch to calculate spanning tree. The cost assigned to each port is based on its data rate.
Switching Mode	Local	Store Forward, Cut Through	Store and Forward: Forwarding takes place only after receipt of complete frame. This technique buffers the incoming frame and checks for errors. If no error is found it forwards the frame to the outgoing port, otherwise it discards the frame. Cut through: Switch forwards the incoming frames to its appropriate outgoing port immediately after receipt of destination address of the frame.
VLAN Status*	Local	TRUE, FALSE	To enable/disable VLAN

Table ‑: Description of Datalink layer properties of switch parameter

*Requires license for Component 3 Advanced Routing and Switching

Open Shortest Path First (OSPF v2) Routing Protocol#

OSPF Overview#

OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.

OSPF routes IP packets based solely on the destination IP address found in the IP packet header. IP packets are routed "as is" -- they are not encapsulated in any further protocol headers as they transit the Autonomous System. OSPF is a dynamic routing protocol. In NetSim, OSPF can detect topological changes in the AS (such as router interface failures) and calculate new loop-free routes after a period of convergence.

Each router maintains a database describing the Autonomous System's topology. This database is referred to as the link-state database. Each participating router has an identical database. Each individual piece of this database is a particular router's local state (e.g., the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the Autonomous System by flooding.

All routers run the exact same algorithm, in parallel. From the link-state database, each router constructs a tree of shortest paths with itself as root. This shortest-path tree gives the route to each destination in the Autonomous System. The cost of a route is described by a single dimensionless metric.

OSPF Features#

OSPF Messages – Hello, DD, LS Request, LS Update, LS Ack
Router LSA
The Neighbor Data structure features the following
Link state request list
DB summary list
Link state re-transmission list
Link state send list
Link state re-transmission timer
Inactivity timer
Routing table
Shortest path tree
The Interface data structure features
Neighbor router list
Flood timer
Update LS list
Network LS timer
Delayed ack list
The Protocol data structure features
Interface list
Area list
Max age removal timer
SPF timer
Routing table
The Area Data structure features
Associated interface list
Router LSA list
Network LSA list
Router summary LSA list
Network summary LSA list
Max age list
Router LS timer
Shortest path list
The following can be logged during simulation
Hello log
SPF log
Common log
Debug logs – LSDB, RXList, RLSA, RCVLSU, LSULIST, Route

Excluded Features#

The following features in OSPF have not been implemented - Multiple Areas, Network LSA, Router summary LSA, Network summary LSA, Authentication, Equal cost multipath, External AS, External routing information, Interface type – Broadcast, NBMA, Virtual, Point to multi-point

OSPF: GUI Parameters#

OSPF properties can be set by right clicking on Router --> Properties --> Application layer see Figure 3‑14.

Figure ‑: Routing protocol properties of router

The properties that can be set are:

Parameter	Type *	Range	Description
Version	Global	Fixed	OSPF Version 2 as per RFC 2328 for IPv4.
LSRefresh Time (s)	Global	Fixed	The maximum time between distinct originations of any particular Link State Advertisement (LSA). If the link state age field of one of the router’s self-originated LSAs reaches the value LSRefreshTime, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. The value of LSRefreshTime is set to 30 minutes.
LSA Maxage (s)	Global	Fixed	The maximum age that an LSA can attain. When an LSA's LS age field reaches MaxAge, it is reflooded in an attempt to flush the LSA from the routing domain. LSAs of age MaxAge are not used in the routing table calculation. The default value of MaxAge is set to 1 hour or 3600s
Increment Age (s)	Global	0 - 100	This is an internal variable of NetSim used for simulation purposes. This value decides how often to increase the age of the LSA in the OSPF LSA Lists. A small value will cause frequent updates and provide higher accuracy but may slow down simulation, and vice versa for a large value
Maxage removal Time (s)	Global	0 - 9999	This variable decides the time when the LSA is removed from the MaxAgeLSA List
MinLS Interval (s)	Global	Fixed	The minimum time between distinct originations of any particular LSA. The value of MinLSInterval is set to 5 seconds
SPFCalc Delay (ms)	Global	0 - 9999	If SPF calculation is triggered, then the router will wait for this duration before starting the calculation. This can be used for the router to take multiple updates into account
Flood Timer (ms)	Global	0 - 9999	The amount of time to wait before initializing the flood procedure. A random number between 0 to the set value will be chosen. The flood timer on/off is per the ISSENDDELAYUPDATE variable setting
Advertise Self Interface	Global	True/False	This is reserved for future use. As of NetSim v12, this should always be true. This will be used when a point-to-multipoint link is connected to the interface, and when such links are connected this should be set to false
Send Delayed Update	Global	True/False	This variable can be set to true to delay sending the LSU. If set to true, then the delay would be per the flooding timer. Else the update is set immediately.

Table ‑: Description of Application layer Routing protocol properties

*Global – Changes in all devices of similar type. Local – Only changes in current device

Transmission Control Protocol (TCP)#

TCP overview#

TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi-network applications. The TCP provides for reliable communication between host computers connected computer communication networks. Very few assumptions are made as to the reliability of the communication protocols below the TCP layer. TCP assumes it can obtain a simple, potentially unreliable datagram service from the lower-level protocols. In principle, the TCP should be able to operate above a wide spectrum of communication systems ranging from wired to wireless to mobile communication.

The TCP fits into a layered protocol architecture just above a basic Internet Protocol which provides a way for the TCP to send and receive variable-length segments of information enclosed in IP packets. The IP packet provides a means for addressing source and destination TCPs in different networks. The IP protocol also deals with any fragmentation or reassembly of the TCP segments required to achieve transport and delivery through multiple networks and interconnecting gateways.

Application
TCP
IP
MAC
PHY

Figure ‑: Protocol Layering

TCP Features#

The following features are implemented in TCP.

Three-way handshake (open/close)

Sequence Numbers
Slow start and congestion avoidance
Fast Retransmit/Fast Recovery
Selective Acknowledgement

Congestion Control Algorithms in TCP#

The following congestion control algorithms are supported in NetSim.

Old Tahoe
Tahoe
Reno
New Reno
BIC
CUBIC

Limitations of TCP#

Send and Receive buffers are infinite

TCP: GUI parameters#

The TCP parameters can be accessed by right clicking on a node and selecting Properties -> Transport Layer

Figure ‑: Transport layer protocol properties of wired node

The properties that can be set are:

Parameter	Type *	Range	Description
Congestion Control Algorithm	Local	OLD TAHOE, TAHOE, RENO, NEW RENO, BIC, CUBIC	Congestion control algorithm is used to control the network congestion. Old Tahoe is the combination of slow start and congestion avoidance algorithm. The Fast-retransmit algorithms operating with Old Tahoe is known as the Tahoe. This algorithm works based on duplicate ack. When it receives three duplicate ack, which is the indication of segment loss, that segment will be retransmitted immediately without waiting for timeout. Reno implements fast recovery in case of three duplicate acknowledgements. New Reno improves retransmission during the fast-recovery phase of TCP Reno. BIC algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm. CUBIC is an implementation of TCP with an optimized congestion control algorithm for high bandwidth networks with high latency.
Congestion plot enabled	Local	FALSE, TRUE	Congestion plot can enable or disable by selecting value as TRUE and FALSE
Max SYN Retries	Local	1-10	Maximum number of TCP SYN ACK packets that can be retransmitted. The value should in the range of 1 to 10.
Acknowledgement Type	Local	Delayed, Undelayed	If set to delayed, ACK response will be delayed improving network performance. If set to Un delayed, ACK will be sent immediately without delay.
MSS (bytes)	Local	64-1460	The maximum amount of data that a single message may contain. The MSS is the maximum data size and does not include the size of the header. MSS = MTU – (Network and Transport layer protocol headers).
Initial SSThreshold(bytes)	Local	5840-65535	The server-initial–ss-threshold should be in the range between 5840 and 65535 bytes.
Time Wait Timer(s)	Local	30-240	The Time wait timer default value is 120 seconds. The purpose of TIME-WAIT is to prevent delayed packets from one connection being accepted by a later connection.
Selective ACK	Local	TRUE, FALSE	In Selective Acknowledgment (SACK) mechanism, the receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments.
Window Scaling	Local	TRUE, FALSE	The TCP window scaling option is to increase the receive window size allowed in Transmission Control Protocol above its former maximum value of 65,535 bytes.
Sack Permitted	Local	TRUE, FALSE	The SACK-permitted option is offered to the remote end during TCP setup as an option to an opening SYN packet. The SACK option permits selective acknowledgment of permitted data.
Timestamp Option	Local	TRUE, FALSE	TCP is a symmetric protocol, allowing data to be sent at any time in either direction. Therefore, timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamps Option.

Table ‑: Description of Transport layer protocol properties

TCP Performance Metrics#

TCP Metrics table will be available in the Simulation Results dashboard if TCP is enabled in at least one device in the network. It provides the following information specific to TCP.

Parameter	Description
Source	It displays the name with ID of the source device which generates TCP packets
Destination	It displays the name with ID of the destination device which receives TCP packets
Local Address	It displays the local IP address with port number of the device present in source column
Remote Address	It represents the remote IP address with port number for the source and destination
Syn Sent	It is the number of syn packets sent by the source
Syn-Ack Sent	It is the number of syn ack packets sent by the destination
Segment Sent	It is the number of segments sent by a source
Segment Received	It is the number of segments received by a destination
Segment Retransmitted	It is the number of segments retransmitted by the source
Ack Sent	It is the number of acknowledgements sent by a source to destination in response to TCP syn ack and the number of acks sent by destination to source in response to the successful reception of data packet
Ack Received	It is the number of acknowledgements received by source in response to data packets and the number of acks received by destination in response to syn ack packet
Duplicate segment received	It is the number of duplicate segments received by destination
Out of order segment received	It is the number of out of ordered packets received by destination
Duplicate ack received	It is the number of duplicate acknowledgements received by source
Times RTO expired	It is the number of times RTO timer expired at source

Table ‑: Parameter discerption of TCP Metrics table

TCP Reference Documents#

RFC 793: TRANSMISSION CONTROL PROTOCOL
RFC 1122: Requirements for Internet Hosts -- Communication Layers
RFC 5681: TCP Congestion Control
RFC 3390: Increasing TCP's Initial Window
RFC 6298: Computing TCP's Retransmission Timer
RFC 2018: TCP Selective Acknowledgment Options
RFC 6582: The NewReno Modification to TCP's Fast Recovery Algorithm
RFC 6675: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
RFC 7323: TCP Extensions for High Performance
https://research.csc.ncsu.edu/netsrv/sites/default/files/cubic_a_new_tcp_2008.pdf
https://research.csc.ncsu.edu/netsrv/sites/default/files/bitcp.pdf
https://research.csc.ncsu.edu/netsrv/sites/default/files/hystart_techreport_2008.pdf

User Datagram Protocol (UDP)#

UDP Overview#

UDP (User Datagram Protocol) is a communication protocol that offers a limited amount of service when messages are exchanged between computers in a network that uses the Internet Protocol (IP). UDP uses the Internet Protocol to get a data unit (called a datagram) from one computer to another.

This protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring reliable delivery of streams of data should use the Transmission Control Protocol (TCP).

UDP: GUI parameters#

The UDP protocol can be set for an application by clicking on the Applications Transport Protocol option as shown below see Figure 3‑17.

Figure ‑: Application configuration window

UDP Performance Metrics#

UDP Metrics table will be available in the Simulation Results dashboard if UDP is enabled in at least one device in the network. It provides the following information specific to UDP see Table 3‑23.

Parameter	Description
Device Id	It is the Id of a device in which UDP is enabled
Local Address	It represents the IP address with port number of the local device (either source or destination)
Foreign Address	It represents the IP address with port number of the remote device (either source or destination)
Datagram sent	It is the total number of datagrams sent from the source
Datagram received	It is the total number of datagrams received at the destination

Table ‑: Parameter discerption of UDP Metrics table

UDP Reference Documents#

RFC 768: User Datagram Protocol

IP Protocol#

IP Performance Metrics#

IP Metrics table will be available in the Simulation Results dashboard if IP is enabled in at least one device in the network. It provides the following information specific to IP protocol:

Parameter	Description
Device_Id	It displays the Id’s of the Layer_3 devices
Packet sent	It is the number of packets sent by a source, intermediate devices (Router or L3 switch)
Packet forwarded	It is the number of packets forwarded by intermediate devices (Router or L3 switch)
Packet received	It is the number of data packets received by destination, intermediate devices (routing packets (OSPF, RIP etc.) received by Routers)
Packet discarded	It is the number of data packets that are discarded after their TTL value is expired.
TTL expired	Time-to-live (TTL) is a value in an Internet Protocol (IP) packet that tells a network router whether or not the packet has been in the network too long and should be discarded
Firewall blocked	It is the number of packets blocked by firewall at routers

Table ‑: Parameter discerption of IP Metrics table

Buffering, Queueing and Scheduling#

Buffers#

Devices and their Interfaces with buffers that support queuing and scheduling algorithms are:

Router (WAN – Network Layer)
EPC (WAN – Network Layer)
6LOWPAN (WAN – Network Layer)
Satellite Gateway (WAN – Network Layer)

Queuing and scheduling in NetSim, works as follows:

The scheduler schedules packet transmission from the head-of-queue per the scheduling algorithm. FIFO algorithm uses a single queue while Priority, RR and WFQ use 4 queues (1 queue for each priority)
The buffer size is a user input. This buffer is not split among the various queues. At any point in time the cumulative size of all queues is the buffer fill.
The way in which the individual queues are filled up, is per the queuing algorithm selected (implemented in version 12.1)

The buffer is an egress buffer. The buffer size in Mega Bytes (MB), for each interface mentioned above is a user input. The options 8, 16, 32, 64, 128, 256, 512, 1024, 2048 and 4096 MB

Queuing#

Drop Tail: The queue is filled up till the buffer capacity. When the queue is full if any packet arrives, it is dropped. The buffer size is a user input.

Random Early Detection (RED):

The queue is filled up till the average queue size is equal to minimum threshold, without dropping any packet.
Randomly packets are dropped when the average queue size is between minimum threshold and maximum threshold. The number of packets being dropped depends on the Max Probability value.
All packets are dropped when the average queue size is above maximum threshold.

User Inputs - Maximum threshold, minimum threshold and maximum probability.

$$Avg\ = \frac{t_{n}}{t_{n + 1}}\ \left( Avg - x_{n} \right) + x_{n}$$

Avg – Average Queue Size. Avg is initially 0

t_n – Time when n^th packet was added to the queue

t_n + 1 – Current time which is the time when the (n+1)^th packet is added

x_n _– Size of n^th packet (B)

Packets are dropped if

$No\ of\ Dropped\ Packets > \frac{Rand\ (0,1)}{P}\ $ where p = C₁ × Avg + C₂

$$C_{1} = \frac{Max\ Probability}{(Max\ Threshold - Min\ Threshold)}$$

$$C_{2} = \ \frac{Max\ Probability}{(Max\ Threshold - Min\ Threshold)} \times Min\ Threshold$$

Weighted Random Early Detection (WRED):

Please refer to RED explained earlier. This is modified as follows

There are different Max and Min threshold value for each type of priority, i.e. High, Medium, Normal, Low (The RED algorithm had only one set of Max and Min Threshold)
For the given threshold values of the packets, Random Early Detection (RED) algorithm is applied.

Reference Documents

Sally Floyd, Van Jacobson (1993). Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking.

Queue Size: The queue depth can be obtained from the Event Trace or by modifying the protocol source code. To obtain it from the event trace, an MS Excel script would need to be written to filter by node, and at different points of time, add the number of APP-OUT events and subtract the number of TRANSPORT-OUT events. Note that deeper issues such as segmentation etc. will need to be handled appropriately based on the way the application and transport layer interact.

Scheduling#

First In First Out (FIFO): Packets are scheduled according to their arrival time in the queue. Hence, first in packet in queue is scheduled first.

Priority: NetSim supports 4 priority queues namely High, Medium, Normal and Low. With this scheduling, first all packets in the High priority queue are served, and then those in Medium, then in normal and finally those packets in the low priority queue. Note that this could lead to situations where only higher priority packets are served and lower priority packets are never served.

Round Robin: Packet from all the 4 priorities are served in circular order. When packet arrives, they are stored in the corresponding priority list

Weighted Fair Queuing (WFQ): When packet arrives, they are stored in corresponding list according to priority. Packets are served in order of maximum weight of the priority list. In NetSim WFQ is approximated as:

Weight = (Number of packets in Queue) × Priority where

Priority = 1, 2, 3 or 4

1 - Low priority, 2 - Normal, 3 – Medium, 4 - High

Early Deadline First (EDF): Packets are added in the queue as they arrive. While dequeuing the packets with earliest deadline are served first. The packets which have exceeded deadline are dropped.

Deadline = Max Latency − Packet Creation Time

Max Latency with respect to quality of service (QoS) of the packet is a user input

Links#

Modeling Error in Wired Links#

The error rates in NetSim wired links are based on a standard error measurement unit called BER or Bit Error Rate. BER represents the ratio of errored bits to total bits.

The BER value can be set by the user. A typical value of BER, say 1 × 10⁻⁶, which equals 0.000001, means that 1 bit is in error for every one-million bits transmitted. It is important to note that Bit Error Rate is NOT equal to Packet error rate. (PER)

PER = 1 − (1−BER)^L where L is the packet length in bits

For BER values less than 0.001, this is mathematically approximated in NetSim as

PER = BER * L

Featured Examples#

Sample configuration files for all networks are available in the Examples Menu in NetSim Home Screen. These files provide examples on How NetSim can be used – the parameters that can be changed and the typical effect it has on performance.

Factors affecting WLAN PHY Rate#

The examples explained in this section focuses on the factors which affect the PHY Rate/Link Throughput of 802.11 based networks:

Transmitter power (More Tx power leads to higher throughput)
Channel Path loss (Higher path loss exponent leads to lower throughput)
Receiver sensitivity (Lower Rx sensitivity leads to higher throughput)
Distance (Higher distance between nodes leads to lower throughput)

Effect of Transmitter power #

Open NetSim and Select Examples->Internetworks->Wi-Fi-> Effect of Transmitter Power then click on the tile in the middle panel to load the example as shown in Figure 4‑1.

Figure ‑: List of scenarios for the example of effect of transmitter power

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑2.

Figure ‑: Network set up for studying the effect of transmitter power

Increase in transmitter power increases the received power when all other parameters are constant. Increased received power leads to higher SNR and hence higher PHY Data rates, lesser error and higher throughputs.

Network Settings

Environment Grid length: 500m x 500m
Distance between Access Point and the Wireless Node is set to 35m
Set transmitter power to 100mW under Interface Wireless > Physical layer properties of Access point
Set DCF as the medium access layer protocol under datalink layer properties of access point and wireless node.
Channel Characteristics: Path Loss Only, Path Loss Model: Log Distance, Path Loss Exponent: 2.5
Application Generation Rate: 10Mbps (Packet Size: 1460, Inter Arrival Time: 1168µs)
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
Enable the Plots and Run the simulation for 10s
Go back to the scenario and decrease the Transmitter Power to 100, 60, 40, 20 and 10 respectively and run simulation for 10s. See that, there is a decrease in the Throughput gradually.

Results

Transmitter Power (mW)	Throughput (Mbps)	Phy Rate (Mbps)
100	5.94	11
60	3.79	5
40	1.67	2
20	0.89	1
10	0.0	0

Table ‑: Result comparison of different transmitter power vs. throughput

Effect of AP-STA Distance on throughput #

Open NetSim and Select Examples > Internetworks > Wi-Fi > Effect of AP STA Distance on throughput then click on the tile in the middle panel to load the example as shown in Figure 4‑3.

Figure ‑: List of scenarios for the example effect of AP-STA distance on throughput

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑4.

Figure ‑: Network set up for studying the Effect of AP-STA Distance on throughput

As the distance between two devices increases the received signal power reduces as propagation loss increases with distance. As the received power reduces, the underlying PHY rate of the channel drops.

Network Settings

Environment Grid length: 500m x 500m
Distance between Access Point and the Wireless Node is set to 5m
Set DCF as the medium access layer protocol under datalink layer properties of access point and wireless node.
WLAN Standard is set to 802.11ac and No. of Tx and Rx Antenna is set to 1 in access point and No. of Tx is 1 and Rx Antenna is set to 2 in wireless node (Right-Click Access Point or Wireless Node > Properties > Interface Wireless > Transmitting Antennas and Receiving Antennas) and Bandwidth is set to 20 MHz in both Access-point and wireless-node Transmitter Power set to 100mW in both Access-point and wireless-node.
Wired Link speed was set to 1Gbps and propagation delay to 10 µs in wired links.
Channel Characteristics: Path Loss Only, Path Loss Model: Log Distance, Path Loss Exponent: 3.5.
Application Generation Rate: 100 Mbps (Packet Size: 1460, Inter Arrival Time: 116 µs)
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
Enable the plots and run the simulation for 10s.
Go back to the scenario and increase the distance as per result table and Run simulation for 10s.

Results

Distance (m)	Throughput (Mbps)
5	22.81
10	21.61
15	17.87
20	14.70
25	12.49
30	9.56
35	5.63
40	0

Table ‑: Result comparison of different distance vs. throughput

Plot

Figure ‑: Plot of Throughput vs Distance

Effect of Pathloss Exponent #

Open NetSim and Select Examples > Internetworks > Wi-Fi > Effect of Pathloss Exponent then click on the tile in the middle panel to load the example as shown in Figure 4‑6.

Figure ‑: List of scenarios for the example of effect of pathloss exponent

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file as shown Figure 4‑7.

Figure ‑: Network set up for studying the effect of pathloss exponent

Path Loss or Attenuation of RF signals occurs naturally with distance. Losses can be increased by increasing the path loss exponent (η). This option is available in channel characteristics. Users can compare the results by changing the path loss exponent (η) value.

Network Settings

Environment Grid length: 500m x 500m
Distance between Access Point and the Wireless Node is set to 20m
Set DCF as the medium access layer protocol under datalink layer properties of access point and wireless node. WLAN Standard is set to 802.11ac and No. of Tx and Rx Antenna is set to 1 in both access point and wireless node (Right-Click Access Point or Wireless Node > Properties > Interface Wireless > Transmitting Antennas and Receiving Antennas) and Bandwidth is set to 20 MHz in both Access-point and wireless-node and Transmitter Power set to 100mW in both Access-point and wireless-node.
Wired Link speed was set to 1Gbps and propagation delay to 10 µs in wired links.
Channel Characteristics: Path Loss Only, Path Loss Model: Log Distance, Path Loss Exponent: 2
Application Generation rate: 100 Mbps (Packet Size: 1460, Inter Arrival Time: 116 µs)
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
In NetSim GUI Plots are Enabled and Run simulation for 10s.
Go back to the scenario and increase the Path Loss Exponent from 2 to 2.5, 3, 3.5, 4, and 4.5 respectively and Run simulation for 10s.

Results

Path loss Exponent	Throughput (Mbps)
2.0	22.81
2.5	21.61
3.0	20.04
3.5	14.70
4.0	9.56
4.5	0

Table ‑: Result comparison of different pathloss exponent value vs. throughput

Plot

Figure ‑: Plot of Throughput vs Path loss Exponent

Queuing and buffer overflow in routers #

Open NetSim and Select Examples > Internetworks >Queuing and buffer overflow in routers then click on the tile in the middle panel to load the example as shown in Figure 4‑9.

Figure ‑: List of scenarios for the example of queuing and buffer overflow in routers

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file as shown Figure 4‑10.

Figure ‑: Network set up for studying the queuing and buffer overflow in routers

Network Settings

Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP

Generation rate = 10Mbps for each application (Packet Size: 1460, Inter Arrival Time: 1168µs)
Generation Rate (Mbps) = (Packet size (bytes) * 8) / Inter arrival time (µs))
The traffic generation rate can be modified by changing application properties. Note that the generation rate should be less than or equal to service rate for steady-state simulation, where the service rate is defined as the data rate supported by the Bottle-neck link. In this case, there is no bottle neck link since all links support up to 100 Mbps
Plots and Packet Trace is Enabled
Simulate for 100s and note down the throughput
Go back to the scenario and change the link speed (both Uplink and Downlink Speed) between Router_5 and Wired_Node_4 from the default 100 Mbps to 25 Mbps. In this case, the link between Router_5 and Wired_Node_4 becomes a Bottle-neck link, since the link rate (i.e., service rate) is less than the generation rate of 30 Mbps (10 * 3).

Discussion

Bottleneck link 100Mbps: In this scenario, router receives packets from three links at the rate of 10 Mbps each, a total of 30 Mbps. And the router-node link supports 100 Mbps. Hence there is no queuing / packet drop in the Router. The application throughput would be approximately equal to the generation rate.

Figure ‑: Application Metrics window for Bottleneck link 100Mbps

Bottleneck link 25Mbps: In this case, the bottleneck link supports only 25 Mbps. Due to this, packets get accumulated in the router's buffer, which overflows after reaching its limit and hence router starts dropping the packets. Application throughput would be approximately equal to the bottle neck link capacity.

Figure ‑: Application Metrics window for Bottleneck link 25Mbps

Frame aggregation in 802.11n #

Open NetSim and Select Examples > Internetworks > Wi-Fi > 802.11n Frame Aggregation then click on the tile in the middle panel to load the example as shown in Figure 4‑13.

Figure ‑: List of scenarios for the example of 802.11n frame aggregation

The following network topology is shown in NetSim UI as shown Figure 4‑14.

Figure ‑: Network set up for studying the 802.11n frame aggregation

Network Settings

In the Environment Settings, Grid length is set to 50m * 50m

Distance between Access Point and the Wireless Node is 20m
Set DCF as the medium access layer protocol under datalink layer properties of Access point and wireless node.
Click on the Application icon present in the top ribbon/toolbar
CBR Application with 100 Mbps Generation Rate (Packet Size: 1460, Inter Arrival Time: 116µs)
Set Transport Protocol to UDP
WLAN Standard is set to 802.11n and No. of Frames to Aggregate is set to 1 in both access point and wireless node (Right-Click Access Point or Wireless Node > Properties > Interface Wireless > No. of Frames to Aggregate)
Channel Characteristics: Path Loss Only, Path Loss Model: Log Distance, and Path Loss Exponent: 3. (Wireless Link Properties)
Enable the Plots and Packet trace and run the simulation for 10s. Then check the throughput in the results window
Go back to the scenario and increase the No. of Frames to Aggregate to 5 and 10 respectively and check the throughput in the results window.

Results and discussion

No of Frames Aggregated	Application Throughput
1	23.97 Mbps
5	44.77 Mbps
10	54.24 Mbps

Table ‑: No of Frames Aggregated vs. Application Throughput

Frame aggregation is responsible for joining multiple MSDUs into a single MPDU that can be delivered to the physical layer as a single unit for transmission. As we increase the number of frames aggregated it results in lesser number of ack’s. Hence, more data frames are transmitted per unit time leading to a higher application throughput.
For No. of frames to Aggregate is set to 5, we get five successive frames followed by a WLAN_Block_Ack (which is used to acknowledge that five frames are received successfully). Users can observe this in Packet Trace by filtering packet status to successful and Tx_ID as Access Point and Wireless Node.
Note that in the early stages of the simulation the AP would transmit whatever the number of frames/packets in its buffer. It will not wait for 5 frames to be aggregated, if say number of frames to be aggregated is set as 5. If Access Point buffer has more than 5 frames, it will aggregate 5 frames and then send. After sending 5 frames it will receive one WLAN_Block_Ack.

Rate Adaptation in 802.11b #

NetSim rate adaptation is explained in section 3.1.21 of this document. This experiment can be performed with Standard and Pro version of NetSim since it involves code modification.

User should uncomment the following line (line #38) in IEEE802_11.h in 802.11 project and rebuild the code and then perform this example.

#define _RECALCULATE_RX_SENSITIVITY_BASED_ON_PEP_

Open NetSim, Select Examples > Internetworks > Wi-Fi > 802.11 Rate Adaptation then click on the tile in the middle panel to load the example as shown in Figure 4‑15.

Figure ‑: List of scenarios for the example of 802.11 rate adaptation

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for Rate Adaptation.

Figure ‑: Network set up for studying the Wi-Fi Rate Adaptation

Network Settings

Environment Grid length: 500m * 500m
Distance between AP and Wireless Node is 65.5m
Enabled Packet Trace and plot option
Set rate adaptation as Generic in datalink properties of access_point and wireless node
Set DCF as the medium access layer protocol under datalink layer properties of access_point and wireless node.
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
Set WLAN Standard à 802.11b
Channel Characteristics à Path Loss only, Path Loss Model à Log Distance and Path loss Exponent à 3.25. (Wireless Link Properties)
CBR application with 10Mbps generation rate (Set Packet Size: 1460 Bytes, Inter Arrival Time: 1168 micro sec)
Simulate for 10 sec.

Results and Discussion

Open Packet Trace and filter Packet Type to CBR, Transmitter_ID to Access Point 3 andf filter the packet status to errored and successful then calculate Phy rate. Phy rate can be calculated using packet trace by using the formula shown below:

Phy rate (802.11b) = Phy_layer_payload * 8/(phy end time−phy arrival time−192)

192 μs 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 NetSim User Manual > Section 8.4.2 How to set filters to NetSim Trace file.

Figure ‑: Packet Trace

The ‘Generic’ rate adaptation algorithm is similar to the Auto Rate Fall Back (ARF) algorithm. In this algorithm:

Rate goes up one step for 20 consecutive packet successes.
Rate goes down one step for 4 continuous packet failures

In the above screenshot, the Phy rate reduces from 11Mbps to 5.5Mbps, since there are 4 consecutive data error packets. Then the rate increases from 5.5Mbps to 11Mbps one there is 20 consecutive successful data packet transmissions.

802.11n MIMO #

Open NetSim, Select Examples -> Internetworks -> Wi-Fi -> 802.11n-MIMO then click on the tile in the middle panel to load the example shown in Figure 4‑18.

Figure ‑: List of scenarios for the example of 802.11n-MIMO

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for 802.11n-MIMO.

Figure ‑: Network set up for studying the 802.11n-MIMO

Network Settings

Environment Grid length: 50m * 50m

Distance between AP and Wireless node is 20m.
Set DCF as the medium access layer protocol under datalink layer properties of access_ point and wireless node
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
WLAN Standard is set to 802.11n and No. of Tx and Rx Antennas is set to 1 in both access point and wireless node (Right-Click Access Point or Wireless Node > Properties > Interface Wireless > Transmitting Antennas and Receiving Antennas)
Channel Characteristics à Path Loss only, Path Loss Model à Log Distance and Path loss Exponent à 3. (Wireless Link Properties.
CBR application with 50Mbps generation rate. (Set Inter Arrival Time: 233 (micro sec)).
Enable Plots.
Simulate for 10 sec and check the throughput.
Go back to the scenario and increase the Number of Tx and Rx Antenna 1*1 to 2*2, 3*3, 4*4 respectively and check the throughput in the results window.

Results and Discussion

Number of Tx and Rx Antenna	Throughput
1 x 1	23.97 Mbps
2 x 2	31.04 Mbps
3 x 3	33.38 Mbps
4 x 4	35.95 Mbps

Table ‑: Number of Tx and Rx Antenna vs. Throughput

MIMO is a method for multiplying the capacity of a radio link using multiple transmit and receive antennas. Increasing the Transmitting Antennas and Receiving Antennas in PHY Data rate (link capacity) and hence leads to an increase in application throughput.

Effect of Bandwidth and Guard Interval in Wi-Fi 802.11ac#

Effect of Bandwidth #

Open NetSim and Select Examples > Internetworks > Wi-Fi > Effect of bandwidth in Wi-Fi 802.11ac then click on the tile in the middle panel to load the example as shown in Figure 4‑20.

Figure ‑: List of scenarios for the example of effect of bandwidth in Wi-Fi 802.11ac

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file as shown Figure 4‑21.

Figure ‑: Network set up for studying the effect of bandwidth in Wi-Fi 802.11ac

Network Settings

Environment Grid length: 50m * 50m.
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
Channel Characteristics: NO PATHLOSS in wireless link properties.
Set Bit Error rate and Propagation delay to zero under wired link properties
Set 802.11ac standard and Bandwidth to 20MHz under Wireless Interface->Physical Layer properties of the access point and wireless node.
Set DCF as the medium access layer protocol under Wireless Interface-> datalink layer properties of access point and wireless node
Set transmitter power as 40mW under Wireless Interface->Transmitter Power properties of the access point and wireless node.
Enable packet trace and plots.
Set generation rate as 100 Mbps under Application properties (Packet Size = 1460 Bytes, Interarrival time = 116 microseconds). Generation rate can be calculated by using the formula below:

$$Generation\ Rate\ (Mbps) = \ Packet\ Size\ (Bytes)*\frac{8}{Interarrival}time\ (µs)$$

= 1460 (Bytes)*8/116 (µs) \~ 100 Mbps

Run simulation for 10s and see Application Throughput in the Results Window.
Go back to the scenario and increase the Bandwidth 20 to 40, 80, 160 respectively and check the throughput in the results window.

Analytical Model

The average time to transmit a packet comprises of

DIFS
Backoff duration
Data packet transmission time
SIFS
MAC ACK transmission time

The timing diagram is as shown below Figure 4‑22.

Figure ‑: Timing diagram for WLAN

The Average throughput can be calculated by using the formula below:

$$Average\ Throughput\ (Mbps) = \ \frac{Application\ Payload(Bytes)}{Average\ Time\ per\ Packet(µs)}$$

Average time per packet (µs)= DIFS + Average Backoff time + Packet Transmission Time + SIFS + Ack Transmission Time

Packet Transmission Time (µs)= Preamble time + (MPDU Size/Data rate)

Average Backoff time (µs) = (CWmin/2) * Slot Time

Ack Transmission Time (µs)= Preamble time + (Ack Packet size/Ack data rate)

DIFS (µs)= SIFS + 2 * Slot Time

Average Backoff time (µs)= (CWmin/2) * Slot Time

Where,

Application payload = 1460 Bytes

Average time per packet = 34 + 67.5 + 185.36 + 16 + 212.88 = 513.74 µs

SIFS = 16 µs

Slot time = 9 µs

CWmin = 15 slots for 802.11ac

DIFS = SIFS + 2 * Slot Time = 16 µs + 2 * 9 µs = 34 µs

Average Backoff time = 67.5 µs

Packet Transmission Time = 44 µs + (1532 * 8/86.7 Mbps) = 185.36 µs

Preamble time = 44 µs for 802.11ac standard

MPDU Size = 1460 + 8 + 20 + 44 = 1532 Bytes

Ack Transmission Time = 44 µs + (152 Bytes * 8 / 7.2Mbps) = 212.88 µs

Average throughput = 1460 * 8/ (513.74) = 22.7 Mbps

Similarly calculate throughput theoretically for other samples by changing bandwidth and compare with Simulation throughput. Users can get the data rate by using the formula given below:

𝑃ℎ𝑦 𝑟𝑎𝑡𝑒 (802.11ac) = 𝑃ℎ𝑦_𝑙𝑎𝑦𝑒𝑟_𝑝𝑎𝑦𝑙𝑜𝑎𝑑 ∗ 8/(𝑝ℎ𝑦 𝑒𝑛𝑑 𝑡𝑖𝑚𝑒 − 𝑝ℎ𝑦 𝑎𝑟𝑟𝑖𝑣𝑎𝑙 𝑡𝑖𝑚𝑒 − 44)

Results and Discussion

Bandwidth (MHz)	Analytical Estimate of Throughput (Mbps)	Simulation Throughput (Mbps)
20	22.70	22.80
40	33.77	33.94
80	43.39	43.64
160	49.35	49.75

Table ‑: Result comparison of different bandwidth vs. Analytical Estimate of Throughput and Simulation Throughput

One can observe that there is an increase in throughput as we increase the bandwidth from 20MHz to 160MHz.

Effect of Guard Interval #

Open NetSim and click on Examples > Internetworks > Wi-Fi > Effect of Guard Interval in Wi-Fi 802.11ac then click on the tile in the middle panel to load the example as shown in Figure 4‑23.

Figure ‑: List of scenarios for the example of effect of guard interval in Wi-Fi 802.11ac

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file as shown Figure 4‑24.

Figure ‑: Network set up for studying the guard interval in wi-fi in Wi-Fi 802.11ac

Network Settings

Environment Grid length: 50m * 50m.
Click on the Application icon present in the top ribbon/toolbar and set Transport Protocol to UDP
Channel Characteristics: NO PATHLOSS in wireless link properties.
Set 802.11ac standard and Bandwidth to 20MHz under Wireless Interface->Physical Layer properties of the access point and wireless node.
Set DCF as the medium access layer protocol under Wireless Interface-> datalink layer properties of access point and wireless node.
Set Bit Error rate and Propagation delay to zero under wired link properties.
Set transmitter power as 40mW under Wireless Interface->Transmitter Power properties of the access point and wireless node.
Enable plots.
Set Guard interval to 400ns under Wireless Interface->Physical Layer properties of access point and wireless node.
Set generation rate as 100 Mbps under Application properties (Packet Size = 1460 Bytes, Interarrival time = 116 microseconds). Generation rate can be calculated by using the formula below:
$Generation\ Rate\ (Mbps) = \ Packet\ Size\ (Bytes)*\frac{8}{Interarrival}time\ (µs)$
= 1460 (Bytes)*8/116 (µs) \~ 100 Mbps
Run simulation for 10s and note down the throughput.
Go back to the scenario and increase the Guard interval to 400 to 800 and check the throughput in the results window

Calculate throughput theoretically as explained above and compare with Simulation throughput.

Results

Guard Interval (ns)	Theoretical Throughput (Mbps)	Simulation Throughput (Mbps)
400	17.76	22.80
800	16.87	21.38

400

17.76

22.80

800

16.87

21.38

Table ‑: Result comparison of different Guard Interval vs. Theoretical Throughput and Simulation Throughput

Peak UDP and TCP throughput 802.11ac and 802.11n #

Open NetSim, Select Examples ->Internetworks-> Wi-Fi -> Peak UDP and TCP throughput 802.11ac and 802.11n then click on the tile in the middle panel to load the example as shown Figure 4‑25.

Figure ‑: List of scenarios for the example of Peak UDP and TCP throughput 802.11ac and 802.11n

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file as shown Figure 4‑26.

Figure ‑: Network set up for studying the Peak UDP and TCP throughput 802.11ac and 802.11n

IEEE802.11n#

Network Settings

Set the following property as shown in below given Table 4‑8.

Interface Parameters
Physical Layer
Standard	IEEE802.11n
No. of Frames to aggregate	64
Standard Channel	36 (5180MHz)
Buffer Size	100MB
Guard Interval	400ns
Bandwidth	40 MHz
Frequency Band	5 GHz
Transmitter Power	100mW
Antenna Gain	0
Antenna height	1m
Reference distance (d0)	1m
Transmitting Antennas	4
Receiving Antennas	4
Datalink Layer
Rate Adaptation	False
Short Retry Limit	7
Long Retry Limit	4
Dott11_RTSThreshold	3000bytes
Medium Access Protocol	DCF

Table ‑: Detailed Network Parameters for IEEE802.11n

Set wired link properties as shown below.
Uplink speed and Downlink speed (Mbps)- 1000 Mbps.
Uplink BER and Downlink BER – 0.
Uplink and Downlink Propagation Delay(µs) – 10.
The Channel Characteristics were set as No pathloss in wireless link properties.
Set Downlink application source node as Wired Node destination node as Wireless Node.

Application Properties
App1_CBR
Packet Size (Byte)	1450
Inter Arrival Time (µs)	11.6
Transport Protocol	UDP

Table ‑: Application Parameters

Plots are enabled in NetSim GUI.
Run simulation for 5 sec. After simulation completes go to metrics window and note down throughput value from application metrics.

Go Back to 802.11n UDP Scenario and Change Transport protocol to TCP, Window scaling is set to True and Scale shift count set to 5 in the transport layer of Wired node and Wireless node for the other sample (i,e 802.11n TCP), run the simulation for 5 sec and note down throughput value from application metrics.

Results

Transport Protocol	Throughput (Mbps)
UDP	464.41
TCP	386.12

Table ‑: Results comparison of TCP and UDP throughputs for IEEE802.11n

Plot

Figure ‑: Plot of Throughput (Mbps) Vs. Transport Protocol for IEEE802.11n

IEEE802.11ac#

Network Settings

Set the following property as shown in below given table:

Interface Parameters
Standard	IEEE802.11ac
No. of Frames to aggregated	1024
Standard Channel	36 (5180MHz)
Rate Adaptation	False
Short Retry Limit	7
Long Retry Limit	4
Dott11_RTSThreshold	3000bytes
Medium Access Protocol	DCF
Buffer Size (Access Point)	100MB
Guard Interval	400ns
Bandwidth	160 MHz
Frequency Band	5 GHz
Transmitter Power	100mW
Antenna Gain	0
Antenna height	1m
Reference distance (d0)	1m
Transmitting Antennas	8
Receiving Antennas	8

Table ‑: Detailed Network Parameters for IEEE802.11ac

Set wired link properties as shown in below.
Uplink speed and Downlink speed (Mbps)- 10000 Mbps.
Uplink BER and Downlink BER – 0.
Uplink and Downlink Propagation Delay(µs) – 10.
The Channel Characteristics were set as No pathloss in wireless link properties.
Set Downlink application source node as Wired Node destination node as Wireless Node.

Application Properties
App1_CBR
Packet Size (Byte)	1450
Inter Arrival Time (µs)	1.93
Transport Protocol	UDP

Table ‑: Application Parameters

Plots are enabled in NetSim GUI.
Run simulation for 10 sec. After simulation completes go to metrics window and note down throughput value from application metrics.

Go Back to the 802.11ac UDP Scenario and Change Transport protocol to TCP, Window scaling is set to True and Scale shift count set to 5 in the transport layer of Wired node and Wireless node for the other sample (i,e 802.11ac TCP), run the simulation for 10 sec and note down throughput value from application metrics.

Results

Transport Protocol	Throughput (Mbps)
UDP	5361.42
TCP	3207.06

Table ‑: Results comparison of TCP and UDP throughputs for IEEE802.11ac

Plot

Figure ‑: Plot of Throughput (Mbps) Vs. Transport Protocol for IEEE802.11ac

TCP Window Scaling #

Open NetSim, Select Examples->Internetworks->TCP Window Scaling then click on the tile in the middle panel to load the example as shown in Figure 4‑29.

Figure ‑: List of scenarios for the example of TCP Window Scaling

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for TCP Window scaling as shown Figure 4‑30.

$C:\Users\TETCOS_PC\Desktop\Capture.PNG$

Figure ‑: Network set up for studying the TCP Window Scaling

The TCP throughput of a link is limited by two windows: the congestion window and the receive window. The congestion window tries not to exceed the capacity of the network (congestion control); the receive window tries not to exceed the capacity of the receiver to process data (flow control).

The TCP window scale option is an option to increase the receive window size allowed in Transmission Control Protocol above its former maximum value of 65,535 bytes.

TCP window scale option is needed for efficient transfer of data when the bandwidth-delay product is greater than 64K. For instance, if a transmission line of 1.5 Mbit/second was used over a satellite link with a 513 milliseconds round trip time (RTT), the bandwidth-delay product is 1500000 × 0.513 = 769, 500 bits or about 96,187 bytes.

Using a maximum window size of 64 KB only allows the buffer to be filled to $\frac{65535}{96187} = 68\ \%$ of the theoretical maximum speed of 1.5 Mbps, or 1.02 Mbps.

By using the window scale option, the receive window size may be increased up to a maximum value of 1,073,725,440 bytes. This is done by specifying a one-byte shift count in the header options field. The true receive window size is left shifted by the value in shift count. A maximum value of 14 may be used for the shift count value. This would allow a single TCP connection to transfer data over the example satellite link at 1.5 Mbit/second utilizing all of the available bandwidth.

Network Settings

Wired_Node_1 in Transport Layer TCP Window Scaling à FALSE (by default) and Congestion plot set as TRUE.
Application Generation rate à 10Mbps (Set Inter arrival time = 1168)
Bit error rate (Uplink and Downlink) à 0 in all wired links
Enabled Wireshark Capture in General Properties Wired Node 1 à Set as Offline
Link1 & Link3 Propagation delay (uplink and downlink) à5(Microsec) (by default)
Change the Link2 speed à 10Mbps, Propagation delay (uplink and downlink) ->100000 (Microsec)
Simulate for 100sec and note down the throughput
Now change the Window Scaling à TRUE (for all wired nodes)
Simulate for 100s and note down the throughput.

Results and Discussion

Window Scaling	Application Throughput (Mbps)
FALSE	2.5
TRUE	8.7

Table ‑: Results comparison for with/without Window Scaling

Throughput calculation (Without Window Scaling)

Theoretical Throughput = Window size / Round trip time = $\frac{65525*8\ Bytes}{200ms}\ $ = 2.62 Mbps

Go to the simulation result window -> plots -> TCP Congestion Plot Figure 4‑32/Figure 4‑33.

Figure ‑: Result window

Figure ‑: TCP Congestion Plot for wired node_1

In Window Scaling False, the Application_Throughput is 2.5 Mbps less than the theoretical throughput since it initially takes some time for the window to reach 65535 B.

Figure ‑: TCP Congestion Plot for wired node_2

In Window Scaling TRUE, From the above screenshot, users can notice that the window size grows up to 560192Bytes because of Window Scaling. This leads to a higher Application_Throughput compared to the case without window scaling.

We have enabled Wireshark Capture in the Wired Node 1. The PCAP file is generated silently at the end of the simulation. Double click on WIRED NODE1_1.pcap file available in the result window under packet captures, In Wireshark, the window scaling graph can be obtained as follows. Select any data packet with a left click, then, go to Statistics > TCP Stream Graphs > Window Scaling > Select Switch Direction.

Figure ‑: Wireshark Window when Window Scaling is TRUE

IP Addressing in NetSim#

When you create a network using the GUI, NetSim will automatically configure the IP address to the devices in the scenario. Consider the following scenarios:

If you create a network with two wired nodes and L2_Switch, the IP addresses are assigned as 11.1.1.1 and 11.1.1.2 for the two wired nodes. The default subnet mask is assigned to be 255.255.0.0. It can be edited to 255.0.0.0 (Class A) or 255.255.255.0 (Class C) subnet masks. Both the nodes are in the same network (11.1.0.0).

Similarly, if you create a network with a router and two wired nodes, the IP addresses are assigned as 11.1.1.2 and 11.2.1.2 for the two wired nodes. The subnet mask is default as in above case, i.e., 255.255.0.0. The IP address of the router is 11.1.1.1 and 11.2.1.1 respectively for the two interfaces. Both the nodes are in different networks (11.1.0.0 and 11.2.0.0) in this case.

The same logic is extended as the number of devices is increased.

Configuring Static Routing in NetSim #

Static Routing

Routers forward packets using either route information from route table entries that configured manually or the route information that is calculated using dynamic routing algorithms. Static routes, which define explicit paths between two routers, cannot be automatically updated; you must manually reconfigure static routes when network changes occur. Static routes use less bandwidth than dynamic routes. No CPU cycles are used to calculate and analyze routing updates.

Static routes are used in environments where network traffic is predictable and where the network design is simple. You should not use static routes in large, constantly changing networks because static routes cannot react to network changes. Most networks use dynamic routes to communicate between routers but might have one or two static routes configured for special cases. Static routes are also useful for specifying a gateway of last resort (a default router to which all unrouteable packets are sent).

Note that the static route configuration running with TCP protocol requires reverse route configuration.

How to Setup Static Routes

In NetSim, static routes can be configured either prior to the simulation or during the simulation.

Static route configuration prior to simulation:

Via static route GUI configuration
Via file input (Interactive-Simulation/SDN)

Static route configuration during the simulation:

Via device NetSim Console (Interactive-Simulation/ SDN)

Static route configuration via GUI

Open NetSim, Select Examples->Internetworks->Configuring Static Route then click on the tile in the middle panel to load the example as shown in Figure 4‑35.

Figure ‑: List of scenarios for the example of Configuring Static Route

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for Configuring Static Routing in NetSim as shown Figure 4‑36.

Without Static Route#

Figure ‑: Network set up for studying the Configuring Static Route

Network Settings

Environment Grid length: 500m * 500m.

Create a Scenario as shown in above screenshot.
Generate CBR Traffic Between Wired node 6 and Wired node 7 and set the transport layer protocol as UDP.
The default routing protocol is OSPF in application layer of Routers.
Wired link Properties are default.
Enable packet trace and plots.
Run simulation for 10 seconds.
Observe in Animation Window packet flows from Wired Node 6 -> Router 1-> Router 5-> Router 4-> Wired Node 7 as shown in below Figure 4‑37.

Figure ‑: Animation Window packet flows from Wired Node 6àRouter 1àRouter 5àRouter 4 à Wired Node 7

With Static Route#

Static routing configuration

Open Router 1 properties->Network_Layer. Enable - Static IP Route ->Click on Configure Static Route IP and set the properties as per the screenshot below and click on Add and then click on OK.

Figure ‑: Static IP Routing Dialogue window

This creates a text file for every router in the temp path of NetSim which is in the format below:

Router 1:

route ADD 11.7.0.0 MASK 255.255.0.0 11.1.1.2 METRIC 1 IF 1

route ADD destination_ip MASK subnet_mask gateway_ip METRIC metric_value IF Interface_Id

where

route ADD: command to add the static route.

destination_ip: is the Network address for the destination network.

MASK: is the Subnet mask for the destination network.

gateway_ip: is the IP address of the next-hop router/node.

METRIC: is the value used to choose between two routes.

IF: is the Interface to which the gateway_ip is connected. The default value is 1.

Similarly Configure Static Route for all the routers as given in below Table 4‑15.

Devices	Network Destination	Gateway	Subnet Mask	Metrics	Interface ID
Router 1	11.7.0.0	11.1.1.2	255.255.0.0	1	1
Router 2	11.7.0.0	11.2.1.2	255.255.0.0	1	2
Router 3	11.7.0.0	11.3.1.2	255.255.0.0	1	2
Router 4	11.7.0.0	11.7.1.2	255.255.0.0	1	3

Table ‑: Static Route configuration for routers

After configuring the router properties.
Run the simulation for 10 seconds and check packet animation window.
Observe in Animation Window packet flows from Wired Node 6 -> Router 1-> Router 2-> Router 3-> Router 4-> Wired Node 7 as shown in Figure 4‑39.

Figure ‑: Observe in Animation Window packet flows from Wired Node 6àRouter 1àRouter 2àRouter 3àRouter 4àWired Node 7

Disabling Static Routing

If static routes were configured via GUI, it can be manually removed > prior to the simulation from the Static IP Routing Dialogue or > from the file input.
If static routes were configured during the run time, the entries > can be deleted using route delete command during runtime.

Configuring IP addresses, subnets and applying firewall rules based on subnets using Class B IP addresses #

Introduction#

IP Addressing#

A unique number ID is assigned to one of the hosts or interfaces in a network. An IP address is an address used to uniquely identify a device on an IP network. An IPv4 address is made up of 32 binary bits, which can be divided into a network portion and a host portion with the help of a subnet mask. These 32 binary bits are further broken into four octets (1 octet = 8 bits). Each octet is converted to decimal and separated by a period (dot). For this reason, an IP address is said to be expressed in dotted decimal format (for example, 172.16.0.0). The value in each octet ranges from 0 to 255 in decimal, or 00000000 - 11111111 in binary.

Figure ‑: Subnet mask diagram

IP address classes#

Class	Address range	Subnet masking	Leading Bits	Max number of Networks	Max number of Hosts	Application
IP CLASS A	1 to 126	255.0.0.0	8	128	16,777,214	Used for a large number of hosts.
IP CLASS B	128 to 191	255.255.0.0	16	16384	65,534	Used for medium-size networks.
IP CLASS C	192 to 223	255.255.255.0	24	2097157	254	Used for local area network.
IP CLASS D	224 to 239	N/A	N/A	N/A	N/A	Reserve for multi-tasking.
IP CLASS E	240 to 254	N/A	N/A	N/A	N/A	This class is reserved for R&D

Table ‑: IP address class and its application

Configuring Class-B address in NetSim#

The default IP addressing in NetSim is class A addressing. However, users can reconfigure (static) IP addresses with different classes. These settings are available in the network layer of end nodes, routers, and L3 switches.

Example 1: In this example, we have created a simple LAN network and modified the IP address of the routers and the users in the LAN network. Refer Figure 4‑40. In this we have used the IP address of range 172.16.0.1-172.16.255.254 with a mask 255.255.0.0. When its put differently, the IP is 172.16.0.0/16.

Figure ‑: IPv4 Class B IP addressing

Subnetting#

Subnetting is the practice of dividing a network into two or more smaller networks. It increases the routing efficiency, enhances the security of the network, and reduces the size of the broadcast domain.

A subnet mask is used to divide an IP address into two parts. One part identifies the host (computer), and the other part identifies the network to which it belongs. For better understanding of how an IP address and subnet masks work, look at an IP address and see how it's organized.

Subnet	Host	Slash Method
1	65536	/16
2	32768	/17
4	16384	/18
8	8192	/19
16	4096	/20
32	2048	/21
64	1024	/22
128	512	/23
256	256	/24
512	128	/25
1024	64	/26
2048	32	/27
4096	16	/28
8192	8	/29
16384	4	/30
32768	2	/31
65536	1	/32

Table ‑: Class-B Subnetting using the slash method

Network ID	Subnet Mask	Host ID Range	Usable Host	Broadcast ID
172.16.0.0	/18	172.16.0.1-172.16.63.254	16382	172.16.63.255
172.16.64.0	/18	172.16.64.1-172.16.127.254	16382	172.16.127.255
172.16.128.0	/18	172.16.128.1-172.16.192.254	16382	172.16.192.255
172.16.192.0	/18	172.16.192.1-172.16.255.254	16382	172.16.255.255

Table ‑: Using subnet mask 255.255.192.0i.e., /18 creating 4 different subnets with 16382 usable hosts

Configuring Class-B subnetting#

We provide two examples to explain Class B sets. The example shows how to create 4 Subnets with 16382 Hosts using: (i) A single switch and (ii) Multiple switches

Subnets using single switch: Note that IP address and subnet masks are configured. The application (traffic) flow is configured for intra-subnet communications.

Figure 4‑42: Pair of users communicating with each other belong to separate subnet per Table 4‑18.

Configuring IP addresses and subnets in NetSim is as simple as configuring it in MS Operating System. The devices in NetSim are configurable via GUI, to set the IP and subnet, users need to modify the Network Layer as shown below.

Figure ‑: Configuring IP address and subnet mask in network layer of device in NetSim

Subnets using multiple switches: Here subnets have been configured using multiple switches. In the given example as shown in Figure 4‑44, we have considered 4 departments in a university campus, by configuring subnets for CS, EC, MECH, and EE. Application (traffic flow) is set for both intra and inter-subnet communication.

Department Name	IP Address Range
Computer Science (CS)	172.16.0.1-172.16.63.254
Electronics and Communication (EC)	172.16.64.1-172.16.127.254
Mechanical Engineering (ME)	172.16.128.1-172.16.192.254
Electrical Engineering (EE)	172.16.192.1-172.16.255.254

Table ‑: subnets in a university based on Table 4‑18

Figure ‑: All the users are communicating from different subnets using a router and switch by configuring.Class-B subnetting has been configured

Firewall rules based on subnets#

An important benefit of subnetting is security. Firewall/ACL rules can be configured at a subnet level. NetSim provides options for users to configure ACL/firewall rules i.e., to PERMIT or DENY traffic at a router based on (i) IP address/Network address (ii) Protocol (iii) Inbound / Outbound traffic.

Example 4: In this example, we have explained how users can set firewall rules to DENY traffic at a subnet level.

The topology considered here is the university network as shown in Figure 4‑44.
The firewall/ACL rules are set in the Organization Router
ACL Rules:
For the CS-department Video traffic is denied
For the EC-department TCP traffic is denied
For the Mechanical department, Video Traffic is denied
For the EE department TCP traffic is denied
These rules can be set in NetSim UI just by filling an ACL application of the router as shown below in Figure 4‑45.

Figure ‑: Setting firewall rules in the organization router

Different OSPF Control Packets #

There are five distinct OSPF packet types.

Type	Description
1	Hello
2	Database Description
3	Link State Request
4	Link state Update
5	Link State Acknowledgement

Table ‑: Different OSPF Control Packets

The Hello packets

Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers. All routers connected to a common network must agree on certain parameters (Network mask, Hello Interval and Router Dead Interval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships.

The Database Description packet

Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose, a poll-response procedure is used. One of the routers is designated to be the master, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets DD sequence numbers.

The Link State Request packet

Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor’s database that are more up to date. Multiple Link State Request packets may need to be used. A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself. The router may receive even more recent instances in response.

The Link State Update packet

Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet. Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor.

The Link State Acknowledgment packet

Link State Acknowledgment Packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple LSAs can be acknowledged in a single Link State Acknowledgment packet.

Open NetSim, Select Examples->Internetworks->Different OSPF Control Packets then click on the tile in the middle panel to load the example as shown in Figure 4‑46.

Figure ‑: List of scenarios for the example of different ospf control packets

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for Different-OSPF-Control-Packets in NetSim as shown Figure 4‑47.

Figure ‑: Network set up for studying the different ospf control packets

Network Settings

Set OSPF Routing protocol under Application_Layer properties of a router.

Configured CBR application with default properties and set application Start Time(s) to 30Sec.
Enabled Packet Trace and Plot.
Simulate for 100 sec.

Results and Discussion

Open Packet animation window and click on play button. Users can observe all the OSPF packets. OSPF neighbors are dynamically discovered by sending Hello packets out each OSPF-enabled interface on a router. Then Database description packets are exchanged when an adjacency is being initialized. They describe the contents of the topological database. After exchanging Database Description packets with a neighboring router, a router may find that parts of its topological database are out of date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up to date. The sending of Link State Request packets is the last step in bringing up an adjacency. A packet that contains fully detailed LSAs, typically sent in response to an LSR message. LSAck is sent to confirm receipt of an LSU message.

Figure ‑: different ospf control packets in the animation window

The same can be observed in Packet trace by filtering CONTROL_PACKET_TYPE/ APP_NAME to OSPF_HELLO, OSPF_DD, OSPF_LSACK, OSPF_LSUPDATE and OSPF_LSREQ packets as shown below Figure 4‑49.

Figure ‑: different ospf control packets in the packet Trace

An enterprise network comprising of different subnets and running various applications #

Create a simple enterprise network, comprising of, two branches, head-quarters and a data center. Branches and headquarters are connected to the data center over the public cloud. In NetSim, users can model the network, by just adding the network elements, through click and drop, and renaming them suitably as shown below Figure 4‑51.

Open NetSim, Select Examples->Internetworks->Enterprise Network then click on the tile in the middle panel to load the example as shown in Figure 4‑50.

Figure ‑: List of scenarios for the example of enterprise networks

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for Enterprise Network in NetSim as shown in Figure 4‑51.

Figure ‑: Network set up for studying the enterprise network

Network Settings for Enterprise Network I

We have changed the link rate for the outbound link i.e. Link 28 from Branch 1 as 2Mbps.
Configured one FTP application from 14 to the file server 39 (File Size (Bytes) to 80000 and Inter_Arrival_Time (Sec) to 1), a Database application from 15 to the Database server 41, and eight email applications running between 16, 17, 18, 26, 27, 28, 29, 30 and the Email server 40.
Enabled Plots and Simulated for 100s.

Enterprise Network II

In this sample, we have added more nodes via the switch and configured 3 FTP applications from systems 43, 45, 46 to FTP server 39 (File Size (Bytes) to 80000 and Inter_Arrival_Time (Sec) to 1), as shown in Figure 4‑52.

Figure ‑: Configuring FTP applications from systems 43,45,46 to FTP server 39

Simulated for 100 seconds.

Enterprise Network III

In this sample, we have changed the outbound link speed i.e. Link 28 to 4Mbps and simulated for 100 seconds.

Enterprise Network IV

In this sample, we have changed the outbound link speed i.e., Link 28 to 2Mbps and configured Voice applications from 14, 15, 46, 45 and 43 to Head office 10 as shown in Figure 4‑53.

Figure ‑: Configuring voice applications from 14, 15, 43, 45, 46 to HO 10

Also changed Scheduling type to Priority under Network Layer Properties of Router33 Interface_WAN properties as shown below Figure 4‑54.

Figure ‑: WAN Interface – Network layer properties window

Simulated for 100 seconds.

Enterprise Network V

In this sample, we have changed the start time for Voice and FTP applications to 40 seconds, email application to 30 seconds and database application to 40 seconds.
Enabled Plots and simulated for 100 seconds.

Results and Discussion

Enterprise Network I Open metrics window and calculate the average delay for e-mail application present under Application properties shown below in Figure 4‑55.

Figure ‑: Application metrics table for Enterprise Network I

The average delay experienced by the e-mail applications is 1.90 s

Enterprise Network II: In this Sample, the average delay for email applications has increased to 11.64 s due to the impact of additional load on the network.

Enterprise Network III: In this Sample, the average delay for e-mail applications has dropped down to 0.89 s due to the increased link speed.

Enterprise Network IV: In this Sample, the average delay for the e-mail application has increased to 6.33 s since voice has a higher priority over data, and the routers will first serve the voice packets in its queue and only then route the data packets.

Enterprise Network V: In this Sample, users can notice that email application sees good throughput initially after which it is flat. On the other hand, the voice application throughput is NIL till 31 seconds, since it has no traffic, and starts picking up 31 seconds onwards.

Figure ‑: EMAIL Throughput Plot for Application 8

Figure ‑: VOICE Throughput Plot for Application 14

Internetworks Experiments in NetSim#

Apart from examples, in-built experiments are also available in NetSim. Examples help the user understand the working of features in NetSim. Experiments are designed to help the user (usually students) learn networking concepts through simulation. The experiments contain objective, theory, set-up, results, and inference. The following experiments are available in the Experiments manual (pdf file).

Understand Measures of Network Performance: Throughput and Delay

Throughput and Bottleneck Server Analysis
Delay and Little’s Law
Understand working of ARP, and IP Forwarding within a LAN and across a router
Simulate and study the spanning tree protocol.
Introduction to TCP connection management
Reliable data transfer with TCP
Mathematical Modelling of TCP Throughput Performance
Study how throughput and error of a Wireless LAN network changes as the distance between the Access Point and the wireless nodes is varied.
WiFi: UDP Download Throughput
How many downloads can a Wi-Fi access point simultaneously handle?
TCP Congestion Control Algorithms
Multi-AP Wi-Fi Networks: Channel Allocation
Study the working and routing table formation of Interior routing protocols, i.e. Routing Information Protocol (RIP) and Open Shortest Path First (OSPF)
M/D/1 and M/G/1 Queues
Wi-Fi Multimedia Extension (IEEE 802.11 EDCA)
Understand the working of OSPF.
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.
Understand the working of TCP BIC Congestion control algorithm, simulate and plot the TCP congestion window.
Simulating Link Failure

Reference Documents#

IEEE 802.3 standard for Ethernet
IEEE 802.11 standards for Wireless LAN
RFCs 777, 760, 792 for Internet Control Message Protocol
IENs 108, 128 for Internet Control Message Protocol
RFC 2328 for Open Shortest Path First (OSPF)

Latest FAQs#

Up to date FAQs on NetSim’s Internetworks library is available at

https://tetcos.freshdesk.com/support/solutions/folders/14000108665

https://tetcos.freshdesk.com/support/solutions/folders/14000113123

https://tetcos.freshdesk.com/support/solutions/folders/14000119396

In other words, the instantaneous PER is used in a Bernoulli trial to decide whether the current packet is successfully received or not ↩

Key	Action
`?`	Open this help dialog
`s`	Search the Documentation
`e`	Edit current page on GitHub