Mobile Ad-hoc Network (MANET) Simulator based on Local-Multipath Adaptive Routing (LMAR) Protocol

1 Introduction

In this section, the MANET simulator designed for simulating the proposed SELMAR protocol is introduced. The functioning of the simulator is explained in the following sections, and some of the important classes, variables, and functions of the simulator are described. Finally, the simulation results of the SELMAR protocol are examined considering selfishness and wormhole attack.

The MANET simulator is implemented for simulating ad hoc network protocols, specifically used for performance analysis of the SELMAR protocol. The MANET simulator is written in the Visual C++ programming language and operates under the Windows operating system.

2 Simulator Operation

To simulate an ad hoc network, its components including routers, links, and traffic need to be defined. Routers can be added individually based on the desired topology or randomly generated as a group of 100 nodes (as shown in Figure 1) and placed on the coordinate plane.

The routers, links, and traffic components must be specified for simulating an ad hoc network.

Figure 1: Random Topology Generation

After placing the randomly generated routers on the coordinate plane (similar to Figure 2), they can be moved using the mouse. Additionally, by right-clicking on the nodes, they can be deleted or their user-defined properties can be modified.

Figure 2: Display of Randomly Generated Topology by MANET

The user-defined properties of the routers can be accessed both through the toolbar and by right-clicking. The properties of the routers include a unique title for each router, radio coverage (in point units), processing delay (in tick units), buffer size (in packet units), the physical path of the router's image on the hard disk, the horizontal coordinates of the router, the vertical coordinates of the router, template length (in point units), template width (in point units), and the type of the router (normal, malicious, or selfish). (Figure 3).

Figure 3: Router Configuration Dialog

Wireless links between neighboring nodes are represented by colored lines. After the user sets the positions of the nodes, the software, based on Figure 4, can display the possible wireless links by selecting the 'Create Link' option. The software compares the distance between nodes with their radio coverage range, and if the distance between two nodes is less than the radio coverage of both nodes, a link between them is displayed.

Figure 4: Establishing Connections between Nodes

After displaying the links, it is also possible to move the nodes. However, if the nodes move out of each other's radio range (Figure 5), the link between the two nodes will turn red, indicating the loss of wireless connection.

Figure 5: Node 10 Moving Out of the Coverage of Nodes 17 and 19

Now we need to define the traffic between nodes. To establish communication between nodes, the traffic between each specific source and destination can be configured according to the corresponding protocol. As shown in Figure 6, the start time of the communication can also be set in terms of ticks, allowing the desired traffic to flow between the source and destination at the specified time through the corresponding protocol.

Figure 6: Opening the Traffic Definition Dialog

The window for configuring the traffic between a specific source and destination at a desired time, based on the corresponding protocol, is shown in Figure 7.

Figure 7: Traffic Configuration Dialog

To perform the simulation, you can select the 'Profile' option from the Simulation section in the program's toolbar, as shown in Figure 8.

Figure 8: Simulation Window Initialization

Then the simulation window is opened (Figure 9). By pressing the 'Resume' button, the simulation continues and the 'Resume' button changes to 'Pause'. Similarly, by clicking the 'Pause' button, the simulation is paused, and the 'Pause' button changes to 'Resume'. To control the simulation speed, you can adjust the slider [1] to increase or decrease the simulation speed (by default, the simulation speed is set to its minimum value).

Figure 9: Simulation Control Dialog

In the real world, each router independently performs its network operations using its internal processor. In virtual simulation, the aim is to highlight the differences between routers by defining their specific and fundamental characteristics, and to be able to track the entire network operations using a single processor. In practice, all routers work in parallel, but for simulation purposes, we need to schedule the requested tasks of each node within specific time intervals based on the processing power and other computer specifications.

In the MANET software, efforts have been made to speed up the simulation process by allowing all routers to advance one time unit (tick) in each time interval. To make the simulation more realistic, in each execution of the time loop, all routers perform their assigned tasks for one time unit (tick). The requested actions from each node include downloading (receiving a packet at the end of the desired link connected to the node), packet processing, and uploading (sending the processed packet to the beginning of the desired link connected to the node). To ensure that the download and upload actions occur only once in each time loop, a bit is used to identify whether the link is active or inactive. The mentioned approach seemed very beneficial to the program designer compared to other methods.

When traffic transmission begins, the source node first performs the routing operation and initiates the route discovery phase. To do this, it generates a route request packet and broadcasts it to its neighbors. It should be noted that the route request packet is created only once in memory because the protocol used is based on distance vectors, and thereafter, nodes only propagate a reference to the packet. This greatly helps increase the simulation speed. The clock loop of the nodes is repeated every few milliseconds based on the user-selected values in the simulation window, allowing the network simulation to progress accordingly.

In each iteration of the clock loop, every network router listens to its outgoing links to receive any packets that have reached the end of their respective routes. These received packets are stored in the receiver buffer and processed sequentially. For example, intermediate nodes examine the received packets to determine which next node to forward them to, and data packets are collected by the destination node. The transmitted packets are placed in the sender buffer of the nodes and sent to the desired neighbors through the corresponding links in order.

With this description, it can be understood that buffer models are also defined for modeling link delays. The uploaded packets are stored inside these buffers and effectively ride on the link to reach the other side. At the other end (the head of the link), they are downloaded by the neighboring node. This approach applies to all links. Additionally, in each iteration of the clock loop, nodes individually advance the clock of their own links to facilitate the movement of packets within them.

The packet delay within the links (in terms of ticks) is calculated based on the distance between connected nodes through the link, and one unit is subtracted from it for each clock tick. When the delay counter reaches zero, it means the packet has reached the end of the link or the head opposite to the link, ready to be received by the neighboring node in the next clock cycle.

The links between routers are initially black. As the route request packets pass through the links, their color changes to blue, and when the route reply packets move through the links, their color turns yellow. When a data packet resides inside a link, the link color becomes purple, and finally, upon the return of the ACK packet to the source, the link colors along the route turn green, indicating successful communication establishment.

The processing and routing of nodes are based on the network layer traffic protocol, which is considered when defining the traffic by the user. The packet processing depends on the type of packets. For example, in the absence of a specific route to the destination, a route request packet is broadcasted to neighbors, while an ACK packet is forwarded to the next node towards the source. In addition to the regular processing tasks, traffic-generating nodes must measure the round trip time between the request packet departure and the response packet arrival and always expect to receive an ACK message indicating the successful arrival of data upon sending a certain number of data packets.

In the MANET program, the data link layer and physical layer protocols are simplified. In the physical layer model, packets are transmitted and received as byte-pointer signals without noise. Various factors influencing digital communications, such as noise, fading, multipath, etc., have been disregarded in this project, and the physical layer model has been simplified to the simplest form. This is because the objective of the project is to investigate the effects of known attacks on network layer protocols, and these factors have been ignored due to their negligible impact. Additionally, the data link layer and the MAC sublayer have been considered as completely bidirectional without collision, meaning that connected nodes can send data in either direction over their shared link without data collisions, and the data can be easily received by the nodes at the other end.

3 Introduction to Classes (Variables and Functions)

3-1 Introduction

The MANET software consists of five main classes, and the other software classes are either subclasses of these five classes or predefined classes from MFC [6]. The five major classes of the MANET program are CLink, CPacket, CRouter, CTable, and CTraffic. In this section, we will explain each of these classes used in the software, including their variables and functions.

3-2 CLink Class

The CLink class is used to model the links between nodes in the MANET network. Any variable defined as a CLink class must point to two corresponding nodes, representing the two endpoints of the link. Additionally, depending on the type of connection and its bandwidth, the transmission frequency of the link can be set using the Frequency variable.

The Router1 and Router2 variables identify the router nodes at both ends of the link. The Start and End variables indicate the coordinates of the link's starting and ending points on the screen. The Draw function is used to color the link. The color of the link is determined by the type of the latest packet that entered it. For example, a route request packet turns the link blue, a route reply packet turns it yellow, a data packet turns it purple, and an ACK packet turns it green. The rgb variable of type COLORREF is used to access the colors.

The Distance2 function calculates the square of the distance between the starting and ending nodes of the link, and the output of this function is used to calculate the delay variable in the link. The Duplex variable indicates whether the link is simplex or duplex. The pointers to the uploaded packets by the first node are stored in the array variable p1s, and the pointers to the uploaded packets by the second node are stored in the array variable p2s. Furthermore, the propagation delay of each of these sets is stored sequentially in the array variables pd1s and pds2.

The important functions used in the CLink class include Transmit, Download, and Upload. The Transmit function is used to move packets based on the delay value for each tick of the clock. Routers can use the Upload function to inject their own transmitted packets onto the links, and on the other hand, after the delay variable of each packet becomes zero, the desired router can use the Download function to download and receive the packet from the corresponding link.

3-3 CPacket Class

The CPacket class is used to model the packets used in ad hoc networks. Each variable of type CPacket contains a unique identifier (ID variable) that is usually assigned randomly. Additionally, the Type variable determines the type of the packet, which is initially set to zero, indicating a route request packet. If the value of the Type variable is one, it represents a route reply packet. If the value is two, it represents a data packet, and if the value is three, it represents an ACK packet.

In addition to these, the CPacket class contains source and destination names (Source and Destination variables) of string type, which indicate the origin and destination of the packet during its transmission. Furthermore, the SeqNum variable represents the last received sequence number from the source and helps intermediate nodes update their routing tables when this number is new. The Expiration variable indicates the lifespan of the packet, which decreases by one unit as the packet passes through each node. The Protocol variable represents the type of protocol on which the packet is based for generation and processing. If the ChangePath variable of the CPacket class becomes active (its value is greater than zero), it triggers a change in the route at intermediate nodes. This variable plays a significant role in the routing operation of the protocol.

3-4 CTraffic Class

The CTraffic class is designed to model the traffic in ad hoc networks. Anything defined from the CTraffic class contains two pointers of the CRouter class, which point to the source and destination of the traffic. The start and end nodes of the CTraffic class are the Source and Destination variables of the CTraffic class. The Protocol variable in the CTraffic class indicates the type of protocol on which the traffic is defined, and the Start variable represents the time when the traffic generation starts in the network, expressed in ticks. The default protocol used in this class is the ELMAR protocol, and the default value for the start of traffic is always zero (simulation origin).

3-5 CTable Class

The CTable class is designed to model routing tables of nodes. Each variable of type CTable must point to a unique destination using a string variable called Destination. Each router may have multiple routes for each possible destination. The number of routes available to a node for each destination is less than or equal to the number of node's neighbors. Each variable of the CTable class has an array of routes (of type CPath) that represents only the next hop to reach the destination, as the protocols used work with distance vectors and are not of the "source route" type.

The Index variable indicates the current index of the route in the array of routes that the node uses. When the Index variable exhausts all available routes, the Round variable becomes active, indicating at least one complete round of searching for routes. These two variables play a fundamental role in finding the appropriate route between the source and destination in the induced subgraph of the network's topology.

3-6 CRouter Class

The CRouter class models the routers of ad hoc networks and is considered the main class of the MANET simulator software. Anything of type CRouter has a unique IP address stored in the Caption variable. The horizontal and vertical coordinates, as well as the length and width of the rectangular shape representing the router on the screen, are defined by the variables X, Y, RectLength, and RectWidth, respectively.

Some other parameters that can be changed by the user include radio coverage, delay, buffer size, router type, and the physical image path stored in the variables Coverage, Delay, BufferSize, Type, and ImagePath, respectively. The router type can be ad hoc, selfish, or malicious. The CRouter class has access to several arrays of pointers, allowing it to model network operations.

The links array contains pointers to all the links connected to the router, represented by the CLink class. The traffics array contains pointers to all the traffic generated by the router, created by the CTraffic class. The arrays receivedpackets, generatedpackets, processedpackets, and datapackets hold pointers to all the received, generated, processed, and data packets (of type CPacket) that the router has interacted with.

The tables array contains pointers to the routing tables for specific destinations. The neighboring routers, which are also instances of the CRouter class, are stored in the neighbors array, and the order of neighbors in the array corresponds to the order of links in the links array. For example, neighbor number 7 is connected to the router via link number 7.

Each CRouter instance maintains sequence numbers and expiration times for different packets in the variables SeqNum and Exp, respectively. Additionally, each router has its own clock, which measures the number of ticks elapsed since the router was turned on, stored in the Clock variable. The SendData control variable regulates the timing of data transmission and becomes active after performing a routing operation.

The main core of the CRouter class is the tick process, which increments the value of the router's Clock variable by one unit with each execution within the program's main loop. The Receive, Process, and SparkTraffic processes are then invoked. The Receive process handles packet downloading and reception (if any) from the links. The Process process consists of four parts, where the execution of one of the functions ProcessRReqPacket, ProcessRREpPacket, ProcessDataPacket, or ProcessACKPacket depends on the type of the currently read packet from the router's buffer. The SparkTraffic function is used for generating traffic in the network.

The delay time for packet processing is calculated by the GetProcessDelay process. To generate route request, route reply, data, and acknowledgment packets, the GenRReq, GenRRep, GenDataPacket, and GenAckPacket processes are used, respectively. The router checks the uniqueness of received packets using the arrays of packets and the IsProcessed process, ensuring that non-duplicate received packets are processed in subsequent clock ticks. To broadcast the desired packet to neighbors, the router utilizes its Broadcast function to upload the packet on all links.

By receiving various packets, the router adjusts and updates its routing tables using the Update function. The CRouter class employs the GetTableIndexToDest function to obtain the table index corresponding to a specific destination and uses the GetTableIndexToSource process to determine the table index associated with the desired source. The CRouter class uses the GetNextHop function for routing received packets to the intended destination. With these summarized explanations, the CRouter class will be capable of independently performing all the tasks corresponding to the protocol.

4 Simulation Results

In this section, the SELMAR protocol has been simulated in a network topology consisting of 50 nodes randomly placed next to each other (Figure 10). The nodes that intend to establish a connection are marked with a red circle. The source node is node number zero, and the destination node is node number 49.

Figure 10 represents a custom network topology with 50 nodes. 

By simulating the routing request packets in the network, they are broadcasted and the links turn blue. Then the routing reply packets move through the network and the color of the links turns yellow. A depiction of the network topology during the simulation process is shown in Figure 11.

Figure 11 illustrates the dissemination of routing request and reply packets in the network. 

Then, Node 0 sends the data packets towards Node 49 by selecting the shortest path in the routing table. Intermediate nodes forward the traffic in the direction of the input index of their respective tables. The purple path represents the forward data path from the source to the destination. The ACK packet follows the reverse path (green path) back to the source (Figure 12) because intermediate nodes set up the reverse hop return path in their tables. Thus, the green path, representing the return path to the source, re-colors the forward purple path to the destination.

Figure 12, the green-colored path represents the reception of the ACK packet.

Node 28, which is a neighbor of Node 49 (the destination), is indicated by a black circle around it. Node 28 is included in the selected communication path. To test the protocol's resistance against selfishness, we change the attribute of Node 28 from cooperative to selfish and perform the simulation twice for the same topology.

Eventually, as shown in Figure 13, the alternative route (49-30-25-36-27-0) is chosen instead of the previous route (49-28-19-40-6-0). We continue the selfish behavior of the neighbor nodes, and this time we make Node 30 selfish. The simulation results indicate that the local optimal route will be 49-4-20-37-42-0.

Figure 13, the resistance of the SELMAR protocol against the selfishness of Node 28 is demonstrated.

Now, we also change the type of Node 4, which is a neighbor of the destination, to selfish. This time, the number of communication interruptions increases, and the protocol, after trying numerous paths, can find a route to the destination through Node "1". The selected path in this case is 49-1-26-2-43-5-0, as shown in Figure 14.

Figure 14: The ability of the SELMAR protocol to deal with node selfishness

Although the number of communication attempts increases as the number of selfish nodes increases, each attempt to establish a connection avoids the input indices of the intermediate nodes from the selfish nodes (similarly for malicious nodes). Therefore, increasing the number of these attempts contributes to the establishment of subsequent connections because the intermediate nodes have modified their input index tables for subsequent connection attempts, and the selfish nodes are not selected for collaboration in forwarding the data packets. As a result, the number of communication attempts for subsequent connections decreases.

To demonstrate the resistance of the SELMAR protocol against an active wormhole attack, we consider the same random topology as before and introduce a wormhole link (red line) between Node 24 (neighbor of the source node) and Node 30 (neighbor of the destination node). As shown in Figure 15, the shortest path between the source (Node 0) and the destination (Node 49) will include nodes 49-30-24-0.

Figure 15: The resistance of the SELMAR protocol against wormhole attack

The wormhole nodes discard the data packets. By conducting simulations, it is observed that after 5 attempts to establish a connection, the SELMAR protocol can track the local optimal path 49-4-29-43-5-0. Thus, it can be understood that wormhole nodes are more dangerous than selfish nodes, and increasing the number of wormhole links causes finding a suitable path to take longer. Wormhole nodes attract network traffic towards themselves, similar to black holes. Simulation results demonstrate that the longer the length of the wormhole, the more threatening it is to the network, and more effort is required for the routing algorithm to converge and establish the communication path between the source and the destination. On the other hand, the attacking nodes must incur higher costs to establish longer wormholes! Similar to the method of preventing selfishness growth, as the number of communication attempts increases, the intermediate nodes change their jumping direction away from the wormhole attackers for subsequent hops. This point is beneficial in terms of improving the protocol's performance in establishing subsequent connections between network nodes.

5 Conclusion

In this chapter, we have explained the functioning of the MANET simulator used in this project and introduced the important classes, variables, and functions defined in this software. Finally, we simulated the SELMAR protocol using the MANET program. Based on the simulation results and the arguments presented in the previous chapter, we can conclude that the SELMAR protocol demonstrates the necessary resistance against both active and passive attacks and achieves the desired level of security. Furthermore, considering the properties of its underlying algorithm, ELMAR, it also exhibits superior performance compared to previous multipath routing protocols.

[1] Slider

[2] Clock

[3] Download

[4] Upload

[5] Medium Access Control (MAC) Sub Layer

[6] Microsoft Foundation Classes

[7] String