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.

1. CBR

2. Custom

3. COAP

4. Database

5. FTP

6. Email

7. HTTP

8. PEER_TO_PEER

9. Video

10. Voice

11. Sensor App

12. Erlang Call

13. BSM

14. Emulation (available only if Emulator Add-on is licensed)

To set up the application click on the application icon from the tool bar as shown below Figure 6‑1.

Figure 6‑1: Application icon from the tool bar

Figure 6‑2: Application Configuration Window

This properties window allows you to model the application traffic. There may be more than one application you may require for your simulation study. You can add (or) delete one or more applications by clicking on the "+" or "-" symbols present on top left-hand side next to the Application.

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, COAP, 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'.

• For Multicast Applications, users can enter the number of > multicast destinations in the Destination Count filed and specify > the Device IDs of the destination devices separated by comma (",") > in the Destination ID field. E.g., 6, 7, 8

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 1^st^ second and stops at the 10^th^ 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.7 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 true, application will start at a random time between 0 and inter-arrival time. Having a random start-up time provides more realism to the model since all applications need not necessarily start at time = 0 in the real world.

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

Session Protocol: Session Protocol is applicable only for applications that support RTP (Real-time Transport Protocol)

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#

Brief explanation of application types as shown below Table 6‑2.

Application Type Properties Units Description
CBR – Constant bit Rate Packet size (Constant distribution) – It is the size of the packet 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 TimePacket 3: Packet 2 + Interarrival Time....Packet (n+1): Packet n + Interarrival TimeEnds at Application end time.
Inter Arrival Time (Constant distribution) – It is the gap between two successive packets µs
Custom Packet size (Constant, Exponential, Uniform and Normal distribution) – It is the size of the packet bytes It is user defined application where the packet size and inter-arrival time can be set per user requirements.
Inter Arrival Time (Constant, Exponential, Uniform and Normal distribution) – It is the time gap between two successive packets µs
Peer to Peer File size distribution (Constant, Exponential distribution)
Value – Size of the file bytes
Piece size - Each file is divided into equal sized pieces. This property represents the size of each piece bytes
Email Email send/receive Represents the rate at which emails are sent/receive - Email is a client-server configuration, not a source-destination confirmation. Both sides can send and receive.
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 confirmation. The client node sends a page request to the server, and the server responds with the pages (whose size is in bytes).
Page size (Constant, Exponential distribution) It is the size of each page bytes
Page count – Represents the number of pages
COAP – Constrained Application Protocol Inter Arrival Time (Constant, Exponential distribution) – It is the time b//w two successive COAP requests. seconds It is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks and designed for M2M applications.
Page size (Constant, Exponential distribution) – It is the size of each page.
bytes
Response time – It is the time taken by a device to generate response ms
Multicast response – Represents the server responds to multicast response or not -
NSTART – Limit the number of simultaneous outstanding interactions that a client maintains to a given server -
DEFAULT_LEISURE – This setting is only relevant in multicast scenarios, outside the scope of the EST-coaps draft -
PROBING_RATE: A parameter which specifies the rate of re-sending Non-confirmable messages. -
Ack required – It represents whether the ack for the request/response to be sent or not -
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.Ex – FileZillaThe generation times would be as follows:File 1: Application start time.File 2: File 1 + Interarrival TimeFile 3: File 2 + Interarrival Time....File (n+1): File n + Interarrival TimeEnds at Application end timeThe 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.Ex – 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.Ex – 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.Ex – 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 callNote – 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.Ex – 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.
Packet Inter Arrival Time (Constant, Uniform and Normal distribution) - It is the gap between two successful packets µs
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 6‑2: Brief explanation of 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.

### 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:

1. 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)

2. Video Codec Models: H.261, H.263, MPEG1 Low Res, MPEG1 High Res, MPEG2 Low Res, MPEG2 High Res

3. 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$

• $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 6‑3: 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.

$$f(x;\lambda,\ k) = \ \left{ \begin{matrix} \ \frac{k}{\lambda}\ \left( \frac{x}{\lambda} \right)^{k - 1}e^{- \left( \frac{x}{\lambda} \right)^{k}}\ x \geq 0 \ \ \ \ \ 0\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ x < 0\ \ \ \ \ \end{matrix} \right.\$$

• The parameters to use are specified in Table 6‑4.
Model_Type Avg bit rate λ k Frames per second (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 6‑4: Parameters for the Buffered video streaming models BV1 through BV6. $\mathbf{\lambda}$ 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 $\mathbf{\lambda,\ k}$ and $\mathbf{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

$$Generation\ Rate\ (Mbps) = \frac{Packet\ size\ (bytes)*\ 8}{InterArrivalTime(µs)}$$

Example: Packet size = 1460 Bytes and Inter arrival time = 20000 µs.

Generation rate (Mbps) = $\frac{1460 \times 8}{20000}$ = 0.584Mbps

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:

$$Generation\ Rate\ (bits\ per\ second) = \ fps \times ppf \times bpp$$

where, fps = frames per second

ppf = pixel per frame

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\ (Mps) = \ 20 \times 10000 \times 0.52\ = \ 104000\ bits\ per\ second\ = \ 0.1040\ Mbps$$

Voice

$$Generation\ Rate\ (Mbps) = \frac{Packet\ size\ (bytes) \times 8}{InterArrivalTime(µs)}\$$

Note that the distribution type is constant (deterministic) for all codec types except custom.

Email

$$Generation\ Rate\ (Mbps) = \frac{Email\ size\ (bytes) \times 8}{Duration(\mu s)}$$

Example: Email size = 20000bytes, Duration = 1s.

$$Generation\ rate\ (Mbps) = \frac{20000*8}{1000000}\ = \ 0.16\ Mbps$$

HTTP

$$Generation\ Rate\ (Mbps) = \frac{Page\ size\ (bytes) \times 8 \times \ Page\ count}{InterArrivalTime(\mu s)}\$$

Example: Page size = 20000 Bytes, Page Count = 2, Inter arrival time = 3s

$$Generation\ rate\ (Mbps) = \frac{20000 \times 8 \times 2}{3000000}\ = \ 0.106\ Mbps$$

FTP

$$Generation\ Rate\ (Mbps) = \frac{File\ size\ (bytes) \times 8}{InterArrivalTime(s)}$$

Example: File size = 100000 Bytes, Inter arrival time = 5s

$$Generation\ rate\ (Mbps) = \frac{100000 \times 8}{5}\ = \ 0.16\ Mbps$$

Database

$$Generation\ Rate\ (Mbps) = \frac{Packet\ size\ (bytes) \times \ 8}{InterArrivalTime(µs)}$$

Example: Packet size = 10000 Bytes, Inter arrival time = 1000000µs

$$Generation\ rate\ (Mbps) = \frac{(10000 \times 8)}{1000000}\ \ = \ 0.08\ Mbps$$

BSM

$$Generation\ Rate\ (Mbps) = \frac{Packet\ size\ (bytes) \times \ 8}{InterArrivalTime(µs)}$$

Example: Packet size = 20Bytes and Inter arrival time = 1000000µs.

$$Generation\ rate\ (Mbps) = \frac{20 \times 8}{1000000}\ = \ 0.00016\ Mbps\$$

Sensor

$$Generation\ Rate\ (Mbps) = \frac{Packet\ size\ (bytes) \times \ 8}{InterArrivalTime(µs)}$$

Example: Packet size = 50Bytes and Inter arrival time = 1000000µs.

$$Generation\ rate\ (Mbps) = \frac{50 \times 8}{1000000}\ = \ 0.0004\ Mbps$$

## 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 8 High RTPS
Voice – Two way 8 High UGS
Video 6 Medium nRTPS
FTP 2 Low BE
Database 2 Low BE
Custom 2 Low BE
Video 6 Medium nRTPS
FTP 2 Low BE
Database 2 Low BE

Table 6‑5: 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:

$$\ F(x) = 1 - e^{- \lambda x}$$

Figure 6‑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:

$$T = \ - \log_{e}\frac{1 - R}{\lambda}$$

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#

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

2. If applications are started before OSPF convergence, then.

3. Packets generated before OSPF table convergence may be dropped at the gateway router.

4. The application may also stop if ICMP is enabled in the router.'

5. If TCP is enabled TCP may stop after the re-try limit is reached (since the SYN packets would not reach the destination)

6. For MANET networks the application start time should be a min of 5s, since that amount of time is required for convergence of OLSR/ZRP.