1. O C T O P U S Scalable Routing Protocol For Wireless Ad Hoc Networks
Lab Chief Engineer: Dr. Ilana David
Instructor: Roie Melamed
- Lily Itkin - Evgeny Gurevich - Inna Vaisband -
4/17/2018

2. Location Based Routing Protocols
Proactive protocols
continuously updates the “reachability” information at all the network nodes
when a route is requested, it is immediately available
Problem: waste wireless resources for handling frequent updates, especially for large, highly mobile networks
Reactive protocols
discover routes only upon demand
involve some sort of “global search” which can causes a significant delay
Problem: very slow, high overhead for each request
Octopus - Hybrid protocol - combines the advantages of both approaches
Cheap maintenance of the proactive part (Core module)
Low-overhead location time - reactive part (FL module)
Simple protocol
4/17/2018

3. Octopus’ Grid
The space is divided to horizontal and vertical strips The division is related to a (0,0) point and not affected by the nodes’ locations
Each node knows its vertical and horizontal strips
100
200
300
400
500
600 a b c d e j f g h i
4/17/2018

4. Core Module: The Neighbor List (proactive part)
Every timeout, each node broadcasts its ID and location.
Each node in a range of 250m receives this message and updates its one-hop neighbor list accordingly.
100
200
300
400
500
600
updates the list
updates the list
updates the list a b c d e j f g h i
updates the list
updates the list
4/17/2018

5. Core Module: The Strips DB (proactive part)
End Node j initiates the update of its strip.
At the end, the east table of node a is {b, c, d, e, j}.
j,e,d,c,b,a
j,e,d,c,b
j,e,d,c
j,e,d
100
200
300
400
500
600 a b c d e j f g h i
4/17/2018

6. FL Module: Locating the Target (reactive part)
Example: Node b wants to transmit data to node h, whose location node b doesn’t know h?
100
200
300
400
500
600
source h? a h! b c d e j h!
start communicating f
access g h
target
4/17/2018

7. Project Workflow Analyzing results Simulations Start Point
building relevant tables/graphs
extracting bottle-neck parameters
Simulations
writing scripts
executing scripts
Start Point
Implementation of the basic algorithm
(Project I)
Finding Solution
functionality updates/additions
design optimizations
system/algorithm parameters
Code Updates
design
implementation
testing
4/17/2018

8. Functionality Updates/Additions Motivation
Low success rates (on large grids):
entries found by Find Location module (found ~ 85%)
reply queries returned to the source node (replied ~ 80%)
targets reached from source (received ~ 65%)
Low success rates (on large grids):
entries found by Find Location module (found ~ 85%)
reply queries returned to the source node (replied ~ 80%)
targets reached from source (received ~ 65%)
4/17/2018

9. Functionality Updates/Additions - contd
Sending directions
[1 direction] x [4 sendings] (default) Four directions (North, South, West, East) are being scanned one after another - one direction at a time
[2 directions] x [2 sendings] (optimization) Four directions are being scanned in pairs (North + South, West + East)
[4 directions] x [1 sending] (optimization) Four directions (North, South, West, East) are being scanned simultaneously
[2 directions] x [4 sendings] (optimization) Eight directions are being scanned in pairs (North + South, North-East + South-West, West + East, South-East + North-West)
[4 directions] x [2 sendings] (optimization) Eight directions are being scanned by quartets (North + South + West + East, North-East + South-West + South-East + North-West)
4/17/2018

10. Functionality Updates/Additions - contd
Considerations
Scanning less directions each time (e.g. 1 x 4, 1 x 8)
increases the average search time
decreases the found success rate, because of the chance that the searched mobile node will move to the area that is not in the currently searched direction
Scanning more directories each time (e.g. 4 x 1, 8 x 1)
overhead in resources
high success rates
Conclusion
The total number of sending directions and number of directions sent simultaneously should be determined according to user’s request and resources
4/17/2018

11. Functionality Updates/Additions - contd
Reply routing modes
As soon as the searched node is located, the source should be informed. This can be done in 2 ways:
by GF algorithm (default)
by FL_REPLY algorithm (optimization)
Considerations
Default: the natural way to implement the reply to source is via Geographic Forwarding, because the location of the source is known in the moment of the reply
Problem: the accessibility of the access node from the source via FL ensures the accessibility of the source from the access node via FL (in static mode), but does not necessary means the source will be reached from the access node using GF
Conclusions
The empiric results determined that there is no significant difference between the methods, which means that the problem appears only in very specific configurations
4/17/2018

12. Functionality Updates/Additions - contd
Example:
Node a (source) wants to send data to node e (target)
Node e (target) located by node d (access) via FL
The reply from node d (access) to node a (source) via GF fails
100
200
300
400
500
600 f
target e GF d
access
source a b c FL FL FL
4/17/2018

13. Functionality Updates/Additions - contd
Establishing connections modes
100
200
300
400
source – access – source – target (with reply) the access node replies to the source node, which initiates communication with the target
source
initiates communicating a
target g h
access
100
200
300
400
source – access – target (without reply) request is sent directly from the access node to the target node, which initiates communication with the source
source a
initiates communicating
target g h
access
4/17/2018

14. Functionality Updates/Additions - contd
Conclusion
The empiric results determined that the rate of the received packets without reply is significantly higher than the rate of the received packets with reply
4/17/2018

15. Functionality Updates/Additions - contd
Absolute/Estimated Location There are several options of treating the location to which data should be sent, considering the mobility of the system nodes:
The specified location is the most reliable, although was supplied some time ago. Data is sent to the specified location (default)
The specified location is not reliable enough. An estimated location is calculated based on specified location, target’s velocity (a vector) and time since the location was supplied. Data is sent to the estimated location (optimization)
Basic assumptions:
The velocity of each node is constant during all time of the simulation.
A node changes direction only when it reaches the randomly predefined destination.
The grid is large enough, so nodes rarely change direction.
Estimation:
The location can estimated once – at the moment the sending is originated
The location can be re-estimated after each hop on the route from sender to the target.
4/17/2018

16. Functionality Updates/Additions - contd
Conclusions
The empiric results determined that sending data to the estimated location gives higher success rates than sending to the original location
4/17/2018

17. Functionality Updates/Additions - contd
Cache
The nodes that are located during reactive requests are stored in cache of the nodes in the route
During the reactive requests, FL/GF are initiated only if the searched node is not found in cache
When cache is activated, the timeout parameter defines when the data stored in cache is valid and when it is not
Conclusions
Naturally the found success rates are higher and the received success rates decrease when cache option is activated
Yet, the economy of the system resources (forwardings per packet) is significant
The final decision is a matter of users’ needs and resources
4/17/2018

18. Functionality Updates/Additions - contd
4/17/2018

19. Functionality Updates/Additions - contd
Core and FL Queues
Each time a node sends a packet it is copied to the relevant queue
When the node makes sure the next hop has received the packet (by “hearing” next hop redirecting the packet), it is deleted from the queue
In case the packet was not deleted from the queue during timeout interval, it is being rescheduled
Motivation
The optimization prevents discontinuances in packet transmission
4/17/2018

20. Functionality Updates/Additions - contd
Example: disconnection of transmission
the expected receiver gets out of the transmission range => the packet is lost
there are no nodes in the transmission range of the receiver => the packet is lost
100
200
300
400
100
200
300
400
sender
sender
packet
lost
packet
lost h a g g a g
receiver
receiver
receiver
4/17/2018

21. Functionality Updates/Additions - contd
Conclusions
The empiric results determined that all success rates were improved
No resource overhead
4/17/2018

22. Functionality Updates/Additions - contd
Bypass – Core and FL
The optimization is used when there are no available nodes (receivers) in the sending direction
When the mode is activated, the sender chooses an alternative route that exceeds the strip limit and bypasses the dead area
The route returns to the original strip as soon as possible
100
200
300
400
500
600 a e b d FL FL BP BP c
4/17/2018

23. Functionality Updates/Additions - contd
Conclusions
The empiric results determined that using bypass optimization improves the success rates. The improvement is most significant in the medium grid spaces
4/17/2018

24. Functionality Updates/Additions - contd
Validate DB The entry is defined as not a valid neighbor and being deleted from the node’s DB lists (one-hop neighbors and strips)
by Location
When estimated location exceeds the limits of the neighbors lists
Estimated location is being calculated based on the DB current and previous locations
by Time
Timeout after the last update
Conclusions
The empiric results determined that the reliability of the DB is higher when the neighbors lists are validated by Location and by Time
4/17/2018

25. Functionality Updates/Additions - contd
Two-hop neighbor table An extra table managed by Core module.
decreases the overhead of the reactive FL module
increases the overhead of the proactive Core module
Results
Slightly higher success rates
Significantly larger data-bases to maintain
Significantly higher overhead per packet
Conclusions
The disadvantages supersede the advantages
4/17/2018

26. Functionality Updates/Additions - contd
Unstable Nodes
the basic assumption that all nodes are available at all times is not accurate
in fact, nodes may turn on and off from time to time due to numerous reasons (low battery, no reception etc)
to analyze real-life connectivity, portions of nodes were defined as not reachable in random intervals of time
Results
as it was expected the success rates are inversely proportional to the number of the non-stable nodes.
4/17/2018

27. Functionality Updates/Additions - contd
4/17/2018

28. Porting to Linux Motivation: Overhead: Conclusions
Failure to run simulations on large grid-spaces
Enabling simulation control from remote location
Testing the results in different environments
Overhead:
Reinstallation of NS2 under Linux environment
Porting of Octopus modules into NS2 under Linux environment
Adjustment of simulations’ scripts to Linux environment
Conclusions
The problem of simulations on large grid-spaces was solved
Simulation results found to be similar in both environments
4/17/2018

29. Development Environment
Platform
The protocol is implemented in NS2, discrete event simulator targeted at networking research
The protocol is written in C++ and OTcl
The test environment written in CShell and Tcl
The protocol and tests are supported in Cygwin and Linux environments
System Parameters
Numerous system parameters were expected to impact simulation results and needed fine-tuning based on empirical experiments
These parameters were defined so that they can be easily changed
Among others, these parameters include Strip Resolution, Queues’ Timeouts, Number of Retransmissions, Proactive Updates Intervals etc.
4/17/2018

30. System Parameters
As an example, the Strip Resolution was found to be one of the most important parameters to influence on success rates
4/17/2018

31. Simulations
The following scripts were written in order to automate the process of running experiments
single_test.csh <parameter lists> - responsible for setting the desired configuration, running the experiment several times (for better accuracy), collecting and processing the relevant statistical data
test_all.csh <output file> - contains a list of single_test executions with different parameters
file.tcl
the actual input parameter to the NS2 application
responsible for randomly defining each node’s route on the grid during simulation
dynamically updated by single_test on each execution
4/17/2018