Applications (Network Traffic Generator)
Applications are the sources of traffic in the network. This traffic is modeled as individual packets. These packets flow from the source to the destination over the designed network. As it flows through the network, depending on the devices, link bandwidths and networking protocols, the packets would experience network effects such as delay, error, loss etc.
Applications are generally parameterized in terms of packet size, inter-packet arrival time, priority, transport protocol running below etc. Therefore, each application has its own distinctive traffic pattern and creates its own unique load on the network.
Different applications have differing levels of complexity. Some applications are used to quickly model basic requirements while in other cases parameters can be accurately modeled to carefully reproduce real world characteristics. For example, if the goal is to analyze protocol behavior, then using a simple CBR application (that generates a certain number of packets every second of a fixed size) would suffice.
NetSim allows users to model and simulate different types of applications.
CBR
Custom
Database
FTP
Email
HTTP
Video
Voice
Sensor App
Erlang Call
BSM
Interactive Gaming
Emulation (available only if Emulator Add-on is licensed)
To set up the application click on Set Traffic from the top ribbon as shown below Figure-1.
Figure-1: Types of applications available in Set Traffic
Figure-2: Application Configuration Window
These application models have default values set, for the various application properties, to model standard application behavior. Users can modify the parameters to model their own applications.
Common properties for all applications
Application Method: It specifies the type of Application method Unicast/Multicast/Broadcast.
Application Type: It specifies the type of application such as CBR, Custom, Peer to Peer, Email, HTTP, FTP, Voice, Video, Database, Erlang Call, Sensor App, BSM, and Emulation.
Application ID: This property represents the unique identification number of the application.
Application Name: It specifies the name of the application.
Source Count: This property represents number of sources for the application. Voice, Video, FTP, Database and Custom applications have only one source.
Source ID: This property represents the unique identification number of the source.
Destination Count: This property represents number of destinations for the application. Voice, Video, FTP, Database and Custom applications have only one destination.
Destination ID: This property represents the unique identification numbers of the destination.
For Unicast Applications, users can select the ID of a device in the network as the Destination ID.
For Broadcast Applications, the Destination ID, is set to ‘0’.
Start time: This property represents the start time of the application in seconds.
End time: This property represents the end time of the application in seconds.
For example, if Start time is 1s and end time is 10s then application starts generating traffic at the 1st second and stops at the 10th second.
Encryption: Encrypts Application packet payload using algorithms such as AES, DES, XOR and TEA. The effect of encryption can be analyzed by enabling Wireshark option in either the source or the destination devices. Refer Section 8.5 on “Packet Capture and Analysis Using Wireshark” for further details.
In NetSim the packet size remains constant when encrypting using these algorithms. Therefore, using different encryption models will not have any impact on the network performance metrics that NetSim outputs. NetSim does not perform decryption of the packet at the receiver end since it does not have any impact on the performance metrics generated.
Random Startup: If random start-up is set to true, the application will start at a random time between the start time and 100 milliseconds after the start time. Having a random start-up time provides more realism to the model, as in the real world, all applications do not necessarily start at time = 0.
QoS: NetSim provides QoS differentiation for the different types of applications through four defined scheduling service types, also called QoS classes as shown below Table-1.
QoS Class |
Description |
Priority |
|---|---|---|
UGS - Unsolicited Grant Service |
The UGS scheduling service type is designed to support real-time data streams consisting of fixed-size data packets issued at periodic intervals. |
High |
rtPS - Real-time Polling Service |
The rtPS scheduling service type is designed to support real-time data streams consisting of variable-sized data packets that are issued at periodic intervals. This would be the case, for example, for MPEG (Moving Pictures Experts Group) video transmission. |
Medium |
ertPS - Extended real-time Polling Service |
The ertPS is a scheduling mechanism that builds on the efficiency of both UGS and rtPS. UGS allocations are fixed in size, ertPS allocations are dynamic. The ertPS is suitable for variable rate real-time applications that have data rate and delay requirements. |
Normal |
nrtPS - Non-real-time Polling Service |
The nrtPS is designed to support delay-tolerant data streams consisting of variable-size data packets for which a minimum data rate is required. The standard considers that this would be the case, for example, for an FTP transmission. |
Low |
BE - Best Effort |
The BE service is designed to support data streams for which no minimum service guarantees are required and therefore may be handled on a best basis. |
Low |
Table-1: Different QoS classes with Description and Priority in NetSim
Priority: The priority is automatically set based on the QoS class set by the user. Depending on the scheduling algorithm the router would process packets, with different priorities, differently.
Transport Protocol: This parameter is newly added to the Applications window where by default it selects the Transport Layer Protocol (either TCP or UDP) depending on the application that is set by the user.
Note: Users can also change the value of this parameter according to the transport protocol they intend to run a particular application.
Application Types
Application Type |
Properties |
Units |
Description |
|---|---|---|---|
CBR – Constant bit Rate |
Packet size (Constant distribution) – A fixed packet size |
bytes |
Packets of constant size are generated at constant inter arrival times. The generation times would be as follows: Packet 1: Application start time. Packet 2: Packet 1 + Interarrival Time Packet 3: Packet 2 + Interarrival Time Packet (n+1): Packet n + Interarrival Time Ends at Application end time. |
Inter Arrival Time (Constant distribution) – A fixed time gap between two successive packets |
µs |
||
Custom |
Packet size (Constant, Exponential, Uniform and Normal distribution) – Packet sizes are drawn from the respective distribution |
bytes |
It is user defined application where the packet sizes and inter-packet arrival times can be fixed (constant distribution) or can be a random variable (exponential, uniform or normal distribution) |
Inter Arrival Time (Constant, Exponential, Uniform and Normal distribution) – The time gap between two successive packets are drawn from the respective distribution |
µs |
||
Email send/receive Represents the rate at which emails are sent/receive |
Email is a client-server configuration, not a source-destination configuration. Both sides can send and receive. E.g., Outlook, Apple mail, Gmail etc. |
||
Duration (Constant, Exponential distribution) Time between two successive emails |
Seconds |
||
Email size (Constant, Exponential distribution) Size of an email |
Bytes |
||
HTTP – Hyper Text Transfer Protocol |
Inter Arrival Time (Constant, Exponential distribution). It is the time gap between two successive HTTP requests |
seconds |
HTTP is a request-response application; it uses a client-server configuration, not a source-destination configuration. The client node sends a page request to the server, and the server responds with the pages (whose size is in bytes). HTTP utilizes TCP to transfer its information between computers (usually Web servers and clients). TCP should mandatorily be set as the transport layer protocol. In the application metrics as part of an HTTP application, users can see two rows of metrics, one corresponding to requests from the client to the server and the other corresponding to the replies from the server to the client |
Page size (Constant, Exponential distribution) It is the size of each page |
bytes |
||
Page count – Represents the number of pages |
|||
FTP – File Transfer Protocol |
File size (Constant, Exponential distribution) – It is the size of the file |
bytes |
It is a standard network protocol used for the transfer of files between a client and server Note: Devices must have TCP enabled as the transport layer protocol. E.g., FileZilla The generation times would be as follows: File 1: Application start time. File 2: File 1 + Interarrival Time File 3: File 2 + Interarrival Time . . . . File (n+1): File n + Interarrival Time Ends at Application end time The files are in-turn fragmented into packets during the simulation. Users can generate one file by setting
\[Application\ End\ Time < (Application\ Start\ Time + File\ Interarrival\ Time)\]
|
File Inter Arrival Time size (Constant, Exponential distribution) – It is the gap between two files |
seconds |
||
Database |
Transaction size (Constant, Exponential distribution) - It represents the size of each transaction |
bytes |
A database application is a computer program whose primary purpose is entering and retrieving information from a computerized database. E.g., MS Excel, MySQL etc. |
Transaction Inter Arrival Time (Constant, Exponential distribution) – It is the time gap between two successful transactions |
µs |
||
Voice |
Packet size (Constant, Exponential) – It is the size of the packet |
bytes |
It allows users to configure voice application between client and server. Note: Distribution is constant only for all codec types except custom. E.g., Skype |
Packet Inter Arrival Time (Constant, Exponential distribution) - It is the gap between two successful packets |
µs |
||
Service type – CBR, VBR |
|||
Suppression models available for VBR – Deterministic, Markov chain |
|||
Success ratio - Sets the ratio of the packets that are not silenced during VBR calls |
% |
||
Video |
Model Type – Independent Gaussian First order dependent gaussian H_261, H_263, MPEG1_Low_Res, MPEG1_High_Res, MPEG2_Low_Res, MPEG2_High_Res, Buffered video streaming 1 Buffered video streaming 2 Buffered video streaming 3 Buffered video streaming 4 Buffered video streaming 5 Buffered video streaming 6 |
It allows users to configure video application between client and server. E.g., – Skype |
|
Erlang Call |
Packet size (Constant, Exponential distribution) – It is the size of the packet |
bytes |
The erlang is a unit of traffic density in a telecommunications system. One erlang is the equivalent of one call The Distribution is constant only for all codec types except custom |
Packet Inter Arrival Time (Constant, Exponential distribution) - It is the gap between two successful packets |
µs |
||
Call duration (Constant, Exponential distribution) – It is the duration of each call |
seconds |
||
Call Inter Arrival Time (Constant, Exponential distribution) - It is the gap between two successful calls |
seconds |
||
Service type – VBR, CBR |
|||
Suppression model available for VBR – Deterministic, Markov chain |
|||
Success ratio - Sets the ratio of the packets that are not silenced during VBR calls |
% |
||
Sensor App |
Packet size (Constant, Uniform and Normal distribution) – It is the size of the packet |
bytes |
Used to create application between two sensors. E.g., Smart home, Smart water etc. |
Packet Inter Arrival Time (Constant, Uniform and Normal distribution) - It is the gap between two successful packets |
µs |
||
BSM – Basic safety message |
Packet size (Constant, Uniform and Normal distribution) – It is the size of the packet |
bytes |
The BSM Application class sends and receives the IEEE 1609 WAVE (Wireless Access in Vehicular Environments) Basic Safety Messages (BSMs). The BSM is a 20-byte packet that is generally broadcast from every vehicle at a nominal rate of 10 Hz. Note: Available only with VANET component. E.g., Traffic management |
Packet Inter Arrival Time (Constant, Uniform and Normal distribution) - It is the gap between two successful packets |
µs |
||
Interactive Gaming |
Uplink Inter Arrival Time Constant distribution - A fixed time gap between two successive packets |
µs |
Interactive Gaming is based on standard 3GPP R1-070674. It is a two-way application and involves UL and DL packet transfers between a client and a server. The transport protocol used in this application is UDP. Uplink Inter Arrival Time (ms) is constant value and is a user input \(\lbrack 1,\ 100\rbrack\). The generation times for Uplink gaming network would therefore be as follows: Packet 1: Application start time. Packet 2: Packet 2 + Interarrival Time Packet 3: Packet 3 + Interarrival Time ... Packet (n+1): Packet n + Interarrival Time Ends at Application end time. Downlink Inter packet arrival times are calculated using Fisher-Tippett distribution whose PDF is:
\[f_{\ x\ } = \frac{1}{b}e^{- \left( \frac{x - a}{b} \right)}e^{\left( {- e}^{- \left( \frac{x - a}{b} \right)} \right)}\]
where, \(a\) and \(b\) are constants. \(a\ (ms) = \lbrack 20,\ 500\rbrack\), \(b(ms) = \lbrack 4,\ 25\rbrack\) and \(b \leq \frac{a}{3}\). Uplink and Downlink Packet-Size is calculated using Fisher-Tippett distribution whose PDF is:
\[f_{\ x\ } = \frac{1}{b}e^{- \left( \frac{x - a}{b} \right)}e^{\left( {- e}^{- \left( \frac{x - a}{b} \right)} \right)}\]
where, \(a\) and \(b\) are constants. \(a\ (B) = \lbrack 20,\ 500\rbrack\), \(b(ms) = \lbrack 4,\ 100\rbrack\) and \(b \leq \frac{a}{3}\) |
Uplink Packet size Fisher-Tippett distribution - The time gap between two successive packets is drawn from the Fisher-Tippett distribution |
Bytes |
||
Downlink Inter Arrival Time Fisher-Tippett distribution - The time gap between two successive packets are drawn from the Fisher-Tippett distribution |
µs |
||
Downlink Packet size Fisher-Tippett distribution - The time gap between two successive packets is drawn from the Fisher-Tippett distribution |
Bytes |
||
Emulation |
Source Real IP - Specifies the real IP Address of source device in Emulation |
NetSim Emulation application enables users to connect NetSim simulator to real devices and interact with live applications. Note: Will be present only when Emulator Add-on is licensed |
|
Source Port - Specifies the Port no used for transmission by Application running in source device |
|||
Destination Real IP - Specifies the real IP Address of destination device in Emulation |
|||
Destination Port - Specifies the Port no used for reception by Application running in destination device |
Table-2: Parameters used in modeling different application types.
Voice Models
Codec stands for Coder-decoder. Codecs are devices which encode / decode digital data streams. Codec is the component of any voice system that translates between analog speech and the bits used to transmit them. Every codec transmits a burst of data in a packet that can be reconstructed into voice.
Various voice codecs are available in NetSim to choose from. Packet size and Inter-arrival time value will vary depending on the codec value chosen.
G.711: G.711 is a Pulse code modulation (PCM) of voice frequencies on a 64-kbps channel. G.711 uses a sampling rate of 8,000 samples per second. Non-uniform quantization with 8 bits is used to represent each sample, resulting in a 64-kbps bit rate.
G.729: The G.729 speech codec uses audio data compression algorithm and compress the data at bit rates that vary between 6.4 and 12.4 kbps. Coding of speech at 8 kbps using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).
G.723: G.723 is an ITU standard for speech codecs that uses the ADPCM method and provides good quality audio at 24 and 40 Kbps.
GSM-FR: GSM–Full Rate (GSM-FR). The codec operates on each 20ms frame of speech signals sampled at 8 KHz and generates compressed bit-streams with an average bit-rate of 13 kbps. The codec uses Regular Pulse Excited – Long Term Prediction – Linear Predictive Coder (RPE-LTP) technique to compress speech.
GSM-EFR: GSM enhanced full rate speech codec is a speech coding standard that was developed in order to improve the quite poor quality of GSM-Full Rate (FR) codec. Working at 12.2 kbps the EFR provides wire like quality in any noise free and background noise conditions. The EFR 12.2 kbps speech coding standard is compatible with the highest AMR mode (both are ACELP).
CELP: Code excitation linear prediction. This model has a packet size of 18 B and inter-packet arrival time of 30 ms.
MELP: Mixed excitation linear prediction. This model has a packet size of 8 B and an inter-packet arrival time of 22.5 ms.
CUSTOM: It is similar to the CUSTOM application type explained in the table above.
Codec |
Packet Size (B) |
Inter Arrival Time (µs) |
Average Bit Rate (kbps) |
|---|---|---|---|
G.711 |
160 |
20000 |
64 |
G.729 |
20 |
20000 |
8 |
G.723 |
24 |
30000 |
6.4 |
GSM-FR |
33 |
20000 |
13.2 |
GSM-EFR |
31 |
20000 |
12.4 |
CELP |
18 |
30000 |
4.8 |
MELP |
8 |
22500 |
2.84 |
CUSTOM |
1460 |
20000 |
584 |
Table-3: Average bit rate for various voice codecs (CBR Service)
Video Models
Introduction to Video Models
A digital video source (e.g., a movie stored on a computer disk, or a live video from a teleconference) essentially comprises a sequence of images, called frames. Each frame is a digital image comprising an array of pixels. A video source is characterized by the frame rate, expressed in frames per second (fps), and the number of pixels per frame (ppf). Typical values of the frame rate are 30, 50, and 60, whereas typical values of pixels per frame are in the range of \(10^{5}\) to \(10^{6}\).
Each pixel is encoded into a number of bits to represent the intensity and colour at that point in the image. If the “raw” bits for all the pixels are put together, the number of bits per frame become very large, and it becomes impractical to handle digital video on packet communication networks. Various intraframe and interframe coding techniques are used to reduce the number of bits that need to be sent for each frame.
Video Models in NetSim
In NetSim the following video models are available:
Basic bits per pixel models:
Independent Gaussian (termed as continuous normal VBR prior to v13)
First order dependent Gaussian (termed as Continuous State Autoregressive Markov prior to v13)
Video Codec Models: H.261, H.263, MPEG1 Low Res, MPEG1 High Res, MPEG2 Low Res, MPEG2 High Res
Buffered Video Streaming Model: Options BV1 through BV6
Note: Quantized State Continuous Time Markov and Simple IPB Composite Model were discontinued from v13 onwards. If older config files with these entries are imported, then NetSim would automatically replace them with the Independent gaussian model with default parameters set.
Basic bits per pixel models
Since, for a given video, the number of pixels per frame remains constant from frame to frame, it is convenient to consider the number of bits per pixel (obtained by dividing the number of bits generated for a frame by the number of pixels). This measure is also illustrative as it permits comparison between the number “raw” bits generated for each pixel, and the average number of bits per pixel after data compression. This results in a sequence of bits per pixel, say \(b_{k}\), where k is the sequence number of the frame. For simulating a video stream in a communication network simulation, we need a statistical model of the sequence \(b_{k}\), k=0,1, 2, ⋯ The bits emitted for each frame (obtained by multiplying the generated bits per pixel by the number of pixels per frame; we denote this sequence by \(B_{k}\)) are then packetized, thereby yielding a sequence of packets which are then emitted into the network for transport.
Independent Gaussian: This simple model uses independent samples from a Gaussian (or Normal) distribution to generate the number of bits per pixel generated for each frame. In this simplest model, the number of bits per pixel is not necessarily an integer (hence, the term “continuous”), and the number of bits in successive frames are assumed to be statistically independent. Hence, this model has just two parameters
\(\mu\ (bits):\ \)the mean number of bits per pixel. NetSim range [0.01, 1.00]
\(\sigma\ (bits):\) the standard deviation of the number of bits per pixel. NetSim range [0.01, 1.00]
The data generation rate (in bits per second) for the video application can be calculated by \(\overline{B} = fps \times ppf \times \mu\), and \(Var(B) = fps^{2} \times ppf^{2} \times \sigma^{2}.\)
First order dependent Gaussian: This model incorporates the autocorrelation between the frames. The number of bits generated for each frame is not necessarily an integer, but the number of bits per pixel in successive frames are modeled as a first-order autoregressive process driven by an independent Gaussian sequence (which is itself independent from frame to frame). Thus, starting with bits per pixel \(b_{0}\), the successive \(b_{k}\) are generated as follows:
\[b_{k} = a\ b_{k - 1} + b\ w_{k}\]\(\ \ \ \ \)where
\(a\ \)and \(b\ \)are parameters of the autoregressive process, and \(w_{k},\ k \geq \ 1,\ \)is an independent sequence of independent random variables. It is important to note that the \(b\ \)is positive and \(|a| < 1\), and \(w_{k}\) is an independent Gaussian sequence with mean \(\eta\) and variance 1.
With the above conditions on \(a\ \)and \(b,\ \)the sequence \(b_{k}\) (and, therefore, the sequence \(B_{k})\ \) has a steady state, with \(\overline{b} = \left( \frac{b}{1 - a} \right)\eta\) and \(Var(b) = \left( \frac{b^{2}}{1 - a^{2}} \right).\) The steady state variance and standard deviation of the sequence \(B_{k}\) can be obtained by recalling that \(B_{k} = fps \times ppf \times b_{k};\) i.e., \(\overline{B} = fps \times ppf \times \left( \frac{b}{1 - a} \right)\eta,\ \)and \(Var(B) = (fps \times ppf)^{2} \times \left( \frac{b^{2}}{1 - a^{2}} \right).\)
Video Codec Models
The list of video codec models and their parameters is provided in table below
Model Type |
Packet Size (B) (Exponentially distributed) |
Inter packet arrival time (ms) |
Frames Per second |
Average Bit Rate (Mbps) |
|---|---|---|---|---|
H.261 |
160 |
20 |
50 |
0.064 |
H.263 |
160 |
20 |
50 |
0.064 |
MPEG1_Low_Res |
2500 |
20 |
50 |
1 |
MPEG1_High_Res |
7500 |
20 |
50 |
3 |
MPEG2_Low_Res |
7500 |
20 |
50 |
3 |
MPEG2_High_Res |
37500 |
20 |
50 |
15 |
Table-4: The input parameters used in NetSim for the various Video codecs and the resultant average bit rate
Buffered Video Streaming Models
The Buffered Video Streaming Models are based on IEEE 802.11-14/0571r12 standard. The video traffic from Video Source to Video Receiver is generated as follows.
The packet size (bytes) is generated per the Weibull distribution which has the following formula.
Model_Type |
Avg bit rate |
\[\mathbf{\lambda}\]
|
\[\mathbf{k}\]
|
Frames per second (\(\mathbf{fps)}\) |
|---|---|---|---|---|
Buffered_Video_Streaming_1 |
2 Mbps |
6950 |
0.8099 |
31 |
Buffered_Video_Streaming_2 |
4 Mbps |
13900 |
0.8099 |
31 |
Buffered_Video_Streaming_3 |
6 Mbps |
20850 |
0.8099 |
31 |
Buffered_Video_Streaming_4 |
8 Mbps |
27800 |
0.8099 |
31 |
Buffered_Video_Streaming_5 |
10 Mbps |
34750 |
0.8099 |
31 |
Buffered_Video_Streaming_6 |
15.6 Mbps |
54210 |
0.8099 |
31 |
Table-5: Parameters for the Buffered video streaming models BV1 through BV6. λ and k parameters are the scale and shape parameters of the Weibull distribution for determining packet size. The average bit rate is the generation rate for the given values of λ,k and fps.
The steps pertaining to adding TCP latency in the AP is not required since NetSim models Wi-Fi and TCP protocol operation.
The standard does not provide the frame per second values. This was derived from the average bit rate, \(\lambda\) and \(k\).
Network Traffic Generation Rate for Different Applications
This section explains how the traffic generation rate can be calculated for different types of applications:
CBR and Custom application
Example: \(Packet\ size\ = \ 1460\ Bytes\ and\ Inter\ arrival\ time\ = \ 20000\ µs.\)
Video
The Independent Gaussian model is the simplest of all video models in NetSim. It uses the normal distribution for the generation of bits per pixel. In this model, consecutive packet sizes are independent of each other. The generation rate for video application can be calculated by using the formula shown below:
where,
\(fps\ = \ frames\ per\ second,\ \ ppf\ = \ pixel\ per\ frame\ and\ bpp\ (µ)\ = \ bits\ per\ pixel\ (mean)\)
Users can set the above-mentioned parameters in the Application Properties.
Example: Frames per second = 20, pixels per frame = 10000, bits per pixel = 0.52 then the generation rate would be
\[Generation\ Rate\ (bps) = \ 20 \times 10000 \times 0.52\ = \ 104000\ bits\ per\ second\ = \ 0.1040\ Mbps\]
Voice, CBR Service
Example: Packet Size = 160 Bytes, Packet Inter Arrival Time = 20000 µs,
Voice, VBR Service, Deterministic
Example: Packet Size = 160 Bytes, Packet Inter Arrival Time = 20000 µs, Success Ratio = 90 %
Voice, VBR Service, Markov chain
Example: Packet Size = 160 Bytes, Packet Inter Arrival Time = 20000 µs, Speech Activity Factor = 0.6.
Example: Email size = 20000bytes, Duration = 1s.
HTTP
Example: Page size = 20000 Bytes, Page Count = 2, Inter arrival time = 3s
FTP
Example: File size = 100000 Bytes, Inter arrival time = \(5\ \mu s\)
Database
Example: Packet size = 10000 Bytes, Inter arrival time = 1000000 μs
BSM
Example: Packet size = 20Bytes and Inter arrival time = 1000000µs.
Erlang Call
CBR Service
\[Generation\ Rate\ (Mbps) = \frac{Packet\ Size(B) \times 8}{Packet\ IAT(\mu s)} \times \frac{Call\ Duration}{Call\ Duration\ (s) + Call\ IAT\ (s)}\ \\]
Example: Packet Size = 160 Bytes, Packet Inter Arrival Time = 20000 µs, Call Duration = 60 s, Call Inter Arrival Time = 60 s.
VBR Service, Deterministic
Example: Packet Size = 160 Bytes, Packet Inter Arrival Time = 20000 µs, Call Duration = 60 s, Call Inter Arrival Time = 60 s.
VBR Service, Markov chain
Example: Packet Size = 160 Bytes, Packet Inter Arrival Time = 20000 µs, Call Duration = 60 s, Call Inter Arrival Time = 60 s, Speech Activity Factor = 0.5.
Sensor
Example: Packet size = 50Bytes and Inter arrival time = 1000000µs.
Interactive Gaming Model
Uplink
Example: a = 45 B, b = 5.7B, Inter arrival time = 40ms. Then the mean packet size is given by
Since \(R = rand(0,\ 1)\), \(\mathbb{E}(R) = 0.5\) and hence,
And since interarrival time is 40ms, the mean generation rate is:
Downlink
Example: \(a\ = \ 120\ B,\ b\ = \ 36\ B,\ a\ (IAT) = \ 55ms,\ b\ (IAT)\ = \ 6ms.\ \)
The mean packet size is given by:
\(\mathbb{E}(x) = a - b \times ln( - ln\mathbb{(E}(R))\)
We know the \(\mathbb{E}(R) = 0.5\) and hence,
The mean Inter Arrival Time is given by:
The mean generation rate is:
Priority and QoS of Applications
The various application traffic generated in NetSim have the following priority and QoS values as shown below.
Application Type |
Priority Value |
Priority |
QoS Class |
|---|---|---|---|
Voice – One way Voice – Two way |
8 8 |
High High |
RTPS UGS |
Video |
6 |
Medium |
nRTPS |
Database |
2 |
Low |
BE |
Custom |
2 |
Low |
BE |
FTP |
2 |
Low |
BE |
2 |
Low |
BE |
|
HTTP |
2 |
Low |
BE |
Table-6: Priority and QoS of Applications
Note: Priority of “Normal” has a Priority Value of 4 and “nRTPS” QoS Class. Ex: Video over TCP.
Priority will have an impact on network performance when multiple applications with different priorities are configured in a network. These packets will be queued and dequeued from the router buffer based on the priority.
Capture real applications and simulate in NetSim
Users can capture packets from a live network using Wireshark. This can then be used as an input to NetSim as explained in Section 4 of the Emulator technology library user guide.
Modelling Poisson arrivals in NetSim
Any time you have events which occur individually at random moments, but which tend to occur at an average rate when viewed as a group, you have a Poisson process.
For example, we can estimate that a certain node generates 1200 packets per minute. These packets are randomly generated within a minute, but there are on average 1200 packets per minute. If 1200 packets generated per minute that, on average, one packet is generated every \(\frac{60}{1200} = 0.05\ s\). So, let’s define a variable \(\lambda = \frac{1}{0.05} = 20\ \)and call it the rate parameter. The rate parameter \(\lambda\) is a measure of frequency: the average rate of events (packets) per unit of time (in this case, seconds).
Knowing this, we can ask questions like, what is the probability that a packet will be generated within the next second? What’s the probability within the next 10 seconds? There’s a well-known function to answer such questions. It’s called the cumulative distribution function for the exponential distribution, and it looks like this:
Figure-3: Plot for cumulative distribution function for the exponential distribution
Basically, the more time passes, the more likely it is that a packet is generated. The word “exponential”, in this context, refers to exponential decay. As time passes, the probability of having no packets generated decays towards zero – and correspondingly, the probability of having at least one packet generated increases towards one.
Plugging in a few values, we find that:
The probability of generating a packet within the next 0.05 seconds is F (0.05) ≈ 0.63
The probability of generating a packet within 1 second is F (1) ≈ 0.999999998
In particular, note that after 0.05 seconds – the prescribed average time between packets – the probability is F (0.05) ≈ 0.63.
Generating Poisson arrivals in NetSim
We simply write a function to determine the exact amount of time until the next packet. This function should return random numbers, but not the uniform kind of random number produced by most generators. We want to generate random numbers in a way that follows our exponential distribution.
Given that the inverse of the exponential function is ln, it’s easy to write this analytically, where R is the random value between 0 and 1:
Where T is the time at which the next packet is generated.
The simple way of selecting this via the UI is to select exponential distribution for inter-arrival time inside application properties.
Application Configuration – Special Conditions
In a wired network with routers and switches OSPF, spanning tree etc. takes times to converge and hence it is a good practice to set the application start time greater than OSPF convergence time. In general, the applications can start at 20s for smaller networks and should be increased as the size of the network grows.
If applications are started before OSPF convergence, then.
Packets generated before OSPF table convergence may be dropped at the gateway router.
The application may also stop if ICMP is enabled in the router.’
If TCP is enabled TCP may stop after the re-try limit is reached (since the SYN packets would not reach the destination)
For MANET networks the application start time should be a min of 5s, since the amount of time is required for convergence of OLSR/ZRP.