← Back

Outputs: Results, Plots and Data Files

Results Window

The simulation results window in NetSim offers a unified dashboard for convenient analysis. Simulation results include application metrics, link metrics, graphical plots, detailed logs, traces, packet capture for network analysis, and the capability to save plots for future analysis. The tabular presentation includes end-to-end delays, jitter, errors, packets generated/received/collided, route tables, TCP acknowledgments, retransmissions, etc.

Figure-1: Simulation Results Window.

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 layer. It is calculated as the APP_IN time at destination minus APP_OUT time at source.

Link metrics

Displays 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.

Additional Metrics

Users can observe additional metrics based on the protocols used in the network. Users can click on Additional Metrics icon from the Results dashboard to view the additional metrics table as shown in figure below.

Figure-2: Additional Metrics option in Results Dashboard.

Figure-3: Additional Metrics Window.

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.

• Harvested Energy – It’s the process of capturing and utilizing ambient energy from the environment to replenish the battery. In NetSim, harvested energy is computed periodically based on user inputs - harvesting current and voltage.

  \[Engergy\ Harvested\ = \ Recharging\ current \times \ Voltage \times \ Time\]

• 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.

LTENR Cell Metrics

Displays LTE/LTENR Metrics associated with each cell. Since NetSim currently uses Omni directional antennas a cell is all carriers in a Macro cell eNB Omni Ant; it is not a "sector carrier".

• Macro cell eNB Omni Ant Name - It is the device name of Macro cell eNB Omni Ant.

• Macro cell eNB Omni Ant Interface ID - It is unique LTE/LTENR RAN interface ID of the Macro cell eNB Omni Ant.

• PDSCH Bytes Transmitted (bytes) - It is the total number of bytes of data traffic transmitted in the downlink (Macro cell gNB/eNB Omni Ant to UEs) in the LTE/LTENR RAN interface of the Macro cell gNB/eNB Omni Ant.

• PUSCH Bytes Transmitted (bytes) - It is the total number of bytes of data traffic transmitted in the uplink (UEs to gNB/eNB) in the LTE/LTENR RAN interface of the Macro cell eNB Omni Ant.

• PDSCH Throughput (Mbps) - Downlink data delivered to its (respective) destination every second.

  \[PDSCH\ Throughput(Mbps) = \frac{PDSCH\ Bytes\ Transmitted\ (bytes)\ *\ 8}{Simulation\ Time\ (\mu s)}\]

• PUSCH Throughput (Mbps) - Uplink data delivered to its (respective) destination every second.

  \[PUSCH\ Throughput(Mbps) = \frac{PUSCH\ Bytes\ Transmitted\ (bytes)\ *\ 8}{Simulation\ Time\ (\mu s)}\]

The Bytes transmitted and Throughput calculations take into account all UEs associated with the Base station (BS or Macro cell eNB Omni Ant.). During simulations there could be handovers. When this occurs, calculations are carried out considering the BS to which the UE is associated. Recall that in the application throughput expression the denominator is \((ApplicationEndTime - ApplicationStartTime).\ \)Whereas in the above throughput expressions the denominator is \(SimulationTime\). Hence even under cases with no handovers, the Cell throughputs will not reconcile with Application Throughputs.

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-4: Environment Variables window

Note: To effect changes, user must restart NetSim. In the event this doesn’t work please restart you system.

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

Figure-5: Application metrics table in results window

Export to .csv

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

Figure-6: Select Option Export Results (.xls/.csv) in Result window.

XL/CSV file:

Figure-7: Option Export Results (.xls/.csv) to export all the metrics.

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 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 application metrics is architected in NetSim.

Results files written at the end of simulation.

The following table lists the various files that will be written in the NetSim input-output directory on completion of simulation.

S. No	File	Contents
1	Metrics.xml	Contains network metrics
2	ConfigLog.txt	Records errors if any, in the configuration file.
3	LogFile.txt	Logs control flows across various layers in the Network Stack
4	PacketTrace.csv	If enabled, records detailed packet level information
5	EventTrace.csv	If enabled, records information about each event in the discrete event simulation
6	Static ARP.txt	Logs the IP address and MAC address of devices in the scenario

Table-1: Different results files written at the end of simulation in the I/O directory

Plots Window

In NetSim, Plots are the graphical representations of simulation results. Plots visualize various aspects of network performance including Application Performance, Link Performance, Radio Measurements, TCP Congestion and Buffer Occupancy.

Figure-8: NetSim Plots window.

The process of generating plots involves two steps. First, the user selects the Plot(s) from the list available in the design window as show in Figure-9. Then the user must choose the specific device, link, application, etc, in the plots window as shown in Figure-9. This plots window, as shown in Figure-8, becomes accessible only after the simulation concludes.

To enable Plots,

• Users can click on the “Configure Reports” tab on the top.

• Then click on “Plots” icon in the top ribbon, which will then open a right plot panel, containing a list of available plots for the network as chosen by the user.

• Check boxes can be enabled to generate the respective plots, as shown below.

Figure-9: Click on “Configure reports” tab on top. Then click on “plots” icon in the top ribbon. You can then see the list of available plots is in the right-hand side properties panel.

Plots can be accessed post simulation from the results dashboard. Click on plots in the Results window to go to the plots section. Then click on the appropriate plot to open the Plots Window. Multiple plots can be opened simultaneously.

Figure-10: Click on plots in the Results window to go to the plots section. Then click on the appropriate plot to open the Plots Window. Note that multiple plots can be opened simultaneously.

The NetSim Plot window consists of plot commands, plot parameters, tabs related to chart, annotation, series, axis, etc.

Figure-11: Plot commands, Plot parameters, Data Table and Plot area.

Figure-12: The different options on the right-hand side tab of the Plots window.

Application and Link Throughput Plots

If application and link throughput plots are enabled, NetSim plots the instantaneous (50 ms averaging window default) throughput all links and all applications in the network.

Figure-13: Application Throughput Plot

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.

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 enabling Buffer Occupancy Plot in the GUI.

Users can click on Configure reports tab, then click on plots option from the top ribbon. From the right panel under Buffer Occupancy select the Buffer Size vs Time.

Figure-14: Buffer Occupancy Plot Enabled

Post simulation, we can see the Buffer Size vs Time plot in plots section and Buffer_Occupancy_Log under the Logs section in the Results Dashboard.

Figure-15: Results Dashboard

Buffer_Occupancy_Log records the occupied buffer size, total buffer size of each device over time. Information present in Buffer Occupancy Log is:

• Time in Microseconds

• Device ID

• Device Name

• Interface ID

• Interface Name

• Occupied Buffer Size (Bytes) by each device.

• Total Buffer size (Bytes), devices having buffer configured in GUI will be the total buffer size record in this column. Rest of the devices will have infinite buffers.

• Virtual Interface Name for the Access point running over EDCAF protocol.

• Remarks such as ENQUEUE, DEQUEUE and DROP.

Figure-16: Buffer Occupancy Log

Buffer size vs Time plot is plotted for Occupied Buffer size (Bytes) in Y-axis against Time (Microseconds) in X-axis.

Figure-17: Buffer Occupancy Plot

TCP Congestion Window Plot

The TCP Congestion window over time can be plotted by enabling TCP Congestion Window Plot in the GUI.

Users can click on Configure reports tab, then click on plots option from the top ribbon. From the right panel under TCP Congestion Window select the Window Size vs Time.

Figure-18: TCP Congestion Plot Enabled

Post simulation, we can see the Window Size vs Time plot in plots section and TCP_Congestion_Window_Log under the Logs section in the Results Dashboard.

TCP_Congestion_Window_Log records the sender window size over time. Information present in TCP_Congestion_Window_Log is:

• Time in Microseconds

• Application ID

• Application Name

• Source Device Name

• Source ID

• Destination Device Name

• Destination ID

• Source Socket Address

• Destination Socket Address

• Sender Window Size (Bytes)

Figure-19: TCP Congestion Window Log

Figure-20: TCP Congestion window plot post simulation.

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}\\]

Network Logs

Users can enable protocol specific log files such as the Radio Measurement log, Radio resource allocation log etc., by clicking on the Configure Reports tab and select Plot icon option present in the toolbar as shown below.

Figure-21: Enabling log files in NetSim GUI.

The panel that appears will contain a list of logs that are applicable for the current Network. Check boxes can be enabled to generate the respective logs. Log files can be accessed post simulation from the results dashboard as shown below:

Figure-22: Log Files available in Results dashboard.

Packet Trace

NetSim allows users to generate trace files which provide detailed packet information useful for performance validation, statistical analysis, custom code de-bugging and synthetic data generation for machine learning. 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 is not written for every packet being transmitted by N1 and the subsequently by N2. This means that packets 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 that by default, packet tracing option is turned off. Turning on Packet Trace will slow down the simulation significantly.

How to Enable Packet trace

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

Figure-23: Network Scenario

Step 2: By default, Packet trace is disabled, to enable packet trace click on Configure Reports tab and enable Packet trace as shown in the below figure.

Figure-24: Packet trace option in ribbon.

Step 3: Click on the Run 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:

Figure-25: 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-26: Packet Trace

Step 2: Click the 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-27.

Figure-27: Select Transmitter ID arrow mark in the header in packet trace

Figure-28: 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 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-29: Select Packet ID arrow mark in the header in packet trace

Scenario is as shown below Figure-30 and traffic flow is from Wired Node 2 to Wired Node 3.

Figure-30: 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-31.

Figure-31: 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-32: 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-33: 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-34: 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-35: 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-36: 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-37.

Figure-37: 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-38: 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-39: 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-40.

Figure-40: Select the PACKET_TYPE Check Box and drag it to the ROWS fields

• This will look like

Figure-41: 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-42: PivotTable Created with Packet Status

Delay analysis

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

Figure-43: Network Topology with different application

Consider network scenario with 1 router and 6 wired nodes. Create 3 applications as per the following Table-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-2: Application Properties

Note: Users need to select Codec as CUSTOM for voice application as shown in the below screenshot Figure-44.

Figure-44: 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-45: 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-46: 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-47.

Figure-47: Added Selected fields to Filter

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

Figure-48: 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-49: 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-50: 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-51: Select Count of DELAY drop down and select Value Field settings as SUM

• Again, Drag and drop DELAY to VALUES field.

Figure-52: 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-53: Calculated the Application Delay in Pivot table

• Compare the obtained value with the DELAY in Application Metrics

Figure-54: 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-55: 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-56: 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-57: 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-58.

Figure-58: 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-59: 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-60: 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-61: 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-62: Calculate the throughput by using the following formula

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

Figure-63: 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-64: In the Tools group Select Pivot chart

• This will display a pivot chart shown below.

Figure-65: 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 0 For 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_BlockACK OSPF: OSPF_HELLO, OSPF_D-D, OSPF_LSR, OSPF_LSU, OSPF_LSA RIP: RIP_Message GSM: GSM_Channel_Request, GSM_Channel_Granted, GSM_Call_Request, GSM_Channel_Request_For_Incoming, GSM_Call_Accepted CDMA: CDMA_Channel_Request, CDMA_Channel_Granted, CDMA_Call_Request, CDMA_Channel_Request_For_Incoming, CDMA_Call_Accepted DSR, AODV, ZRP, OLSR: RREQ, RREP, NDP_HELLO_MESSAGE, OLSR_TC_MESSAGE Zigbee: Zigbee_BEACON_FRAME, Zigbee_ACK Cognitive Radio: SCH, FCH, DS-MAP, US-MAP, UCD, DCD, BW_REQUEST, UCS_NOTIFICATION LTE: 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 <Device-type>-<ID> 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 <Device-type>-<ID> 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 <Device-type>-<ID> 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 <Device-type>-<ID> 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.
REMOTE_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
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-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, 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.

Figure-66: 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 enabled by clicking on Configure Reports tab and unable 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-67: 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-68: 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-4: Event Trace fields and Descriptions

Calculation of Delay and Application throughput from event trace

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

Figure-69: Network Scenario to calculate delay and throughput

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

3. Open event trace from the simulation results windows as shown in the below Figure-70.

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

Figure-70: Select Event Trace option in results window.

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

Figure-71: Select Pivot Table (Custom) in excel sheet

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

Figure-72: A blank PivotTable

6. 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.

Figure-73: Select Second Event_Time field in the VALUES and select the Value Field Settings

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

Figure-74: Select Summarize value field by Count

5. Then finally the Pivot Table Fields will be as shown below Figure-75.

Figure-75: Selected Fields to one of the four areas Field list

6. 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-76: Select the Event type, Protocol Name, Source and Destination ID etc

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

Figure-77: Created Pivot Table

8. 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-78: 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 a 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-79: 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-80: 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-81: 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-82: Select the Event type, Protocol Name, Source and Destination ID etc

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-83: Calculate Application Throughput using formula

Compare with the Application throughput in the Application_Metrics_Table

Figure-84: Compare the Application_Metrics_Tables throughput and Pivot table throughput

Mobility Viewer

NetSim Mobility Viewer enables the user to observe the path taken by the nodes during the simulation. The Mobility Viewer is available for mobile ad-hoc networks, sensor networks, 4G, 5G networks, Cellular, VANETs, and underwater acoustic networks.

The mobility path for the file-based mobility model can be observed prior to the simulation, whereas the path for other models like random walk, random waypoint, group mobility, and pedestrian mobility can only be observed post-simulation.

To enable mobility viewer in the above networks, create a scenario with desired mobility model and click on configure tab and plots. Then in the right panel click on mobility log and click on run simulation.

Figure-85: Enabling Mobility log prior to simulation

After simulation, in the design window click on the Mobility Viewer and set the properties and click on View Mobility Path.

Figure-86: Mobility viewer property settings

In the image below, we have considered the Random Waypoint mobility model.

Figure-87: Mobility path for random way point model includes a pause time of 10 sec.

Similarly screenshots of the paths for other mobility models using the mobility viewer are shown below.

Figure-88: Mobility path for Random walk model

Figure-89: Mobility path for group mobility involving 8 nodes defined into 4 groups

Figure-90: Mobility path for file-based mode where node 2 moves away and returns to the transmitter

Figure-91: Mobility path for pedestrian model with a stop probability of 0

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-92: 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-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-93.

Figure-93: Packets Captured in Wireshark

The detail of the contents of the selected packet can be seen in the below panes as shown below Figure-94.

Figure-94: 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 88, tcp protocol is filtered.

Figure-95: 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-96: 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-97.

Figure-97: 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-98: 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-99: 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-100: Select one data Packet in Wireshark

Choose statistics🡪TCP Stream Graph🡪Window Scaling.

Figure-101: Statistics>TCP Stream Graph>Window Scaling

Click on Switch Direction in the window scaling graph window.

Figure-102: 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-103.

Figure-103: Comparing the packet lengths in Wireshark.

Creating IO graphs

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

Figure-104: 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-105.

Figure-105: Statistics Menu > Flow Graph in Wireshark

Protocols supported in Wireshark – NetSim interfacing

When interacting with NetSim, Wireshark by default logs the following protocols.

Routing protocols
RIP (Routing Information Protocol)
OSPF (Open Shortest Path First)
WSMP (Wireless Mesh Standard Protocol)
Ad hoc routing protocols
RPL (Routing Protocol for Low-Power and Lossy Networks)
DSR (Dynamic Source Routing)
AODV (Ad hoc On-Demand Distance Vector)
OLSR (Optimized Link State Routing)
Internet Control Message Protocol (ICMP)
ICMP Echo Request/Reply
ICMP Destination Unreachable
ICMP Time Exceeded
ICMP Parameter Problem
Transport protocols
TCP (Transmission Control Protocol)
UDP (User Datagram Protocol)
Data link layer
802.11 (Wi-Fi)

Table-6: Protocols logged by Wireshark when interfacing with NetSim

Note: Protocols such as LTE_NR, 802.22, Zigbee, OpenFlow are not logged currently in Wireshark.