1941_lab

8/2/2019 1941_lab

1/44

1941Understanding MANET Model Internals

and Interfaces

CONFIDENTIAL RESTRICTED ACCESS:

This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.

2008 OPNET Technologies, Inc.

8/2/2019 1941_lab

2/44

8/2/2019 1941_lab

3/44

INSTRUCTIONS FOR LAB SETUP:

1. When you download all lab files, you must modify the following preferences in yourenvironment (Edit->Preferences and search and replace the preferences described below):

a. Assuming that you are downloading the files to c:\op_models folder, add that folder asthe first line against mod_dirs preference.

b. Include c:\op_models to the compiler flag as follows

i. comp_flags_common: "/W3 /D_CRT_SECURE_NO_DEPRECATE /IC:\op_models /IC:\PROGRA~1\OPNET\145~1.A\models\std\include"

ii. Also consider the OPNET version. If you have a version later than 14.5, replace145~1.A with the version you have installed.

c. We also recommend you change the following preferences.

i. kernel_type: development

ii. tool_open_save_behavior: never_browse

iii. process_edit_close_on_save: TRUE

iv. des.configuration_mode: detailed

2. If you are attempting to execute these labs in a few releases after 14.5 PL8, it is recommendedyou delete all .obj file from C:\op_models folder where the downloaded lab files reside. Thenbefore executing the first lab, force recompile all models. This can be done as: DES-

>Configure/Run Discrete Event Simulation->Execution->Advanced->Compilation->Check the

box Force model recompilation.

3. The exact results and event numbers described in traces in these labs may change in futurereleases. However you will observe the same patterns.

8/2/2019 1941_lab

4/44

1941 Understanding MANET Model Internals and Interfaces

CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc. 2008 OPNET Technologies, Inc. Page 1

Lab 1: AODV Customization

Overview

AODV (Ad-hoc On-demand Distance Vector) is one of the most popular MANET routing protocols.

OPNET provides a detailed, open source code AODV model based upon RFC 3561. Upon arrival ofdata, if no route exists, AODV broadcasts a route request to the destination. Each intermediate hop

automatically builds a reverse route to the source and also rebroadcasts the route request. The

destination replies to the first route request and sends a route reply in the direction it was received.

AODV is expected to find shortest hop paths with these mechanisms between the source and thedestination.

Objectives1. Enhance AODV functionality to perform minimum cost routing instead of minimum hop

routing.

2. Compare the performance of min cost AODV with the min hop AODV on a simple network.

3. Discuss pros and cons of this customization.

AODV Customization Design

Before implementing the extensions of AODV in OPNET, it is essential to describe a) why

customization is needed, and b) how the customization will be achieved.

As noted above, by default, AODV uses the route request-reply mechanism to find a path towardsthe destination. It is expected to be a minimum hop path. However if nodes along the hops had

different WLAN data rates, it may be advantageous to avoid low data rate nodes. For this, we need

two things:

a. Tie the notion of cost to WLAN data rate.

b. Extend AODV to make use of this concept. The extension primarily involves twothings: i) Communicate the cost in route requests and replies, and ii) Change the

default distance vector routing algorithm to prefer low cost paths instead of low hop

paths.

As done with other popular routing protocols (e.g. OSPF), we use the following formula to derive

cost of an interface: Cost = Reference bandwidth/actual data rate. We set the reference bandwidth tobe 54 Mbps noting that it is the maximum possible WLAN data rate (for 802.11g technology) in

OPNET.

In order to construct the minimum cost paths, we need to change following route requestmechanism:

Send route request: Send a route request with a nodes cost. Default: Route request is not sentwith a cost. The hop count is initialized to 0.

Forwarding a route request:

8/2/2019 1941_lab

5/44



o If the incoming route request has the same sequence number but lowers the cost of apreviously forwarded route request from the same source, forward it. Default: An

incoming route request is dropped if a route request with the same sequence numberand from the same source was forwarded before.

o While forwarding the route request, add that nodes cost to the cumulative cost.Default: Only the hop count is incremented.

Route request at the destination:

o If the incoming route request lowers the cost of the existing route, send a routereply back to the precursor. Default: If the incoming route request lowers the hop

count, only then a route reply is sent back. (We have assumed the sequence numbers

are same).

The following changes are done in the route reply mechanism: A route reply is sent by the destination with its cost and it is incremented at every hop.

Default: Only the hop count is incremented.

The source checks the cumulative cost of the received route reply, and if it is lower than theexisting route, accepts the new route. Default: The source would not receive more than 1route reply to its outstanding route request.

We have now completed the design of our proposed protocol modifications. We will now focus upon

how to implement this design in OPNET.

Getting Started

1. Start Modeler: Double click on OPNET Modeler 14.5 icon on your desktop.

2. This lab involves custom coding in AODV process model. For users who prefer not to code:you can follow the instructions henceforth, observe the code in aodv_rte process model, and

execute the scenarios for performance validation. Treat all code implement instructions ascode observe instructions.

3. For users who want to code, follow these instructions:

In Modeler window, clickFile Open Files of Type Process Model. If you are not already in C:\op_models directory, select it on the left.

Now from the file navigator window, open the process model aodv_rte_user andsave it as aodv_rte in the same directory.

ClickYes when asked to overwrite. Do not close this process model.

A. Understanding the Changes in Data Structures

1. [OPTIONAL] The first thing in customization is to either design new data structures orenhance the existing ones. In this lab, data structures and function signatures have been

8/2/2019 1941_lab

6/44



enhanced for you. The changes are in header files aodv.h, aodv_pkt_support.h and

aodv_ptypes.h in the C:\op_models folder. They are tagged with comment 1941 lab.

B. Computing AODV Cost based upon the WLAN Data Rate:

1. Open the process model aodv_rte if not already open using File Open Files of Type Process Model. (Navigate to C:\op_models if not there already).

2. Click on the FB button. This opens the function block. Press Ctrl F and search for:implement 1. This should bring you on line 82. (Alternatively, you may scroll to line 82 or

use Edit Go to Line). We are in AODV initialization function. Here, we will discover aWLAN MAC process and get the underlying WLAN data rate using OPNET process

registry. Session 1528 teaches the use of OPNET process registry in more detail.

Right below the commented line 1941 CODE IMPLEMENT 1, implement the following code:

a. The general idea here is that each OPNET process publishes itself with certainattributes. Another process can discover any other process using these attributes.

In the above case, AODV discovers WLAN MAC process using attributesprotocol and mac_type.

3. Observe the code immediately following. Our scheme is only designed to work for singleWLAN interface nodes, so we throw an error when zero or more WLAN MAC processes are

found. Once exactly 1 WLAN MAC process is found, we will read its data rate and calculate

the cost.

4. Scroll down a little if needed, and find the commented line 1941 CODE IMPLEMENT 2(around line 102 exact line number depends upon how many lines your previous code has

used), and implement the following code:

a. In this step, you queried the discovered WLAN process for its data speed andcomputed the AODV cost. The MACRO WLAN_REF_BANDWIDTH is set to

54 million in the header block (HB) of the aodv_rte process model.

5. Now back in your function window, type Ctrl F and search for: observe 1. Around line200 (depending upon lines used in your code), you should see a custom attribute beingparsed. This custom attribute is part of the compound attribute AODV parameters.

Changing this attribute to Enabled will activate our custom AODV routing algorithm.

8/2/2019 1941_lab

7/44



C. Making Modifications to the Route Request Mechanism:

1. In the Find window, type implement 3. (Around line 2047 depending upon how earliercode is entered). You are in the function aodv_rte_route_request_send(), which generatesand sends the route request. While generating the route request, we will also pass the cost of

the interface. Pass this cost as the last argument to the function

aodv_pkt_support_rreq_option_create() as shown:

a. We have changed the signature of this function to facilitate an intake of an extraparameter. After the parameter sequence_number, dont forget to insert a

comma.

2. If the find window is not open, clickCtrl F and type observe 2. This will take you aroundline 796. You are in a function that processes received route requests. Observe how wefacilitate forwarding of lower cost route requests.

a. The function aodv_route_request_forward_entry_exists() takes the cumulative costof the route request along with source identifier and the sequence ID. The function

returns the cost of the existing forwarded route request in the return variable

existing_request_forward_entry_cost; if such an entry exists.

b. If we are not using custom AODV, or if we received a route request with an equal orhigher cost, we exit by destroying the route request. Otherwise we continue and

eventually forward this route request.

c. The function aodv_route_request_forward_entry_exists() internally resets the costof the route request to the lower value, if the received route request has a lowercumulative cost.

3. A few lines below (around line 858), find the string in comments 1941 CODEIMPLEMENT 4. Once we decide to forward this route request, we increase its cost with the

interfaces own cost. Right below it, implement the following code:

D. Modifying AODV Routing based upon Cost instead of Hop Count for Reverse Routes:

1. Continue scrolling down a few lines and find the string 1941 CODE OBSERVE 3 (aroundline 920). The function that creates the reverse route to the source

aodv_route_table_entry_create() takes the cost as the last input parameter.

8/2/2019 1941_lab

8/44



2. Immediately below, find the string 1941 CODE OBSERVE 4. This is where anintermediate node or a destination compares its existing reverse route to the source to the

information provided by the new route request.

a. First the sequence numbers are compared.

b. If the sequence numbers are the same, we compare the hop count for default AODVand cost for custom AODV. This is an instance where we have changed the distance

vector algorithm for AODV.

c. Should we accept the new route based upon the incoming cost, we update the existingroute with the new cost.

E. Making Modifications to the Route Reply Mechanism:1. Open the Find window by pressing Ctrl F and type implement 5. You will be taken around

line 2162. We are in the function where a route reply is created and sent back. Implement thecode by passing the parameter of cost as the last argument to the function

aodv_pkt_support_rrep_option_create() as shown below:

a. A minimum cost route request enabled construction of a minimum cost reverse path.Similarly a minimum cost route reply would enable construction of a minimum cost

forward path. Again as before, the signature of the above function has already beenchanged. Do not forget to put a comma after the argument

AODVC_ROUTE_REPLY.

2. Open the find window by pressing Ctrl F and type implement 6. You will be taken nearline 1393. This is the function where a route reply is received and processed. Similar to theroute request, the cost of route reply is also incremented along each hop. Right below the

line, implement the following code:

F. Modifying AODV Routing based upon Cost instead of Hop Count for Forward Routes:1. Open the find window by pressing Ctrl F and type observe 5. You will be taken near line

1486. This is where the destination of the route reply (i.e. the source) processes the routereply. Observe the conditions for accepting the route reply and updating the route. For our

minimum cost algorithm, we prefer cost over hop count. You may stop when you find the

commented line 1941: END CODE OBSERVE 5.

8/2/2019 1941_lab

9/44



2. Select File Commit and clickCompile Compile Code in the process editor window.Should any warnings/errors show up, check the code first. Should errors persist, contact one

of the TAs or the instructor. When compilation succeeds, close the process model.

G. Comparing Performance of Min-hop AODV and Min-cost AODV on a Simple Network:

1. Open the project manet_internals by clicking File Open Files of Type Project.The scenario aodv_default opens.

2. In this scenario, there are 2 ways to go from the source node to the destination: throughhigh_cost_node1 (2 hops) or through low_cost_node1 low_cost_node2

low_cost_node3 low_cost_node4 (5 hops). The WLAN data rate of high_cost_node1 is 1

Mbps and the WLAN data rates of all other nodes is 11 Mbps.

3. Right click on any node and select EditAttributes. Examine the setting of the Attribute Ad-HOC Routing Parameters AODV ParametersMin Cost Routing. It is disabled.From coding changes done in section B.4, you should know where this attribute is parsed and

how it was used in the AODV routing. Close the attribute window by clicking Cancel.

4. Execute this scenario in debug mode: ClickDES Configure/Run Discrete EventSimulation and clickRun. In the debug console, enter the following (press keyafter each line):

ODB> tstop 65

ODB> ltrace 1941_aodv

ODB> continue

5. Scroll up in the debug window.

a. Examine event 654 (subject to change for future releases for users performing this laboutside of OPNETWORK 2008). In this event, destination receives the first routerequest from source via the intermediate node high_cost1.

b. Examine event 895 (subject to change for future releases for users performing this laboutside of OPNETWORK 2008). In this event, destination receives its second route

request from the source via the node low_cost4. What happens in this event?Answer: Because the destination had already received a route request from the source

via high_cost_node1, it simply destroys the second route request. Both route requestshave the same sequence number. Since the source has already found a route (as

evident by the absence of another route request with a higher sequence number),

subsequent route requests are ignored.

6. In the debug window, type (press key after each line):

8/2/2019 1941_lab

10/44



ODB> deltrace all

ODB> continue

7. When the simulation concludes, close the window, and open the panels by clickingHide/Show Graph Panels button from the project workspace. Load results by clicking DES

Panel Operations Panel Templates Load with Latest Results. Observe trafficdrops and high delays as shown below.

8. Switch to the scenario aodv_custom (Scenario Switch to Scenario). In this scenario, youwill first activate custom AODV routing by changing the new attribute. First select all nodesby right clicking on any node and selecting Select Similar Nodes. Then right click on any

node again, and select Edit Attributes. Go to Ad-HOC Routing Parameters AODVparametersMin Cost Routing and set it to Enabled. ClickApply to Selected Objects asshown below. ClickYes in the warning window that appears subsequently.

8/2/2019 1941_lab

11/44



9. Execute the scenario in debug mode by clicking DES Configure/Run Discrete EventSimulation. ClickRun. In the debug window, type (press key after each line):

ODB> ltrace 1941_aodv

ODB> continue

10.When the scenario finishes, scroll up to examine the debug output. Around event 895 (exactevent number may differ), you should find the destination receiving the duplicate route

request with a lower cost. It does two things: a) keeps and updates the route request and b)

sends a new route reply back to the source.

8/2/2019 1941_lab

12/44



11.Around event 1074 (exact event number may differ), you will find the source accepting thisnew route reply based upon the cost.

12.Close the debug window after examining the traces. Activate the stored results panels byclicking Hide/Show Graph Panels button and clickDES Panel Operations PanelTemplates Load with Latest Results to load the results. Observe that custom AODVyielded better performance as shown below.

8/2/2019 1941_lab

13/44



Conclusion

When using OPNET for R&D, these are the broad recommended steps:

a) Make a consistent design. For example, route request forwarding mechanism was a crucial piece

of our minimum cost AODV. We forced forwarding of those requests, which reduced the cost ofpreviously forwarded requests. Without this, our minimum cost scheme would not work.

b) Change existing data structures and interacting API accordingly, or introduce new data structuresand write API around it. If you introduce a new major data structure, writing _create, _destroy, _set,

_get style functions make it very easy to extend your code. API style code writing makes

modifications easy.

c) After implementing your scheme, create small and targeted test networks to ensure it works asexpected.

d) Test your scheme on large networks and compare it to the default scheme. OPNET allows you torapidly deploy large networks under various environments (slides 5 to 7 from the presentation). You

can use parametric studies feature to compare various schemes against a changing parameter.

In this lab, you changed the internals of AODV and made it behave differently. This custom AODV

is not claimed to be superior to default AODV. One of the problems it has is long hops, which

may be undesirable. You may want to extend AODV to tackle more interesting problems; one suchbeing implementing minimum cost AODV while constraining number of hops.

OPNETs intuitive API structure makes it easy for you to absorb changes in important datastructures. Using labeled traces makes it easy to test the protocol on small and controlled scenarios.

Various utility objects (RxGroup for instance to force communication range) and easy to deploytraffic sources make target network creation a rapid process. Thus usage of OPNET makes it

possible to design and rapidly prototype various customizations of the standard AODV protocol.

END OF LAB 1

8/2/2019 1941_lab

14/44



Lab 2: OLSR Customization

Overview

OLSR (Optimized LinkState Routing) is one of the most popular MANET routing protocols.

OPNET provides a detailed, open source code OLSR model based upon RFC 3626. OLSR is aproactive routing protocol. It builds routes and maintains them independently of application data

arrival. In order to conserve bandwidth, OLSR facilitates election of MPRs (Multi-Point Relay),

which serve two purposes: a) generate topology control messages, which condense a dense mesh

wireless topology by eliminating redundancies, and b) form a small subset of data forwarders.

Objectives

1. Enhance OLSR functionality to elect MPRs based upon interface cost.

2. Compare the performance of customized OLSR with the default OLSR on a simple testnetwork.

3. Discuss further enhanced customizations of OLSR.

OLSR Customization Design

In this lab, we tie the notion of cost to that of WLAN data rate as per the previous lab (Cost =

Reference bandwidth/actual data rate, reference bandwidth = 54 Mbps). In this lab, we make use of

cost as follows: Each node advertises its cost, and maintains the cost of every neighbor. Whileselecting the MPRs, low cost neighbors are preferred over high cost neighbors as MPR candidates

even though the operation may result in a higher number of MPRs. Selecting a high number of

MPRs can make the size of TC messages bigger, and also increase number of forwarding nodes.

However the additional data rates provided by these MPRs may justify the costs.

We will implement and find out if our idea works for the simple OLSR test case we have designed.

Getting Started

1. This lab involves custom coding in OLSR process model. For users who prefer not to code:do not do anything. You can follow the instructions henceforth, observe the code in olsr_rte

process model, and execute the scenarios for performance validation. Treat all code

implement instructions as code observe instructions.2. For users who want to code, follow these instructions:

a. If Modeler is not open, double click on OPNET Modeler 14.5 icon on your desktop.

b. In Modeler window, clickFile Open Files of Type Process Model.c. If you are not already in C:\op_models directory, select directory on the left.

d. Now from the file navigator window, open the process model olsr_rte_user and saveit as olsr_rte in the same directory.

8/2/2019 1941_lab

15/44



e. ClickYes when asked to overwrite. Do not close this process model.

A. Computing OLSR Cost based upon the WLAN Data Rate:

1. This step is similar to the previous lab. In the editor window of the olsr_rte process model,click on FB to open the function block. Press Ctrl F to open the Find window and type

1941 code observe 1. Starting from line 176 to line 203, observe that we query for the datarate of the WLAN process and set the OLSR cost appropriately.

2. [OPTIONAL] Data structure and signature changes for custom functionality have been donein: olsr_pkt_support.h, and the header block (HB) of olsr_rte process model. These changes

have accompanying comments with tag 1941 lab.

B. Making Modifications to the Hello Packets:1. Every node advertises its cost in the hello packets. If the function block ofolsr_rte process

is closed, open it by clicking FB in olsr_rte process editor window again. Press Ctrl F andtype 1941 code implement 1 in the Find window. Just below line 1926, implement the

following code:

a. What about the copy and destroy procedure for the hello message? In the Findwindow, type 1941 code observe 3, which brings you to approximately line

4278. In function olsr_rte_olsr_message_copy(), observe the following code:

What is happening here is that an explicit copy of the hello message is not made.Rather, a reference count is stored on the original pointer, which is incremented

each time the packet is copied. This is an efficiency technique that can save

temporary memory increase and also memory fragmentation. Since the kernel doesnot have to allocate dynamic memory, simulation speed can also increase.

b. As for the destruction of the message, examine the code in functionolsr_rte_olsr_message_destroy():

8/2/2019 1941_lab

16/44



Here, you will examine the reference count being decremented each time the packet is

destroyed until it has reduced to 0 (which means the original copy itself is being

destroyed). At that point, the packet contents are deallocated.

This shows that code changes are not necessary for copy/destroy procs for the hellomessage.

2. After receiving a hello packet, each node records the cost of the neighbor in the associateddata structure. In the Find window, type 1941 code implement 2. You will be taken around

line 1220. Immediately below, implement the following code:

a. The data structure OlsrT_Neighbor_Set_Entry has been augmented by adding thefield cost, which you can examine in the header block (HB) of the process model.

C. Making Changes to the Default MPR Selection Algorithm:

1. Now we change the MPR selection algorithm as described in the introductory section. In theFind window of the function block, type 1941 code observe 4. You are taken around line2523. Examine the modified MPR selection algorithm:

b. Each neighbor from the neighbor set is examined.

i. First we find the neighbor with the best willingness.

ii. Modification: If willingness is equal, we find the neighbor with the leastcost.

iii. If both willingness and cost are equal, we find the neighbor with the mostreachability (strict 2-hop neighbor count) and finally with the most degree

(2-hop neighbor count).

c. We pick the best neighbor in the current iteration, put it in the MPR set andupdate the strict 2-hop neighborhood. This means we remove all the strict 2-hopneighbors that are covered by the MPR we selected. If there are more strict 2-hop

neighbors to be covered, we continue. Else we end our algorithm.

d. As you can see, the modified MPR selection algorithm picks a neighbor with thebest value of the tuple [willingness, cost, reachability, degree]. The defaultalgorithm would use the tuple [willingness, reachability, degree].

2. Scroll a little down until you see the commented line 1941: CODE IMPLEMENT 3. Here,you will implement a trace to examine which MPR nodes are selected in default as well as

modified algorithms. Implement the following highlighted code.

8/2/2019 1941_lab

17/44



a. You can recall that OLSR addresses are integers. The first function call convertsthe integer address to an IP address. The second function prints the IP address in a

user readable form. The third function obtains the name of the host given the IP

address. These IP support functions are available in the standard models and canbe used extensively for various purposes. In this exercise, we used them to create

user friendly debugging traces that should tell us exactly how MPR selection is

done.

3. Select File Commit and clickCompile Compile Code in the process editor window.Should any warnings/errors show up, contact one of the TAs or the instructor immediately.

When compilation succeeds, close the process model.

D. Comparing Performance of Default and Custom OLSR on a Simple Network:

1. Select File Open Files of Type Project manet_internals (from theC:\op_models directory). Switch to scenario olsr_default using Scenario SwitchScenario.

2. Network layout is as shown:

8/2/2019 1941_lab

18/44



Here, the destination node has 3 strict 2-hop neighbors: high_cost1, high_cost2 and low_cost1. Itselects MPRs from the set of 1-hop neighbors: low_cost2, high_cost3, and low_cost3. By default,

the 1-hop neighbor high_cost3 provides coverage to all 3 2-hop neighbors, and hence would become

the MPR. Then high_cost3 would originate a TC message and advertise the link between itself and

destination. This would create link state information on remote node source and influence routingaccordingly.

The high_cost named nodes have 1 Mbps data rates, and low_cost named nodes have 11 Mbps data

rates. With our custom MPR algorithm, we will show that the new MPR set for the destination

would contain low_cost2 and low_cost3. We will then analyze how routing will be performed fromthe source to the destination in both situations and if an improvement can be achieved.

3. Execute the scenario by clicking DES Run Discrete Event Simulation. In the debugwindow, type (press after each line):

ODB> tst 50

ODB> mltr 556 1941_olsr

8/2/2019 1941_lab

19/44



ODB> continue

a. 556 is the module ID of the manet_rte_mgr module of the destination. Refer toOPNETWORK session 1502 for more understanding of the ODB commands.

Examine the MPR selection trace.

b. Which node became MPR for the node destination? Why did the MPR selectionalgorithm terminate without considering other 1-hop neighbors?

4. Now we will examine the information repository in the node source to understand how itwill construct a graph from the available link state information. It will run the Dijkstraalgorithm on this graph to determine routes to all destinations within its domain. In the debug

window, type (press after each line):

ODB> ltr olsr_nbr

ODB> ltr olsr_tc

ODB> ltr olsr_routing_table

ODB> prod 140

a. 140 is the process ID of the olsr_rte process in node source.

b. The IP address of the node destination is 192.0.0.1.

c. At every node, the following links are added to the network graph:

i. A link is added between the node itself and every symmetric 1-hopneighbor.

ii. A link is added between every symmetric 1-hop and 2-hop neighbor aslong as the 2-hop entry is not expired.

iii. A link is added between every MPR and its corresponding MPR selectoras long as the TC entry is not expired. (MPR for the TC entry is in the

field last address for that entry).

d. Take home exercise: Draw a network graph rooted at source from theinformation repository found at the source. Determine all the possible ways toreach the node destination. What is the last hop node before the destination?

(Hint: This must be the MPR for the destination).

e. It can be verified that from the perspective of source, the shortest route to thedestination must pass through the node high_cost3.

8/2/2019 1941_lab

20/44



5. Type the following in the debug window (press after each line):

ODB> deltr all

ODB> continue

6. Close the simulation execution window when done. Click the Hide/Show Graph Panelsbutton in the project window. ClickDES Panel Operations Panel TemplatesLoad with Latest Results. Examine the poor traffic performance as shown:

Click the Hide/Show Graph Panels button again to hide the graphs. Then press Ctrl Alt D

on the keyboard. This brings a demand route browser window. Visualize the demand path as

shown:

8/2/2019 1941_lab

21/44



You may visualize all the 8 paths (traced at periodic interval of 10 seconds) by clicking Yes

in the Display column on the right. When done, close the route browser window.

a. The exact path is subject to randomness.

7. Now switch to scenario olsr_custom by clicking Scenarios Switch to Scenario. Rightclick on any node and select Edit Attributes. Examine the attribute Ad-HOC Routing

Parameters OLSR Parameters Custom MPR Enabled. Verify it is enabled. Thisattribute is already enabled on all nodes. ClickCancel to close the attribute window. You

will now execute the scenario and examine the result of the custom MPR algorithm.

8. ClickDES Run Discrete Event Simulation. In the debug window, type (click after each line):

ODB> tst 50

ODB> mltr 556 1941_olsr

ODB> continue

a. Examine the final MPR computation at node destination. Which nodes havebecome MPRs? How did the MPR customization affect number of MPRs

selected?

9. Type the following in the debug window (press after each line):

ODB> ltr olsr_nbr

8/2/2019 1941_lab

22/44



ODB> ltr olsr_tc

ODB> ltr olsr_routing_table

ODB> prod 140

a. Take home exercise: Draw the network graph from the perspective ofsourceagain by examining the link addition rules from section D.4.c.

b. Verify that low_cost2 and low_cost3 are now the last hop nodes before thedestination. We think that traffic should travel on one of these 2 last hops and

improve performance.

10.Type the following in the debug window:

odb> deltr all

odb> continue

Close the simulation execution window when done. Also repeat step 6 (page 19) to view

latest results and browse the route taken. You will notice that the route indeed goes throughone of the low_cost nodes. The traffic performance is also much better.

8/2/2019 1941_lab

23/44



a. The results are sensitive to randomness. In that case, read the following section.Close the demand browser when done.

E. Validating the Proposed Implementation for Target Performance:

1. You soon realize that the results obtained do not explain a number of things:

a. We used cost only to influence MPR selection. These do not explain why we take theroute through low_cost1 node on the first hop.

Even with our changes, it is not necessary for the last hop to be between MPR and

MPR selector from the perspective of the source. This is so, because every node

includes links between each 1-hop and 2-hop neighbors (refer to link additional ruleson D.4.c). Using those rules, here are the link state graphs maintained at source and

its neighbor low_cost1:

8/2/2019 1941_lab

24/44



source source

destination destination

low_cost3 low_cost3low_cost2low_cost2

low_cost1low_cost1

high_cost3 high_cost3

Link state graph from the perspective of

source


low_cost1

source source

destination destination

low_cost3 low_cost3low_cost2low_cost2

low_cost1low_cost1

high_cost3 high_cost3


source


low_cost1

The above picture shows that from the perspective of the source, only the 2 nodes in

the corner (low_cost2 and low_cost3) connect to the destination. These are the MPRs

due to our custom algorithm. However when low_cost1 creates the graph, it adds linkbetween the middle node (high_cost3) and destination as well. Thus a packet arriving

at the node low_cost1 may take any of the 2 possible paths, one of which goes

through the low data rate node, and other goes through the high data rate node.

In fact, we havent implemented the other significant portion to really achieve

minimum cost routing: weighing each link itself and perform Dijkstra on theweighted graph. Thus the good results we obtained in this scenario are an effect of

randomness. In order to get a true sense of whether our algorithm really works, we

will use a parametric run with different random seeds.

i. If initial random seed in a discrete event simulation is the same, exactsame sequence of events would take place, because a computer would

generate the same sequence of random numbers for the simulation.However if we changed the seed, we would get a different sequence of

events. If our algorithm is truly doing what we intend, it should show usthe same statistical behavior no matter what the random seed is. With this,now we will test our scheme with different seeds and examine the results.

2. In the current scenario, clickDES Configure/Run Discrete Event Simulation. Click thebutton Enter Multiple Seed Values. Enter the values as shown in the picture below. When

all values are entered, click the button OK in the Attribute:Seed window.

8/2/2019 1941_lab

25/44



The DES execution window should look as follows. Click the button Run.

A DES Execution manager window will open and it will run all 11 instances of thesimulation. This will take a while. Click the Close button to close this window when all runs

are done.

3. Right click in the project workspace and select View Results. Click the tab DES ParametricStudies. Go to Object Statistics source destination Traffic Received (bits/sec) time average, and click the button Set as Y-Series at the bottom. Examine the averagetraffic received versus various random seeds. The large variability indicates that received

traffic is very sensitive to the random seed.

8/2/2019 1941_lab

26/44



a. OPNET allows running multiple instances of parametric runs on different CPUs in amulti-processor machine. See the product documentation for grid computing.

4. Observe that the 2nd run has a lower throughput. Close the results window. Press Ctrl Alt Din the project window. Select 2 from the dialogue box (for the second run in the parametric

series) and clickOK. Visualize the demand as described in step D.6 (on page 19).

a. What is the last hop towards the destination? Answer: As we suspected, last hopchanged to high_cost3, which is due to all links between symmetric neighbors and 2-hop neighbors treated equally bythe neighbor low_cost1. We conclude that further

modification is needed to truly achieve min cost routing in OLSR. Close the demand

browser when done.

8/2/2019 1941_lab

27/44



Conclusion

The conclusions of the previous lab apply here as well. In addition, this lab brings out the importantconcept of proving whether your modifications really improved the performance of the default

scheme. If your modification is targeted to improve performance in a certain environment, all such

environments should be precisely identified. For example, you may achieve better results for highlymobile situations. In such cases, you can conduct parametric studies with respect to mobility.

In this lab, you changed the internals of OLSR and made it behave differently. You implementedtraces to verify that your changes were taking effect, and with the help of a small test network, you

were able to verify how your changes affect the performance of the default MPR algorithm. Then

you executed a parametric run with different random seeds and concluded that the changes are notsufficient for target performance (which is achieving minimum cost routing in OLSR).

OPNETs intuitive API structure makes it easy for you to absorb changes in important datastructures. Using labeled traces makes it easy to test the protocol on small and controlled scenarios.

Various utility objects (RxGroup for instance to force communication range) and easy to deploy

traffic sources make target network creation a rapid process. The usage of OPNETs parametric runsfeature helps you evaluate your algorithms with respect to any number of parameters (random seed

included). Thus usage of OPNET makes it possible to design and rapidly prototype various

customizations of the standard OLSR protocol.

END OF LAB 2

8/2/2019 1941_lab

28/44



Appendix D: Implementing Custom Proactive MANET protocol

in OPNETAn ExampleObjective:

Add a custom MANET routing protocol called MyProto. This protocol will use UDP port 999 tocommunicate with UDP. The protocol will be created as a child process ofmanet_rte_mgr that sits

above UDP. The protocol will implement the functionality of exchanging periodic hello messages

and adding the route to neighbors in IP Common Route Table.

Qualifying Remark:

In this example, it is assumed throughout that MyProto is a Proactive routing protocol. The

architecture of reactive routing protocols is different due to their on demand nature. In appendix C,OPNETs implementation of the reactive routing protocols will be presented in brief as a guideline.

Step 1: Add the protocol in the IP Header Files

1. Add the routing protocol to the list of dynamic routing protocol enumerated inIpT_Rte_Protocol defined in ip_rte_v4.h.

2. Add the routing protocol to the list of protocols that operate on IP Common Route Table

(code added in ip_cmn_rte_table.h)a. Define the string name for routing protocol as IpC_Rte_MyProto.

b. Add IpC_Rte_MyProto in the IpT_Rte_Proto_Type structurec. Define the macro name for the protocol (here IPC_DYN_RTE_MYPROTO)

8/2/2019 1941_lab

29/44



Step 2: Create a new child process

Create a new process model myproto_rte for the custom MANET routing protocol.

Default transition

Transition to send

periodic hello messages

8/2/2019 1941_lab

30/44



Step 3: Attach the child process to the parent manager process

1. To define the new child process myproto_rte as the child process ofmanet_rte_mgr,open manet_rte_mgr.pr.m.2. Select File/Declare Child Process Model.3. Select myproto_rte from the list of processes.4. Add the protocol specific attributes to manet_rte_mgr.pr.m

Open manet_rte_mgr.pr.m.

Select Interfaces/Model Attributes.

Add MyProto Parameters as the attribute name for the protocol. Make sure Groupname is AD-HOC Routing Parameters.

Attributes defined here will be seen while configuring the protocol at a node. Attributes

will be parsed by the myproto_rte child process model.

In this example protocol implementation, we are creating just one attribute, HelloInterval to control the periodicity of the hello message.

5. Add code in manet_rte_mgr_routing_protocol_determine() in manet_rte_mgr.pr.m toinvoke MyProto custom MANET routing protocol as shown:

module_data_ptr is populated with the routing protocol name that is configured on thisnode.

8/2/2019 1941_lab

31/44



6. If it is MyProto, invoke the child process myproto_rte and store its handle in a statevariable child_prohandle.

Step 4: Read the configured protocol at interfaces in ip_dispatch

Add code in ip_dispatch.pr.m to check ifMyProto is configured on the node (interfaces) and

then inform manet_rte_mgr that in turn invokes the myproto_rte child process.

1. Add code in the ip_dispatch_init_phase_2 () function:

Following the code-check, it sets manet_enabled to TRUE and sets the protocol name inmodule_data_ptr.

8/2/2019 1941_lab

32/44



2. Add code in the ip_interface_routing_protocols_obtain () function.

The following code reads the protocol configured on end-stations.

3. Add code in the ip_rte_proto_string_parse () function:

8/2/2019 1941_lab

33/44



4. Add code in ip_dispatch_cleanup_and_create_child_processes ():

Note: This function invokes manet_rte_mgr by calling ip_manet_rte_mgr_init(), if

MyProto routing protocol is configured on this node.

Step 5: Handle the incoming/outgoing packets at the IP layerControl and data communication is handled naturally for you, since it happens via UDP. However

there is one exception you need to be aware of. Since OPNET also implements reactive protocols,

and since reactive protocols need to do a route discovery should a route not exist, data packets needto be forwarded to reactive protocols conditionally. Your protocol is proactive. BUT you should

augment the condition to say that if the protocol is NOT MyProto, then forward the packets to

reactive protocols if needs be. This will make sure that adding your code does not break legacyfunctionality.

8/2/2019 1941_lab

34/44



Open ip_rte_support.ex.c file and add code in ip_rte_gateway_datagram_dest_get ()function:

Step 6: Add new protocol name and attributes to the list of protocols on a node

1. Add the MyProto protocol string to the list of protocols that are seen while configuringrouting protocol on router interfaces.

a. Open ip_dispatch.pr.m.b. Select Interfaces/Model Attributes.c. Select ip router parameters, then clickEdit Properties.

d. Select Interface Information from the new window that opens, then clickEditProperties.e. Select Routing Protocol(s) from the new window that opened, then clickEdit

Properties.

f. Add MYPROTO as Symbol and MyProto as Value.g. ClickOK to all open windows.h. Select File/Save to save changes in process model.

8/2/2019 1941_lab

35/44



2. Add the MyProto string to the AD-HOC Routing Protocol attribute.a. Open manet_mgr.pr.m.b. Select Interfaces/Model Attributes.c. Select AD-HOC Routing Protocol, then clickEdit Properties.d. Add MYPROTO as Symbol and MyProto as Value.e. ClickOK to all open windows.f. Select File/Save to save the process model changes.

3. Add routing protocol to the node models (here showing example formanet_station_adv.nd.m).

a. Open the node model manet_station_adv.ndm.m.b. Select Interfaces/Node Interfaces.c. Find and select the manet_rte_mgr.MyProto Parameters attribute name.d. ClickRename/Mergee. Select manet_rte_mgr.MyProto Parameters from Unmodified Attribute list of

Rename/Merge Attribute window.f. Click on the >> button.

This will add the attribute on the right-hand side of the window.

g. Change the Promotion name to MyProto Parameters.h. ClickOK.i. Find MyProto Parameters in the attribute list and change the status to set.

8/2/2019 1941_lab

36/44



j. ClickOK to close the Node Interfaces panel.k. Select File/Save to save the node model changes.

l. Select File/Close to close the node model.

Other node models in MANET Object Palette also can be changed to add MyProto routing protocolattributes.

4. Observe the changes in AD-HOC Routing Parameters after adding a manet_station nodemodel in a project.

8/2/2019 1941_lab

37/44



Step 7: Create a new packet format for the MyProto custom MANET routing protocol

In this example implementation, we create a new packet format called myproto. This packet has

only one field Packet Sequence Number as shown in the figure below.

Step 8: Detail the implementation of the myproto_rte child process

In this example implementation, we are going to do the following:

Initialize the child process

Send periodic hello message

Receive packet

Add source address in IP Common Routing Table

The state variables defined in Edit State Variable SV block are shown below:

Header files added in Header Block (HB)

8/2/2019 1941_lab

38/44



Process Initialization Function (myproto_rte_init ())

1. Call the initialization function myproto_rte_init () from enter exec ofinit state.2. Define the prototype in Header Block (HB).3. Obtain your own process handle and get the handle to IpT_Rte_Module_Data pointer.

4. Get the process handle of UDP and open the UDP connection. Determine the input andoutput stream indexes for communication.

8/2/2019 1941_lab

39/44



5. Create a receive port for this process. Note in this example implementation, MyProtocommunicates with UDP using UDP port 999. (MYPROTOC_UDP_PORT is defined as

999 in header block)

6. Create a unique protocol id for MyProto and initialize the IP Common Route Table.7. Parse protocol attributes configured by user.8. Define global statistics handle and initialize all state variables.9. Schedule periodic hello messages.

8/2/2019 1941_lab

40/44



Function to parse protocol attributes (myproto_rte_attributes_parse ())

Use op_ima_obj_attr_get() to parse the protocol attributes.

Function to handle Packet Arrival1. Add code in Exit execs ofwait state to handle invocation interrupts as shown below.

Note: Variables used in Exit execs can be defined in Temporary Variable TV block.

8/2/2019 1941_lab

41/44



2. These are the functionalities ofmyproto_rte_pkt_arrival_handle():

Access the packet

Obtain following information from the ICI added by UDPo IP address of source node of the packeto IP address of interface that received this packet

Process the packet (here: we add the entry in IP Common Route Table)

Free the address pointers

Destroy the packet

8/2/2019 1941_lab

42/44



Function to add routes to IP Common Route Table (myproto_rte_add_route ())

1. Create the subnet mask.2. Create destination prefix using ip_cmn_rte_table_dest_prefix_create().

Note IP Common Route Table entries are indexed by destination prefix.

3. Get the port information of the interface that received this packet usinginet_rte_is_local_address () and ip_rte_port_infor_from_tbl_index ().

4. Check that this entry already exists in IP Common Route Table usinginet_cmn_rte_table_entry_exists ().

5. Add new entry using Inet_Cmn_Rte_Table_Entry_Add ().

For more details on this function please refer to ip_cmn_rte_table.ex.c.

Function to send periodic Hello (myproto_rte_hello_expiry_handle ())

Create a transition on wait state to invoke myproto_rte_hello_expiry_handle () when a self-

interrupt of type MYPROTOC_HELLO_EXPIRY is received. The condition check is defined inheader block (please refer to header block snap-shot).

8/2/2019 1941_lab

43/44



This function will

Schedule the next self interrupt for hello generation,

Create and send new hello message

Function to create packet (myproto_rte_pkt_create ())

Use op_pk_create_fmt () to create hello packet. Note that we are using myproto packet format to

send hello message. Use op_pk_nfd_set_int32 () to set the values of packet fields (here Packet

Sequence Number).

Note: If packet format contains a field of type structure, associate print and destroy procedures topacket (use op_pk_nfd_set_ptr ()). Use op_pk_bulk_size_set () to set the size for the packet.

8/2/2019 1941_lab

44/44


Function to send packet (myproto_rte_pkt_send ())

1. Set the fields in ICI to pass information to UDP.a. Set rem_port with UDP communication port (here 999).b. Set rem_addr with destination address (here global broadcast addr).

2. Install the ICI using op_ici_install () (remember udp_command_inet ICI was created in theinit function).

3. Use op_pk_send_delayed() to send packet with jitter.4. Uninstall the ICI.

The implementation ofMyProto custom MANET routing protocol is complete. Create a simple

scenario of three nodes configured to run MyProto routing protocol and test the protocol.

1941_lab

Documents