Mobile ad hoc networks (MANET)
Mobile ad hoc networks (MANET)
Mobile ad hoc networks (MANET)
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