Model Features

Ad hoc On Demand Distance Vector Routing

The Ad Hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multi-hop routing between participating mobile nodes wishing to establish and maintain an ad hoc network. AODV allows mobile nodes to respond to link breakages and changes in network topology in a timely manner. When links break, AODV causes the affected set of nodes to be notified so that they can invalidate the routes using the lost link. AODV in NetSim can run in layer 3 over MAC/PHY protocols such as 802.11, 802.15.4, TDMA and DTDMA.

The features of AODV implemented in NetSim are:

Broadcast Route Discovery Mechanism, and Route Maintenance: AODV accomplishes this with the help of RREQ and RREP. The packet trace file in NetSim helps to view and understand how AODV accomplishes this mechanism using RREQ and RREP packets.

Timer - based states: Routing table states expire when the route remains inactive for a certain period of time. This is established by the use of the lifetime field in the routing table and RREP packets. The lifetime field can be observed in Wireshark under the AODV RREP packets.

Sequence numbers: The source sequence number is a monotonically increasing number maintained by each source node. It is used by other nodes to determine whether the information contained in the packet sent by the source node is new. The destination sequence number is created by destination and includes it with the routing information sent to the requesting nodes. Usage of destination sequence number ensures loop freedom. The route with the greatest sequence number is used by requesting nodes to reach their destination. This also prevents routing loops and avoids using inactive or old routes. The source and destination sequence numbers can be viewed in Wireshark under the RREQ and RREP packets in AODV protocols. Some important fields of the RREQ format that can be viewed in NetSim using Wireshark are mentioned below Table-1.

Hop Count	The number of hops from the Originator IP Address to the node handling the request.
Destination IP Address	The IP address of the destination for which a route is desired.
Destination Sequence Number	The latest sequence number received in the past by the originator for any route towards the destination.
Originator IP Address	The IP address of the node which originated the Route Request.
Originator Sequence Number	The current sequence number to be used in the route entry pointing toward the originator node.

Table-1: Important fields of the RREQ format viewed in NetSim using Wireshark

Some important fields of the RREP format that can be viewed in NetSim using Wireshark are mentioned below Table-2.

Hop count	The number of hops from the Originator IP Address to the Destination IP Address.
Destination IP Address	The IP address of the destination for which a route is supplied.
Destination Sequence Number	The destination sequence number associated to the route
Originator IP Address	The IP address of the node which sends the RREQ.
Lifetime	The time in milliseconds for which nodes receiving the RREP consider the route to be valid.

Table-2: Important fields of the RREP format viewed in NetSim using Wireshark

Dynamic Source Routing (DSR)

The Dynamic Source Routing (DSR) protocol is a simple and efficient routing protocol designed specifically for multi-hop wireless ad hoc networks of mobile nodes. Using DSR, the network is completely self-organizing and self-configuring, requiring no existing network infrastructure or administration.

Network nodes cooperate to forward packets for each other, enabling communication over multiple "hops" between nodes that are not directly within wireless transmission range of one another. As nodes move, join, or leave the network, and as wireless transmission conditions (e.g., interference sources) change, all routing is automatically determined and maintained by the DSR protocol.

Since the number or sequence of intermediate hops needed to reach any destination may change at any time, the resulting network topology can be dynamic and rapidly evolving.

In NetSim, DSR operates at Layer 3 over MAC/PHY protocols such as 802.11, 802.15.4, TDMA, and DTDM

Using Link-Layer Acknowledgements

If the MAC protocol in use provides feedback as to the successful delivery of a data packet (such as is provided for unicast packets by the link-layer acknowledgement frame defined by IEEE 802.11), then the use of the DSR Acknowledgement Request and Acknowledgement options is not necessary. If such link-layer feedback is available, it should be used instead of any other acknowledgement mechanism for Route Maintenance, and the node should not use either passive acknowledgements or network-layer acknowledgements for Route Maintenance.

When using link-layer acknowledgements for Route Maintenance, the retransmission timing and the timing at which retransmission attempts are scheduled are generally controlled by the particular link layer implementation in use in the network. For example, in IEEE 802.11, the link-layer acknowledgement is returned after a unicast packet as a part of the basic access method of the IEEE 802.11 Distributed Coordination Function (DCF) MAC protocol; the time at which the acknowledgement is expected to arrive and the time at which the next retransmission attempt (if necessary) will occur are controlled by the MAC protocol implementation.

Using Network-Layer Acknowledgements

When a node originates or forwards a packet and has no other mechanism of acknowledgement available to determine reachability of the next-hop node in the source route for Route Maintenance, that node should request a network-layer acknowledgement from that next-hop node. To do so, the node inserts an Acknowledgement Request option in the DSR Options Header in the packet. The Identification field in that Acknowledgement Request option must be set to a unique value over all packets recently transmitted by this node to the same next-hop node.

When using network-layer acknowledgements for Route Maintenance, a node should use an adaptive algorithm in determining the retransmission timeout for each transmission attempt of an acknowledgement request. For example, a node should maintain a separate round-trip time (RTT) estimate for each node to which it has recently attempted to transmit packets, and it should use this RTT estimate in setting the timeout for each retransmission attempt for Route Maintenance.

While simulating certain network configurations, users may see that packets received are more than packets sent. This is because:

This is being measured as part of our UDP protocol metrics in layer 4 in the source and in the destination.
Let us say UDP protocol at source node A sends a datagram. At the MAC - WLAN sends the frame and starts a retransmission timer.
If no Ack is received within this timer period, it would initiate a re-transmission (consider cases where the WLAN Ack has a collision or is errored).
As the destination, the MAC (WLAN) layer would send up to UDP both the first packet it received and the re-transmitted packet it received.
UDP protocol in the destination would count both the packets received.

Figure-1: Application Configuration window

Why do we see continuous RREQ and RREP packets in DSR?

When the Data packet is to be transmitted, in DSR, within the NETWORK OUT Event, the DSR-packet-processing function is called. This initiates Route discovery, if no route to destination exists. Once discovery is complete, DSR switches to Route maintenance mode.

Route Maintenance is the mechanism by which a source node S is able to detect, while using a source route to some destination node D, if the network topology has changed such that it can no longer use its route to D because a link along the route no longer works.

In Route Maintenance mode, DSR checks for ACKs for every data packet sent. If the ACK for a data packet is not received within a specified time (as defined by the Maintenance Time Out) then Route Error (RERR) gets triggered. This trigger leads to removal of Route entries from the Route Cache thereby causing Route discovery to be initiated again.

A typical simulation scenario where Route discovery, Router error, Router Error cycle is repeated, is when the network has multiple applications generating data packets at the exact same time. This can cause packet collisions in the MAC layer. Since no packet is received no ACK is sent. The non-receipt of ACK within the specified time causes RERR to get triggered.

AODV/DSR Metrics

AODV or DSR Metrics table will be part of the results dashboard if routing protocol in the network layer is set to either AODV or DSR in at least one device in the simulated network scenario.

Parameter	Description
Device Id	It is the unique ID of the wireless node
RREQ sent	It is the number of Route Request packets sent by wireless node during Route Discovery process
RREQ forwarded	It is the number of Route Request packets forwarded by wireless node during Route Discovery process
RREP sent	It is the number of Route Reply packets sent by wireless node when route is found during Route Discovery process
RREP forwarded	It is the number of Route Reply packets forwarded by a wireless node when route is found during Route Discovery process
RERR sent	It is the total number of Route Error packets sent by a wireless node during Route Maintenance
RERR forwarded	It is the total number of Route Error packets forwarded by a wireless node during Route Maintenance
Packet originated	It is the total number of packets originated in a source node
Packet transmitted	It is the total number of packets transmitted by a source node and intermediate device (LoWPAN Gateway or sink node)
Packet dropped	It is the total number of packets dropped by a wireless node

Table-3: Parameter Description for AODV/DSR Metrics table

Zone Routing Protocol (ZRP)

The ZRP is based on two procedures:

Intrazone Routing Protocol (IARP) and
Interzone Routing Protocol (IERP).

Through the use of the IARP, each node learns the identity of and the (minimal) distance to all the nodes in its routing zone. The actual IARP is not specified and can include any number of protocols, such as the derivatives of Distance Vector Protocol (e.g., Ad Hoc On-Demand Distance Vector, Shortest Path First (e.g., OSPF). In fact, different portions of an ad hoc network may choose to operate based on different choices of the IARP protocol. Whatever the choice of IARP is, the protocol needs to be modified to ensure that the scope of this operation is restricted to the zone of the node in question.

Note that as each node needs to learn the distances to the nodes within its zone only, the nodes are updated about topological changes only within their routing zone. Consequently, in spite of the fact that a network can be quite large, the updates are only locally propagated.

IERP

While IARP finds routes within a zone, IERP is responsible for finding routes between nodes located at distances larger than the zone radius. IERP relies on border casting. Border casting is possible as any node knows the identity and the distance to all the nodes in its routing zone by the virtue of the IARP protocol.

The IERP operates as follows: The source node first checks whether the destination is within its routing zone. (Again, this is possible as every node knows the content of its zone). If so, the path to the destination is known and no further route discovery processing is required. If, on the other hand, the destination is not within the source's routing zone, the source border casts a route request (referred to here as a "request") to all its peripheral nodes. Now, in turn, all the peripheral nodes execute the same algorithm: check whether the destination is within their zone. If so, a route reply (referred to here as a "reply") is sent back to the source indicating the route to the destination. If not, the peripheral node forwards the query to its peripheral nodes, which, in turn, execute the same procedure. An example of this Route Discovery procedure is demonstrated in the figure below Figure-2.

Figure-2: Interzone Routing Protocol Discovery procedure

Node A has a datagram to node L. Assume routing zone radius of 2. Since L is not in A's routing zone (which includes B, C, D, E, F, G), A border cast a routing request to its peripheral nodes: D, F, E, and G. Each one of these peripheral nodes check whether L exists in their routing zones. Since L is not found in any routing zones of these nodes, the nodes border cast the request to their peripheral nodes. In particular, G border casts to K, which realizes that L is in its routing zone and returns the requested route (L-K-G-A) to the query source, namely A.

IARP

In Zone Routing, the Intra zone Routing Protocol (IARP) proactively maintains routes to destinations within a local neighborhood, which we refer to as a routing zone. More precisely, a node's routing zone is defined as a collection of nodes whose minimum distance in hops from the node in question is no greater than a parameter referred to as the zone radius. Note that each node maintains its own routing zone. An important consequence is that the routing zones of neighboring nodes overlap.

An example of a routing zone (for node A) of radius 2 is shown below Figure-3.

Figure-3: Intra zone Routing Protocol Discovery procedure

In this example, nodes B through F are within the routing zone of node A, while node G is outside node A's routing zone. Node E can be reached via two paths from A: one with a length of 2 hops and the other with a length of 3 hops. Since the minimum hop count is less than or equal to 2, E is included in A's routing zone.

Peripheral Nodes are nodes whose minimum distance to a given node is exactly equal to the zone radius. Thus, in the example above, nodes D, F, and E are the peripheral nodes of node A.

To construct a routing zone, a node must first identify its neighbors. A neighbor is a node with which direct (point-to-point) communication can be established and is, therefore, one hop away. Neighbor identification can be provided by MAC protocols, such as in polling-based protocols, or by a separate Neighbor Discovery Protocol (NDP).

Neighbor discovery typically involves the periodic broadcasting of "HELLO" beacons. The reception (or quality of reception) of these beacons is used to determine the status of the connection to the beaconing neighbor.

This neighbor discovery information forms the basis of the Intra zone Routing Protocol (IARP). IARP can be derived from globally proactive link-state routing protocols that offer a complete view of network connectivity.

Optimized Link State Routing Protocol (OLSR)

OLSR is developed for mobile ad hoc networks. It operates as a table driven, proactive protocol, i.e., exchanges topology information with other nodes of the network regularly. Each node selects a set of its neighbor nodes as "multipoint relays" (MPR). In OLSR, only nodes, selected as such MPRs, are responsible for forwarding control traffic, intended for diffusion into the entire network. MPRs provide an efficient mechanism for flooding control traffic by reducing the number of transmissions required.

Nodes selected as MPRs also have a special responsibility for declaring link state information in the network. Indeed, the only requirement for OLSR to provide shortest path routes to all destinations is that MPR nodes declare link-state information for their MPR selectors. Additional available link-state information may be utilized, e.g., for redundancy.

Nodes which have been selected as multipoint relays by some neighbor node(s) announce this information periodically in their control messages. This allows a node to announce the network that it has reachability to the nodes which have selected it as an MPR. In route calculation, MPRs are used to form the route from a given node to any destination in the network. Furthermore, the protocol uses the MPRs to facilitate efficient flooding of control messages in the network.

One Hop neighbor

Node X is considered a neighbor of node Y when node Y is within communication range of node X, meaning there is an established link between OLSR interfaces on both nodes that enables direct communication.

Two Hop neighbor

A 2-hop neighbor of node X is a node that is not directly connected to X, but is connected to one of X's direct neighbors.

Multipoint Relays (MPR)

Multipoint Relays (MPRs) are a smart technique used to reduce the number of broadcast messages in a wireless network. Normally, when a node sends out a broadcast message (like link information), all its neighbors may forward it again, which creates a lot of unnecessary traffic and wastes bandwidth. MPRs solve this by selecting only a few special neighbors to forward those messages.

Each node chooses some of its 1-hop neighbors as its MPRs. These MPRs are chosen in such a way that they can reach all the 2-hop neighbors. This means only a less number of nodes need to retransmit the message to spread it across the network.

The chosen MPR nodes will forward broadcast messages from that node.
The rest of the neighbors receive the message but do not retransmit it.
This reduces the number of duplicate messages in the network and saves battery and bandwidth.

Also, each node keeps track of which neighbors have selected it as their MPR, using the HELLO messages that are exchanged regularly.

Topology discovery

The link-sensing and neighbor-detection parts of the protocol provide each node with a list of neighbors it can directly communicate with. Combined with the Packet Format and Forwarding part, this enables an optimized flooding mechanism through MPRs. Using this, topology information is disseminated throughout the network.

TC Message Format

Figure-4: TC Message Format

The TC message consists of the following fields:

ANSN (Advertised Neighbor Sequence Number):

A 16-bit field used to indicate the freshness of the TC information.

Reserved:

A 16-bit field reserved for future use; always set to 0.

Advertised Neighbor Main Addresses:

These are one or more addresses of the neighboring nodes that the sender can reach and wants to inform others about. Usually, these are the nodes that have selected the sender as their MPR.

Core Functionality of OLSR

OLSR's core working is made up of several key parts:

Packet Format and Forwarding

All control messages (like HELLO, TC, etc.) follow a common packet format.

Figure-5: Packet Format

OLSR uses a smart way to flood (send to all nodes) control messages across the network using a technique called MPR (MultiPoint Relay) to reduce unnecessary retransmissions.

Link Sensing

Each node sends HELLO messages at regular intervals through its network interfaces.
These messages help a node detect which of its neighbors are reachable (link sensing).
This creates a local link set—a list of links to neighboring nodes.

Neighbor detection

Neighbor detection populates the neighborhood information base and concerns itself with nodes and node main addresses. The mechanism for neighbor detection is the periodic exchange of HELLO messages.

A node maintains a set of neighbor tuples based on the link tuples. This information is updated according to changes in the Link Set. The Link Set keeps the information about the links, while the Neighbor Set keeps the information about the neighbors. There is a clear association between those two sets, since a node is a neighbor of another node if and only if there is at least one link between the two nodes.

The "Originator Address" of a HELLO message is the main address of the node that emitted the message. Upon receiving a HELLO message, a node should first update its Link Set and then update its Neighbor Set.

MPR Selection

Each node selects a few special neighbors called MPRs (MultiPoint Relays).
These MPRs are chosen in such a way that if they forward a message, it will reach all 2-hop neighbors (neighbors of neighbors).
This reduces the number of transmissions during flooding.
Nodes advertise their selected MPRs in their HELLO messages.

TC message

In order to build the topology information base, each node, which has been selected as MPR, broadcasts Topology Control (TC) messages. TC messages are flooded to all nodes in the network and take advantage of MPRs. MPRs enable a better scalability in the distribution of topology information.

The list of addresses can be partial in each TC message (e.g., due to message size limitations, imposed by the network), but parsing of all TC messages describing the advertised link set of a node MUST be complete within a certain refreshing period (TC INTERVAL). The information diffused in the network by these TC messages will help each node calculate its routing table.

When the advertised link set of a node becomes empty, this node SHOULD still send (empty) TC-messages during the duration equal to the "validity time" (typically, this will be equal to TOP HOLD TIME) of its previously emitted TC-messages, in order to invalidate the previous TC-messages. It SHOULD then stop sending TC-messages until some node is inserted in its advertised link set.

A node MAY transmit additional TC-messages to increase its reactiveness to link failures. When a change to the MPR selector set is detected and this change can be attributed to a link failure, a TC-message SHOULD be transmitted after an interval shorter than TC INTERVAL.

Route Calculation

After collecting enough link information through HELLO and TC messages, each node calculates the best route to all other nodes.
This is usually done using shortest-path algorithms like Dijkstra which finds the minimum-cost path from the source node to all other nodes based on the link metrics (e.g., hop count, ETX).

Energy model in MANETs

A Mobile Ad-hoc Network (MANET) consists of self-organizing wireless mobile nodes deployed without a centralized infrastructure. Nodes communicate with each other using a limited battery supply. NetSim supports DSR, AODV, ZRP, and OLSR as the network layer protocols, considering transmission power and residual battery power. This work aims to increase the network lifetime while reducing energy consumption and minimizing end-to-end delay.

Energy is a very important part in ad-hoc networks because all nodes in this network communicate with each other, consuming power in the process. The primary source of power is the battery of the mobile node. A node consumes energy in various modes, including sending/transmitting mode, receiving mode, and idle mode.

Transmitting mode: In this Tx mode, the node consumes energy to transfer packets or data. The amount of energy consumed in this mode depends on the number of packets sent by the node, greater the number of packets, the more energy is consumed.

Receiving mode: In the Rx mode, In this mode, the node actively listens for incoming data, consuming energy as it receives data from the sender.

Idle mode: In idle mode, a node neither transmits or receives data packets. However, it still needs to listen to the wireless medium for potential packet reception and check for the addition of any new nodes to the network. As a result, the energy consumed in idle mode is less than that consumed in transmitting or receiving mode, since no actual communication occurs during idle mode.

In NetSim, default energy model settings are as follows [2]:

Transmitting current (mA): 316.7
Receiving current (mA): 261.1
Idle mode current (mA): 227
Voltage (V): 3.6

The power model is disabled by default, it can be enabled in physical layer of wireless node Omni Ant.

Click on wireless nodes properties and then will open a right side property panel to Interface 1(Wireless) > Physical layer.

Figure-6: Power Model in MANET.

Mobility models in NetSim

The change in position of a user over time can be configured using mobility models. Such models are frequently used in simulation to evaluate the performance of mobile wireless systems. The mobility models available in NetSim are:

Random Walk Mobility Model

This is a simple mobility model based on random directions and speeds. In this mobility model, a mobile node moves from its current location to a new location by randomly choosing a direction. The speed can be set in the GUI. The calculation interval determines how often a new choice is made. For e.g., a 1s calculation interval means that a new position is chosen every 1s.

Random Waypoint Mobility Model

This model includes pause time between changes in direction and/or speed. A mobile node begins by staying in one location for a certain period of time (i.e., a pause time). Once this time expires, the mobile node chooses a random destination in the simulation area. The mobile node then travels toward the newly chosen destination at the selected speed. Upon arrival, the mobile node pauses for a specified PauseTime before starting the process again. Note that the movement calculation is done every Calculation Interval. Therefore, it is recommended to set the PauseTime as an integral multiple of Calculation Interval.

Group Mobility Model

This model describes the behavior of mobile nodes as they move together i.e. the devices having common group id will move together.

Pedestrian Mobility Model

This model is applicable to each node (local parameter), and the configuration parameters are:

Pedestrian Max Speed (m/s) (Range: 0.0 to 10.0. Default: 3.0)
Pedestrian Min Speed (m/s) (Range: 0.0 to 10.0. Default: 1.0)
Pedestrian stop probability (Range: 0 to 1)
Pedestrian stop duration (s). (Range: 1 to 10000)

In this model it is assumed that the pedestrian stops at traffic lights. The stop probability represents the probability of encountering a traffic light. This is checked for every calculation interval. Once stopped, the pedestrian waits for a duration equal to stop duration for the light to turn green. A new direction is chosen randomly after every stop with$\ \theta\ $ (angle between new direction and current direction) taking values of 0, 90, 180, 270. These $\theta$ values represent the pedestrians continuing in the same direction, taking a left, taking a U turn and taking a right respectively.

A new speed is chosen randomly after event stop. $Min\ speed \leq \ Speed\ \leq Max\ speed$

The maximum number of stops and starts is 10.

File Based Mobility Model

In the File Based Mobility model, users can write their own custom mobility models and define the movement of the mobile users. The content should be per the NetSim Mobility File Format explained below. Users can also generate the mobility files using external tools like SUMO (Simulation of Urban Mobility), VanetMobiSim etc.

The NetSim Mobility File setting and format is explained below:

Step 1: Right click to open Properties as a new window of Wireless Node (MANET) or UE (LTE Networks). Then properties > Position Properties > Mobility model as File Based Mobility and click on Open Mobility file.

Step 2: Inside the csv file and write the node mobility in format shown below.

<TIME IN SECONDS>,<DEVICE ID>,X,Y,Z

Figure-7: Mobility.csv file with inputs added via MS Excel

When using spreadsheet software commas (,) are included automatically between the entries in each column. When using text editors such as notepad, users will have to manually include comma (,) between each entry.

Figure-8: Mobility.csv file with comma separated inputs added via text editor (notepad)

To write comments, use # tag
Specify the new location of the specific device at the specific time

Simulations with older input format in mobility.txt file (as shown below) will continue to be supported, in the absence of mobility.csv file.

$time <Time in seconds> "$node_(<NodeID - 1>) <X Coordinate> <Y Coordinate> <Z Coordinate>"

Example: $time 1 "$node_(0) 400 400 0"

A sample file-based mobility example is present at <NetSim Installed Directory> DocsSample ConfigurationMANET.

It can have the coordinates of one node over time, followed by the coordinates of the next node over time and so on. However, for a given device, the entries in the file need to be in increasing order of time.

NetSim does not interpolate device mobility between two entries in the mobility file. This means that during the simulation the device “jumps” to the next point at that instant in time. Mobility is not “continuous” from one point to another over time. Continuous or fine-grained mobility can, however, be approximated by reducing the time interval between successive entries. Since Excel-based mobility files are supported, generating such fine-grained traces is straightforward

Omni and sector (directional) antennas

NetSim MANET supports Omni and sector antennas. These antenna patterns are defined by gain values that vary as a function of direction in three dimensions. Thus, a transmitter’s antenna provides a gain value with respect to every other point in space. The same is true of a receiver’s antenna. For a given transmission, the gains of both the transmitter and receiver, with respect to each other, are considered.

Omni directional antennas have an isotropic pattern i.e., the gain in all directions is 0 dB. This makes them well-suited for scenarios where uniform coverage is required in all directions.

Sector antennas are modeled per the standard 2D parabolic antenna. The key characteristic of a sector antenna is its horizontal radiation pattern, which is designed to focus the signal in a specific direction. This directional pattern allows for targeted coverage, making sector antennas ideal for applications that require directed communication over a particular sector of space. The horizontal radiation pattern of a sector antenna is given by

\[A_{E,H}(\varphi) = - \min\left\lbrack 12\left( \frac{\varphi}{\varphi_{3dB}} \right)^{2},A_{m} \right\rbrack\]

where,

$A_{m}$is the front to back ratio (i.e., the ratio of power gained between the front and rear of a directional antenna). This is a user input with a default setting is 30 dB.
$\varphi$ is the angle formed between the direction of interest (i.e., the line connecting the transmitter and the receiver) and the antenna's boresight direction (azimuth angle).
$\varphi_{3dB}$ is the 3 dB, or half power, beam width of the antenna.

The sector antenna gain is given by the expression.

\[A_{E}(\varphi,\theta) = G_{E,\ \max} - \ \min\left\{ - \left\lbrack A_{E,H}(\varphi) + A_{E,V}(\theta) \right\rbrack,A_{m} \right\}\]

where,

$A_{E,V}(\theta)$ is currently 0 dB, and is a parameter reserved for future use to include the vertical radiation pattern of the antenna, and
$G_{E,\ \max}\ $is the maximum directional gain of the radiation element (in dB) i.e., the gain along the antenna boresight; this parameter is a user input, and the default value is 8 dBi.

The boresight angle denotes the azimuthal direction of maximum gain, or the highest radiated power, and is a user input. This can vary from 0 to 360 degrees.

Angle in NetSim is defined to start at 0 from the positive X-axis. In the network scenario, if positive Y points downward, the angle increases on clockwise rotation from the positive X-axis. If positive Y points upward, the angle increases in an anti-clockwise direction from the positive X-axis. The unit for angle is degrees.

The gain computations for a transmitter-receiver pair are given below.

Figure-9: The illustration shows a transmitter at x₁, y₁ and a receiver at x₂, y₂. The green lines represent the boresight azimuth direction of each antenna. The blue line is the line joining the transmitter and the receiver. φ_tx (and φ_rx) are the angles formed between the line connecting the transmitter and the receiver and the transmit antennas (and receive antennas respectively) boresight direction.

Let the transmitter be a $X_{1},Y_{1}$ and the receiver at $X_{2},Y_{2}$. Let $\phi_{T_{X}}^{boresight}$ and $\phi_{R_{X}}^{boresight}$ be the boresight azimuth angles of the transmitter and the receiver configured by the user through the GUI.

We know that,

\[\theta_{T_{X} - R_{X}} = \tan^{- 1}\left( \frac{y_{2} - y_{1}}{x_{2} - x_{1}} \right)\]

and clearly,

\[\theta_{R_{X} - T_{X}} = \pi + \theta_{T_{X} - R_{X}}\]

\[\phi_{T_{X}} = \phi_{T_{X}}^{boresight} - \ \theta_{T_{X} - R_{X}}\]

\[\phi_{R_{X}} = \phi_{R_{X}}^{boresight} - \theta_{R_{X} - T_{X}}\]

The sign of $\phi_{T_{X}}$ or $\phi_{R_{X}}$ doesn’t matter since the square of the term is used in the gain calculations.

\[A_{T_{X}}(\phi) = - \min\left\lbrack 12\left( \frac{\ \phi_{T_{X}}}{\phi_{3dB}} \right)^{2},\ Am \right\rbrack\]

\[A_{T_{X}}(\phi) = - \min\left\lbrack 12\left( \frac{\ \phi_{R_{X}}}{\phi_{3dB}} \right)^{2},\ Am \right\rbrack\]

\[T_{X}\ Gain = G_{E,\ \max} - \min\left\lbrack - \left( A_{T_{X}}(\phi) \right),Am \right\rbrack\]

\[Rx\ Gain = G_{E,\ max} - min\left\lbrack - \left( A_{R_{X}}(\phi) \right),Am \right\rbrack\]

Enabling the radio measurements log allows for the visualization of transmit and receive antenna gains for each transmission.

Limitations

The vertical radiation pattern is not currently supported. Hence the horizontal radiation pattern is assumed to be valid for all values of the coordinate $z$.

How are packet collisions modelled in NetSim?

Packet Collision is a theoretical concept. In the real world, a packet is not a "physical" entity that can collide. Therefore, a "collision" is the interference of two radio waves (of the packets being sent).

In NetSim the collision model is as follows:

At the transmitter, when a packet is being transmitted, if the sum of received power from all other nodes is greater than the receiver sensitivity then that packet is marked as collided.

At the receiver, when a packet is being received, if the sum of the received power from all other nodes, except the node from where this packet is being transmitted, is greater than the receiver sensitivity then that packet is marked as collided.

There is also a special case where a single packet can be marked as collided as explained in Figure-10.

Figure-10: Packet collisions modelled.
Where,

T1 and T2 are transmitters.

R1 and R2 are receivers.

How is packet error decided in NetSim

The way the packet error is decided is given as follows:

The way the packet error is decided is given as follows:

Compute Rx power at the receiver based on Tx Power, fewer losses due to Propagation. Propagation models cover HATA Urban, Sub Urban, COST 231 HATA, Indoor Home / Office, Factory, Lognormal, Free space. Apart from path loss, fading and shadowing can also be modeled.

Rx Power / (Background Noise + Interference noise) = SINR. Here Interference noise is due to other transmissions within the network.

Based on the SINR, BER is got from the respective modulation curve/table.

Based on the BER, the packet error rate is decided

NetSim does not perform bitwise simulation since it would be too computationally intensive.

Broadcast in MANETs

In MANET, only neighbor (nodes within transmission range) broadcast is supported; multi-hop broadcast is not supported. This means that nodes that are 2-hops or more away will not receive the broadcast packets. The reason for not implementing a multi-hop broadcast is explained below.

The simplest form of broadcast in an ad hoc network is where a node transmits a broadcast packet, which is received by all neighboring nodes that are within transmission range. Upon receiving a broadcast packet, each node determines if it has transmitted the packet before. If not, then the packet is retransmitted. This process allows for a broadcast packet to be disseminated throughout the ad hoc network. The process terminates when all nodes have received and transmitted the packet being broadcast at least once.

This method of broadcasting is required given the dynamic nature of ad hoc networks, i.e., nodes move around, and neighbors may change as the broadcast is happening. Now, since all nodes participate in the broadcast, it causes flooding and hence suffers from the Broadcast Storm Problem. Flooding is extremely costly and leaves the network completely congested.

Special algorithms are required to alleviate the broadcast storm problem, and custom development is necessary to implement them.

Radio measurement log file and plots

NetSim IEEE 802.11 Radio Measurements log file records pathloss, shadowing loss, fading loss, received power, transmitted power, SNR, and BER. This log can be enabled by clicking on configure reports in top ribbon > Plots > Select IEEE 802.11 Radio Measurements log under Network Logs as shown below

Figure-11: Enabling the IEEE 802.11 Radio Measurements log
The IEEE802.11 Radio Measurements log.csv file will contain the following information:

Time in Milliseconds

Transmitter Name

Receiver Name

Distance between the Transmitter and the Receiver in meters

Packet ID

Packet Type

Control Packet Type

Transmitter Power in dBm

Pathloss in dB

Shadowing Loss in dB

Fading Loss in dB

Total Loss in dB

Transmitter Antenna Gain in dB

Receiver Antenna Gain in dB

Received Power in dBm

Interference in dBm

SNR in dB

SINR in dB

BER

NSS (Number of Spatial Streams

MCS Index

The log file can be accessed from the Simulations Results Window under the log as shown below.

Figure-12: Opening IEEE 802.11 Radio Measurements log from simulation results window

Figure-13: IEEE 802.11 Radio Measurements log file
NetSim plots

NetSim also provides energy and Wi-Fi radio measurement plots for MANET. Enabling the plots is explained in the section Enable Protocol Specific Logs. Here is the plot showing the transmit energy vs. time for an AODV scenario with five nodes.

Figure-14: Plot of Transmit Energy vs Time for MANET
The Wi-Fi Radio measurement plots are shown in featured example in Featured Examples section.