Introduction to wireless ad-hoc networkrouting protocols

Speaker: 張簡稜剛碩二專 N9490001

成醫資訊室 應用系統 A 組程式設計師

References

INTERNET-DRAFT, Dynamic Source Routing protocol, 1999

Source: .J. GARCIA-LUNA, M. SPOHN Source Tree Adaptive Routing Internet Draft, draft-ietf-manet-star-00.txt, work in progress, October 1999

Ad hoc routing environment

Nodes do not have a priori knowledge of topology of network around them, they have to discover it.

Network topology changes rapid and frequently

The power supply is not permanent

Routing algorithms design considerations

keep routing table reasonably small keep table up-to-date when nodes die, move

or join require small amount of messages/time to

converge save energy

Routing algorithm types

Classify by how router obtain control information

Pro-active (Table-driven)– These algorithms maintain fresh list of

destinations and their routes.

Reactive (On-demand)– When no designed route is found, protocol

finds one. Route is not so fresh as pro-active

Reactive (On-demand) parameters

All on-demand protocols differ on the following mechanisms– How to flood-search packet and their response?– How to cache information heard from node search?– How to determine the cost of a link?– How to determine the existence of a neighbor?

You will see this in the following DSR protocol introduction

Routing algorithm types (cont)

Classify by what information router use Distance-vector

– Exchanges (target, distance)– Exchanging routing table directly, and computing optimum

path– RIP, BGR

Link-stat– Exchanges (link (u, v), status)– Exchanges link status and stores into topological database

then compute optimum path on topological database– OSPF, ad-hoc table driven protocols

Routing algorithm design approach

ORA (Optimum routing approach)– Almost all wired routing algorithms, – table driven ad-hoc routing algorithms

LORA (Least-overhead routing approach)– Limit the routing control information bandwidth

(overhead)– On-demand ad-hoc routing algorithms

Dynamic Source Routing Protocol

Reactive (On-demand) Source Route protocol INTERNET-DRAFT

– Expires 19 January 2005

Simple to demonstrate the reactive protocol– The reason that I choose it to presentation to u

DSR is based on source routing

each data packet sent carries in its header the complete, ordered list of nodes through which the packet will pass – Header[ source->b->c->..->destination]

WHY?– allows the sender to select and control the

routes used for its own packets

DSR protocol algorithm

Does route to destination is in route cache?– Yes, send data.– No, execute Route Discovery.

A problem?– The route information may be not be newest

status of the current topology

DSR Route Discovery procedure

Send RREQ packet, Route Request RREQ will floods to neighbors recursively

until destination RREQ will records the node it have passed Destination will compute a better route and

put it with RREP, Route Reply Destination replies RREP to source, and now

source knows the route to destination

Flooding Algorithm

Nodes receive the RREQ

Does target in RREQ is me?– Yes, reply RREP to initiator (sender)– No, next question.

Does initiator, route id and target is the same as the prior packet received Yes, discard the packet. No, append my address to the route records in R

REQ and boradcast RREQ to neighbors

Target replay RREP

Does route to initiator is in route cache?– Yes, send RREP to initiator– No, execute Route Discovery for initiator but

piggyback RREP on the RREQ to initiator (avoid route discover recursively)

Why not reverse the route in route record as the route to initiator?– It assumes the route is not bidirectional, this is

common status in wireless transmission

Send Buffer

Packet will be stored in send buffer if its destination address is not discovered

Packet will be stamped a stored time that it was placed in this buffer

Packet will be discarded when the stored time is expired after send buffer timeout

Buffer is FIFO Queue

Send Buffer(2)

If packet remains in the send buffer, the node will occasionally initiate new Route Discovery for the packet’s destination address

exponential back-off algorithm to limit the rate to initiate new route discovery– Doubling timeout between two successive

discovery initiated

Exponential back-off

After i collisions, a random number of slot times between 0 and 2^i − 1 is chosen– 1st collision, the wait time may be 0, 1– 2nd collision, wait time may be choose from 0,1,2

and 3– 3nd collision?

Route maintenance

In source route, each node transmitting the packet is responsible for confirming the data can flow over the link from the node to the next hop

Acknowledgement is simple in wireless network, passive acknowledgement– B can confirms receipt at C by overhearing C

transmit the packet forwarding to D

Software Acknowledgement

network has no acknowledgement foundation the node transmitting the packet can

explicitly requests a DSR-specific software acknowledgement be returned by the next node along the route

When sender receives an SA, it will not send SA request for a period of time

Software Acknowledgement(2)

Node retransmitted SA request to a node C for a maximum times and has not been received any SA reply, it marks the node C broken link and return Route Error

Flooding the Route Error to the source and node passed

Source choose or discovery another route to destination node

Source-Tree adaptive routing (STAR)

Table-driven Source: .J. GARCIA-LUNA, M. SPOHN

Source Tree Adaptive Routing Internet Draft, draft-ietf-manet-star-00.txt, work in progress, October 1999

Features

Routing approach can be adaptive between ORA and LORA

Using Source-Tree to compute the route path

Route information router had

Neighbor set Topology graph=adjacent links + source

trees of neighbors Topology graph router’s source tree Source tree route-selection algorithm

route table

Source Tree

The set of links to destinations– Each destination has only one route– source tree can be viewed as set consist of route

to each destination

Derived route path from source tree is simple and quickly

In Tree, there is only one route between any two nodes

Topology Graph cached available routes

In Graph, there is one or more routes between any two nodes

Topology Graph Source Tree Source tree stores active route set Topology Graph stores partial available

route set

In Graph, there is one or more routes between any two nodes

Link information is obtained by exchange source trees

Link information is obtained by exchange source trees

Result:– When report a link to destination failed also

indicates the new link to the destination– Not send a LSU for failed link explicitly

Exchange fail links comparison

Exchange fail links info by LSU– A discover L(B, W) failed– A LSU(B, W, failed) (explicitly report failed)– A LSU(C, W, new)

Exchange fail links info by Source Tree– A discover L(B, W) failed– Compute new ST from TG– A LSU(ST) (update implicitly failed link)

LSU structure

LSU=(u, v, l, t)– u denotes the link head– v denotes the link tail– l denotes the cost of the link– t denotes the timestamp assigned to the LSU

LSU exchange

Valid LSU– u, link head is the source of the LSU– Timestamp of LSU is greater than timestamp in

TG with the same source

Remove link in TG– If the link is not in any source tree reported by

neighbors, then delete it from TG

ORA

Send LSU under these conditions– Source tree changes– Neighbor report a outdated LSU

LORA

Keep a route as long as it leads to the destination

Not keep the optimum route Send LSU under these conditions

– Unreachable destination– New destination– Possible permanent routing loops– Cost of routes exceeding the threshold

Finished thanks!!

HAVE any question?