26.01.2014 Views

Mobile ad hoc networks (MANET)

Mobile ad hoc networks (MANET)

Mobile ad hoc networks (MANET)

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> (<strong>MANET</strong>)<br />

Circle Lecture Communication Systems<br />

Winter Term 2004/2005<br />

1 Introduction<br />

2 Media access<br />

3 Routing<br />

4 Current research areas<br />

Prof. Dr. M. Zitterbart<br />

Institute of Telematics<br />

Dr.-Ing. Kilian Weniger<br />

Outline<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 1<br />

www.tm.uka.de<br />

1 Introduction<br />

What are mobile <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong>?<br />

Wireless <strong>networks</strong> without infrastructure<br />

no base station/access points, no backbone<br />

Each terminal is host and router at the same time!<br />

Terminals may be mobile<br />

Packet-based data forwarding<br />

Routes between two devices can be several hops long<br />

– also called multi-hop <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong><br />

Ad-<strong>hoc</strong> <strong>networks</strong> are self-organizing<br />

No central components<br />

Example<br />

r<br />

transmission<br />

range r<br />

Node<br />

Link<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 2<br />

www.tm.uka.de


Example of data packet routing in <strong>MANET</strong>s<br />

transmission<br />

range<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 3<br />

www.tm.uka.de<br />

Advantages and applications<br />

<strong>Mobile</strong> <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong>: Advantages<br />

Simple, fast and cheap setup of <strong>networks</strong><br />

e.g. with 802.11b in the 2.4 GHz (ISM) band: no license required<br />

transmit power can be reduced compared to wireless infrastructure <strong>networks</strong><br />

distance to nearest neighbor can be lower than to the base station<br />

More robust concerning failure of single components due to decentralized structure<br />

Military applications<br />

formations of soldiers, tanks, planes,...<br />

Civil applications<br />

conferences, exhibitions, meetings, lectures<br />

telematics applications in traffic<br />

Extension of cell-based systems (WLAN, UMTS)<br />

Entertainment on travels (file sharing, gaming,... in trains, cars or planes)<br />

sport events<br />

<strong>networks</strong> for cabs, police,…<br />

sensor <strong>networks</strong><br />

In case of disasters<br />

<br />

<br />

In case of infrastructure failure (telephone network,..): e.g. earthquakes<br />

rescue operations, e.g. after avalanches<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 4<br />

www.tm.uka.de


Application 1: Sensor <strong>networks</strong><br />

Protection against or reaction to<br />

disasters<br />

Situation: Flood disaster<br />

Sandbags protect a dyke<br />

Support by sensor <strong>networks</strong><br />

Sandbags are equipped with<br />

sensors<br />

Sensors cooperate to detect<br />

leaks in the dyke<br />

Collection and preprocessing of<br />

data<br />

Source: Timmermann, Uni Rostock<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 5<br />

www.tm.uka.de<br />

Application 2: Vehicle <strong>networks</strong><br />

Vehicles send immediate reports to other (following) vehicles, e.g. about<br />

Traffic jams<br />

Obstacles<br />

Dangerous spots<br />

Speed controls<br />

...<br />

Demonstrator Fleetnet-Project<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 6<br />

www.tm.uka.de


Application 3: Integration with cellular systems<br />

Project IPonAir: „Integration of wireless <strong>networks</strong> with the Internet“<br />

Internet access via several<br />

intermediate terminals<br />

UMTS base station<br />

Internet<br />

WLAN access point<br />

e.g. no access network<br />

in direct range<br />

lo<strong>ad</strong> balancing<br />

Extension of<br />

access network<br />

Ad-<strong>hoc</strong> communication,<br />

e.g. for P2P or<br />

multi-player games<br />

Ad-<strong>hoc</strong><br />

communication<br />

Extension of access<br />

network<br />

Ad-<strong>hoc</strong><br />

Communication<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 7<br />

www.tm.uka.de<br />

Properties of mobile <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong><br />

Highly dynamic network topology<br />

Mobility of devices<br />

Changing properties of the wireless channel (F<strong>ad</strong>ing, multipath propagation)<br />

Partitioning and merging of <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong> possible<br />

No infrastructure<br />

No central „always on“ components<br />

Limited battery power of mobile devices<br />

Worsened by signaling traffic, e.g. of the routing protocol<br />

Limited bandwidth<br />

Worsened by signaling traffic, e.g. of the routing protocol and the MAC protocol<br />

Asymmetric/Unidirectional links<br />

Quality of connections can differ between both directions<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 8<br />

www.tm.uka.de


Motivation<br />

2. Media access<br />

Media access control is necessary to enable controlled access to a<br />

medium shared by several devices<br />

MAC algorithms for fixed <strong>networks</strong> (e.g. CSMA/CD) usually cannot be<br />

applied in a wireless environment:<br />

Construction of transceivers, being able to bro<strong>ad</strong>cast and receive on the<br />

same frequency at the same time, is difficult<br />

No collision detection at sender<br />

Signal strength degr<strong>ad</strong>es qu<strong>ad</strong>ratically with the distance<br />

Problem of hidden or exposed terminals<br />

Possible algorithm<br />

IEEE 802.11 in Ad-<strong>hoc</strong> mode with<br />

Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 9<br />

www.tm.uka.de<br />

802.11 MAC-layer: Distributed Coordination Function<br />

Sender<br />

DIFS<br />

Data frame<br />

Receiver<br />

SIFS<br />

Ack<br />

Other<br />

stations<br />

Waiting time<br />

DIFS<br />

Contention period<br />

(backoff)<br />

Data frame<br />

t<br />

Station senses medium<br />

Case 1: Medium is free for „Distributred InterFrame Space (DIFS)“<br />

Station may send the data frame<br />

Case 2: Medium ist busy<br />

Station waits till medium is free for IFS<br />

Transmission is delay by random backoff time<br />

Backoff timer is freezed when other stations are sending<br />

Ack for received data frame (after Short IFS)<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 10<br />

www.tm.uka.de


Problem of hidden terminals<br />

Hidden terminal<br />

A sends to B<br />

C does not receive A anymore<br />

C wants so send to B, Medium is free for C (CS fails)<br />

Collision at B, A does not recognize this (CD fails)<br />

A is „hidden“ for C<br />

A<br />

B<br />

C<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 11<br />

www.tm.uka.de<br />

MAC-layer: DCF with RTS/CTS<br />

Request-to-Send (RTS)/Cleat-to-Send (CTS) option<br />

Sender tansmits RTS first<br />

contains Network Allocation Vector (NAV)<br />

Receiver replies with CTS (after SIFS)<br />

Sender sends data frame and receivers sends ack (after SIFS)<br />

Other stations store NAV<br />

Virtual reservation<br />

Sender<br />

DIFS<br />

RTS<br />

data<br />

Receiver<br />

SIFS<br />

CTS<br />

SIFS<br />

SIFS<br />

ACK<br />

Other<br />

Stations<br />

NAV (RTS)<br />

NAV (CTS)<br />

Waiting time<br />

Backoff<br />

DIFS<br />

data<br />

t<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 12<br />

www.tm.uka.de


Exposed terminals<br />

Exposed terminal<br />

B sends to A<br />

C wants to send to D<br />

C must wait: CS signals an that medium is busy<br />

This is unnecessary: A is outside C‘s range<br />

C is “exposed“ to B<br />

A<br />

B<br />

C<br />

D<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 13<br />

www.tm.uka.de<br />

3. Unicast routing protocols for mobile <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong><br />

Routing protocols developed for fixed <strong>networks</strong> (e.g. RIP, OSPF, ...) cannot be<br />

applied to mobile <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong> without modifications<br />

slow convergence<br />

too much overhe<strong>ad</strong><br />

Routing protocols for <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong> must, in contrast, converge quickly and<br />

use as little bandwidth as possible for control traffic<br />

Different metrics are possible for mobile <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong><br />

Minimal number of hops<br />

Minimal delay<br />

Minimal packet loss<br />

Maximal signal stability and route stability over time<br />

Maximal battery runtime of a mobile device<br />

Maximal lifetime of the whole network<br />

e.g. until partitioning due to empty batteries of a network node<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 14<br />

www.tm.uka.de


Classification<br />

Flooding for data transfer<br />

Most simple “protocol“: Each node forwards each packet exactly once<br />

very high overhe<strong>ad</strong><br />

Proactive Routing (Table-driven)<br />

Routes to all nodes are maintained<br />

Routes are permanently available<br />

Constantly high control overhe<strong>ad</strong><br />

Reactive Routing (On-demand)<br />

Routes are determined only when needed (Route Discovery)<br />

Time delay at the beginning, as the route must be determined first<br />

Control overhe<strong>ad</strong> depends on number of connections<br />

Hybrid Routing<br />

Mixture of proactive and reactive routing<br />

There is not (yet) a one-fits-all routing protocol for mobile <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong><br />

Adequacy of a protocol depends on scenario<br />

Standardization of <strong>ad</strong>-<strong>hoc</strong> routing protocols: IETF <strong>MANET</strong> WG [3]<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 15<br />

www.tm.uka.de<br />

Principle<br />

Proactive routing protocols<br />

Nodes constantly determine routes to all other nodes in the network<br />

Approaches<br />

Distance Vector Routing<br />

based on Bellman-Ford Algorithm<br />

Each node determines for each other node<br />

– its neighbor (next hop), via which the shortest route to the specific node le<strong>ad</strong>s<br />

– the length of this route<br />

This information is periodically bro<strong>ad</strong>cast to all neighbors<br />

Example fixed network: Routing Information Protocol (RIP)<br />

Link State Routing<br />

Each node periodically bro<strong>ad</strong>casts the status of its links, together with link state<br />

information received from its neighbors<br />

Therefore, each node knows the whole network topology<br />

Shortest route to each node can be determined with Dijkstra‘s Shortest Path First<br />

Algorithm<br />

Example fixed network: Open Shortest Path First (OSPF)<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 16<br />

www.tm.uka.de


Example: Optimized Link State Routing (OLSR)<br />

Goal: Efficient flooding of Link State Information!<br />

1. Determination of neighborhood<br />

Periodic bro<strong>ad</strong>cast of HELLO messages. These contain:<br />

– Addresses of the nodes from which HELLO messages are currently received<br />

– State of the links to these node: symmetric (bidirectional) or asymmetric<br />

(unidirectional)<br />

Neighborhood relationships computable from this information<br />

– Y is a “1-hop neighbor” of X X receives HELLO message from Y<br />

– Y is a “2-hop neighbor“ of X Y X and X sees Y in a HELLO message<br />

received from Z<br />

– Y is a „strict 2-hop neighbor“ of X Y is a 2-hop, but not a 1-hop neighbor of X<br />

– Relationships are in each case defined as symmetric and as asymmetric<br />

– Example: X sees itself in a HELLO message by Y Y is a symmetric<br />

1-hop neighbor of X<br />

Delete neighborhood information after timeout as a reaction to link breaks<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 17<br />

www.tm.uka.de<br />

Multipoint Relays<br />

2. Determination of „Multipoint Relays“ (MPR)<br />

The MPRs of X are a subset of the symmetric 1-hop neighbors of X<br />

This subset is determined such that each symmetric 2-hop neighbor<br />

of X can be reached via at least one MPR<br />

Determination of the subset according to heuristics on every change<br />

detected within the 2-hop neigborhood<br />

Selected MPRs are announced in HELLO messages<br />

3. Determination of the „MPR Selectors“ (MS)<br />

The MS of X are the nodes that have chosen X as their MPR<br />

X gets to know about these nodes in the HELLO messages<br />

received<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 18<br />

www.tm.uka.de


Example OLSR I<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

Only symmetric links in this<br />

example!<br />

B<br />

H G F A D E<br />

C<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

2-hop neighbors<br />

MPR<br />

MS<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 19<br />

www.tm.uka.de<br />

Example OLSR II<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

B<br />

H G F A D E<br />

C<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

A<br />

A<br />

A, E<br />

A, G<br />

G<br />

2-hop neighbors<br />

MPR<br />

MS<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 20<br />

www.tm.uka.de


Example OLSR III<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

B<br />

H G F A D E<br />

C<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

F, D<br />

A, D, F<br />

A, D, F<br />

A, E<br />

D<br />

A, G<br />

F, H<br />

G<br />

2-hop neighbors<br />

E, G<br />

E, G<br />

E, G<br />

A<br />

A<br />

MPR<br />

D, F<br />

D, F<br />

D, F<br />

D<br />

F<br />

MS<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 21<br />

www.tm.uka.de<br />

Example OLSR IV<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

B<br />

H G F A D E<br />

C<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

B, C, D, F<br />

A, D, F<br />

A, D, F<br />

A, B, C, E<br />

D<br />

A, B, C, G<br />

F, H<br />

G<br />

2-hop neighbors<br />

E, G<br />

E, G<br />

E, G<br />

F<br />

A<br />

D<br />

A<br />

MPR<br />

D, F<br />

D, F<br />

D, F<br />

B<br />

D<br />

B<br />

F<br />

MS<br />

B, C<br />

B, C<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 22<br />

www.tm.uka.de


Example OLSR V<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

B<br />

H G F A D E<br />

C<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

B, C, D, F<br />

A, D, F<br />

A, D, F<br />

A, B, C, E<br />

D<br />

A, B, C, G<br />

F, H<br />

G<br />

2-hop neighbors<br />

E, G<br />

C, E, G<br />

B, E, G<br />

F<br />

A, B, C<br />

D<br />

A, B, C<br />

MPR<br />

D, F<br />

D, F<br />

D, F<br />

B<br />

D<br />

B<br />

F<br />

MS<br />

D, F<br />

B, C<br />

B, C<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 23<br />

www.tm.uka.de<br />

Example OLSR VI<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

B<br />

H G F A D E<br />

C<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

B, C, D, F<br />

A, D, F<br />

A, D, F<br />

A, B, C, E<br />

D<br />

A, B, C, G<br />

F, H<br />

G<br />

2-hop neighbors<br />

E, G<br />

C, E, G<br />

B, E, G<br />

F<br />

A, B, C<br />

D, H<br />

A, B, C<br />

F<br />

MPR<br />

D, F<br />

D, F<br />

D, F<br />

B<br />

D<br />

B, G<br />

F<br />

G<br />

MS<br />

D, F<br />

A, B, C, E<br />

A, B, C, G<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 24<br />

www.tm.uka.de


Example OLSR VII<br />

Determination of neighbors, MPR and MS (HELLO messages)<br />

B<br />

H G F A D E<br />

C<br />

S<br />

T<br />

A<br />

B<br />

L<br />

E<br />

!<br />

Node<br />

A<br />

B<br />

C<br />

D<br />

E<br />

F<br />

G<br />

H<br />

1-hop neighbors<br />

B, C, D, F<br />

A, D, F<br />

A, D, F<br />

A, B, C, E<br />

D<br />

A, B, C, G<br />

F, H<br />

G<br />

2-hop neighbors<br />

E, G<br />

C, E, G<br />

B, E, G<br />

F<br />

A, B, C<br />

D, H<br />

A, B, C<br />

F<br />

MPR<br />

D, F<br />

D, F<br />

D, F<br />

B<br />

D<br />

B, G<br />

F<br />

G<br />

MS<br />

D, F<br />

A, B, C, E<br />

A, B, C, G<br />

F, H<br />

S<br />

T<br />

A<br />

B<br />

L<br />

E<br />

!<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 25<br />

www.tm.uka.de<br />

Optimized Link State Routing (OLSR)<br />

Efficient flooding possible with this algorithm<br />

Source node bro<strong>ad</strong>casts message<br />

Optimization compared to the standard flooding algorithm:<br />

Not all nodes forward the message, but only the MPRs<br />

– Y forwards a message received from X, if X is an MS of Y<br />

Forwarding also done as a bro<strong>ad</strong>cast<br />

Forwarding of duplicates is avoided by the use of sequence numbers<br />

Number of selected MPRs has a direct effect on network lo<strong>ad</strong><br />

Number of MPRs should be optimal (minimal) to reduce traffic<br />

Standard<br />

flooding<br />

Efficient<br />

flooding with MPR<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 26<br />

www.tm.uka.de


Example OLSR VIII<br />

Efficient flooding of messages, example: source node B<br />

B<br />

H G F A D E<br />

C<br />

MPRs of B<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 27<br />

www.tm.uka.de<br />

Example OLSR IX<br />

Efficient flooding of messages, example: source node B<br />

MPR of F<br />

B<br />

MPR of D<br />

H G F A D E<br />

C<br />

• Nodes F and D are MPRs of B and forward the packet received<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 28<br />

www.tm.uka.de


Example OLSR X<br />

Efficient flooding of messages, example: source node B<br />

MPR of G<br />

B<br />

H G F A D E<br />

C<br />

• Node B does not forward the packet received by F and D again (sequence numbers)<br />

• Node G is an MPR of F and forwards the packet received from F<br />

• Node F does not forward the packet received by G again (sequence numbers)<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 29<br />

www.tm.uka.de<br />

Optimized Link State Routing (OLSR)<br />

Efficient flooding of link state information<br />

Each node X with MS Ø periodically sends a TC (Topology Control) message.<br />

It contains:<br />

own <strong>ad</strong>dress<br />

complete list of own MS<br />

Each node in the network collects information about MS from TC messages<br />

Network topology can be reconstructed to a sufficient extent<br />

Shortest routes can be determined according to Dijkstra<br />

Optimization: Combination (Piggyback) of HELLO and TC messages<br />

Reduction of media accesses<br />

Particular effective in <strong>networks</strong> with a high node density<br />

Only few nodes act as MPR<br />

OLSR is a „standard protocol“ (experimental) in the IETF (RFC 3626)<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 30<br />

www.tm.uka.de


Principle<br />

Reactive routing protocols<br />

A node only knows the routes it actually requires<br />

No periodic updates<br />

Tasks of a reactive routing protocol<br />

Finding a route (Route Discovery)<br />

Only when a node wants so send data to a node, but does not yet have a route to that<br />

node<br />

Maintaining a Route (Route Maintenance)<br />

Only active routes are maintained<br />

Comparison to proactive routing protocols<br />

Advantage<br />

Only routes that are actually needed are determined and maintained<br />

No periodic transmission of messages necessary less use of resources<br />

Dis<strong>ad</strong>vantage<br />

Time delay at the beginning of a communication: route has to be determined first<br />

Control overhe<strong>ad</strong> depends on number of connections and mobility<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 31<br />

www.tm.uka.de<br />

Route Discovery<br />

Example: Ad Hoc On Demand Distance Vector Routing (AODV)<br />

Sender S floods the <strong>ad</strong>-<strong>hoc</strong> network with a Route Request (RREQ)<br />

RREQ contains source <strong>ad</strong>dress S and destination <strong>ad</strong>dress D<br />

Nodes that are involved in forwarding the RREQs store the <strong>ad</strong>dress of<br />

the node from which they received the RREQ<br />

The so-called „Reverse Path“ into the direction of the sender S is built<br />

up<br />

Only works with bidirectional links!<br />

When the destination node D receives the RREQ, it answers with a<br />

Route Reply (RREP)<br />

RREP contains source <strong>ad</strong>dress S<br />

RREP is forwarded via unicast to node S (use of Reverse Path)<br />

With the forwarding of the RREPs, the so-called “Forward Path” into the<br />

direction of the destination node D is built up<br />

The Forward Path is used for data traffic<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 32<br />

www.tm.uka.de


AODV: Route Request I<br />

Source: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Z<br />

A<br />

B<br />

H<br />

S<br />

C<br />

I<br />

E<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

Node that has received a Route Request (RREQ)<br />

Node in transmission range<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 33<br />

www.tm.uka.de<br />

AODV: Route Request II<br />

Source: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Bro<strong>ad</strong>cast<br />

Z<br />

A<br />

B<br />

H<br />

S<br />

C<br />

I<br />

E<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

RREQ<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 34<br />

www.tm.uka.de


AODV: Route Request III<br />

Source: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Z<br />

S<br />

E<br />

A<br />

B<br />

H<br />

C<br />

I<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

Reverse Path<br />

Each node stores the <strong>ad</strong>dress of the neighbor from which a RREQ packet<br />

has been received<br />

Requires state maintenance in all nodes<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 35<br />

www.tm.uka.de<br />

AODV: Route Request IV<br />

Source: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Z<br />

S<br />

E<br />

A<br />

B<br />

H<br />

C<br />

I<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

The Reverse Path from each intermediate node to the sender is built up<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 36<br />

www.tm.uka.de


AODV: Route Request V<br />

Quelle: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Z<br />

A<br />

B<br />

H<br />

S<br />

C<br />

I<br />

E<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 37<br />

www.tm.uka.de<br />

AODV: Route Request VI<br />

Source: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Z<br />

A<br />

B<br />

H<br />

S<br />

C<br />

I<br />

E<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

When the RREQ has arrived at D, there is a Reverse Path from D to S<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 38<br />

www.tm.uka.de


AODV: Route Reply<br />

Source: N. Vaidya, Tutorial Mobicom 01<br />

Y<br />

Forward Path for data<br />

Z<br />

S<br />

E<br />

A<br />

B<br />

H<br />

C<br />

I<br />

RREP<br />

G<br />

F<br />

K<br />

J<br />

M<br />

D<br />

N<br />

L<br />

Thereupon, D sends a RREP to S via the Reverse Path<br />

By the RREP, the Forward Path for data traffic from S to D is built up<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 39<br />

www.tm.uka.de<br />

AODV: Sequence numbers<br />

Each node has a Destination Sequence Number<br />

Determines the “up-to-dateness” of routing information<br />

Is only incremented, never decremented<br />

Exception: Overflows<br />

RREQ contains last known Destination Sequence Number of the<br />

destination node<br />

Optimization: Destination nodes or intermediate nodes knowing a newer route<br />

(higher Destination Sequence Number) reply with RREP<br />

RREP also contains Destination Sequence Number<br />

If more than one RREP has been received, the RREP with the highest<br />

Destination Sequence Number will be used<br />

In case of equal Destination Sequence Numbers, the one with the lowest Hop Count<br />

is selected<br />

May accelerate the establishment of a route and save protocol overhe<strong>ad</strong> in<br />

combination with Expanding-Ring-Search<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 40<br />

www.tm.uka.de


AODV: Optimizations<br />

Expanding Ring Search<br />

RREQs are not flooded in the whole network<br />

First, RREQs with low time-to-live (TTL) are sent<br />

If the search fails, a RREQ with a higher TTL is sent<br />

Reduces network lo<strong>ad</strong> when determining routes to nearby nodes<br />

In case of distant nodes<br />

Slower route establishment<br />

Nearby nodes have to forward many RREQs<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 41<br />

www.tm.uka.de<br />

AODV: Maintenance of a route<br />

Reverse/Forwarding Path entries are deleted after timeout<br />

Soft-state approach<br />

The transport of data along a route refreshes this route<br />

Timers are reseted<br />

Detection of link breaks<br />

Missed HELLO messages<br />

Missed link-layer acknowledgements (Receipts on MAC layer)<br />

Reaction to Link breaks: Sending of a RERR<br />

contains increased Destination Sequence Number<br />

Is forwarded to the source<br />

Source tries to find a new route by issueing a RREQ<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 42<br />

www.tm.uka.de


AODV: Maintenance of a route<br />

Destination Sequence Numbers prevent loops<br />

A sends to D, Link from C to D breaks<br />

RERR from C to A gets lost<br />

Later, C wants to send to D<br />

RREQ contains higher Destination Sequence Number<br />

A receives RREQ via C-E-A<br />

A sees higher Destination Sequence Number and does not sent RREP<br />

for D<br />

A B C D<br />

E<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 43<br />

www.tm.uka.de<br />

Local Route Repair<br />

AODV: Optimizations<br />

In case of a link break, RERR is not sent to the source immediately<br />

Node detecting a link break searches a new route to the destination itself<br />

(RREQ)<br />

Can reduce network lo<strong>ad</strong> in the average<br />

Can le<strong>ad</strong> to worse (longer) routes, as only sections of the route are<br />

newly determined<br />

AODV is a „standard protocol“ (experimental) in the IETF<br />

(RFC 3561)<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 44<br />

www.tm.uka.de


4. Current research areas<br />

There are intensive research activities in many areas of mobile <strong>ad</strong>-<strong>hoc</strong><br />

<strong>networks</strong> (also at our institute)<br />

Multicast-Routing<br />

Lots of group applications, like E-Learning, are based on IP-Multicast routing<br />

protocols<br />

Autoconfiguration<br />

dynamic assignment of unique IP <strong>ad</strong>dresses with a distributed mechanism<br />

Service Awareness<br />

In a mobile environment, finding mobile services is of crucial importance<br />

Integration with fixed <strong>networks</strong><br />

How can the integration of mobility protocols (<strong>Mobile</strong> IP) and routing in mobile <strong>ad</strong>-<strong>hoc</strong><br />

<strong>networks</strong> be realized?<br />

Power Control<br />

Control over topology by variation of transmit power of each device and thereby<br />

minimization of interference between the nodes<br />

Security<br />

Integration of security mechanisms into mobile <strong>ad</strong>-<strong>hoc</strong> <strong>networks</strong> is very difficult<br />

Scalability, ...<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 45<br />

www.tm.uka.de<br />

IP-Autoconfiguration in <strong>MANET</strong>s<br />

Internet Protocol (IP) requires unique IP <strong>ad</strong>dresses<br />

Autoconfiguration of the network<br />

Requirements<br />

Efficiency concerning communication complexity<br />

<br />

<br />

<br />

<br />

<br />

Robustness against packet loss<br />

Support for network partitioning and<br />

merging<br />

Resolution of <strong>ad</strong>dress conflicts<br />

As few <strong>ad</strong>dress changes as possible<br />

Flexibility concerning routing protocol<br />

Hierarchical <strong>ad</strong>dressing, if necessary<br />

Rapidness of <strong>ad</strong>dress assignment<br />

1<br />

A<br />

Data path<br />

B<br />

2<br />

4<br />

C<br />

F<br />

Address<br />

7<br />

?<br />

1<br />

E<br />

D<br />

5<br />

Example of network merging<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 46<br />

www.tm.uka.de


The PACMAN concept<br />

Robustness by a hybrid approach as well as coupling with routing<br />

Distributed allocation table and Duplicate Address Detection (DAD)<br />

Implicit support for network merging<br />

Efficiency by cross-layer/passive mechanisms<br />

Passive DAD by anomaly detection in routing protocol traffic<br />

Passive synchronization of the allocation table<br />

Reduction of dependencies by modular architecture<br />

Routing protocol<br />

instance<br />

Application<br />

comm.<br />

Transport.<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 47<br />

Routing protocol<br />

packets<br />

PACMAN<br />

Network<br />

Data Link<br />

Physical<br />

PACMAN:<br />

Passive Autoconfiguration<br />

for <strong>Mobile</strong> Ad <strong>hoc</strong> Networks<br />

www.tm.uka.de<br />

Example: Neighborhood History (NH) Module<br />

Model of a proactive link-state routing protocol<br />

Nodes periodically send routing protocol messages<br />

Source <strong>ad</strong>dress (SA)<br />

Sequence number (SN)<br />

Set of bidirectional link states (LS)<br />

Each node forwards them<br />

Principle of the NH module<br />

Utilization of bidirectional<br />

neighborhood relationships<br />

Maintenance of an NH table<br />

with <strong>ad</strong>dresses which were<br />

neighbors in the past time span t d<br />

3<br />

A<br />

B<br />

SA: 4<br />

SN: 5<br />

LS: 1,2,3<br />

4 1<br />

D E<br />

2<br />

NH table(C)<br />

2,3<br />

C<br />

1<br />

NH: Neighborhood History<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 48<br />

www.tm.uka.de


Prototype Implementation<br />

Implementation for Pocket<br />

PCs with Linux operating<br />

system<br />

Modification of routing<br />

protocol implementations<br />

not necessary<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 49<br />

www.tm.uka.de<br />

Multicast-Routing<br />

Multicast is a 1:n communication which enables group communication<br />

Group of nodes is identified by an IP multicast <strong>ad</strong>dress<br />

Application only has to send a data packet once<br />

Addressed to the IP multicast <strong>ad</strong>dress of the corresponding group<br />

Multicast data packet is forwarded to all group members<br />

Application scenarios for multicast<br />

Streaming<br />

E.g. Internet r<strong>ad</strong>io<br />

CSCW (Computer Supported Cooperative Work)<br />

E.g. video conferences, whiteboards, distributed editors<br />

Multiplayer games<br />

E-Learning<br />

Service Discovery<br />

…<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 50<br />

www.tm.uka.de


ODOMP - On-demand Overlay Multicast Protocol<br />

Creation of an overlay network between the group members<br />

Group member are connected via IP-in-IP tunnels<br />

Multicast data packets are encapsulated in IP unicast packets<br />

Routing is done by an arbitrary underlying unicast routing protocol (e.g. AODV)<br />

Overlay has the form of a tree<br />

Source node is root of the tree<br />

Data duplication by none-leaf nodes<br />

Group members forward a copy of the multicast data packet to each of their<br />

downstream members<br />

sender<br />

Group member<br />

Non-group member<br />

„Real“ link<br />

Overlay link<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 51<br />

www.tm.uka.de<br />

References<br />

[1] C.-K. Toh, Ad Hoc <strong>Mobile</strong> Wireless Networks: Protocols and Systems,<br />

Prentice Hall, 2002<br />

[2] C. Perkins, Ad-<strong>hoc</strong> Networking, Addison Wesley, 2000<br />

[3] IETF <strong>MANET</strong> Working Group, http://www.ietf.org/html.charters/manetcharter.html<br />

<strong>Mobile</strong> <strong>ad</strong> <strong>hoc</strong> <strong>networks</strong> 52<br />

www.tm.uka.de

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!