• MANETs

MANETs

---

Introduction#

In the NetSim’s Internetworks library Wireless nodes connect to an Access Point (AP) while in NetSim’s LTE and 5G libraries, the mobile nodes (UEs) connect to base stations (eNBs, gNBs). There is no such association between the wireless stations and any fixed infrastructure in MANETs.

A Mobile Ad hoc Network (MANET) is an autonomous system of mobile nodes. In such networks, information transport services are built over a set of arbitrarily located nodes, which are possibly mobile. Every node behaves both like a mobile host and as a wireless router. There are many obvious applications for such networks including emergency communications, vehicular communications, military applications, etc.

Such networks have dynamic (sometimes rapidly changing), random, multi-hop topologies which are composed of relatively bandwidth-constrained wireless links. MANETs must therefore support efficient operation in mobile wireless environments by incorporating routing functionality into mobile nodes. Note that, such multi-hop networks exploit spatial reuse; transmissions can occur simultaneously on links that are sufficiently separated in space.

In NetSim MANETs, data packets are sent between source-destination pairs by multi-hop relaying. The MANETs in NetSim may operate in isolation or may have bridge nodes to interface with other networks (wired networks, or even other MANETs).

NetSim MANET library supports the following protocols.

• Layer 3 Unicast Routing

• Dynamic Source Routing (DSR)

• Adhoc On demand Distance Vector Routing (AODV)

• Optimized Link state Routing (OLSR)

• Zone Routing Protocol (ZRP)

• MAC / PHY (interfaced from NetSim Internetworks library)

• 802.11 a, b, g, n, ac. p and e

NetSim MANETs component can be interfaced with:

• NetSim Component 6 (IOT) module to run 802.15.4 in MAC/PHY

• NetSim Component 9 (VANETs) module to run IEEE 1609 WAVE in MAC/PHY

• NetSim TDMA Radio Networks (Add on) to run TDMA/DTDMA in MAC/PHY

Figure 1‑1: A typical MANET Network scenario in NetSim. The topology shows multiple MANETs connected via a bridge node, and connected to an external network through a router

Figure 1‑2: The Result dashboard and Plot window shown in NetSim after completion of simulation

The digital communication system employed, the transmit power used, and the radio propagation characteristics of the environment determine the “links” in the network.

Performance analysis of wireless ad hoc networks is a challenging task because such analysis must take into account the interactions between the wireless physical layer, radio propagation, multiple access, random topology, routing, and the characteristics of the application that generates the traffic carried by the network. Therefore, unlike wired and fixed topology networks, understanding and optimizing the performance of MANETs is a difficult undertaking, owing to the complex interaction between the various “layers” of the network.

Simulation GUI#

In the Main menu select àNew SimulationàMobile Adhoc networks as shown Figure 2‑1.

Figure 2‑1: NetSim Home Screen

Fast Configuration#

Figure 2‑2: Fast Configuration window

Fast Config window allows users to define device placement strategies and conveniently model large network scenarios especially in network such as MANET, TDMA Radio Networks, WSN and IoT. The parameters associated with the Fast Config Window is explained below:

Grid length: It is the area of simulation environment. Users can change the length of the grid in the range of 50-1000000m.

Side length: It specifies the area in the grid environment within which the devices will be placed. Users can change the side length of the grid in the range of 50 - 1000000m.Side length should be multiple of 50. Side length should always be set to a value less than or equal to the Grid length.

Device Placement#

Automatic Placement#

• Uniform Placement: Devices will be placed uniformly with equal gap between the devices in area based on the side length. This requires users to specify the number of devices as square number. For Eg. 1, 4, 9, 16 etc.

• Random Placement: Devices will be placed randomly in the grid environment within the area based on side length.

• File Based Placement: In order to place devices in user defined locations file-based placement option can be used. The file has the following general format:

• \<DEVICE_NAME>,\<DEVICE_TYPE>,\<X_COORDINATE>,\<Y_COORDINATE>

Where,

DEVICE_NAME – is any name that will be assigned to the device.

DEVICE_TYPE – is the unique Device Identifier specific to each type of device in NetSim.

Following table provides the DEVICE_TYPE’s of all possible devices for networks with support for Device Fast Configuration:

NETWORK	DEVICE_TYPE
Manets	WIRELESSNODE BRIDGE_WIREDNODE BRIDGE_WIRELESSNODE WIREDNODE ROUTER L2_SWITCH
WSN	Sensors SinkNode
IOT	IOT_Sensors LOWPAN_Gateway WIREDNODE IOT_ROUTER ACCESSPOINT L2_SWITCH

Table 2‑1: Fast Configuration window support different networks

X_COORDINATE – the value of X coordinate of the device

Y_COORDINATE – the value of Y coordinate of the device

Eg: MANET_File_based_Placement.txt

Wireless_Node,WIRELESSNODE,100,150

Wireless_Node,WIRELESSNODE,150,100

Wireless_Node,WIRELESSNODE,100,100

Wireless_Node,WIRELESSNODE,50,50

Open NetSim, in the Main menu select New Simulation→Mobile Adhoc networks. Select File Based Placement option under Automatic Placement and give the path of the text file as shown below Figure 2‑3.

Figure 2‑3: Device placement Strategy to File based Placement

After giving the path, Click on OK will display the MANET network shown below, where all devices are placed as per the positions given in the text file as shown Figure 2‑4.

Figure 2‑4: Network Topology

Number of Devices: It is the total number of devices that is to be placed in the grid environment. It should be a square number in case of Uniform placement.

Manually Via Click and Drop#

Selecting this option will load an empty grid environment where users can add devices by clicking and dropping the devices as required.

Create Scenario#

Wireless Node#

A MANET consists of mobile platforms -- simply referred to as "wireless nodes" in NetSim --which are free to move about arbitrarily. They are IP addressable devices. Wireless Nodes in NetSim MANETs library act as both end-nodes as well as routers. These nodes make routing decisions using the IP fabric.

In NetSim MANETs, each node can have only one wireless interface.

Bridge Node#

Bridge Node acts as a bridge/interface/gateway between multiple MANETs. Packets from one MANET can be routed to another MANET via a Bridge Node as shown Figure 2‑5.

Figure 2‑5: Multiple MANET Connected via a Bridge Node

Each Bridge Node has 24 interfaces. When connecting bridge nodes to one another or to routers, care should be taken to ensure that the static routes are set. This is required since the bridge nodes do not run any routing protocol.

NetSim supports Wired and Wireless Bridge nodes as shown Figure 2‑6/Figure 2‑7.

Figure 2‑6: Two wired bridge nodes can be connected to each other using P2P wired links

Figure 2‑7: Two wireless bridge nodes can be connected to each other using P2P wireless links

A wired bridge node cannot be connected to a wireless bridge node and vice versa.

Adhoc Link#

At a given point in time, depending on the nodes' positions and their transmitter and receiver coverage patterns, transmission power levels and interference levels, a wireless connectivity in the form of a random, multihop graph or "ad hoc" network exists between the nodes. This ad hoc topology may change with time as the nodes move or adjust their transmission and reception parameters. Ad hoc links are used in NetSim to visually represent this connection of devices in an Ad hoc basis as shown in Figure 2‑8.

Figure 2‑8: Mobile Adhoc Network

Wireless links generally have significantly lower capacity than their hardwired counterparts. In addition, the realized throughput of wireless communications after accounting for the effects of multiple access, fading, noise, and interference conditions, etc. is often much less than a radio's maximum transmission rate.

Connecting Adhoc links is a two-step process.

• Click and drop the Adhoc link icon from the device panel.

• Click (select) the Adhoc link, from the ribbon (toolbar). Then click on a wireless node and on the dropped adhoc link icon (on grid). This will connect the wireless node to the adhoc link.

• The connection between wireless nodes and adhoc link (icon on grid) is not to be done using a wireless link but using an Adhoc link (in ribbon) itself.  

Single MANETs#

A sample single MANET scenario comprises of only wireless nodes without any bridge node. It would look as shown below Figure 2‑9.

Figure 2‑9: A Single MANET scenario

Multiple MANETs#

Multiple MANETs allows users to interconnect two or more MANETs using a bridge node. Select “Manually via Click and Drop” option in the Mobile Adhoc Networks fast config window as shown below and click on OK button as shown Figure 2‑10.

Figure 2‑10: Fast Configuration Window - Manually Via Click and Drop

Click and drop Wireless nodes, Adhoc links and Bridge Node onto the grid environment

Figure 2‑11: Multiple devices dropped on GUI

Click on Adhoc Link icon (in ribbon). Then click on adhoc link icon (in grid) and on Wireless node (in grid) to connect Adhoc link to Wireless Node. Similarly connect Wireless Nodes to Adhoc links to form two different MANET’s using Adhoc links. Further connect the two MANET’s using a bridge node as shown below Figure 2‑12.

Figure 2‑12: Multiple MANET Scenario

Multiple MANETs do not support DSR, OLSR and ZRP protocols which is available in single MANETs.

Set Node, Link and Application Properties#

Right click on the appropriate node or link and select Properties. Then modify the parameters according to the requirements.

• Global Properties: Certain properties are global in nature, i.e., changing properties in one node will automatically reflect in the others in that network.

• In case of MANET, in Wireless Node, Routing Protocol in Network Layer is global and all user editable properties in Datalink Layer, Physical Layer and Power are Local.

• The following are the main properties of wireless node in Datalink and Physical layers as shown Figure 2‑13/Figure 2‑14.

Figure 2‑13: Datalink layer properties window for wireless node

Figure 2‑14: Physical layer properties window for wireless node

Figure 2‑15: Battery Model for Wireless node

• Click on the Application icon present on the ribbon and set properties. Multiple applications can be generated by using “+” button in Application properties.

• Set the values according to requirement and click OK.

Figure 2‑16: Application icon and Configuration Window

Enable Packet Trace, Event Trace & Plots (Optional)#

Click Packet Trace / Event Trace icon in the tool bar and check Enable Packet Trace / Event Trace check box and click OK. To get detailed help, please refer sections 8.4 and 8.5 in User Manual. Select Plots icon for enabling Plots and click OK.

Figure 2‑17: Enable Packet Trace, Event Trace & Plots options on top ribbon

Run Simulation#

• Click on Run Simulation icon on the top toolbar

Figure 2‑18: Run Simulation option on top ribbon

• Set the Simulation Time and click on OK.

Figure 2‑19: Run Simulation window

Note on MANET implementation in NetSim:

• If user wants to implement HTTP application among Nodes, TCP must be enabled in Source Node as TCP is set to disable by default.

• OLSR is a proactive link-state routing protocol, which uses Hello and topology control (TC) messages to discover and then disseminate link state information throughout the mobile ad hoc network.

• Individual nodes use this topology information to compute next hop destinations for all nodes in the network using shortest hop forwarding paths. For topology control (TC) messages to disseminate throughout, it requires 5 or more seconds depending upon the network size. In general, it is (5.5 secs + Tx_Time * network size).

• Hence, when simulating OLSR in MANET the Application Start Time must be greater than 5s (preferably greater than 10s) because in OLSR Topology Control (TC) messages start at 5s. Once the TC messages are sent, some further time will be required for OLSR to find the route. This can be done by setting the “Start_Time” parameter in Application properties.

Model Features#

Adhoc On Demand Distance Vector Routing#

The Ad hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multihop 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 and the packet animation window in NetSim help 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 viewed 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 send by the source node is new. The destination sequence number is created by destination to be included with the routing information that it sends to the requesting nodes. Usage of destination sequence number ensures loop freedom. The route with the greatest sequence number is used by requesting node to reach destination. This also prevents routing loops and avoid 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 3‑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 3‑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 3‑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 send the RREQ.
Lifetime	The time in milliseconds for which nodes receiving the RREP consider the route to be valid.

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

Dynamic Source Routing (DSR)#

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in 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 to allow communication over multiple "hops" between nodes not directly within wireless transmission range of one another. As nodes in the network move about or join or leave the network, and as wireless transmission conditions such as sources of interference change, all routing is automatically determined and maintained by the DSR routing protocol. Since the number or sequence of intermediate hops needed to reach any destination may change at any time, the resulting network topology may be quite rich and rapidly changing. DSR in NetSim can run in layer 3 over MAC/PHY protocols such as 802.11, 802.15.4, TDMA and DTDMA.

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 value unique 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 send the frame and starts a re-transmission 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 3‑1: Application Configuration window

Who do we see continuous RREQ and RREP packets in DSR?#

When the Data packet are 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 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, Route discovery, Router Error cycle is repeated, is when the network has multiple applications generate 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 network scenario simulated.

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‑3: Parameter Description for AODV/DSR Metrics table

Zone Routing Protocol (ZRP)#

The ZRP is based on two procedures:

1. Intrazone Routing Protocol (IARP) and

2. 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 choice 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 3‑2.

Figure 3‑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 Intrazone 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‑3.

Figure 3‑3: Intrazone Routing Protocol Discovery procedure

Note that in this example nodes B through F are within the routing zone of A. Node G is outside A's routing zone. Also note that E can be reached by two paths from A, one with length 2 hops and one with length 3 hops. Since the minimum is less or equal than 2, E is within A's routing zone.

Peripheral nodes are nodes whose minimum distance to the node in question is equal exactly to the zone radius. Thus, in the above figure, nodes D, F, and E are A's peripheral nodes.

The construction of a routing zone requires a node to first know who its neighbors are. A neighbor is defined as a node with whom direct (point-to-point) communication can be established and is, thus, one hop away. Identification of a node's neighbors may be provided directly by the media access control (MAC) protocols, as in the case of polling-based protocols. In other cases, neighbor discovery may be implemented through a separate Neighbor Discovery Protocol (NDP). Such a protocol typically operates through the periodic broadcasting of "hello" beacons. The reception (or quality of reception) of a "hello" beacon can be used to indicate the status of a connection to the beaconing neighbor.

Neighbor discovery information is used as a basis for the IARP. IARP can be derived from globally proactive link state routing protocols that provide 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 when 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. Thereby a node announces to the network, that it has reachability to the nodes which have selected it as an MPR. In route calculation, the 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.

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, which has emitted the message. Upon receiving a HELLO message, a node SHOULD first update its Link Set and then update its Neighbor Set.

Topology discovery#

The link sensing and neighbor detection part of the protocol basically offers, to each node, a list of neighbors with which it can communicate directly and, in combination with the Packet Format and Forwarding part, an optimized flooding mechanism through MPRs. Based on this, topology information is disseminated through the network.

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.

Mobility models in NetSim#

Mobility models represent the movement of mobile user, and how their location, velocity and acceleration change over time. Such models are frequently used for simulation purposes when new communication or navigation techniques are investigated, or to evaluate the performance of mobile wireless systems and the algorithms and protocols at the basis of them.

The movement of all nodes in NetSim is logged in the Animation_Node_Movement.txt file (if animation is enabled). This file will get saved to the same folder where the experiment is saved. Upon examining the file one can note that the node movement calculations are done every Calculation_Interval.

The mobility models provided in NetSim are as follows:

Random Walk Mobility Model#

It 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 and speed in which to travel. The new speed and direction are both chosen from pre-defined ranges. Each movement in the Random Walk Mobility Model occurs in either a constant time interval or a constant distance traveled, at the end of which a new direction and speed are calculated.

Random Waypoint Mobility Model#

It 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 and a speed that is uniformly distributed between [minspeed, maxspeed]. 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#

It is a model which 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)

• Pedestrain_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 assume that the pedestrian stops at traffic lights. The stop_probability represents the probability of encountering a traffic light. This is checked for every Calcuation_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 θ  (angle between new direction and current direction) taking values of 0, 90, 180, 270. These θ values represent the pedestrian continuing in the same direction, taking a left, taking a U turn and taking a right respectively.

A new speed is chosen randomly after evert stop. Min_speed ≤ Speed ≤ Max_Speed

The maximum number of stops and starts is 10.

File Based Mobility Model#

In File Based Mobility, 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. The user can also generate the mobility files using external tools like SUMO (Simulation of Urban Mobility), Vanet MobiSim etc.

The NetSim Mobility File setting and format is explained below:

Step 1: Right click to open Properties of Wireless_Node (MANET) or UE (LTE Networks). Then properties > General Properties > select 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 3‑4: 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 3‑5: 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

For experiments with the 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>"

A sample file-based mobility experiment is present at \<NetSim Installed Directory> \Docs\ Sample_Configuration\ MANET.

It can have the co-ordinates of one node over time, followed by the co-ordinates 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. The mobility is not “continuous” from one point to another over time.

Visualizing node movement in NetSim Animator#

NetSim animator animates the flow of packets in the network along with device mobility if configured. Viewing of node movement in NetSim animator is impacted by:

• Time Units: movement is based on update interval which by default is set to 1 second in the UI. In case of file-based mobility, for example there are movement entries at 1.25 seconds and 1.5 seconds. However, the animator progresses time in the order of microseconds. This sometimes means that users would need to wait for a long time to view node movement.

• Application start time: It is generally set to 5s but can be set to other values. Packet generation will start only at the application start time.

• Grid size: If the grid size is set in thousands of meters whereas the movement of the devices is only in tens of meters then movement may not be visible even though it is happening.

• Relation between time set in mobility file and time set for simulation: In case of File Based Mobility where a movements file (mobility.txt) is provided as input to NetSim, if the mobility file contains entries beyond the simulation time, only those entries that lie within the simulation start and end time will be considered for the simulation and corresponding movement can be viewed in the animation. 

• Channel characteristics: If the devices communicating in the network aren't within the range of one another or if there is no successful data transmission in the network during the simulation, animation may not show any device movement. 

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

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

• 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, Friis 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 bit-wise simulation since it would be too computationally intensive.

Broadcast and Multicast in MANETs#

In MANET, only neighbor (nodes within transmission range) broadcast/multicast is supported; multi-hop broadcast/ multicast 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 multi-hop broadcast/multicast 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, its 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. Custom development will be required to implement them.

Featured Examples#

Sample configuration files for all networks are available in Examples Menu in NetSim Home Screen. These files provide examples on how NetSim can be used – the parameters that can be changed and the typical effect it has on performance.

AODV Routing #

Adhoc On Demand Distance Vector Routing (AODV) protocol defines 3 message types:

• Route Requests (RREQs) - RREQ messages are used to initiate the route-finding process.

• Route Replies (RREPs) - RREP messages are used to finalize the routes.

• Route Errors (RERRs) - RERR messages are used to notify the network of a link breakage in an active route.

The route discovery process involves ROUTE REQUEST (RREQ) and ROUTE REPLY (RREP) packets. The source node initiates the route discovery process using RREQ packets. The generated route request is forwarded to the neighbors of the source node and this process is repeated till it reaches the destination. On receiving a RREQ packet, an intermediate node with route to destination or the destination node generates a RREP containing the number of hops required to reach the destination. All intermediate nodes that participate in relaying this reply to the source node creates a forward route to destination.

RERR message processing is initiated when: – Node detects a link break for the next hop of an active route or receives a data packet destined for a node for which it has no (active) route.

Open NetSim and Select Examples->Mobile Adhoc Networks->MANET AODV then click on the tile in the middle panel to load the example as shown in below screenshot Figure 4‑1.

Figure 4‑1: List of scenarios for the example of MANET AODV

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑2

Figure 4‑2: Network set up for studying the MANET AODV

Network Settings#

Step 1: A network scenario is designed in NetSim GUI comprising of 5 Wireless Nodes and one ad-hoc link in the “Mobile Adhoc Network” Network Library.

Step 2: In the General Properties of Wireless Node 3, Wireshark Capture is set to Online.

Step 3: In the General Properties set mobility Model as NO MOBILITY for all devices present in GUI.

Step 4: The Medium Access Protocol was set to DCF in INTERFACE_1(WIRELESS)-> Datalink layer of all Wireless Nodes

Step 5: Channel characteristics are set as: Path loss only; Path loss model: Log Distance; Path loss exponent: 3.

Step 6: Set AODV routing protocol under network layer properties in all nodes.

Step 7: Packet Trace is enabled in the NetSim GUI, and hence we are able to track the route which the packets have chosen to reach the destination based on AODV. In NetSim GUI Plots are Enabled.

Step 8: Click on the Application icon present in the top ribbon/toolbar.

A CBR Application is generated from Wireless Node 1 i.e., Source to Wireless Node 2 i.e., Destination with Packet Size remaining 1460Bytes and Inter Arrival Time remaining 20000µs. Transport Protocol is set to UDP instead of TCP.

Step 9: Run simulation for 10 seconds.

Output: Packet traffic flow can be viewed from the Packet Animation Window as shown Figure 4‑3.

Figure 4‑3: Packet Animation window

• Source Node 1 initiates route discovery process using RREQ packets. The generated route request is broadcasted to the neighbours of the source node i.e. Node 3 and Node 4.

• Node 4 broadcasts the RREQ packet to its neighboring nodes i.e., Node 3, Node 1 since Node 4 does not have route to destination Node 2.

• Similarly, Node3 broadcasts the RREQ packet to Node 5 and Node 4.

• Node 5 broadcasts to Node 2 and Node 3.

• On receiving a RREQ packet, the Destination Node 2 generates a RREP packet and transmits to Node 5, Node 5->Node 3, Node 3->Node 4, and Node 4->Node 1.

• After receiving the RREP, the Source Node 1 starts sending Data packets to Node 2.

The same process can be observed in Packet trace file by filtering Control_Packet_Type/Application_Name to AODV_RREQ and AODV_RREP as shown below Figure 4‑4.

Figure 4‑4: AODV different control packet in Packet trace

Open Wireshark, filter AODV packets and select the RREQ packets and expand Ad Hoc On-demand Distance Vector Protocol to view the above-mentioned fields of RREQ as shown Figure 4‑5.

Figure 4‑5: Analysis of AODV RREQ control packet in Wireshark

Open Wireshark, filter AODV packets and select the RREP packets and expand Ad Hoc On-demand Distance Vector Protocol to view the above-mentioned fields of RREP as shown Figure 4‑6.

Figure 4‑6: Analysis of AODV RREP control packet in Wireshark

ZRP-IARP #

Open NetSim and Select Examples->Mobile Adhoc Networks->ZRP IARP then click on the tile in the middle panel to load the example as shown in below screenshot Figure 4‑7.

Figure 4‑7: List of scenarios for the example of ZRP-IARP

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑8.

Figure 4‑8: Network set up for studying the ZRP-IARP

Network Settings#

1. Grid length: 500m*500m.

2. A network scenario is designed in NetSim GUI comprising of 5 Wireless Nodes and one ad-hoc link in the “Mobile Adhoc Network” Network Library.

3. In the General Properties set mobility Model as NO MOBILITY for all devices present in GUI.

4. The Medium Access Protocol was set to DCF in INTERFACE_1(WIRELESS)-> Datalink layer of all Wireless Nodes

5. Configure CBR application from Wireless Nodes 1 to Wireless Nodes 2 with Transport Protocol to UDP in Application Properties

6. Channel characteristics: Path loss only, Path loss model: Log Distance, Path loss exponent: 3.

7. Set ZRP routing protocol under network layer properties in all nodes.

8. Enable Packet Trace.

9. In NetSim GUI Plots are Enabled.

10. Run simulation for 10 seconds.

Output#

Open Packet trace and observe Control_Packet_Type/App_Name.

Figure 4‑9: Packet Trace

Users can see only NDP_Hello_Message since the destination node is within the zone. The ZRP framework proactively maintains local routing information (routing zones) based on periodic exchanges of neighbor discovery messages.

ZRP-IERP #

Open NetSim and Select Examples -> Mobile Adhoc Networks -> ZRP IERP then click on the tile in the middle panel to load the example as shown in below screenshot Figure 4‑10.

Figure 4‑10: List of scenarios for the example of ZRP-IERP

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑11.

Figure 4‑11: Network set up for studying the ZRP-IERP

Network Settings#

1. Grid length: 500m*500m.

2. A network scenario is designed in NetSim GUI comprising of 12 Wireless Nodes and one ad-hoc link in the “Mobile Adhoc Network” Network Library.

3. In the General Properties set mobility Model as NO MOBILITY for all devices present in GUI.

4. The Medium Access Protocol was set to DCF in INTERFACE_1(WIRELESS)-> Datalink layer of all Wireless Nodes

5. Configure CBR application from Wireless Nodes 1 to Wireless Nodes 12 with Transport Protocol to UDP in Application Properties

6. Channel characteristics: Path loss only, Path loss model: Log Distance, Path loss exponent: 3.

7. Set ZRP routing protocol under network layer properties in all nodes.

8. Enable Packet Trace.

9. In NetSim GUI Plots are Enabled.

10. Run simulation for 10 seconds.

Output#

Open Packet trace and filter Control_Packet_Type/App_Name to IERP_Route_Request

Figure 4‑12: Packet Trace

In the above packet trace, Node-1 is sending IERP_Route_Request packets to its peripheral nodes 8, 9,10 and 11 since the destination is not present in Node1’s zone. Similarly, Node 1 transmits IERP_Route_Request packets to Node 2. Node 2 sends IERP_Route_Reply packet in response to the IERP_Route_Request. And the data packet routes through Node 1->Node 6->Node 8->Node 12. This can be observed in Packet animation also as shown in Figure 4‑13.

Figure 4‑13: Packets take the route 1 > 6 > 8 > 12 when running ZRP-IERP

MANET-OLSR #

Open NetSim and Select Examples -> Mobile Adhoc Networks -> MANET OLSR then click on the tile in the middle panel to load the example as shown in Figure 4‑14.

Figure 4‑14: List of scenarios for the example of MANET OLSR

NetSim UI displays the following network when you open the example configuration file see Figure 4‑15.

Figure 4‑15: Network set up for studying the MANET OLSR

Network Settings#

1. Grid length: 500m*500m.

2. A network scenario is designed in NetSim GUI comprising of 5 Wireless Nodes and one ad-hoc link in the “Mobile Adhoc Network” Network Library.

3. In the General Properties set mobility Model as NO MOBILITY for all devices present in GUI.

4. The Medium Access Protocol was set to DCF in INTERFACE_1(WIRELESS)-> Datalink layer of all Wireless Nodes

5. Configure CBR application with Transport Protocol to UDP in Application Properties

6. Channel characteristics: Path loss only, Path loss model: Log Distance, Path loss exponent: 3.

7. Set OLSR routing protocol under network layer properties in all nodes.

8. Enable Packet Trace.

9. In NetSim GUI Plots are Enabled.

10. Run simulation for 30 seconds.

Output#

Open Packet trace and filter Control_Packet_Type/App_Name to NDP_HELLO_MESSAGE, Source_ID and Transmitter_ID to Node-1. All the nodes in the network exchange the NDP_HELLO_MESSAGEs periodically (for every 2 seconds- check NETWORK_LAYER_

ARRIVAL_TIME column) to detect the neighbours. In the below screenshot, Node-1 is broadcasting NDP_HELLO_MESSAGES to its neighbours 2, 3, 4 and 5 for every 2 seconds as shown Figure 4‑16.

Figure 4‑16: NDP_HELLO_MESSAGES to its neighbours 2, 3, 4 and 5 for every 2 seconds in Packet Trace

Now filter Control_Packet_Type/App_Name to OLSR_TC_MESSAGE, Source_ID and Transmitter_ID to Node-1. All nodes in the network broadcasts Topology Control (TC) messages (for every 5 seconds - check NETWORK_LAYER_ARRIVAL_TIME column) in order to build the topology information base. In the below screenshot, Node-1 is broadcasting OLSR_TC_MESSAGE to its neighbors 2, 3, 4 and 5 for every 5 seconds as shown Figure 4‑17.

Figure 4‑17: OLSR_TC_MESSAGE to its neighbors 2, 3, 4 and 5 for every 5 seconds in packet trace

Multiple MANETS #

Open NetSim and Select Examples->Mobile Adhoc Networks->Multiple MANETs then click on the tile in the middle panel to load the example as shown in below screenshot Figure 4‑18.

Figure 4‑18: List of scenarios for the example of Multiple-MANETs

Multiple MANETs allows users to interconnect two or more MANETs using a bridge node. Click and drop Wireless nodes, Adhoc links and Bridge Node onto the grid environment and connect Wireless Nodes to Adhoc links to form two different MANET’s using Adhoc links. Further connect the two MANET’s using a bridge node as shown below Figure 4‑19.

Figure 4‑19: Network set up for studying the Multiple-MANETs

Network Settings#

1. Grid length: 500m*500m.

2. Configure CBR application from Wireless_Node_1 to Wireless_Node_3 with Transport Protocol to UDP in Application Properties.

3. Set AODV routing protocol under network layer properties in all nodes.

4. The Medium Access Protocol was set to DCF in Interface (Wireless)-> Datalink layer of all wireless nodes and Bridge Node (Interface_1 and Interface_2).

5. Enable Packet Trace.

6. In NetSim GUI Plots are Enabled.

7. Run simulation for 10 seconds.

Output#

After simulation, open packet trace and filter CONTROL_PACKET_TYPE/APP_NAME to App1_CBR. In the below screenshot, users can observe that the packets from Source Node-1 are going to Destination Node-3 via Bridge Node-5.

Figure 4‑20: Packet transmitting from Source Node-1 to Destination Node-3 via Bridge Node-5 in Packet Trace

Power model in MANETs #

Sometimes nodes in MANETs may rely on batteries or other exhaustible means for their energy. For such nodes, an important system design criteria for optimization may be energy conservation.

Open NetSim and Select Examples-> Mobile Adhoc Network ->Power model in MANETs then click on the tile in the middle panel to load the example as show in below screenshot Figure 4‑21.

Figure 4‑21: List of scenarios for the example of Power model in MANETs

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑22.

Figure 4‑22: Network set up for studying the Power model in MANETs

Network Settings#

1. Grid length à 500m*500m.

2. Open Wireless node Interface properties and set the following properties under Physical Layer as shown below.

1. Idle Mode Current (mA) = 20,

2. Initial Energy (mAH) = 0.1 and

3. Energy harvesting to Off.

Figure 4‑23: Physical Layer Properties window

1. Click on the Application icon present in the top ribbon/toolbar

2. Create CBR Application from Wireless_Node_1 to Wireless_Node_3.

3. Set application start time as 0s and accept default for other parameters.

4. Set DSR routing protocol under network layer properties in all nodes.

5. Set DCF as the medium access layer protocol under datalink layer properties of all wireless node.

6. Enable Packet Trace.

7. In NetSim GUI Plots are Enabled.

8. Run simulation for 50 secs.

Theoretical calculation for battery life:

The battery life can be calculated by using the formula below:

Battery life (Hours)= $\frac{Energy(mAH)}{Load\ current(mA)}$

=$\ \frac{0.1}{20}\ $Hours = 0.005 Hours or 18 secs

Output#

After simulation, open Battery model metrics and observe the consumed energy would be approximately equal to initial energy for Wireless node_1 and Wireless node_3 since these nodes are communicating with each other and hence there is battery consumption. We can also observe that the Remaining energy is approximately 0 for Wireless node_1 and Wireless node_3. i.e., the battery is completely drained as shown Figure 4‑24.

Figure 4‑24: Battery Model Table

Open Packet animation and to check battery level, click on view more and enable the battery power for all the wireless nodes, the battery level of wireless nodes 1 and 3 would reduce with time and packet animation stops at 18.8 seconds approximately since the batteries of wireless nodes 1 and 3 dies as shown in the below screenshot Figure 4‑25.

Figure 4‑25: For wireless nodes 1 and 3 dies In Packet animation window

Application throughput variation with node mobility #

Objective

To simulate and analyze how application throughput varies as the node moves away. This analysis is done for 802.11n standard.

Open NetSim and Select Examples->Mobile Adhoc Networks->Application Throughput Variation with Node Mobility then click on the tile in the middle panel to load the example as shown in below screenshot Figure 4‑26.

Figure 4‑26: List of scenarios for the example of Application Throughput Variation with Node Mobility

MCS	RX Sensitivity	Modulation Technique	Coding Rate	Guard Interval (ns)	Data Rate
0	-82	BPSK	1.0/2.0	400	7.2
1	-79	QPSK	1.0/2.0	400	14.4
2	-77	QPSK	3.0/4.0	400	21.7
3	-74	16QAM	1.0/2.0	400	28.9
4	-70	16QAM	3.0/4.0	400	43.3
5	-66	64QAM	2.0/3.0	400	57.8
6	-65	64QAM	3.0/4.0	400	65
7	-64	64QAM	5.0/6.0	400	72.2
8	-59	256QAM	3.0/4.0	400	86.7

Table 4‑1: MCS Table of 802.11n - 2.4GHz frequency, 1NSS, 400ns GI 20MHz Bandwidth

Distance	Rx Power
100	-80.0893
85	-77.9719
70	-75.4423
55	-72.3002
40	-68.1511
33	-65.6447
30	-64.403
25	-62.0275
19	-58.4519

Table 4‑2: Distances considered in this example

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑27.

Figure 4‑27: Network set up for studying the Application Throughput Variation with Node Mobility

Network Settings#

1. The device coordinates were set as follows:

Device Name	x- axis	y-axis
Wireless_Node_1	0	100
Wireless_Node_2	10	100

Table 4‑3: Devices Position

1. IEEE standard was set to 802.11n in Interface (Wireless)-> Physical layer of both the wireless nodes.

2. The Physical layer properties were set as follows Table 4‑4.

Interface Parameters
Standard	IEEE802.11n
No. of Frames to aggregated	1
Standard Channel	1 (2412MHz)
Transmitting Antennas	1
Receiving Antennas	1
Guard Interval	400ns
Bandwidth	20MHz
Frequency Band	2.4GHz
Transmitter Power	100mW
Antenna Gain	0
Antenna height	1m
Reference distance (d0)	1m

Table 4‑4: Detailed Network Parameters

1. The Medium Access Protocol was set to DCF in Interface (Wireless)-> Datalink layer of both wireless nodes.

2. Right click Wireless_Node_1 -> Network layer Enable Static IP Route and Configure Static Route IP as shown below screenshot Figure 4‑28.

Figure 4‑28: Static IP Route configuration window

1. Rate Adaptation was set as False in Interface (Wireless) -> Datalink layer of both wireless nodes.

2. Channel characteristics are set as: Path loss only; Path loss model: Log Distance; Path loss exponent: 3.

3. The mobility model was set to No Mobility in Wireless_Node_1 and File_Based_Mobility in Wireless_Node_2.

4. Unicast CBR application was configured from Wireless_Node_1 to Wireless_Node_2 with packet size 1460 bytes and Inter Arrival Time 476.2 microseconds, which gives a Generation Rate of 30 Mbps.

5. Set application start time as 0 sec.

6. The Transport protocol was set to UDP.

7. Enable plots and run simulation for 40 seconds.

File based mobility file:

Time(s)	Node ID	X (m)	Y (m)	Z (m)
0	2	19	100	0
2	2	25	100	0
4	2	30	100	0
6	2	33	100	0
8	2	40	100	0
10	2	55	100	0
12	2	70	100	0
14	2	85	100	0
16	2	100	100	0
18	2	120	100	0
20	2	100	100	0
22	2	85	100	0
24	2	70	100	0
26	2	55	100	0
28	2	40	100	0
30	2	33	100	0
32	2	30	100	0
34	2	25	100	0
36	2	10	100	0

Table 4‑5: File based mobility file

Output#

Figure 4‑29: Plot of CBR Application throughput

Inference#

We can see that the Application throughput drops from 25 Mbps to 20 Mbps at around 4 seconds (the distance at this time is 100 m), and then to 16.5 Mbps at 8 seconds (the distance at this time is 140 m) and to 14 Mbps at 10 seconds (the distance at this time is 160 m) and then to 10 Mbps at 13 seconds (the distance at this time is 190 m) and then to 6 Mbps at 16 seconds (the distance at this time is 220 m). Note that this was got when the path loss exponent, in the RF propagation model, was set to 3.0.

Performance of range based pathloss model in MANETs #

Open NetSim and Select Examples->Mobile Adhoc Networks->Range Based pathloss model then click on the tile in the middle panel to load the example as shown in below screenshot Figure 4‑30.

Figure ‑: List of scenarios for the example of Range based pathloss model

Introduction#

The propagation loss depends only on the distance (range) between transmitter and receiver. There is a single Range attribute that determines the path loss.

This is not a real-world loss model but a theoretical model useful for experimentation. Receivers at or within Range meters see a 0 dB pathloss. Hence received power equals transmit power. Receivers beyond Range see a 1000 dB pathloss. Hence received power will be close to -1000 dBm i.e., zero in linear units

Figure 4‑31: This figure explains a typical range based pathloss model. In this example, Node A and B are in transmission range with each other which is denoted by a blue circle where the pathloss is 0dB i.e, successful transmission. And Node C is beyond the range i.e, pathloss is 1000dB all packets are errored and dropped. In NetSim, user must specify the range of the node in meters in the links.

We can use range based pathloss model in networks like Internetworks, Manet, VANET, TDMA, Pure aloha, Slotted aloha, Cognitive radio, IOT, WSN, and UWAN.

In this example we will study the different cases in Range based Pathloss using Mobile adhoc networks.

Case 1: Range Based Pathloss with transmission range (PL=0 dB)#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑32.

Figure 4‑32: For studying the range based pathloss model with range

Network Settings#

1. Environment Grid length:500 x 500

1. Drop 2 wireless node and 1 Adhoc link in Grid environment,

2. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	100	100
Wireless Node-2	180	100

Table 4‑6: Device Placements

1. Right Click on Adhoc link properties set Channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=100

2. Right click on Wireless node properties, Mobility Model: No-Mobility, For both nodes

3. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

4. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-2

5. Application Generation rate: 11Mbps (Packet size: 1460, Inter Arrival Time: 1061 µs)

6. In NetSim GUI Plots Should Be Enabled Run the Simulation for 100 seconds

Output and Plot#

Figure 4‑33: Application Metrics window

Figure 4‑34: NetSim Plot window

Inference#

From above result there is data transmission and Constant plot through-out the simulation as in this case wireless node-2 is with-in the range of wireless node-1 as range-based parameter is set to 100 meters and Wireless node-2 is placed in 80 meters distance from wireless node-1.

Case 2: Range Based Pathloss with out-of-range (PL=1000 dB)#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑35.

Figure 4‑35: For studying the range based pathloss model with-out range

Network Settings#

1. Environment Grid length:500 x 500

2. Drop 2 wireless node and 1 adhoc link in Grid environment,

3. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	100	100
Wireless Node-2	180	100

Table 4‑7: Device placements

1. Right Click on Ad hoc link properties set Channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=50 meters

2. Right click on Wireless node properties, Mobility Model: No-Mobility, For both nodes

3. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

4. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-2

5. In NetSim GUI Plots Should Be Enabled Run the Simulation for 100 seconds

Output and Plot#

Figure 4‑36: Application Metrics window

Figure 4‑37: NetSim Plot window

Inference#

We can observe from above results there is no data transmission as in this case wireless node-2 is out-of-the range as range-based parameter is set to 50 meters and Wireless node-2 is placed in 80 meters from wireless node-1

Case 3: Range Based Pathloss with ping pong in nature#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑38.

Figure 4‑38: For studying the range based pathloss with ping pong in nature

Network Settings#

1. Environment Grid length:500 x 500

2. Drop 2 wireless node and 1 adhoc link in Grid environment,

3. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	100	100
Wireless Node-2	180	100

Table 4‑8: Device Placements

1. Right Click on Ad hoc link properties set Channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=100 meters

2. Right click on Wireless node 1 properties, Mobility Model: No-Mobility

3. Right click on Wireless node 2 properties, Mobility Model: File based mobility

4. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

5. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-2

6. Configure static route from Wireless node 1 to Wireless node 2

7. In NetSim GUI Plots Should Be Enabled Run the Simulation for 55 seconds

File based mobility file is written as in (0^th second) Wireless node 2 will be in range and (5^th second) it will be in out of range and same process will be repeated till 50 seconds

Figure 4‑39: Open mobility text file window

Output and Plot#

Figure 4‑40: Application Metrics window

Figure 4‑41: NetSim Plot window

Inference#

We can observe from above result plot data transmission will start from 0^th sec and it will transfer till 5^th sec and there is no data transmission till 10^th second, again transmission starts from 15^th sec same will be repeated till 50^th sec,

As in this case we made wireless node-2 should be in range first 5 seconds with wireless node 1 and should be out of range after 5 seconds vice-versa, Here range based parameter is set to 100 meters and Wireless node-2 is placed in 80 meters distance from wireless node 1 we have written mobility file as in (0^th second)node will be in range which is inside 100 meters and (5^th second) it will be in out of range which is out of 100 meters and same will be repeated till 50 seconds.

Case 4: Range Based Pathloss with Multihop Communication#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑42.

Figure 4‑42: For studying the range based pathloss model with multihop

Network Settings#

1. Environment Grid length:500 x 500

1. Drop 3 wireless node and 1 adhoc link in Grid environment,

2. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	100	100
Wireless Node-2	140	100
Wireless Node-3	180	100

Table 4‑9: Device Placements

1. Right Click on Adhoc link properties set Channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=50

2. Right click on Wireless node properties, Mobility Model: No-Mobility for all 3 wireless nodes

3. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

4. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-3

5. Configure static route from Wireless node 1 to Wireless node 2 and from Wireless node 2 to Wireless node 3

6. In NetSim GUI Plots Should Be Enabled Run the Simulation for 100 seconds.

Figure 4‑43: Data transmission from WN1 to WN2

Figure 4‑44: Data transmission from WN2 to WN3

Above figures we can observe how multi-hop communication is happening between Wireless Node1 and Wireless Node 3 via Wireless Node 2,Here we have configured application from Wireless Node 1 to Wireless Node 3 as we kept range based parameter 50 meter and Distance between Wireless Node 1 and Wireless Node 3 is 80 meters which is out of range but Wireless Node 2 is with range with both Wireless Node 1 and Wireless Node 3 ,Hence here Wireless Node 1 is using intermediate Node which is Wireless node 2 for data transmission.

Output and Plot#

Figure 4‑45: Application Metrics window

Figure 4‑46: Netsim Plot window

Case 5: Range Based Pathloss with Multihop Communication and Ping-pong in nature#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑47.

Figure 4‑47: For studying the range based pathloss model with multihop and ping-pong in nature

Network Settings#

1. Environment Grid length:500 x 500

1. Drop 3 wireless node and 1 adhoc link in Grid environment,

2. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	0	100
Wireless Node-2	51	100
Wireless Node-3	100	100

Table 4‑10: Device Placements

1. Right Click on Adhoc link properties set channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=50

2. Right click on Wireless node properties, Mobility Model: No-Mobility for Wireless Node1

3. Right click on Wireless node properties, Mobility Model File based mobility for Wireless Node 2 and Wireless Node 3.

4. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero.

5. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-2 and Wireless Node-1 to Wireless Node-3.

6. Configure static route from Wireless node 1 to Wireless node 2 and from Wireless node 2 to Wireless node 3.

7. In NetSim GUI Plots Should Be Enabled Run the Simulation for 60 seconds

File based mobility file is written as in (0^th second) both WN2 and WN3 will be out-of-range and in (10^th second) Wireless Node 2 will come in range of Wireless Node 1 and Wireless Node 3 will be in out of range, From (20^th second) Wireless Node 2 will be in range and Wireless Node 3 will come in range of the Wireless Node 2.

Figure 4‑48: Open mobility text file window

Output and Plot#

Figure 4‑49: Application Metrics window

Figure 4‑50: NetSim Link Throughput Plot window

Figure 4‑51: Application 1 Throughput Plot window

Figure 4‑52: Application 2 Throughput Plot window

Case 6: Range Based Pathloss within range and out of range with Broadcast Application#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑53.

Figure 4‑53: For studying the range based pathloss within range out-of-range with broadcast application

Network Settings#

1. Environment Grid length:500 x 500

1. Drop 3 wireless node and 1 adhoc link in Grid environment,

2. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	0	100
Wireless Node-2	50	100
Wireless Node-3	200	100

Table 4‑11: Device Placements

1. Right Click on Adhoc link properties set channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=100

2. Right click on Wireless node properties, Mobility Model: No-Mobility for all the nodes and INTERFACE-(WIRELESS), Data Link Layer, Medium_access protocol to DCF

3. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

4. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-3

5. In NetSim GUI Plots Should Be Enabled Run the Simulation for 100 seconds

Output and Plot#

Figure 4‑54: Data transmission from WN1 to WN2

From the above figure we can observe there is a Data transmission between WN1 and WN2 and there is no transmission between WN1 and WN3 as we Configured Broadcast application from WN1 and we have set range-based pathloss as 100 meters, As WN2 is within the WN1 there is a transmission and WN3 is out-of-the range there is no transmission between WN1 and WN3.

Figure 4‑55: Application Metrics window

Figure 4‑56: NetSim Plot window

Case 7: Range Based Pathloss Transmission failure due to interference from neighboring transmissions#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑57.

Figure 4‑57: For studying the range based pathloss Transmission failure due to interference from neighboring transmissions

Network Settings#

1. Environment Grid length:500 x 500

1. Drop 4 wireless node and 1 adhoc link in Grid environment,

2. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	0	100
Wireless Node-2	50	100
Wireless Node-3	110	100
Wireless Node-4	140	100

Table 4‑12: Device Placements

1. Right Click on Adhoc link properties set channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=100

2. Right click on Wireless node properties, Mobility Model: No-Mobility for all the nodes and INTERFACE-(WIRELESS), Data Link Layer, Medium access-protocol to DCF

3. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

4. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs) from Wireless Node-1 to Wireless Node-2 and Wireless Node-3 to Wireless Node-4

5. In NetSim GUI Plots Should Be Enabled Run the Simulation for 100 seconds.

Output and Plot#

Figure 4‑58: Representation of transmitters pathloss range

From the above figure we can observe Wireless Node 2 is within the range of Wireless Node 3 and Wireless Node 4, Here Wireless Node 1 to Wireless Node 2 we have configured one application and Wireless Node 3 to Wireless Node 4 we have configured another application,

In this scenario there is no data transmission between Wireless Node 1 to Wireless Node 2, As Wireless Node 2 is within the range of neighboring nodes which is Wireless Node 3 and Wireless Node 4, Hence there is Transmission failure due to the interference from neighboring nodes.

Figure 4‑59: Application Metrics window

Figure 4‑60: Netsim Plot window

Figure 4‑61: Application 2 Throughput Plot window

Case 8: Range Based Pathloss with Carrier sense (CS) blocking due to neighboring transmissions#

The following network diagram illustrates, what the NetSim UI displays when you open the example configuration file see Figure 4‑62.

Figure 4‑62: For studying the range based pathloss Carrier sense (CS) Blocking due to neighboring transmissions

Network Settings#

1. Environment Grid length:500 x 500

1. Drop 4 wireless node and 1 adhoc link in Grid environment,

2. Device placements of wireless nodes are:

Device	X-Coordinate	Y-Coordinate
Wireless Node-1	50	100
Wireless Node-2	0	100
Wireless Node-3	100	100
Wireless Node-4	150	100

Table 4‑13: Device Placements

1. Right Click on Adhoc link properties set channel Characteristics: Pathloss Only, Pathloss model to Range Based, Range(m)=100

2. Right click on Wireless node properties, Mobility Model: No-Mobility for all the nodes and INTERFACE-(WIRELESS), Data Link Layer, Medium-access-protocol to DCF

3. Click on the Application icon present in the top ribbon/toolbar, Set Transport Protocol to UDP and Set start time to zero

4. CBR Application with 11Mbps generation rate (Set Packet size: 1460, Inter Arrival Time: 1061 µs)from Wireless Node-1 to Wireless Node-2 and Wireless Node-3 to Wireless Node-4

5. In NetSim GUI Plots Should Be Enabled Run the Simulation for 100 seconds

Figure 4‑63: Representation of transmitters pathloss range

From the above figure we can observe Wireless Node 1 is within the range of Wireless Node 2 and Wireless Node 3 also Wireless Node 3 is within the range of Wireless Node 1 and Wireless Node 4, As Here we have configured one application from and Wireless Node 1 to Wireless Node 2 and configured another application from Wireless Node 3 to Wireless Node 4

In this scenario there is Wireless Node 1 is in carrier sense range of Wireless Node 3 & Wireless Node 4 hence when Wireless Node 3 is transmitting data to Wireless Node 4, Wireless Node1 will wait due to carrier sense blocking it cant transmit the data, And also when Wireless Node 1 is transmitting data to Wireless Node 2 the Wireless Node 3 will wait as it is carrier sense range of Wireless Node 1,Finally in results we can observe same amount of data is transferred by application 1 and 2

Figure 4‑64: Application Metrics window

Figure 4‑65: Netsim Plot window

Reference Documents#

• IEEE 802.11 - 2012 Standard for Wireless LAN

• AODV – RFC 3561

• OLSR – RFC 3626

• ZRP – Draft RFC Zone ZRP

• MANET Routing protocol performance issues - RFC 2501

Latest FAQs#

Up to date FAQs on NetSim’s MANET library is available at

https://tetcos.freshdesk.com/support/solutions/folders/14000110331