• Outputs Results Plots and Data Files
Outputs Results Plots and Data Files

Result Window and Plots Windows#

The results of a simulation run are presented in a unified dashboard for convenient analysis. Graphics plots comprises of application throughputs, link throughputs, buffer occupancy and TCP congestion windows. The tabular presentation includes end-to-end delays, jitter, errors, packets generated / received / collided, route tables, TCP Acks, retransmissions etc.

Results are organized per interface, per device, per application and per link. In addition, summary metrics are aggregated and presented system-wide (network-level). Information in the trace files contain individual packet flow and individual event execution. Protocol log files records a myriad of information pertaining to protocol operation necessary for in-depth analysis and debugging.

The results can be exported as a .csv file and opened in a spread sheet software like Excel. Results can also be exported in .html format and opened in a browser.

Figure 8‑1: Result Window

If plots are enabled, NetSim plots Instantaneous (50 ms averaging window) Throughput, Cumulative moving average Throughput and Time Average throughput for each link and each application.

Figure 8‑2: Link Throughput plot

Guidance on Zooming, Panning, and obtaining the XY co-ordinate values are provided on the bottom left of the window. The 're-plot' option can be used to change the X-value, Min and Max, and to change the averaging window for plotting the instantaneous throughput.

Since NetSim is a packet level simulator, at an instant in time a destination (of a link or application) can either be (i) receiving packets or (ii) not receiving packets. Therefore, the throughput at a point in time is either $\theta_{\max}$ (the link speed) or $0$. It is thus not meaningful to define the instantaneous throughput for a link or application at an instant in time. Hence, NetSim measures instantaneous throughput over an averaging window as explained below.

Instantaneous Throughput is defined as the bits successfully received in the averaging window divided by the averaging window size (in time units). It is measured every averaging window.

$$\theta_{Inst}\ (bits/s) = \frac{B_{Window}^{RxSuccess}\ (bits)}{W_{size}\ (s)}$$

Each value of the computed instantaneous throughput represents one point in the throughput plot. The computation and plotting are done every $W\ $seconds of virtual simulation time.

When source-data button is clicked, a plotdata.csv file is written by NetSim. This contains the X (Time) and Y (Throughput) coordinates of the points in the plot. NetSim does not save this file. Also, note that the file name does not change with each plot; it remains the same for all plots. It is recommended that a user chooses the save-as option in the spread sheet software (for e.g.: MS Excel) and suitably saves the plot data source file. This file is for users who require the X and Y co-ordinates of the points in the plot for further analysis.

Advanced users should look at the source file from which the plots were generated by NetSim. The filename would be Plot_\<APP_NAME\_Throughput.txt, where APP_NAME is user configurable, and the file would be written in the %temp%/NetSim/\<NetSim-ver\ directory. In that file the 1^st^ column is the Timestamp, and the 2^nd^ column is the Bytes received. NetSim computes and plots the instantaneous throughput from this. For example, if the averaging window were 25ms, and if the source data entries were per the table below

Time (ms) Bytes
1 5
20 15
40 5
60 10
74 5

then the Instantaneous Throughputs, $\theta$ (in Kbps since we have milli seconds in the denominator) would be

  • First 25ms (1 to 25) $\theta = \frac{(5\ + \ 15) \times 8}{25}\ \ = \frac{160}{25} = 6.4\ Kbps$

  • Next 25ms (26 to 50$)\ \theta = \frac{5 \times 8}{25}\ = \frac{40}{25} = 1.6\ Kbps$

  • Next 25ms (51 to 75) $\theta = \frac{(10\ + \ 5) \times 8}{25} = \frac{120}{25} = 4.8\ Kbps$

The link throughput statistic counts all traffic that was sent through a link. It includes data packets and control packets and includes retransmissions, errors, or collisions. This would also include packet flows from multiple applications that may flow through the same link. Timestamp for link throughput is the PHY layer end time of each packet passing through that link.

The application throughput only considers those data packets (application layer packet size) that were sent from the source and that were successfully received at the destination

Buffer Occupancy Plot#

The buffer occupancy over time can be plotted by setting Buffer Occupancy Plot Enabled to True. This parameter is available wherever there are buffers in NetSim such as in Router -- WAN Port -- Network Layer as shown Figure 8‑3.

Figure 8‑3: Buffer Occupancy Plot set to True in WAN Port -- Network Layer

Upon simulation the buffer occupancy plot can be opened from the Results Window and would look as shown below in Figure 8‑4.

Figure 8‑4: Buffer occupancy plot

TCP Congestion Window Plot#

The TCP Congestion window over time can be plotted by setting Congestion Window Plot Enabled to True. This parameter is available in the end nodes where TCP has been enabled, for example Wired Node -- Transport Layer.

Figure 8‑5: TCP Congestion Plot Enabled set to True in Transport Layer

Upon simulation the TCP congestion window plot can be opened from the Results Window and would look like what is shown below in Figure 8‑6.

Figure 8‑6: TCP Congestion window plot

The down sampling algorithm in NetSim's plot engine leads to approximations while plotting, especially in TCP. To obtain a very precise TCP congestion plot window please enable Wireshark interfacing and view the TCP congestion window in Wireshark.

Notes on plots#

  1. To accelerate plotting, NetSim uses down-sampling/decimation to choose n points from N for plotting. NetSim generates n random numbers from a discrete uniform $\ U\ (\ 0,\ \ N - 1)$ distribution and plots for these n points.

  2. To get a more precise plot users can select the min and max values (time) and replot.

  3. The link throughput is calculated as the sum of throughputs in both directions for a full duplex link.

  4. Application throughput is plotted till the last packet reaches or till end of simulation time, whichever is earlier.

  5. Cumulative Moving Average: This is the average of the metric up until the current time and is defined as

$$\overline{\theta}(t) = \frac{1}{t}\int_{0}^{t}{r(u)du}\ $$

Here users can view the values of the metrics obtained based on the overall network and also displays the values of the metrics pertaining to each link.

  • Link ID: It is the unique Id for the link.

  • Link Throughput Graph: Plots throughput vs. Simulation time

Formula:

$$Link\ Throughput\ (Mbps) = \frac{Total\ bytes\ transmitted\ over\ the\ link\ (Bytes)\ \times \ 8}{Simulation\ Time\ (\mu s)}$$

The link throughput considers the entire traffic that was sent through a link. It includes data packets and control packets and includes retransmissions, errors, or collisions. This would also include packet flows from multiple applications that may flow through the same link. The calculation is based on the packet size (bytes) at the PHY layer, which would include app layer payload plus the overheads of all layers.

  • Packets Transmitted: It is the total number of packets transmitted in the link. Along with data packets, it includes protocol control packets like ARP Request, ARP Reply, TCP_ACK, TCP_SYN, RTS, CTS, WLAN_ACK, OSPF_ HELLO, RIP packets etc. Note that this is a link (PHY layer) level measure, and it is not a MAC layer measure. Therefore, the packets transmitted can be greater than the packets generated when running wireless protocols due to re-tries.

  • Packets Errored: Total number of packets error in the link inclusive of data and control packets. 

  • Packets Collided: Total number of packets collided in the link including data and control packets. Note: (i) If two packets collide then this counter is incremented by two (once for each packet). (ii) If a single packet collides N times, then this counter is incremented N times

  • Bytes Transmitted: It is the total number of bytes transmitted in the link. It is equal to the sum of the 'Payload Transmitted' and 'Overhead Transmitted' transmitted in the link.

  • Payload Transmitted: It is the total payload transmitted in the link. 

  • Overhead Transmitted: It is the total overhead transmitted in the link. It includes the layer wise overheads and all control packets in the link.

Queue Metrics#

Displays the values of the queue metrics for the devices containing buffer queue like routers, access points etc. 

  • Device Id - Unique id number of the device.

  • Port Id - Unique id number of the port of the device. This is also called as interface id.

  • Queued Packet - Number of packets queued at a particular port of a device.

  • Dequeued Packet - Number of packets removed from the queue at a particular port of device.

  • Dropped Packet - Number of packets dropped at a particular port of a device.

Protocol Metrics#

The Performance metrics tables of protocols such as TCP, UDP, IP, IEEE802.11, LTE, AODV and DSR are provided in the respective technology library documentation.

Device Metrics#

Displays device related metrics like ARP table, IP forwarding tables. This is also dependent upon the type of network/technology simulated.

IP_Forwarding Table

  • Network Destination - It represents the Network address of the destination.

  • Netmask/Prefix length - A 32-bit combination used to describe which portion of an address refers to the subnet and which part refers to the host.

  • Gateway - It is the IP address of the next-hop router.

  • Interface - It represents a network connection.

  • Metrics - It is the value used to choose between two routes.

  • Type - It represents the type of the network i.e. local/Multicast/Broadcast

Switch MAC Address Table: These metrics will be displayed when we run networks having Switches.

  • MAC Address - It represents the MAC address of the switch interfaces.

  • Type - It is the type of the switch.

  • Outport - It is the output port of the switch.

Cellular Metrics#

Displayed if GSM or CDMA is running in the network.

GSM/CDMA Metrics. MS Metrics

  • MS Id - It is the id of the Mobile station.

  • Call Generated - It is the number of calls generated by a Mobile Station.

  • Call Blocked - It is the number of calls blocked by a Base station when no channel available.

  • Call Blocking probability - It is the probability of calls blocked by a base station.

  • Channel request sent - It is the number of channel requests sent by a mobile station.

  • Call request sent - It is the number of call requests sent by a mobile station (at source)

  • Call request received - It is the number of call requests received by a mobile station (at destination)

  • Call accepted - It represents the number of calls accepted by a mobile station.

  • Call rejected - It represents the number of calls rejected by a mobile station.

  • Handover request - It is the number of handover requests sent by a mobile station. Handover refers to the process of transferring an ongoing call or data session from one channel connected to the core network to another channel.

  • Call dropped - It represents the number of calls dropped by a BS.

  • Call dropping probability - It represents the probability of number of calls dropped by a BS.

Channel metrics#

  • BS Id - It is the Id of a Base Station.

  • Channel Id - It represents the channel number.

  • Uplink frequency - It is the uplink frequency of the GSM network to send data from mobile station to base station.

  • Downlink frequency - It is the downlink frequency of the GSM network to send data from base station to mobile station.

  • Time slot - It represents the time slot. In GSM network, Frequency band is divided into 200kHz carriers and then each carrier is divided into 8 time slots (0-7).

Sensor Metrics (IEEE802.15.4_Metrics)#

Displayed if WSN/IOT is running in the network.

  • Device Id - It represents the Id's of the sensor and LoWPAN Gateway.

  • Packet Transmitted - It is the number of packets (either data/routing/ZigBee) transmitted by Sensor and LoWPAN gateway

  • Packet Received - It is the number of packets (either data/routing/ZigBee) received by Sensor and LoWPAN gateway

  • Ack Transmitted - It is the number of acknowledgements transmitted by a particular device.

  • Ack Received - It is the number of acknowledgements received by a particular device.

  • CCA Attempt - It represents the number of Clear channel Assessment attempts at sensors and LoWPAN Gateway used to determine whether the medium is idle or not.

  • Successful CCA Attempt - It represents the number of successful CCA attempts at sensors and LoWPAN Gateway.

  • Failed CCA - It represents the number of failed CCA attempts at sensors.

  • Total Backoff Time - It is the total backoff time obtained. It is the time that sensors have to wait before attempting to access the channel.

  • Average Backoff time - It is the average backoff time.

  • Beacon Transmitted - It the total number of beacons transmitted by a LoWPAN Gateway. It transmits network beacons in a beacon enabled mode. If beacon mode is enabled, it follows slotted CSMA/CA algorithm

  • Beacon Received - It is the total number of beacons received by the sensors.

  • Beacon Forwarded - It is the total number of beacons forwarded by the sensors.

  • Beacon Time - It is the total time calculated for beacon transmission at LoWPAN Gateway.

  • CAP Time - It is the total Contention Access Period obtained during simulation. During this time, sensors compete for channel.

  • CFP Time - It is the total Contention free period obtained. In CFP, nodes request for guaranteed time slots. If GTS is allocated, nodes can transmit without contention.

Battery Model#

  • Device Name - It represents the Name and Id of the Sensor

  • Initial Energy - It represents the initial energy of the sensors.

  • Consumed Energy - This is the total energy consumed by the respective sensor.

  • Remaining Energy - This is the remaining energy of the sensor at the end of the simulation.

  • Transmission Energy - It is the energy consumed by the respective sensor for transmitting data.

$TransmissionEnergy\ (mJ) = TransmitCurrent\ (mA) \times Voltage\ (V) \times AmountOfTimeRadioIsInTransmitState(s)$.

  • Receiving Energy - It is the energy consumed by the respective sensor while receiving data.

$ReceivingEnergy\ (mJ) = ReceiveCurrent\ (mA) \times Voltage\ (V) \times AmountOfTimeRadioIsInReceiveState(s)$.

  • Idle Energy - When the sensor is active and ready but not currently receiving or transmitting data packets, it is said to be in an idle state. This metrics calculates the energy consumed by the sensor in idle state.

$IdleEnergy\ (mJ) = IdleCurrent\ (mA) \times Voltage\ (V) \times AmountOfTimeRadioIsInIdleState(s)$.

  • Sleep Energy - This is the energy consumed when the respective sensor is in an inactive mode.

$SleepEnergy\ (mJ) = SleepCurrent\ (mA) \times Voltage\ (V) \times AmountOfTimeRadioIsInSleepState(s)$.

CR metrics#

Displayed if 802.22 cognitive radio is running in the network.

Base station Metrics#

  • BS Id - It is the id of a Base Station.

  • Interface Id - It is the Interface Id of a BS

  • SCH sent - SCH. It is the number of Superframe Control Headers sent by a BS. SCH carries Base Station's MAC address along with the schedule of quiet periods for sensing, as well as other information about the cell.

  • FCH sent - It represents the number of Frame Control Headers sent by a BS. It is transmitted as a part of Down Stream (DS) Protocol Data Unit in DS subframe specifies length of either DS-Map if transmitted or US-Map. It is sent in the first two subchannels of the symbol immediately following the preamble symbol.

  • DSA req received - It is the number of Dynamic Service Addition requests received by a BS used to create a new service flow.

  • DSA rep sent - It is the number of DSA replies sent by a BS.

  • DSC req received - It is the number of Dynamic Service Change requests received by a BS to dynamically change the parameters of an existing service flow.

  • DSC rep sent - It is the number of DSC replies sent by a BS.

  • DSD req received - It is the number of Dynamic Service Deletion requests received by a BS to delete an existing service flow.

  • DSD rep sent - It is the number of DSD replies sent by a BS.

  • CHS req sent - It is the number of Channel Switch Requests sent by a BS.

CPE metrics#

  • CPE Id - It represents the Id of Customer Premise Equipment

  • Interface Id - It represents the Interface Id of the CPE

  • SCH received - It is the number of Superframe Control Headers received by a CPE.

  • FCH received - It represents the number of Frame Control Headers received by a CPE.

  • DSA req sent - It is the number of Dynamic Service Addition requests sent by a CPE.

  • DSA rep received - It is the number of DSA replies received by a CPE.

  • DSC req sent - It is the number of Dynamic Service Change requests sent by a CPE.

  • DSC rep received - It is the number of DSC replies received by a CPE.

  • DSD req sent - It is the number of Dynamic Service Deletion requests sent by a CPE.

  • DSD rep received - It is the number of DSD replies received by a CPE.

  • CHS req received - It is the number of Channel Switch Requests received by a CPE.

  • UCS Sent - It is the number of Urgent Coexistence Situations sent by a CPE.

Incumbent Metrics#

  • BS Id - It represents the Id of the Base Station

  • Incumbent Id - It represents the Id of the Incumbent.

  • Frequency - It is the frequency at which the incumbent operates.

  • Operational Time - It is the active period of the incumbent.

  • Idle Time - It is the inactive period of the incumbent.

  • Interference Time - It is the time when interference occurs due to CPE.

Channel Metrics#

  • BS Id - It is the Id of the BS

  • Channel Number - It represents the channel number at which the BS is operating.

  • Frequency - It is the frequency of the channel at which the BS is operating.

  • Spectral efficiency - It refers to the information rate that can be transmitted over a given bandwidth in a specific communication system. It is a measure of how efficiently a limited frequency spectrum is utilized by the physical layer protocol, and sometimes by the media access control protocol.

Application Metrics#

Displays Application performance metrics.

  • Application Id - It is the unique Id of the application running at the source.

  • Application Name - It is unique name of the application running.

  • Source Id - It is the unique Id of the device running that particular application.

  • Destination Id - It is the unique Id of the destination device.

  • Packet generated - It is the total number of packets generated from the source. 

  • Packets Transmitted - It is the total number of packets generated and transmitted from the source. 

  • Packet received - It is the total number of packets received at the destination.

  • Payload Transmitted - It is the total payload transmitted in bytes.  It is equal to the product of 'Packets Transmitted' and 'Packet Size'. This calculation will apply only in case of a constant packet size (CBR, CUSTOM (constant) etc. In other cases, this should be considered as the sum of the payload of the packets transmitted.

  • Payload Received - It is the total payload received at the destination in bytes. 

  • Throughput - Total user data (or) payload delivered to their respective destination every second.

    If Simulation Time \ Application End Time, then

$$Application\ Throughput(Mbps) = \frac{Total\ payload\ delivered\ to\ destination\ (bytes)\ *\ 8}{Time\ last\ received\ packet\ at\ App\ layer(\mu s) - App\ Start\ Time\ (\mu s)}$$

If Simulation Time \< Application End Time, then

$$Application\ Throughput(in\ Mbps) = \frac{Total\ payload\ delivered\ to\ destination\ (bytes)\ *\ 8}{Simulation\ Time(\mu s)\ - App\ Start\ Time(\mu s)}$$

  • Jitter

$$Jitter(\mu s) = \frac{TotalPacket\ Jitter\ of\ all\ successfull\ packets}{Total\ Number\ of\ successfully\ recieved\ packets - 1}$$

$$Packet\ Jitter\ (\mu s) = \ |EndtoEnd\ Delay\ of\ Current\ packet - EndtoEnd\ Delay\ of\ Previous\ Packet|$$

  • Delay - It is the average amount of time taken (calculated for all successful packets) to reach the destination application layer from when the packet is sent from source's application later. It would APP_IN time at destination -- APP_OUT time at source.

IP Metrics#

IP layer metrics calculated for the overall network and displayed for each device.

  • Device Id - It is the unique ID of the Device.

  • Packet sent - Specifies the number of packets (L3 and above) sent by the node.

  • Packet forwarded - Specifies the number of packets (L3 and above) forwarding by an intermediate node(s) to next hop/target node.

  • Packets Received - Specifies the number of packets (L3 and above) successfully received at the destination, from intermediate node(s) and source node(s).

  • Packets discarded - Specifies the number of packets (L3 and above) discarded when there is no route available.

  • TTL Expired - Specifies the number of Data and Control packets (L3 and above) dropped when TTL expires.

  • Firewall block - Specifies the number of packets (L3 and above) blocked by Firewall for example TCP, UDP and ICMP Packets etc.

Advanced Metrics#

In the Application metrics table, in addition to packets generated and packets received, additional information on duplicate packets that were received can be obtained. This is achieved by adding the following environment variable:

PC Settings à Properties à Advance system settings à Environment Variables à User Variables à New

Figure 8‑7: Environment Variables window

Note: For the effect of changes to User needs to restart the System.

The Application metrics table in the results dashboard will display an additional column -- Duplicate packet received as shown below Figure 8‑8.

Figure 8‑8: Application metrics table in results window

Note: Note that keeping track of duplicate packets will slow down the simulation

Notes on metrics#

  1. The metrics are calculated at each layer and might not be equivalent to the same metric calculated at a different layer. For exactness and precision, we recommend users also verify the results with the event trace & packet trace generated by NetSim.

  2. Broadcast / Multicast application will have no entries under Application Metrics in Results window if there are zero packets received. In other words, it will not show '0' throughput. Users may notice that '0' throughput is shown for unicast applications, and this is because of the way Broadcast/Multicast application metrics is architected in NetSim.

The different results files written at the end of simulation#

The following table lists the various files that will be written in the NetSim install directory/ IO path on completion of simulation.

S. No File Contents
1 Metrics.xml Contains the metrics of the network that is simulated recently.
2 Node.pcap Contains the information of captured packets that is recently simulated.
3 LicenseErrorLog.txt Contains the status of the communication between the NetSim dongle and the client
4 ConfigLog.txt This file will be written while reading the Configuration file.
Provides errors if there are errors in the configuration file.
5 LogFile.txt Contains the logs as the control flows across various layers in the Network Stack
6 PacketTrace.csv Contains the detailed packet information. This file will be written only when Packet Trace is enabled.
7 EventTrace.csv Contains the information about each event. This file will be written only when Event Trace is enabled.
8 Animation.txt Contains the information about the flow of the packet.
9 Static ARP.txt Contains the information about the dropped devices like Ip address and mac address.

Table 8‑1: Different results files written at the end of simulation in I/O Path

If NetSim runs via the UI, then the metrics will be displayed automatically at the end of simulation with illustrative tables.

If NetSim runs via CLI, then the metrics will be written into Metrics.txt and MetricsGraph.txt.

Export to .csv#

In NetSim Result Dashboard, users can use the option Export Results (.xls/.csv) to export all the metrics file to XL/CSV file for the further computation or analysis using it.

Figure 8‑9: Select Option Export Results (.xls/.csv) in Result window

XL/CSV file:

Figure 8‑10: Option Export Results (.xls/.csv) to export all the metrics

A web formatted (html file) report can be generated for simulations performed in NetSim, using the Print button present in the results window as shown below Figure 8‑11.

Figure 8‑11: Print Results(.html) in Results window

The report that is generated contains:

  • A screenshot of the network scenario created in NetSim GUI.

  • All the metrics tables that were part of the Simulation Results Window

  • Dynamic Metrics Plots (if Dynamic Metrics is enabled prior to Simulation).

Figure 8‑12: html report generated in PDF format

  • The report that is generated makes it convenient for documentation, reference, study and further analysis.

  • This html report can be printed as PDF or printed out by selecting printer options.

Packet Animation#

NetSim provides the feature to play and record animations to the user. Packet animation enables users to watch traffic flow through the network for in-depth visualization and analysis. Users have the following options before running simulation:

  • Record the animation.

  • Don't play/ record animation and

  • Play and record animation while running simulation.

Graphical user interface, text, application, email Description automatically generated

Figure 8‑13: Run Simulation window

The packet animation would then be recorded, and the user can view the animation from the NetSim Packet Animation window as shown below Figure 8‑14.

Figure 8‑14: Packet Animation window

While viewing packet animation, user can see the flow of packets as well as the type of packet. Blue color packet denotes control packet, green color is used for data packet and red color is error/collided packet.

Packet animation Table#

Packet Animation table is also provided for users to see the flow of packets along with packet animation.

Figure 8‑15: Packet Animation table in animation window

The "Table Filters" option available in the Packet Animator Window allows users to filter the parameters that will be displayed in the Packet Trace Window displayed alongside animation.

Figure 8‑16: Table Filters option available in the Packet Animator Window

Note: Packet Animation table would be displayed only if Packet Trace is enabled in the network before running the simulation.

Packet animation -- Display Settings#

NetSim Packet Animation can be customized using the View More drop-down list provided with the display settings as shown below Figure 8‑17.

Figure 8‑17: Display Settings in Packet animation window

The View More Animation options can be used to view (enable/disable)

  • Device Name

  • IP address of devices

  • VLAN ID

  • Application Flow

  • Node Movement

  • Packet Flow

  • Battery Level

  • Route tables etc alongside animation

Note*: The options displayed under View more* drop down are dependent on the network that is simulated and features that are enabled.

Example on how to use NetSim packet animation feature:#

Case 1: ARP PROTOCOL - WORKING

Figure 8‑18: Intra LAN IP Forwarding

  • Create a scenario with 3 wired nodes, 2 switches and 1 router and connect it based on the following scenario.

Figure 8‑19: Application flow within a LAN

  • Transport Protocol is set to UDP instead of TCP for all the wired nodes.

  • Click on application and set Source_Id and Destination_Id as 1 and 2 respectively.

  • Set Simulation time = 100s. After clicking on Run Simulation, edit Static ARP Configuration tab by setting Static ARP as Disable. Click on OK button to simulate.

Now click on packet animation and analyze the following:

Figure 8‑20: Packet animation window

  • NODE-1 sends ARP_Request which is then broadcasted by SWITCH-4.

  • During the process the devices that receive the ARP_Request packet (Switch, Router, and Node-2) will update their ARP table or the switch table.

  • NODE -2 sends the ARP_Reply to NODE-1 via SWITCH-4.

  • Now NODE-1 updates its ARP table with the MAC address of NODE-2 on receiving the ARP_Reply.

  • After this step, NODE-1 starts sending data packets to NODE-2 since the source now has both IP and MAC addresses of destination.

Case 2: Across-Router-IP-forwarding

Figure 8‑21: Across Router IP Forwarding

  • Follow all the steps till Step 2 and perform the following sample.

  • To run the simulation, click on the Application icon and set the Source_Id and Destination_Id as 1 and 3 respectively.

  • Click on Run Simulation and set Simulation time as 100 sec.

  • Then go to Static ARP Configuration tab and set Static ARP as Disable. Click on OK button to simulate.

Click on packet animation to analyse the following:

Figure 8‑22: Packet animation window

  • NODE-1 transmits ARP_Request which is further broadcasted by SWITCH-4. ROUTER-6 sends ARP_Reply to NODE-1 which goes through SWITCH-4. Then NODE-1 starts to send data to NODE-3.

  • If the router has the address of NODE-3 in its routing table, ARP protocol ends here, and data transfer starts that is PACKET_ID 1 is being sent from NODE-1 to NODE-3.

  • In other case, Router sends ARP_Request to appropriate subnet and after getting the MAC ADDRESS of the NODE-3, it forwards the packet which it has received from NODE-1.

  • When a node has to send data to a node with known IP address but unknown MAC address, it sends an ARP request. If destination is in same subnet as the source (found through subnet mask) then it sends the ARP (broadcast ARP message) request, otherwise it forwards it to the default gateway.

  • Former case happens in case of intra-LAN communication. The destination node sends an ARP response which is then forwarded by the switch to the initial node. Then data transmission starts.

  • In latter case, a totally different approach is followed. Source sends the ARP request to the default gateway and gets back the MAC address of default gateway. (If it knows which router to send then it sends ARP request to the corresponding router and not to Default gateway).

  • When source sends data to default gateway (a router in this case), the router broadcasts ARP request for the destined IP address in the appropriate subnet. On getting the ARP response from destination, router then sends the data packet to destination node.

How to record and save Packet animation as a Video file#

Note: The following procedure applies to Windows 10 Operating system only. Users with other versions of Windows can use third-party video capture tools (Link to a list of common tools) to save NetSim packet animation as a video.

To quickly capture NetSim packet animation, launch the packet animation window. Before playing the animation, press Windows key + G on the keyboard to open Game bar. (or Select windows settings and then select Gaming option for Game bar related settings). Now start recording by pressing record option as shown below. (Shortcut to start recording Windows key + Alt + R)

Figure 8‑23: In packet animation window press Windows key + G on the keyboard and Select Start recording

Then select the checkbox "Enable gaming features for this app to record gameplay" option.

Figure 8‑24: Select the checkbox "Enable gaming features for this app to record gameplay" option

Once you select the checkbox, recording window will open as shown below.

Figure 8‑25: Recording window

Now start playing the animation in NetSim using play button in packet animation window.

Figure 8‑26: Start playing the animation in animation window

Once the animation has been recorded stop recording (Shortcut to stop recording Windows logo key + Alt + R). Recorded clips will be saved in windows default videos folder (E.g.: C:\Users\PC\Videos\Captures).

Packet Trace#

NetSim allows users to generate trace files which provide detailed packet information useful for performance validation, statistical analysis and custom code de-bugging. Packet Trace logs a set of chosen parameters for every packet as it flows through the network such as arrival times, queuing times, departure times, payload, overhead, errors, collisions etc.

The packet trace is written whenever a packet is received at a device. For example, if we have transmission N1 -\ N2 -\ N3, then the packet trace is written for every packet being received at N2 and at N3. Note that it not written for every packet being transmitted by N1 and the subsequently by N2. This means that packet which are transmitted from N1 but which may have been errored or collided before being received by N2 are not written in the packet trace.

By providing a host of information and parameters of every packet that flows through the network, packet trace provides necessary forensics for users to catch logical errors without setting a lot of breakpoints or restarting the program often. Window size variation in TCP, Route Table Formation in OSPF, Medium Access in Wi-fi, etc., are examples of protocol functionalities that can be easily understood from the trace.

Note: By default, packet tracing option is turned off. Turning on Packet Trace will slow down the simulation significantly. After simulation, users would get the "open packet trace" link in the metrics window (will also get Packet_Trace.csv file in the saved folder).

How to Enable Packet trace#

Step 1: Create network scenario comprising of two Wired nodes and Router, create a traffic flow between the two wired nodes.

Figure 8‑27: Network Scenario

Step 2: By default, Packet trace is disabled, to enable packet trace click on icon in the tool bar as shown in the below figure.

Figure 8‑28: Packet trace option in ribbon

Step 3: After Clicking on the packet trace option, users will be allowed select the required properties to log to the packet trace. After selecting the required properties click on the "OK" button.

Figure 8‑29: Attributes in packet trace

Step 4: Click on the Run button and simulate the scenario. After completion of simulation NetSim Results dashboard window appears.

Click on the Open packet trace option from result dashboard Window as shown below:

Graphical user interface, application, table Description automatically generated

Figure 8‑30: Result Dashboard Window

How to set filters to NetSim trace file#

Step 1: Open the trace file. (In this example packet trace is opened)

Figure 8‑31: Packet Trace

Step 2: Click the arrow Filter drop-down arrow in the header of the column you want to filter. In the list of text or numbers, uncheck the (Select All) box at the top of the list, and then check the boxes of the items you want to show.

For example, click on arrow of SOURCE_ID and uncheck the "Select all" check box and select NODE 2 then click on OK.

All the rows which are having NODE 2 as source id will be shown below Figure 8‑32.

Figure 8‑32: Select Transmitter ID arrow mark in the header in packet trace

Figure 8‑33: Filter Transmitter ID to NODE 2 in packet trace

Typically, filters can be set to observe "Errored/Collided/Successful"packets, packets of destination and packets of source.

Observing packet flow in the Network through packet trace file#

Open the packet trace file, Click the arrow Filter drop-down arrow in the header of the column PACKET_ID and uncheck the "Select all" check box and select the packet id which you want to observe, for example 1, and then click on OK.

Figure 8‑34: Select Packet ID arrow mark in the header in packet trace

Scenario is as shown below Figure 8‑35 and traffic flow is from Wired Node 2 to Wired Node 3.

Figure 8‑35: Traffic flow is from Wired Node 2 to Wired Node 3

Flow of packet 1 can be observed from the packet trace as shown below Figure 8‑36.

Figure 8‑36: Flow of packet observed in the packet trace

Note: In the trace file device IDs are shown not device names. Wired Node 1's ID is 2 so it is Shown as NODE-2, Wired Node 2's ID is 3 so it is shown as NODE -3, Router-1' ID is 1 so it is shown as ROUTER-1. Device IDs are shown on the top of the device icon in the above scenario.

In a scenario source and destinations are fixed but transmitter and receiver are changed. For example, in the above scenario NODE-2 is the source and NODE-3 is the destination, but when NODE- 2 sending the packet to the ROUTER-1 then NODE-2 is the transmitter and ROUTER-1 is the receiver. When ROUTER-1 sending the packet to the NODE-3, ROUTER-1 is the transmitter and NODE-3 is the receiver.

Analysing Packet Trace using Pivot Tables#

NetSim Packet trace is saved as a spread sheet. Packet Trace can be converted to an Excel table to make the management and analysis of data easier. A table typically contains related data in a series of worksheet rows and columns that have been formatted as a table. By using the table features, you can then manage the data in the table rows and columns independently from the data in other rows and columns on the worksheet.

PivotTables are a great way to summarize, analyze, explore, and present your data, and you can create them with just a few clicks. PivotTables are highly flexible and can be quickly adjusted depending on how you need to display your results. You can also create Pivot Charts based on PivotTables that will automatically update when your PivotTables do.

If you enable packet trace, Open Packet Trace link present in the Simulation Results Window can be used to load the packet Trace file in MS-Excel. Formats the spread sheet as a table for convenient analysis.

Figure 8‑37: Sheet 1 is the packet trace

Sheet 2 of the packet trace file has a pivot table -- Pivot Table (TX-RX) automatically populated to analyze the packets that were transmitted and received in the network that was simulated. Further users can modify the table by adding or deleting the column headers.

Figure 8‑38: Sheet 2 of the packet trace file has a pivot table

Sheet 3 of the packet trace has a blank pivot table -- Pivot Table (Custom) which can be used to create additional pivot tables from scratch.

Figure 8‑39: Sheet 3 of the packet trace file has a blank pivot table

Steps to analyse the packet trace using pivot tables

Step 1: Click on Packet Trace in the result dashboard, you can find 3 sheets will be created i.e. Packet Trace, Pivot Table (TX-RX), Pivot Table (Custom)

Figure 8‑40: Packet Trace, Pivot Table (TX-RX), Pivot Table (Custom) in packet trace

Step 2: Click on Pivot Table (Custom) to create your own pivot table.

Figure 8‑41: Select Blank Pivot Table (Custom) to create your own pivot table

Once you open the sheet PivotTable (Custom), you will need to decide which fields to add. Each field is simply a column header from the source data. In the PivotTable Field List, check the box for each field you want to add.

Packet Transmitted / Received Analysis#

  • If you want to analyze packets sent from all sources to all destinations, then check SOURCE_ID, DESTINATION_ID and CONTROL_PACKET_TYPE/APP_NAME as shown below Figure 8‑42.

Figure 8‑42: Select the check box of SOURCE_ID, DESTINATION_ID and CONTROL_PACKET_TYPE/APP_NAME in PivotTable Fields

  • The selected fields will be added to one of the four areas below the Field List. Click SOURCE_ID, hold it and drag to the ROW field. Similarly, DESTINATION_ID to COLUMNS and CONTROL_PACKET_TYPE/APP_NAME to VALUES.

Figure 8‑43: Selected fields add to one of the four areas below the Field List

  • The PivotTable will calculate and summarize the selected fields. In this example, the PivotTable shows the packets sent from all sources to all destinations.

Figure 8‑44: PivotTable Created with selected fields

  • The above example shows all the packets which including data packets and control packets.

  • If you wish to know how many Data and how many were control packets then, check the PACKET_TYPE and drag it to the ROWS field as shown below Figure 8‑45.

Figure 8‑45: Select the PACKET_TYPE Check Box and drag it to the ROWS fields

  • This will look like

Figure 8‑46: PivotTable Created with Packet Type

  • Further, if you wish to know how many packets got errored and how many were successful, check the PACKET_STATUS field and drag it to the ROWS field.

Figure 8‑47: PivotTable Created with Packet Status

Delay analysis#

We explain this using a packet trace generated per the following network scenario.

Figure 8‑48: Network Topology with different application

Create a network scenario with 1 router and 6 wired nodes. Create 3 applications as per the following Table 8‑2.

Application Type Source Id Destination Id Transport Protocol Packet Size (Bytes) Inter arrival time (μs)
CBR 2 3 TCP 1460 20000
VOICE 4 5 UDP 1500 20000
CUSTOM 6 7 TCP 1200 20000

Table 8‑2: Application Properties

Note: Users need to select Codec as CUSTOM for voice application as shown in the below screenshot Figure 8‑49.

Figure 8‑49: Application properties Window

Enable Packet Trace and simulate the scenario for 10 seconds. Open packet trace and perform the following steps:

  • Insert a column after PHY_LAYER_END_TIME, then select the whole column and calculate delay for each and every packet by using the formula.

    $$=PHY_LAYER_END_TIME -- APPLICATION_LAYER_ARRIVAL_TIME$$

Figure 8‑50: Calculate delay in packet trace using PHY_LAYER_END_TIME -- APPLICATION_LAYER_ARRIVAL_TIME then Press CTRL + ENTER

  • Then Press CTRL + ENTER. This will calculate delay for the whole column shown below.

Figure 8‑51: Calculate delay for the whole column

  • Name the column as DELAY.

  • Go to Insert-\PivotTable and click on OK to create a blank Pivot Table with the newly added column listed under the PivotTable Fields.

  • Drag and drop DESTINATION_ID, RECEIVER_ID, PACKET_STATUS and CONTROL_PACKET_TYPE/APP_NAME to FILTERS field shown below Figure 8‑52.

Figure 8‑52: Added Selected fields to Filter

  • Filter RECEIVER_ID to Node-3 by clicking on the drop down and select OK.

Figure 8‑53: Filter RECEIVER_ID to Node-3 by clicking on the drop down

  • Similarly filter CONTROL_PACKET_TYPE/APP_NAME to APP1_CBR, DESTINATION_ID to NODE-3 and PACKET_STATUS to Successful

Figure 8‑54: Similarly filter other fields as per screenshot

  • Drag and drop PACKET_ID to ROWS and the Delay value that we calculated earlier to VALUES area.

Figure 8‑55: Drag and drop DELAY value that we have calculated earlier to

ROWS and VALUES field

  • Click on Count of DELAY drop down and select Value Field settings, then Select SUM and click on OK.

Figure 8‑56: Select Count of DELAY drop down and select Value Field settings as SUM

  • Again, Drag and drop DELAY to VALUES field.

Figure 8‑57: Drag and drop DELAY to VALUES field

  • Select one cell and calculate the Application Delay, which is the average delay faced by a packet by using the formula.

$$Application\ \ DELAY\ = \frac{Sum\ of\ DELAY\ of\ Successful\ Packets}{Number\ of\ Packets}$$

Figure 8‑58: Calculated the Application Delay in Pivot table

  • Compare the obtained value with the DELAY in Application Metrics

Figure 8‑59: Compare the obtained DELAY with Application Metrics DELAY

  • To calculate DELAY for VOICE application, filter DESTINATION_ID to Node-5, RECEIVER_ID to Node-5, CONTROL_PACKET_TYPE/APP_NAME to APP2_VOICE and PACKET_STATUS to Successful

  • Similarly calculate and compare DELAY for other applications by following the above procedure.

Throughput analysis#

To explain how users can perform Throughput Analysis, we have used same network design example as was used for Delay analysis above.

After loading the packet trace switch to sheet Pivot Table (Custom), drag and drop SOURCE_ID, RECEIVER_ID, CONTROL_PACKET_TYPE / APP_NAME and PACKET_STATUS to FILTERS field.

  • Similarly drag and drop APP_LAYER_PAYLOAD to ROWS field and VALUES field.

  • Filter SOURCE_ID to NODE-2, CONTROL_PACKET_TYPE APP_NAME to APP1_CBR, PACKET_STATUS to Successful and RECEIVER_ID to NODE-3

  • Click on Count of APP_LAYER_PAYLOAD drop down and select Value Field settings, then Select Sum and click on OK.

  • The pivot table would look like.

Figure 8‑60: Pivot Table

  • Select 1 cell and calculate the throughput by using the formula.

$$\ Application\ throughput\ (Mbps) = \ \frac{Sum\ of\ \ Successfully\ Received\ App\ Layer\ Payload\ (Bytes)*8}{Simulation\ Time\ (\mu s\ )}$$

Figure 8‑61: Calculate the throughput by using the formula in Pivot Table

EmptyCell=GETPIVOTDATA(\"APP_LAYER_PAYLOAD(Bytes)\",\$A\$6,\"APP_LAYER_PAYLOAD(Bytes)\",1460)*8/10000000

  • Now compare the throughput calculated using pivot table with the Application Metrics throughput.

Figure 8‑62: Compared the calculated throughput using pivot table with the Application

Metrics throughput

  • To calculate THROUGHPUT for VOICE application, filter SOURCE_ID to Node-4, RECEIVER_ID to Node-5, CONTROL_PACKET_TYPE/APP_NAME to APP2_VOICE and PACKET_STATUS to Successful

  • Similarly calculate and compare THROUGHPUT for other applications by following the above procedure.

Plotting with Pivot Charts#

In a pivot table, you can create a new field that performs a calculation on the sum of other pivot fields.

  • Open Packet Trace, switch to sheet Pivot Table (Custom)

  • Drag and drop SOURCE_ID, RECEIVER_ID and PACKET_STATUS to FILTERS field, then CONTROL_PACKET_TYPE/APP_NAME, APP_LAYER_PAYLOAD to ROWS field Figure 8‑63.

Figure 8‑63: Drag and drop Sleeted Fields to one of the four areas

below the Field List

  • Filter SOURCE_ID to Node 2, Node 4 and Node 6, then RECEIVER_ID to Node 3, Node 5 and Node 7 and PACKET_STATUS to successful

Figure 8‑64: Filter Source ID and Destination ID

  • Filter CONTROL_PACKET_TYPE/APP_NAME to APP1_CBR, APP2_VOICE and APP3_CUSTOM

  • Select a cell in the pivot table, and on the Excel Ribbon, under the PivotTable Tools tab, click the Options tab (PivotTable Analyze tab in Excel 2013).

  • In the Calculations group, click Fields, Items, & Sets, and then click Calculated Field.

Figure 8‑65: In Calculations group Select Calculated Field

  • Type a name for the calculated field, Application Throughput.

  • Then click on ADD to save the calculated field.

Figure 8‑66: Insert calculated field name and select Add

  • Click on Formula text box and then select APP_LAYER_PAYLOAD in the Fields list and click on Insert Field.

  • Calculate the throughput by using the following formula shown below and click on OK.

$$Application\ throughput\ (Mbps) = \ \frac{Sum\ of\ \ Successfully\ Received\ App\ Layer\ Payload\ (Bytes)*8}{Simulation\ Time\ (\mu s\ )}$$

Formula=\'APP_LAYER_PAYLOAD(Bytes)\'*8/10000000

Figure 8‑67: Calculate the throughput by using the following formula

  • Then Drag and drop the newly added Application throughput to values field

Figure 8‑68: Add Application throughput to values field

  • Select a cell in the pivot table, and on the Excel Ribbon, under the PivotTable Tools tab, click the Options tab (PivotTable Analyze tab in Excel 2013).

  • In the Tools group, click Pivot chart and select OK.

Figure 8‑69: In the Tools group Select Pivot chart

  • This will display a pivot chart shown below.

Figure 8‑70: Pivot Chart

(Note: The procedure may vary with different versions of excel, the given procedure is according to the Excel 2017.)

Packet Trace Fields#

GENERAL FIELDS DESCRIPTION
PACKET_ID Specifies the ID of the Data Packets. For control packets this value is set to 0For every application packet IDs are assigned in serial order. The Packet ID is not a unique number. It is the tuple {Application ID, Packet_ID} that is unique.
SEGMENT_ID Specifies the ID of the segment of the Data Packet. Segmentation is done in transport layer. If the packet size (generated in the APP layer) is greater than the maximum segment size in TRANSPORT layer, packet will get segmented. For control packets it is N/A
PACKET_TYPE Specifies the type of application that generates the packet.It can be Control Packet, Custom, CBR, Peer_to_peer, E-Mail, DataBase, FTP, Video, Voice, HTTP.
CONTROL_PACKET_TYPE Specifies the type of Control Packet transmitted. Following are the Protocol specific control packets WLAN: WLAN_ACK, WLAN_BlockACKOSPF: OSPF_HELLO, OSPF_D-D, OSPF_LSR, OSPF_LSU, OSPF_LSARIP: RIP_MessageGSM: GSM_Channel_Request, GSM_Channel_Granted, GSM_Call_Request, GSM_Channel_Request_For_Incoming, GSM_Call_AcceptedCDMA: CDMA_Channel_Request, CDMA_Channel_Granted, CDMA_Call_Request, CDMA_Channel_Request_For_Incoming, CDMA_Call_AcceptedDSR, AODV, ZRP, OLSR: RREQ, RREP, NDP_HELLO_MESSAGE, OLSR_TC_MESSAGE Zigbee: Zigbee_BEACON_FRAME, Zigbee_ACKCognitive Radio: SCH, FCH, DS-MAP, US-MAP, UCD, DCD, BW_REQUEST, UCS_NOTIFICATIONLTE: LTE_Measurement_Report, LTE_RRC_CONNECTION_SETUP, LTE_RLC_SDU, LTE_RRC_CONNECTION_REQUEST, LTE_RRC_CONNECTION_SETUP_COMPLETE, LTE page, LTE Ack etc.
SOURCE_ID Specifies the - of the source set in the application. Note that if the device name is changed the new name will not reflect in the trace.
DESTINATION_ID Specifies the - of the destination set in the application. Note that if the device name is changed the new name will not reflect in the trace. If the application is a broadcast application the destination field will show 0
TRANSMITTER_ID Specifies the - of the current node which is transmitting the packet. Note that if the device name is changed the new name will not reflect in the trace. The difference between a Source node and a Transmitter, is that when the Source remains constant across the entire packet transmission whereas the transmitter ID changes with each hop of the packet.
RECEIVER_ID Specifies the - of the current node which is receiving the packet. Note that if the device name is changed the new name will not reflect in the trace. The difference between a Destination node and a Receiver, is that when the Destination remains constant across the entire packet transmission whereas the receiver ID changes with each hop of the packet.
APP_LAYER_ARRIVAL_TIME (μs) Specifies the time at which packet is at the Application_Layer of Source_ID (or Transmitter_ID). This is usually the time at which the packet is generated at Source_ID
TRX_LAYER_ARRIVAL_TIME (μs) Specifies the time at which packet reaches the Transport_layer from the application layer. This will usually be the same as Application_layer_Arrival_Time unless there are TCP re-transmissions
NW_LAYER_ARRIVAL_TIME (μs) Specifies the time at which packet reaches the Network_Layer of Transmitter_ID if this is a Router (or) Time at which packet reaches the Network_layer of previous Router / Source_ID (immediate previous Layer 3 or higher device) if current device is Switch / Access Point.
MAC_LAYER_ARRIVAL_TIME (μs) Specifies the time at which packet reaches MAC_Layer of Transmitter_ID
PHY_LAYER_ARRIVAL_TIME (μs) Specifies the time at which packet reaches PHY_layer of Transmitter_ID
PHY_LAYER_START_TIME (μs) Specifies the time at which packet starts betting transmitted in the link between Transmitter_ID and Receiver_ID
PHY_LAYER_END_TIME (μs) Specifies the time at which packet reaches Phy_Layer of Receiver_ID
APP_LAYER_PAYLOAD (Bytes) Specifies the size of the Payload at Application Layer
TRX_LAYER_PAYLOAD (Bytes) Specifies the size of the Payload at Transport Layer
NW_LAYER_PAYLOAD (Bytes) Specifies the size of the Payload at Network Layer
MAC_LAYER_PAYLOAD (Bytes) Specifies the size of the Payload at Data Link Layer
PHY_LAYER_PAYLOAD (Bytes) Specifies the size of the Payload at Physical Layer
PHY_LAYER_OVERHEAD (Bytes) Specifies the size of the overhead in Physical layer
PACKET_STATUS Specifies whether the Packet is Successful, Collided or Errored
LOCAL_ADDRESS Specifies the Port Number at Source Node. Port Numbers are chosen randomly by NetSim.
FOREIGN_ADDRESS Specifies the Port Number at Destination Node. Port Numbers are chosen randomly by NetSim.
CWND (bytes) Specifies the current size of the TCP congestion window
SEQ_NO If TCP is enabled, it specifies the TCP Sequence number of the packet
ACK_NO If TCP is enabled, it specifies the TCP Acknowledgement number of the packet
RTT (seconds) Specifies the Round-Trip Time for the packet
RTO (seconds) Specifies the Retransmission Timeouts
CONNECTION_STATE Specifies the state of TCP connection
isSyn If TCP is enabled, it specifies whether the packet is TCP_SYN or not
isAck If TCP is enabled, it specifies whether the packet is TCP_ACK/TCP_SYN_ACK or not
isFin If TCP is enabled, it specifies whether the packet is TCP_FIN or not
SEGMENT_LENGTH Specifies the segment length of the packet
SOURCE_IP Specifies the IP address of the source
DESTINATION_IP Specifies the IP address of the destination
GATEWAY_IP Specifies the IP address of the device which is transmitting a packet
NEXT_HOP_IP Specifies the IP address of the next hop

Table 8‑3: Packet Trace Fields and Description

NOTE:

  • Each line in the packet trace represents one hop of one packet. 

  • The packet trace is logged in ascending order of time as measured in Phy_Layer_End_Time.

Event Trace (only in Standard/Pro Version)#

NetSim Network Stack and Discrete Event Simulation working#

NetSim's Network Stack forms the core of NetSim and its architectural aspects are diagrammatically explained below. It exactly mirrors the TCP/IP stack and has the following five layers.

  • Application Layer -- CBR, Voice, Video, HTTP, COAP etc.

  • Transport Layer -- TCP, UDP

  • Network Layer -- IP, OSPF, AODV, OLSR etc.

  • MAC Layer -- 802.11, 802.15.4, LTE etc.

  • Physical Layer -- Wired (P2P, P2MP, MP2MP), Wireless (RF Propagation)

Network Stack accepts inputs from the end-user in the form of Configuration file and the data flows as packets from one layer to another layer in the Network Stack.

All packets, when transferred between devices move up and down the stack, and all events in NetSim fall under one of these ten categories of events, namely, Physical IN, Data Link IN, Network IN, Transport IN, Application IN, Application Out, Transport OUT, Network OUT, Data Link OUT and Physical OUT. The IN events occur when the packets are entering a device while the OUT events occur while the packet is leaving a device. In addition to these events there can be TIMER events associated with each protocol.

network_Stack

Figure 8‑71: Flow of one packet from a Wired node to a Wireless node

Every device in NetSim has an instance of the Network Stack shown above. Switches & Access points have a 2-layer stack, while routers have a 3-layer stack. End-nodes have a 5-layer stack.

The protocol engines are called based on the layer at which the protocols operate. For example, TCP is called during execution of Transport IN or Transport OUT events, while 802.11b WLAN is called during execution of MAC IN, MAC OUT, PHY IN and PHY OUT events.

When these protocols are in operation, they in turn generate events for NetSim\'s discrete event engine to process. These are known as SUB EVENTS. All SUB EVENTS, fall into one of the above 10 types of EVENTS and TIMER events if applicable.

Each event gets added in the Simulation kernel by the protocol operating at the particular layer of the Network Stack. The required sub events are passed into the Simulation kernel. These sub events are then fetched by the Network Stack in order to execute the functionality of each protocol. At the end of Simulation, Network Stack writes trace files and the Metrics files that assist the user in analyzing the performance metrics and statistical analysis.

Event Trace#

The event trace records every single event along with associated information such as time stamp, event ID, event type etc. in a text file or .csv file which can be stored at a user defined location. Apart from a host of information, the event trace has two special information fields for diagnostics.

  • A log of the file name and line number from where the event was generated (Please refer "Writing Custom Code in NetSim à Debugging your code à Via CLI") and

  • Previous event which triggered the current event.

Note: Turning on Event Trace will slow down the simulation significantly

NetSim provides users with the option of turning on \"Event Traces\".

How to enable Event Trace via GUI?

If NetSim runs via GUI, event trace can be turned on by clicking the Event Trace icon in the tool bar and selecting the required fields in the event trace.

How to enable Event Trace via CLI?

If NetSim runs via CLI, then the event trace can be turned on by enabling the event trace in the STATISTICS_COLLECTION tag of the configuration file. Following is a screenshot of a Configuration.netsim file with Event Trace disabled:

Figure 8‑72: Open Configuration.netsim in Visual Studio and Event Trace disabled

You can see that the STATUS is set to DISABLE, file name and file path are not set. To enable Event trace these parameters can be modified by editing the Configuration file. Open Configuration.netsim file and provide the file name, path and set status as Enable. Following is a screenshot of a Configuration.netsim file with Event Trace enabled:

Figure 8‑73: Event Trace enabled in Configuration.netsim file

Event Trace Metrics:

Event_Id Specifies the ID of the Event
Event_Type Specifies the type of event being performed, for e.g. - APPLICATION_IN, APPLICATION_OUT, MAC_OUT, MAC_IN, PHYSICAL_OUT, PHYSICAL_IN, etc.
Event_Time Specifies the time (in microseconds) at which the event is being executed
Device_Type Specifies the type of device in which the current event is being executed
Device_Id Specifies the ID of device in which the current event is being executed
Interface_Id Specifies the Interface_Id of device in which the present event is being executed.
Application_Id Specifies the ID of the Application on which the specific event is executed
Packet_Id Specifies the ID of the packet on which the current event is being executed
Segment_Id Specifies the ID of the segment of packet on which the current event is being executed
Protocol_Name Specifies the Protocol which is presently executed
Subevent_Type Specifies the protocol sub event which is being executed. If the sub event value is 0, it indicates interlayer communication (Ex: MAC_OUT called by NETWORK_OUT) or a TIMER_EVENT which has no sub event.
Packet_Size Specifies the size of packet during the current event
Prev_Event_Id Specifies the ID of the event which generated the current event.

Table 8‑4: Event Trace fields and Descriptions

Calculation of Delay and Application throughput from event trace#

  1. Consider the scenario as explained in the section 8.4.5 Delay analysis.

Figure 8‑74: Network Scenario to calculate delay and throughput

  1. Enable Event trace and simulate the scenario for 10 seconds,

  2. Open event trace from the simulation results windows as shown in the below Figure 8‑75.

Note: Event tracing is available only in NetSim standard and pro versions.

Figure 8‑75: Select Event Trace option in results window

  1. Click on Pivot Table (Custom) in excel sheet as shown below.

Figure 8‑76: Select Pivot Table (Custom) in excel sheet

  1. A blank PivotTable and Field List will appear on a new worksheet.

Figure 8‑77: A blank PivotTable

  1. Once PivotTable worksheet open, you will need to decide which fields to add. Each field is simply a column header from the source data. In the PivotTable Field List, check the box for each field you want to add.

Application Delay Analysis:#

  1. Drag and drop the Event_Type, Protocol_Name Fields into FILTERS, Packet_Id into ROWS and Device_Id into COLUMNS.

  2. Drag and Drop Event_Time Field into VALUES twice, then both will show Sum of Event_Time. Recheck that you have dropped the Event_Time field twice.

  3. Click on the second Event_Time field in the VALUES and select the Value Field Settings.

Graphical user interface, application Description automatically generated

Figure 8‑78: Select Second Event_Time field in the VALUES and select the Value Field Settings

  1. A window named Value Field Settings opens then select Count option and click OK button.

Figure 8‑79: Select Summarize value field by Count

  1. Then finally the Pivot Table Fields will be as shown below Figure 8‑80.

Figure 8‑80: Selected Fields to one of the four areas Field list

  1. In the Event_Type select APPLICATION_IN and APPLICATION_OUT, Protocol_Name select APPLICATION and in Column Labels select the Source_Id and Destination_Id. In our example source node ID is 2 and destination node ID is 3.

Note: After selecting the dropdown, to check and uncheck the check box proceed by selecting the selecting the multiple items check box

Figure 8‑81: Select the Event type, Protocol Name, Source and Destination ID etc

  1. The Pivot Table created will be as shown below.

Figure 8‑82: Created Pivot Table

  1. Select the entire empty column H then and enter the formula =IF(AND(LEN(A1), INT(A1)=A1),F1-G1*B1) in function and press CTRL+ENTER

F column is Total Sum of Event_Time, G Column is Total Count of Event_Time, B Column is Sum of Event_time(µs) of the Source.

Figure 8‑83: Select Entire empty column H then and enter the formula =IF(AND(LEN(A1), INT(A1)=A1),F1-G1*B1) in function and press CTRL+ENTER

App Delay = $\frac{Sum\ of\ the\ Delays\ of\ the\ sucessfully\ received\ application\ data\ packets\ by\ the\ destination}{Total\ number\ of\ sucessful\ appplication\ data\ packets\ received\ by\ the\ destination}$

Note: If the packet size is \ 1500 then fragmentation occurs and the packet is received as multiple segments. In NetSim the destination counts each segment as different packet.

Then in an empty cell enter\ =SUMIF(H:H,\"\0\")/GETPIVOTDATA(\"Count of Event_Time(US)2\",\$A\$4,\"Device_Id\",3) where

GETPIVOTDATA (\"Count of Event_Time(US)2\",\$A\$4,\"Device_Id\",3) gives the total number of packets received by the destination (in this case 3). This will give the exact Application Delay.

Figure 8‑84: Calculated Application Delay using Formula in Pivot table

Compare with the Delay in Application_Metrics_Tables and it would exactly match. There might be slight difference in the decimals due to Excel's round offs.

Figure 8‑85: Compare the Application_Metrics_Tables Delay and Pivot table Delay

Application Throughput Analysis#

  1. For Application Throughput drag and drop Event_type, Protocol_Name Fields in FILTERS, Device_Id in ROWS, Packet_Size(Bytes) into VALUES. Change the Value Field Settings of Packets_Size(Bytes) to SUM as mentioned in Delay Analysis.

Figure 8‑86: Selected Fields to one of the four areas Field list

Then Select the Event_Type as APPLICATION_IN, Protocol_Name as APPLICATION and Device_Id as the Destination (in this case destination id will be 3 since we are calculating for APP1 CBR)

Figure 8‑87: Select the Event type, Protocol Name, Source and Destination ID etc

  1. App Throughput = $\frac{TotalPayloadapplicationsuccesfullyreceivedbythedestination}{Simulationtime}$

Then in an empty cell type =GETPIVOTDATA (\"Packet_Size(Bytes)\",\$A\$4)*8/10000000

This gives the Application Throughput in Mbps (Multiplied by 8 to convert Bytes to bits, and divided by 100000 to convert into Mega)

Figure 8‑88: Calculate Application Throughput using formula

Compare with the Application throughput in the Application_Metrics_Table

Figure 8‑89: Compare the Application_Metrics_Tables throughput and Pivot table throughput

Packet Capture & analysis using Wireshark#

Enabling Wireshark Capture in a node for packet capture#

NetSim provides functionality to capture packets in the virtual nodes. The pcap file written by NetSim contains fields of packet layer 3 and above. This pcap file can be opened using the popular software, Wireshark (formerly Ethereal).

To enable packet capture in Wireshark, Right Click on the device where wireshark should be run. In the properties, go to General Properties and set the Wireshark Capture parameter as Online.

Figure 8‑90: Enable Wireshark in General Properties for wired node

Wireshark Capture Options| --------|----------------- Online | Online option will initiate a live interactive packet capture, displaying packets while running simulation Offline | Offline option will initiate silent packet capture and generate a pcap file which can be opened using Wireshark post-simulation Disable | Packets are not captured by Wireshark during simulation.

Table 8‑5: Wireshark Capture Options and Description

Viewing captured packets#

If enabled, Wireshark Capture automatically starts during simulation and displays all the captured packets. To view the details of the packet displayed, click-on the packet as shown below Figure 8‑91.

Figure 8‑91: Packets Captured in Wireshark

The detail of the contents of the selected packet can be seen in the below panes as shown below Figure 8‑92.

Figure 8‑92: Packet Information panes

In the above figure, the details of the packet are displayed in both tree form and bytes form. In the tree form, user can expand the data by clicking on the part of the tree and view detailed information about each protocol in each packet.

Filtering captured packets#

Display filters allow you to concentrate on the packets you are interested in while hiding the currently uninteresting ones. Packets can be filtered by protocol, presence of a field, values of field's etc. To select packets based on protocol, type the protocol in which you are interested in the Filter: field of the Wireshark window and presenter to initiate the filter. In the figure below Figure 8‑93, tcp protocol is filtered.

Figure 8‑93: TCP Protocol is filtered in Wireshark

You can also build display filters that compare values using a number of different comparison operators like ==, != , \, \<, \<=, etc. Following is an example displaying filtered packets whose SYN Flag and ACK Flag are set to 1 in a TCP Stream.

Figure 8‑94: Filtered SYN Flag and ACK Flag are set to 1 in a TCP Stream

Analyzing packets in Wireshark#

Analyzing Conversation using graphs#

A network conversation is the traffic between two specific end points. For example, an IP conversation is all the traffic between two IP addresses. In Wireshark, Go to Statistics Menuà Conversations as shown below Figure 8‑95.

Figure 8‑95: In Wireshark, Go to Statistics Menu \Conversations

Different types of protocols will be available. User can select the specific conversation by going to the desired protocol. For example, in the following diagram, we have selected TCP.

Figure 8‑96: TCP Wireshark Conversion for Wired Nodes

User can also analyze each of the conversation and can create graphs by selecting them and clicking on "Graph".

Figure 8‑97: Select Graph in Wireshark Conversion

Different types of graphs are possible for Round Trip time, Throughput, Time/Sequence (Stevens), Time/Sequence (tcptrace) and Window Scaling

Window Scaling#

Click on data packet i.e. \<None.

Figure 8‑98: Select one data Packet \<None\in Wireshark

Choose statisticsàTCP Stream GraphàWindow Scaling.

Figure 8‑99: Statistics\TCP Stream Graph\Window Scaling

Click on Switch Direction in the window scaling graph window.

Figure 8‑100: TCP Window Scaling Plot

Comparing the packet lengths#

To analyze the packet sizes of all packets transmitted, go to Statistics MenuàPacket lengths. Users can also set filter to analyze a collection of specific packets only. For example, tcp filter is set to obtain the packet length below Figure 8‑101.

Figure 8‑101: Comparing the packet lengths in Wireshark

Creating IO graphs#

To get the graph, go to Statistics Menu à IO Graph.

Figure 8‑102: Statistics Menu \ IO Graph in Wireshark

Creating Flow graphs#

The flow graph feature provides a quick and easy to use way of checking connections between a client and a server. It can show where there might be issues with a TCP connection, such as timeouts, re-transmitted frames, or dropped connections. To access flow graph, go to Statistics Menu à Flow Graph and select the flow type. By default, you can see the flow graph of all the packets. To get the TCP flow, select TCP flow in "Flow Type" dropdown box and you will obtain the flow as shown Figure 8‑103.

Figure 8‑103: Statistics Menu \ Flow Graph in Wireshark