1345 LabManual OPNK2004

1345 Planning and Analyzing Mobile Ad-Hoc Networks
Planning and Analyzing Mobile Ad-Hoc Networks

Lab 1: DSR Route replies using cached routes
DSR is a reactive, source-route MANET protocol. Every node maintains routes to various destinations in a route cache. When Reply using Cached Routes feature is enabled, an intermediate node can to reply on behalf of the destination node if it has a valid route to this destination. Objective In this lab well study the effect of enabling route replies using cached routes in a mobile ad-hoc network running DSR. In the lab you will: 1) Learn how to configure a MANET 2) Familiarize yourself with DSR protocol attributes 3) Collect DSR and MANET related statistics and analyze results 4) Use the DSR route visualization feature Opening the Project 1. Start OPNET IT Guru. a. Double-click on the OPNET IT Guru icon on the desktop. 2. Open the Project 1345_MANETs. a. Select File / Open. b. Select Project. c. Choose 1345_MANETs.
CONFIDENTIAL INFORMATION: DO NOT DISCLOSE, FORWARD, DISTRIBUTE, SHARE, OR MAKE COPIES OF THIS DOCUMENT IN WHOLE OR IN PART. Copyright 2004 OPNET Technologies, Inc.
Page 1 of 34
d. Click on the Open button. The scenario DSR_no_cached_route_replies will appear as shown in the following figure. Note: If you do not want to do the lab yourself then you can open and follow the reference project 1345_MANETs_ref. This project has completed versions of the scenarios for this lab.
Network Description
The four clients download files from FTP Server. The application and profiles have been configured such that Client 1, Client 2, Client 3, and Client 4 download their first file 30 seconds, 35 seconds, 40 seconds, and 45 seconds, respectively, after the simulation begins. Each client downloads three more files 320 seconds, 420 seconds, and 520 seconds after its first download. For information about how to configure applications and profiles, review session 1418: Introductory Application ModelsConfiguring Standard Applications. This MANET uses DSR and the Route Replies using Cached Routes is set to Disabled. You are going to analyze the route discovery times and route replies sent by the nodes in the network. Checking Configuration 1. Right click on Client 1. 2. Select Edit Attributes/AD-HOC Routing Parameters/Ad-HOC Routing Protocol. The protocol is set to DSR. 3. Expand DSR Parameters and check Route Replies using Cached Routes attribute. It is set to Disabled.
Page 2 of 34
4. After reviewing the configuration, click Cancel to close the dialog box.
3. NOTE: All nodes in the network are configured with similar DSR configuration. 4. Attribute Route Replies using Route Cache controls whether the node will search its own route cache for a possible reply or will propagate the route request without searching. Selecting Statistics 1. Right-click anywhere in the workspace and select Choose Individual DES Statistics. 2. Expand Global Statistics. 3. Check the box against DSR and Ftp. This will enable the collection of all DSR- and FTP- related statistics. 4. Expand Node Statistics. 5. Check the box for Client Ftp and DSR. This will enable statistics for Client Ftp and DSR at node level. 6. Click OK to close the dialog box. Run Simulation 1. Click the Configure/Run Discrete Event Simulation (DES) button. 2. Click Run. 3. When the simulation completes click on Close button. Viewing Results 1. Click on Hide/Show Graph Panels icon.
Page 3 of 34
2. Select DES / Panel Operations / Panel Templates / Load with Latest Results. 3. Observe the results shown. Analyzing Results 4. Review the graphs: The default route cache expiry timer is 300 seconds. All routes in a nodes route cache are removed if they are unused for 300 seconds. Each client discovers a route when it makes its first and second FTP download requests because there is a 320 second delay between the two. Thereafter there is a download every 100 seconds (the routes are not removed from the route caches). (Refer to the Network Description section for more information).
Page 4 of 34
Each client downloads four files. The response time for the first two downloads is greater than for the next two downloads. Why?
Page 5 of 34
The route request packets are propagated all the way to the FTP Server that replies to each clients request separately. The server receives route requests from each client for the first two FTP downloads only. The clients use their cached routes for the next two downloads. Observe the total number of RREPs sent by FTP Server (6+4+3+3+3+6 = 25)
Hide Graphs Click the Hide/Show Graph Panels button Viewing Routes The DSR model includes a route visualization feature. The route taken by each packet from source to destination can be viewed in the scenario workspace. 1. Choose Protocols / MANET / DSR / Display DSR Routes from the menu. to hide the graphs.
Page 6 of 34
2. The Route Report for MANET Routes dialog box pops up. 3. Select the route between Client 1 and FTP Server.
The values in the Time column may be different in your dialog box. 4. Click the Display field for a particular time. The route is displayed on the scenario workspace.
5. View other routes. Notice that all routes are through Node 8. 6. Click Clear All Routes in the Route Report for MANET Routes dialog box. 7. Click Close. 8. Choose File / Save from the menu to save your project and scenario. Study the effect of the Route Replies using Cached Routes option 1. Switch to the DSR_with_cached_route_replies scenario. a. Select Scenarios / Switch to scenario. b. Select DSR_with_cached_route_replies. 2. This is the duplicate of the previous scenario. We saw from the route visualization that all route requests are propagated through Node 8. If we enable Route Replies using Cached Routes on Node 8 then it is likely that the route discovery times on the clients will be lowered. 3. Right-click on Node 8 and choose Edit Attributes from the pop-up menu. The Node 8 Attributes dialog box opens. 4. Expand attributes AD-HOC Routing Parameters / DSR Parameters.
Page 7 of 34
5. Set Route Replies using Cached Routes to Enabled. 6. Click OK to close the Attributes dialog box. 7. Statistics are already selected in this scenario. 8. Run the simulation: a. Click the Configure/Run Discrete Event Simulation (DES) button. b. Click Run. c. When the simulation finishes, click the Close button. 9. Click the Hide/Show Graph Panels button 11. Observe the results shown. Analyzing Results 1. Review the graphs: Route Discovery Time (current scenario) graph shows the route discovery time at individual clients for this scenario. The route discovery times for Client 2, Client 3 and Client 4 are less than that for Client 1. Why? on the toolbar.
10. Select DES / Panel Operations / Panel Templates / Load with Latest Results.
Page 8 of 34
Route Replies Sent by FTP Server graph shows the number of replies sent by the FTP server in this scenario. The FTP Server sends only 6 (3 + 3) route replies. Which node is sending the other route replies?
Page 9 of 34
Average (in Ftp Download Response Time (sec)) graph shows the comparison of average of FTP download response time for the two DSR scenarios. The average FTP response time for this scenario is lower than the previous scenario. Why?
Page 10 of 34
Comparing Discovery Time graphs show the comparison of route discovery times of each client for the two DSR scenarios. The route discovery time for Client 1 is almost the same in both scenarios. The discovery time of the other clients has dropped. Why? 2. Review these results. We enabled Route Replies using Cached Routes on Node 8 of second DSR scenario. If we look at the Total Route Replies Sent statistics of Node 8, we find that Node 8 sent the replies on behalf of FTP server. 3. To view this statistic: a. Click the Hide/Show Graph Panels button c. Expand Campus Network/Node 8/DSR. d. Select Total Route Replies Sent statistics. You can see that Node 8 has replied on several occasions. Click Close to close the panel. to hide the graphs.
b. Right click anywhere in the workspace and select View Results.
Page 11 of 34
Conclusion Because Client 1 is the first to request an FTP download, its route requests are propagated all the way to the FTP Server because there is no route to the FTP Server in the network. Node 8 caches the discovered routes. When Client 2, Client 3, and Client 4 request FTP downloads, the route that was discovered for Client 1 is already cached at Node 8. Node 8 replies to the route requests of Client 2, Client 3, and Client 4 instead of propagating the request to the FTP Server. The route discovery times and FTP download response times drop for Client 2, Client 3, and Client 4. Items 1 through 3 are true for the first two downloads because there is a 320-second delay between them. The clients remove unused routes from their route caches after 300 seconds. All four clients have the cached route to the FTP Server for the third and fourth download because there is only a 100 second delay between them. They do not need to initiate a route discovery for these download. to
4. If graphs are still open on the screen, click the Hide/Show Graph Panels toolbar button hide the graphs. Save the project from the menu options and leave it open for future labs. END OF LAB 1
Page 12 of 34
Lab 2: AODV Expanding Ring Search Analysis

Expanding ring search feature in AODV implements controlled flooding of Route Requests (RREQ) during a route discovery process. Instead of full network-wide broadcast, RREQs are transmitted to a subset of restricted hops to find a destination. After each unsuccessful attempt, the Time-to-live (TTL) value for RREQ is increased to cover more area. The attributes for expanding ring search can have a significant impact on the results. Depending on the topology and metrics of interest, TTL attributes can be adjusted to take advantage of this feature. Objectives We will analyze the effects of changing Expanding Ring Search parameters. We will observe why network topology (node deployment) plays a significant role while selecting values for these parameters. In this lab, we will Learn how to configure AODV and set its attribute Collect AODV statistics and analyze results
Network Description There are two subnets, each consisting 22 mobile node and 1 mobile router. The nodes are communicating with each other via their respective gateway routers. All these nodes are configured with random mobility and move within their respective domains (indicated by blue lines). mobile_node_0 (shown in red) is communicating with the nodes in other subnet (shown in yellow).
In this scenario MANET Traffic flows have been configured between source and destination. MANET Traffic Generator generates raw packets over IP. mobile_node_0 sends traffic for the
Page 13 of 34
nodes in the other subnet. The traffic generation is such that source node ( mobile_node_0) communicates with each destination once during the simulation for 30 seconds. Only one flow is active at a time. Gap between each flow is 20 seconds (this traffic pattern ensures that invalid and old routes are expunged from the AODV route tables before the start of next flow. This enables fresh route discovery each for each flow). 1. Switch to scenario AODV_expanding_ring_default: a. Select Scenarios / Switch to scenario. b. Select AODV_expanding_ring_default. 2. Review the AODV attributes configured on mobile_node_0 (node in red): a. Right-click on the mobile_node_0 and select Edit Attributes. b. Expand AD-HOC Routing Parameters/AODV Parameters. c. Check that TTL Parameters is set to Default. d. Expand TTL Parameters and observe the default values used for simulation. Value of 1 for TTL Start indicates that each RREQ will go to one hop for the first time. If unsuccessful to find destination, TTL value will be increased by 2 (TTL Increment). If TTL value reaches 7 (TTL Threshold) without successful route discovery, network-wide broadcast will happen. e. Click Cancel to close the dialog box. 3. Collect Statistics: a. Right-click anywhere on the workspace and select Choose Individual DES Statistics. b. Expand Global Statistics and check the box against AODV, MANET. c. Expand IP and check the box against Number of Hops. d. Expand Node Statistics and select AODV. e. Click OK to close the dialog box. 4. Run the simulation: a. Click the Configure/Run Discrete Event Simulation (DES) button b. Click Run. c. When the simulation completes click on Close button. 5. View Results: a. Click the Hide/Show Graph Panels button. b. Select DES / Panel Operations / Panel Templates / Load with Latest Results. .
Page 14 of 34
c. Observe the results shown. Observations IP.Number of Hops statistics collects the average number of IP hops taken by each data packet between source and destination for this simulation. Observe that distance between source and destination is varying between 3 and 5.
Page 15 of 34
Observe that mobile_node_0 has to send 3 RREQs for first 3 communications and 2 RREQs for next 4 communications. Why is more than one RREQs sent? Observe the route discovery time.
Page 16 of 34
Adjusting the Expanding Ring Search Parameters

In the previous scenario, we saw that the average number of hops (IP.Number of Hops) to reach destination nodes is between 3 and 5. We can adjust the TTL Start parameter, in order to facilitate RREQ to find destination and fewer attempts. 1. Switch to scenario AODV_expanding_ring_adjusted. a. Select Scenarios / Switch to scenario. b. Select AODV_expanding_ring_adjusted. 2. Change default values for expanding ring search TTL parameters. a. Right click on mobile_node_0 (node in red) and select Edit Attributes. b. Expand AD-HOC Routing Parameters/AODV Parameters. c. Expand TTL Parameters and set TTL Start to 4. d. Click OK to close all dialog boxes. 3. Statistics for AODV and MANET traffic are already enabled on global and node level. 4. Run the simulation. a. Click the Configure/Run Discrete Event Simulation (DES) button b. Click Run. c. When the simulation completes click on Close button. 5. View Results a. Click the Hide/Show Graph Panels button. b. Select DES / Panel Operations / Panel Templates / Load with Latest Results. c. Observe the results shown.
Page 17 of 34
We observe that changing TTL Start to 4 reduces the number of RREQs sent by source node. Why?
Route discovery time is reduced after increasing TTL start value as well. Why?
Page 18 of 34
Average (in MANET.Delay) graph compares the end-to-end delay of data packets in two scenarios. MANET delay includes route discovery latency, queuing delays, transmission and propagation delays. Why average end-to-end delay for packets is reduced?
5. Click the Hide/Show Graph Panels button Conclusion
to hide these graphs.
For AODV_expanding_ring_default scenario, each route request was sent out with initial TTL Start value of 1. The destination is more than 3 hops away. The source node waits for expiry time and broadcasts another RREQ with TTL 3 (previous TTL (1) + TTL Increment (2)). It has to send the third RREQ with TTL 5 to reach the destination node and discover the route. Hence we see more than one route requests being sent. For AODV_expanding_ring_adjusted scenario, changing TTL Start to 4 helps first RREQ to travel up to 4 hops. In some cases, it finds the destination in first attempt, and no RREQ retry is required by source node. This reduces the number of RREQs sent by source node. This reduces the route discovery latency as well. Route discovery time affects end-to-end packet delay in a reactive protocol. Reactive protocol (like AODV) finds route on-demand and buffers the data packet during the route discovery process. QUESTION: IS A LARGE TTL START VALUE ALWAYS BENEFICIAL? In the next two scenarios, we will study a topology where large TTL Start is not beneficial. 1. Switch to scenario AODV_high_ttl. a. Select Scenarios / Switch to scenario. b. Select AODV_high_ttl.
Page 19 of 34
Note: The source node (mobile_node_0) has been moved into another subnet where it is closer to the destination nodes. The traffic characteristics remain the same as in the previous scenario. The TTL Start value for mobile_node_0 is set to high value 5. 2. Review the AODV attributes configured on mobile_node_0 (node in red). a. Right click on the mobile_node_0 and select Edit Attributes. b. Expand AD-HOC Routing Parameters/AODV Parameters. c. Expand TTL Parameters is observe TTL Start is set to 5. d. Click Cancel to close the dialog box. 3. Statistics are already enabled on both global and node level. 4. Run the simulation: a. Click the Configure/Run Discrete Event Simulation (DES) button. b. Click Run. c. When the simulation completes, click the Close button. 5. View Results: a. Click the Hide/Show Graph Panels button. b. Select DES / Panel Operations / Panel Templates / Load with Latest Results. c. Observe the results shown.
Page 20 of 34
Observe that for all the communications source node has to send only one RREQ. Why?
The destination nodes are one or two hops away; hence first RREQ is able to find them. But setting large TTL value will allow RREQ broadcast by nodes that are up to 5 hops away from source node. This causes unwanted flooding in the network. We can observe Total Route Requests Forwarded statistics by a distant node to confirm this. a. Click the Hide/Show Graph Panels button c. Select View Results. d. Expand AODV and select Total Route Requests Forwarded. e. Click on Show button on the right bottom corner. f. Click Close to close the View Results panel. to hide the open graph.
b. Right-click on mobile_node_11 (node marked with purple circle in middle of subnet 1).
We see that this distant node is forwarding route requests 5 times (i.e. for each route discovery). Thus RREQs sent by source node causes flooding in large area.
Click the Hide/Show Graph Panels button
to hide the open graphs.
Page 21 of 34
Setting the TTL to a lower value for the same scenario

We will now decrease the TTL Start value from 5 to 2 and see the effect of using lower value on our results. 1. Duplicate this scenario. a. Select Scenarios / Duplicate scenario. b. Type the name as AODV_low_ttl. c. Click OK. 2. Change the TTL Start attribute configured on mobile_node_0 (node in red). a. Right click on the mobile_node_0 and select Edit Attributes. b. Expand AD-HOC Routing Parameters/AODV Parameters. c. Expand TTL Parameters set TTL Start to 2. d. Click OK to close the dialog box. 3. Run the simulation. a. Click the Configure/Run Discrete Event Simulation (DES) button b. Click Run. c. When the simulation completes click on Close button. 4. Compare Results. a. Right-click anywhere in the workspace and select Compare Results. b. Expand AODV and select Total Route Requests Sent. c. Change All Scenarios to Select Scenario as shown in the figure below.
Page 22 of 34
d. Click Show button. A dialog box opens. e. Find AODV_high_ttl and check the box against it. Click OK. f. Let the graph be in the background, and click anywhere in the Compare Results Panel. g. Click Unselect to clear the graph from the panel. h. Select Routing Traffic Sent (bits/sec). i. Change As Is to average as shown in the figure below.
AODV_ttl_high scenario result AODV_ttl_low scenario result
j. Click Show button. Click OK on the dialog box that appears.
Page 23 of 34
k. Close the Compare Results Panel by clicking Close button. l. Observe the graphs. Observations We see that Total Route Requests Sent are same in both the scenarios. Why? We observe that average Routing Traffic Sent (in bits/sec) in scenario AODV_high_ttl is higher than in the scenario AODV_low_ttl. Why? Conclusion Changing TTL value from 5 to 2 did not make difference for Number of RREQ Sent as the destination was close to source node. Hence, source node was able to find route with first RREQ. In scenario AODV_high_ttl, each RREQ is re-broadcasted by neighbors that are up to 5 hops from source node. Where as in AODV_low_ttl scenario, this broadcast was limited to 2 hops. This reduces the unwanted flooding of RREQ in the network and hence reduces the average Routing Traffic Sent. We can observe that distant node (mobile_node_11) does not forward any RREQ in AODV_low_ttl scenario. 1. Right-click on mobile_node_11 (node with purple circle in the middle of subnet 1). 2. Select View Results. 3. Expand AODV and select Total Route Requests Forwarded. It should be empty (i.e. no results available for this statistics). Thus, we saw in this lab that configuring expanding ring search attributes will depend upon the network topology and deployment. User has to analyze his/her topology and traffic pattern to make the best use of these available attributes.
6. Click Hide/Show Graph Panels
to hide the graphs.
7. Select File/Save to save the project. Leave it open for next lab. END OF LAB 2
Page 24 of 34
Lab 3: OLSR - MPR Flooding Concept

OLSR is a proactive routing protocol. It takes advantage of Multi-Point Relays (MPR) flooding to reduce the control overhead in the network. Each node selects a neighbor as relay point (MPR node) to forward its control packets to its two hop neighbors, thus implementing a controlled flooding. MPR flooding concept is said to be more helpful in a dense or clustered network rather than a sparse network. In this lab well see if this is true and analyze the reasons. Objective In this lab, we will Learn how to configure OLSR Learn about OLSR statistics Analyzing OLSR MPR flooding concept
Network Description The scenario represents a MANET network of 500 x 500 meters with 50 nodes. Each node is configured to run OLSR with default parameters. The communication range of each node is configured to 250 meters with the help of the Rxgroup Config utility. Thus, two nodes at maximum distance (end edges of the scenario) will require at least one intermediate node to communicate. The node placement in two scenarios for this lab differs, though the node characteristics remain the same. IP Traffic demands are configured between some nodes. IP Traffic demand sends tracer packets to record routes taken by the packet and help in visualization. 1. Switch to scenario olsr_distributed_network. a. Select Scenarios / Switch to scenario. b. Select olsr_distributed_network. Note: 50 nodes in this scenario are distributed over a 500 x 500 meter area. This network represents a sparse/distributed network. 2. Review the configuration on any node. a. Right click on any node and select Edit Attributes. b. Expand AD-HOC Routing Parameters. c. Observe AD-HOC Routing Protocol is set to OLSR. d. Click Cancel to close the dialog box. 3. Select the Statistics.
Page 25 of 34
a.
Right click on workspace and select Choose Individual DES Statistics.
b. Expand Global Statistics and expand OLSR. c. Select all the OLSR statistics. d. Similarly, expand Node Statistics and expand OLSR. e. Select all OLSR statistics.
4. Run the simulation: a. Click the Configure/Run Discrete Event Simulation (DES) button b. Click Run. c. When the simulation completes click on Close button. 5. View Results: a. Right-click anywhere in the workspace and select View Results. You can also view results by clicking the View Results button. b. Expand OLSR in Global Statistics and select MPR Count statistics. c. Change the filter from As Is to moving_average. This statistics shows the number of MPR nodes in the network at a given time.
Page 26 of 34
Note the number of MPR nodes is 9. Observe that MPR count initially increases till 45, then reduces to 9 and remains there throughout. Why? Answer: Initial high MPR count value happens at the time when each node is in process of learning its neighbors and two hop neighbors. When the topology is diffused in the network, each node has full topology information to calculate its MPR. Hence the count decreases. 6. Click Close to close the panel. 7. Find MPR nodes in the network a. Right click anywhere on the project editor and select Find Top Results. This helps us view the top results for a given statistics from all the values for the current scenario. b. Expand the Node Statistics/OLSR. c. Select MPR Status statistics and click on Find Top Results button. d. Click on the Graph button of the dialog box that appears.
Page 27 of 34
e. This will generate a graph as shown below.
MPR Status statistic represents the status of individual node for being an MPR for a given simulation run (where the value 1 represents MPR and 0 represents non-MPR). We observe that 9 nodes were selected as MPR throughout the simulation.
Page 28 of 34
8. Pull the graph in the rightmost side of the screen. 9. Close both the panels that were used to generate this graph. 10. Identify the nodes selected as MPR in this scenario. a. Select View and click on first item Show Network Browser. This will open a window frame on left side with the list of all nodes in the network. b. Observe the node name shown as MPR in MPR Status graph (mobile_node_57). c. Select mobile_node_57 in this network browser list. This will circle the node in the scenario. Note: The order of nodes in your graph can be different. d. Observe the second name in MPR Status graph (say, mobile_node_56). e. Press Ctrl and select mobile_node_56 in network browser. This will circle mobile_node_56 in scenario retaining the previous selection. f. Perform this for the all nodes that were MPR throughout the simulation. 11. When finished, select View/Show Network Browser to close the browser. 12. Click Hide/Show Graph Panel button to hide the graph.
13. Observe the nodes selected as MPRs (figure shown below).
14. Visualize the routes taken by demand tracer packets: a. Click on Protocols/IP/Demands/Display Routes for Configured Demands.
Page 29 of 34
b. Expand mobile_node_17/mobile_node_43 and select the row. c. Click at No on the Display column on right hand side. Making it Yes will show the route on the scenario.
Observe the route. We see that route taken goes through the MPR node mobile_node_70.
Changing the Placement of the Node to Form a Clustered Network

Now we are going to change the node placement such that same nodes form a clustered network. Well run OLSR and observe the MPR algorithm and flooding efficiency. 1. Switch to scenario olsr_clustered_network. a. Select Scenarios/Switch to Scenario. b. Select olsr_clustered_network.
Note: Here same nodes are clustered into five groups (clusters).
Page 30 of 34
2. Turn-off the automatic node resizing feature to clearly see the nodes in cluster. a. Select View/Layout and uncheck Automatic Icon Scaling. 3. Global and Node Statistics are already enabled. 4. Run the simulation. a. Click the Configure/Run Discrete Event Simulation (DES) button. d. Click Run. e. When the simulation completes click on Close button. 5. View Results. a. Click on Hide/Show Graph Panels button b. Select DES/Panel Operations/Panel Templates/Load With Latest Results. c. Observe the graphs.
We observe that MPR Count has greatly reduced for the clustered scenario. Why?
Page 31 of 34
We also observe that Total Hello Messages Sent remains the same in both networks whereas Topology Control (TC) Traffic Sent reduces for clustered scenario. Why?
6. After observing the graphs, click Hide/Show Graph Panel button 7. Identify the MPR node in this scenario
to hide the graphs.
a. Right click anywhere on the project editor and select Find Top Results. b. Expand the Node Statistics/OLSR. c. Select MPR Status statistics and click on Find Top Results button. d. Click on Graph button of the dialog box that appears. Observe that only mobile_node_56 was MPR throughout the simulation. e. Close all graph related windows. f. Find mobile_node_56 in the network. i. Select View and click on first item Show Network Browser. ii. Select mobile_node_56 and select View/Show Network Browser again. g. Close all the windows related to generating this MPR Status graph. Conclusion In the olsr_distributed_network scenario, nodes were spread all over the space. One intermediate hop is required for communication between two end nodes (nodes at two opposite ends of network). We observed that many nodes were chosen as MPR. MPR algorithm works on the concept of Reachability. A node (say X) calculates reachability for its one-hop neighbors (say neighbor node Y and Z) to its two-hop neighbors. The neighbor with the highest reachability is selected as Xs MPR. For olsr_distributed_network, center nodes have higher reachability as compared to edge nodes. Since all nodes were distributed (not clustered), their reachability differed with respect to individual source nodes. Hence we see many MPRs.
Page 32 of 34
In olsr_clustered_network scenario, the nodes in middle cluster have higher reachability than nodes in the edge clusters. But unlike the previous scenario, all the nodes in center cluster are close to each other, hence all having similar reachability with respect to all source nodes. Hence we see one node from the middle cluster being selected as the MPR. Only MPR nodes generate and forward TC messages. This reduces the Total TC Traffic Sent in olsr_clustered_network. Hello messages are sent periodically by each node and are never forwarded. Because the number of nodes in the network is same for both scenarios, there is no change in Total Hello Messages Sent. In this lab, we analyzed the MPR flooding concept of OLSR. We observed how network topology and node placement could affect control traffic overhead.
END OF LAB 3
Page 33 of 34
Page 34 of 34

1345 LabManual OPNK2004

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1345 LabManual OPNK2004

Uploaded by

Copyright:

Available Formats

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

b. Right click anywhere in the workspace and select View Results.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Lab 2: AODV Expanding Ring Search Analysis

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Adjusting the Expanding Ring Search Parameters

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

5. Click the Hide/Show Graph Panels button Conclusion

to hide these graphs.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Click the Hide/Show Graph Panels button

to hide the open graphs.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Setting the TTL to a lower value for the same scenario

1345 Planning and Analyzing Mobile Ad-Hoc Networks

AODV_ttl_high scenario result AODV_ttl_low scenario result

j. Click Show button. Click OK on the dialog box that appears.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

6. Click Hide/Show Graph Panels

to hide the graphs.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Lab 3: OLSR - MPR Flooding Concept

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Right click on workspace and select Choose Individual DES Statistics.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

e. This will generate a graph as shown below.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

13. Observe the nodes selected as MPRs (figure shown below).

1345 Planning and Analyzing Mobile Ad-Hoc Networks

Changing the Placement of the Node to Form a Clustered Network

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

to hide the graphs.

1345 Planning and Analyzing Mobile Ad-Hoc Networks

1345 Planning and Analyzing Mobile Ad-Hoc Networks

You might also like