Scenario results

In this subsection, we present the reaction of MDSDV to the topology changes during the simulation time. In addition to sending data packets, we present how MDSDV sends and receives control packets to create and update routing tables.

Initial state

At the beginning of this scenario, each participating node is placed in its initial po-sition as shown in Figure 5.17. Each node starts the scenario by creating its routing table with only one entry belonging to itself as shown in Figure 5.18.

Figure 5.17: A simple network of five nodes

Figure 5.18: Routing tables of all nodes in the network at the beginning of scenario

Sending and receiving Hello messages and Update packets

As mentioned in Section 5.3, periodically each node checks its Neighbours Table (NT). If the node’s NT is empty (no entries), the node generates and broadcasts a Hello Message, otherwise, it generates and broadcasts an Update packet.

Figure 5.19 shows that node one checked its NT at 0.031539 sec, and found no entries (no neighbours). Thus, it broadcasts a Hello message. Both of node two and node three receive the Hello message and consider node one as a new neighbour node. Each of them adds an entry in its routing table as a direct route to node one. Tables 5.11 and 5.12 show routing tables of node two and node three respectively, after receiving the Hello message from node one.

At 0.037557 node two checks its NT and finds one entry belongs to node one. There-fore it broadcasts an Update packet as shown in Figure 5.19. Because node zero and node one are in the transmission range of node 2, they receive the Update packet and update their routing tables as shown in Table 5.13 and Table 5.14.

Similarly, when node three checks its NT and finds one entry belongs to node one, it broadcasts an Update packet at 0.039991 as shown in Figure 5.19. Node one and node four are in the transmission range of node three. Thus, they receive the Update packetand update their routing tables as shown in Tables 5.15 and Table 5.16.

Figure 5.19: Broadcasting Hello and Update packets

Table 5.11: Routing Table of node 2 after receiving a Hello message from node 1

Table 5.12: Routing Table of node 3 after receiving a Hello message from node 1

Table 5.13: Routing Table of node 0 after receiving an update packet from node 2

Table 5.14: Routing Table of node 1 after receiving an update packet from node 2

Table 5.15: Routing Table of node 1 after receiving an update packet from node 3

Table 5.16: Routing Table of node 4 after receiving an update packet from node 3

Sending and receiving a Full Dump

As a result of receiving an Update packet from a new neighbour (node zero), node four generates and broadcasts a Full Dump at 99.0743 sec which contains the best route for each destination.

Figure 5.17 shows that routing table of node four contains seven entries. Specifically, it contains 1 route for node zero, 2 routes for node one, 1 route for node two, 2 routes for node three, and 1 route belongs to itself. So, node four should select one route from the two routes that belong to node one, and one route from the two routes that belong to node three.

Table 5.17: Routing Table of node 4 contains 7 entries at the time of generating a Full Dump

Table 5.18: A Full Dump generated by node 4 contains five entries

Selecting the best route can be briefly described as follows. The node selects the route with the higher sequence number. If two routes have the same sequence number, the route with smaller number of hops is selected. Figure 5.17 shows that the RT of node

four contains two routes for node one (row 2 and row 3), and the route with higher sequence number (row 2) is selected. Meanwhile, the same figure shows that the RT contains two routes for node three (row 5 and row 6), and the route with smaller num-ber of hops (row 6) is selected. Figure 5.18 shows the entries of Full Dump that is generated by node four.

When node 0 receives the Full Dump, the routing information (Figure 5.18) is com-pared with the information that is already available at the routing table (Figure 5.19) to update the routing table.

As a result of receiving this Full Dump, node 0 creates one extra route for each des-tination in the network (Yellow colour in Figure 5.20). For example, a new route to node three through node four is obtained (row 7).

Table 5.19: Routing Table of node 0 before dealing with the Full Dump

Table 5.20: Routing Table of node 0 after dealing with the Full Dump

Broadcasting an Error packet

In MANETs, movement of nodes cause broken links. Any node discovers a broken link should broadcast an Error packet. To describe the broken links, we present the following scenario. Line $ns at 100.20 “$node (2) setdest 100.0 310.0 5.0” produce the movements of node two. It means at time 100.20 sec, node two starts to move towards the destination (x=100,y=310) at a speed of 5m/s. As a result, node two and node four become out of each other’s transmission range after some time.

Figure 5.20: Node 2 is bradcasting an Error packet at 116.245953 sec

If a node does not receive any packet from its neighbour for a certain time, the node considers the neighbour as unreachable node. Figure 5.20 shows that node two broad-casts an Error packet at time 116.245953 sec due to the broken link between itself and node four. Routing table of node two before discovering the broken link is shown in

Figure 5.21. As Node two detects that the link between itself and node four is broken, it assigns ∞ metric for each route where node four acts as a first hop as shown in Figure 5.22. Next, it broadcasts an Error packet containing three fields as shown in Figure 5.23. Any node receives the Error packet deletes any route that has the same link Id included in the Error packet.

Table 5.21: RT of node 2 before broadcasting an Error packet at 116.245953 sec

Table 5.22: RT of node 2 after broadcasting an Error packet at 116.245953 sec

Packet Sender Destination Link-Id

2 4 20004

Table 5.23: An Error Packet has been sent by node 2

Forwarding data packets

Sending or forwarding a data can be done by a source node or an intermediate node.

When a node has a ready data to send, it searches for a route to the destination. If only one route is found, the node uses that route to send data. If more than one route is available in the routing table, the best route is used to send data. If no route is available, the node queues the packet in the interface queue. When a node gets a route to a new destination, it checks the interface queue to see if there are queued packets belonging to the new destination.

In this scenario Lines 68-75 determine the source and destination nodes to send and receive data packets. We assume that node four (Destination) receives any incoming TCP traffic. Therefore, it has a TCP sink agent attached to it. The other node (node zero) has an FTP agent connected to its TCP agent, simulating the FTP traffic source.

The FTP traffic (data sending) is started at time 8.0 sec ($ns at 8.0 “$ftp start”).

However, at this time no route is available at the source to the destination node as shown in Table 5.24. Hence, node zero should queue data packets in the interface queue until a route for node four becomes available.

Table 5.24: Routing table of no 0 at time 8.0 sec

Table 5.25: At 10.4097 Node 0 receives an update packet from node 2 contains 4 entries

At time 10.4097 sec , node zero receives an Update packet (Table 5.25) from node 2 containing 4 entries. Table 5.26 shows that node zero updates its routing table by adding 2 new routes (one for node three and one for node four). As soon as it gets a route for node four, node zero starts to forward the queued packets.

In this scenario, we describe the forwarding of packet no 5 from source (node zero) to destination (node four).

- At 10.4097 node zero selects a route in the fifth entry (4 hops) in Table 5.26 and forwards the packet to node two.

- At 10.4146 node two selects a route in the fifth entry (3 hops) in Table 5.27 and forwards the packet to node one.

- At 10.4198 node one selects a route in the fifth entry (2 hops) in Table 5.28 and forwards the packet to node three.

- At 10.4247 node three selects a route in the fifth entry (1 hop) in Table 5.29 and forwards the packet to node four.

Transmitting data packets from node zero to node four is shown in Figure 5.21.

Table 5.26: Routing table of node 0 after updating

Table 5.27: Routing table of node 2 at the time of forwarding packet number 5

Table 5.28: Routing table of node 1 at the time of forwarding packet number 5

Table 5.29: Routing table of node 3 at the time of forwarding packet number 5

Figure 5.21: Node 0 transmits data packets to node 4

Due to the movement of nodes, routing tables may frequently updated. At time 69.4509 node zero received an Update packet (Table 5.31) from node two. Table 5.30 shows the routing table of node zero at the time of receiving the packet. As a re-sult, node zero updates its routing table (row 2, 3, 4, and 5 in Table 5.32. From Table 5.32 we can see that the route to node four becomes in 3 hops. Node zero continue sending the data through this route as shown in figure 5.22.

Table 5.30: Routing table of node 0 at 69.4509 sec before dealing with the update packet

Table 5.31: An update packet contains 4 entries received by node 0 from node 2 at 9.4509 s

Table 5.32: Routing table of node 0 at 69.4509 sec after dealing with the update packet

Figure 5.22: Node 0 transmits data packets to node 4 in 3 hops

5.7 Summary

Due to the large number of control packets transmitted by the preliminary version (MDSDV0), we present a revised version in this chapter to reduce the number of control packets and improve the performance in terms of the packet delivery ratio.

The final version is referred to as MDSDV.

The main source of control packets is from the Update packets and Error Packets that are broadcast to the entire network. Thus, MDSDV uses a different mechanism to deal with these two packets. Instead of rebroadcasting Error and Update packets, MDSDV broadcasts them only to its one hop neighbours. In addition, the Full dump is unicast only to the new neighbours. When a node receives a control packet from a new neighbour, it responds by unicasting its routing table to that neighbour.

MDSDV only uses a Hello Message instead of the Hello Message and Available mes-sagethat are used in MDSDV0. A node broadcasts a Hello Message only when it has no neighbours (this rarely occurs).

Moreover, MDSDV uses another table called a Queue table to queue packets if a route to the destination is not available.

Appendix A presents the performance comparison between the preliminary version and final version of MDSDV. The results show that MDSDV makes dramatic im-provements in delivering data and reducing the control overhead.

Chapter 6