# Orthogonal Routing Protocol

Document Sample

```					Orthogonal Routing Protocol
Bow-Nan Cheng
ORP Overview

 Introduction / Basic Principles
 Design Goals / Key Advantages
 Protocol Specifications
 Analysis and Basic Simulations
 Packetized Simulations and Evaluation
 Conclusion and Future Work
Introduction
   Orthogonal Routing Protocol (ORP) is a
lightweight routing protocol utilizing
directional communications methods (such
as directional antennas or free-space-optics
LEDs) to relax assumptions of location to
address mapping while providing for efficient
medium reuse. ORP provides connectivity
under extreme conditions of high-speed
mobility, connectivity disruptions and minimal
information (ie: lack of GPS localizations
etc.) with relatively high spatial reuse.
ORP Basic Concepts
   Assuming directional
transmissions either
through FSO transceivers
or directional antennas
   Drawing two pairs of
perpendicular lines
intersecting at two different
nodes will always yield
atleast 1 intersection in
each direction between the
perpendicular line pairs
(see picture)
ORP Basic Concepts

   In many cases, nodes will have different sense of direction (ie: Node “D”
thinks “north” is to the right while Node “A” thinks “north” is up)
   Orthogonal intersections will yield a rendezvous point/node regardless of
individual node’s sense of direction
   Supposing Node A wishes to send to Node D, the path taken would be
through the intersection/rendezvous node as show in picture
ORP Design Goals

   Provide Connectivity Under Lessened /
Relaxed Information
 Lack of unified location discovery service
 Lack of universal position and orientation

   Efficient Medium Reuse
   Directionality of sending ensures security and
less collisions
   Highly Scalable
   Less state information maintained at each node
   ORP Path not necessarily Shortest Path
 ORP’s path selection can be suboptimal
 Need to show that ORP Path deviation, under
normal-use conditions, are acceptable when
compared to shortest path
   ORP in its purest form, might result in
unreachability of some nodes.
 ORP’s rendezvous node could be outside of
topology area
 Need to show that these cases are extreme or
propose an alternative (future work)
ORP Specs: Assumptions

 Neighbor Discovery (MAC Property)
 Local Sense of Direction
 Ability to Transmit Directionaly (Antenna
Property)
ORP Specs: Theory
   Key Questions:
   What are the proactive elements of the routing protocol?
Why are they necessary and what aspects can be
tweaked based on usage scenario?
   What are the reactive elements of ORP and why were
some design decisions chosen over others?
   How do we address issues with non-ideal situations
where packets stray from being forwarded in the
orthogonal direction?
   How does ORP recover from route errors and prevent
potential routing loops?
   What are some ways ORP deals with sparse and highly
mobile environments?
ORP Specs: Proactive Elements

 Goal: Establish Rendezvous-node-to-
destination routes
 Tweak Specs: Announcement interval, Route
timeout
ORP Specs: Proactive Elements

   ORP Announcements
   Using local sense of
direction, each node sends an
ORP announcement packet in
orthogonal directions

   ORP Forwarding
Table Build
   Upon receipt of ORP Broadcast
PKT, build forwarding table
(NB ID – neighbor ID, Dir –
Direction, Dest ID – Source
   If TTL on ORP Broadcast
Packet not expired, send
packet along path in same
direction (send transceiver
transceiver)
ORP Specs: Reactive Elements

   ORP Route Request
   When a node receives an ORP
RREQ, check to see if we
have the destination ID in
our forwarding table
   If destination ID not in
our forwarding table:
   Add 180 degrees to the
orientation of the
it and send out of nearest
transceiver
   Else
   Send ORP Probe ACK packet
back through transceiver we
ORP Specs: Reactive Elements

 Goal: Establish the Source-to-rendezvous-
node route
 Source Based routing vs. Next Hop routing
 Easy to update routes
 Forwarding table search easy

 Canpotentially encode trajectory into packet
 New paths can be encoded into packet header quickly
ORP Specs: Forwarding Tables

   Note: only 1-hop tables     ORP Forwarding
maintained. Because of          Table
nature of ORP
Neighbor Node ID
tables might not          Transceiver ID (direction)
include all immediate 1
hop neighbors               Destination Node ID

Expiry Time
ORP Specs: Data Forwarding

   Data Packet
Forwarding
   - When a node receives an Data
Packet, check to see if we
have the destination ID in our
forwarding table
   - If destination ID not in our
forwarding table:
   - Add 180 degrees to the
orientation of the transceiver
that received it and send out
of nearest transceiver
   Else
   Send it in the direction of
destination
ORP Specs: Packet Deviation
Correction
   Problem: real-world
cases usually don’t
have nodes aligned in
grid-like fashion.
Deviation in forwarding
along a line can
severely mess up ORP
forwarding
   In example shown,
source node S, though
intending to send in
orthogonal directions,
ends up sending in
directions far from
orthogonal.
ORP Specs: Packet Deviation
Correction
   Three Step, Three State Method
   Each RREQ and Announcement packet maintains 2
   Deviation
   Deviation State
   Initial deviation is recorded in “deviation” variable in
packet header and deviation state set to 1
   After 2nd node receives packet and sees deviation state
set to 1, forward packets in opposite direction of receipt –
2*deviation and set deviation state to 2
   After 3rd node receives packet, forward packets in
opposite direction of receipt + deviation and set deviation
state back to 1
ORP Specs: Packet Deviation
Correction Example
ORP Specs: Loops and Mobility

 ORP assumes no loops because all packets
are being forwarded in opposite directions
ensuring forward forwarding
 In highly mobile environments, route entry
timeout is reduced and announcement
interval frequency increased. Because of the
directionality of the sending signal, medium
reuse is ok
ORP Analysis and Basic
Simulations
   Key Questions
 Are there certain conditions in which ORP cannot
successfully deliver a packet? What is the upper
bound on the source-destination reachability in
ORP?
 How much state information does each node on
average need to maintain and how does this
compare with other protocols in terms of
scalability?
 How inefficient is ORP path selection compared
to shortest path. Are these results an acceptable
sacrifice for connectivity?
ORP: Reach Probability Upper
Bound
   Methodology: Orthogonal lines drawn from source and
destination. Intersection points measured and if all
intersection points outside of topology area, then destination
is unreachable given orientation and position of source and
destination
ORP: Total State Information
   To measure scalability, it is important to see how
much state information needs to be maintained in
the network. ORP was found to need to maintain
order N3/2 states even for varying topologies
ORP: Shortest Path Inefficiency
   The ORP Path selected vs. Shortest path for a
number of topologies was measured. On average,
in symmetrical topologies like a circle or square,
ORP Path was comparable to Shortest path.
ORP: Packetized Simulations
   Network Simulator used for simulations
   Key Questions:
   What amount of state is maintained in ORP under
random topologies and real-world conditions and how
does it compare with other protocols?
   What is the level of connectivity in random networks
using ORP?
   What happens to ORP when mobility enters the
equation? Are packets still able to be successfully
delivered?
   How does ORP's sending of control packets compare
with DSDV,AODV, and other routing protocols?
ORP: NS2 – Total State vs. Number
of Nodes
   Under grid and random topologies, the total state
maintained in the network vs. the number of nodes
was measured. As expected, the fitted curve was
order N3/2
ORP: NS2 – Frequency of State
Information
ORP: NS2 – Spread of State
Information in Topology
   In the grid topology, the edge nodes seem to
maintain more state. This is only somewhat
the case in random topologies

```
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
 views: 5 posted: 12/28/2011 language: pages: 27