REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Wireless ad hoc network3
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Unit disk graph
1
4
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Unit disk graph5
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
106
Routing Overview Goal: transfer message from one
node to another Which is the “best” path? Generally try
to optimize one of the following: Shortest path (fewest hops) Shortest time (lowest latency) Shortest weighted path (utilize
available bandwidth, battery) Who decides - source or intermediate
nodes? Source (“path”) routing [Like airline
travel] Source specifies entire route Intermediate nodes just forward
to specified next hop Destination (“hop-by-hop”) routing
[Like postal service] Source specifies only destination
in message header Intermediate nodes look at
destination in header, consult internal tables to determine appropriate next hop
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
107
MANET Routing Properties
Distributed operation No external network setup “self-configuring” Efficient when network topology is dynamic (frequent network
changes – links break, nodes come and go) And also:
Loop Freedom Sleep period operation Unidirectional link support Security
Quantitative Properties End-to-End data throughput Delays Route Acquisition time Out of order delivery (percentage)
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
108
Types of protocols behaviour
Proactive protocols They determine routes independently from the traffic patterns Traditional protocols like link-state and distance-vector are proactive
Reactive protocols They create a route only if required
There are also hybrid solutions Aspects to take into consideration
Waiting time for getting a route Proactive protocols are typically faster Reactive protocols normally have a higher latency
Overhead for route discover and maintenance Proactive protocols typically have an higher overhead because they are
always updating routing tables Reactive protocols normally have a lower overhead because they add control
traffic only when necessary
The solution to adopt depends on the type of the data traffic and the type of mobility!
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 manet Working Group
IETF WG: Mobile Ad-hoc Networks (manet) http://www.ietf.org/html.charters/manet-charter.html Additional MANET links:
http://www.ianchak.com/manet/ Additional information is available at:
http://tools.ietf.org/wg/manet
Purpose of MANET working group standardize IP routing protocol functionality suitable for wireless routing
application within both static and dynamic topologies with increased dynamics due to node motion or other factors.
Approaches are intended to be: relatively lightweight in nature suitable for multiple hardware and wireless environments, and address
scenarios MANETs are deployed at the edges of an IP infrastructure hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers)
should also be supported by MANET specifications and management features.
9
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 manet Working Group
The group is pursuing a reactive and a proactive protocol. On the charter page these are called RMP and PMP respectively. Proactive MANET Protocol (PMP) Reactive MANET Protocol (RMP)
In practice the reactive protocol is DYMO and the proactive is OLSRv2.
If significant commonality between RMP and PMP modules is observed, the WG may decide to go with a converged approach.
Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be
addressed. The MANET WG will also develop a scoped forwarding protocol
that can efficiently flood data packets to all participating MANET nodes.
10
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Proposed protocols Here: http://en.wikipedia.org/wiki/Ad_hoc_protocol_list
11
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Classification of Ad Hoc Routing Protocols
Routing protocols for ad hoc wireless networks
Based on routing information update
mechanism
Based on the use of temporal information for
routing
Based on topology information
Based on utilization of specific resources
Proactive(table-driven or
link-state)Hybrid
Path selection using past
history
Path selection using prediction
• DSDV• OLSR• HSR
• ZRP
• DSDV• DSR• AODV• DYMO
• FORP
Reactive(table-driven)
• DSR• AODV• DYMO
Flat routing Hierarchical routing
• DSDV• DSR• AODV• DYMO
• HSR
Energy-aware routing
Geographical routing
• PAR • GPSR
12
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Most relevant routing protocols D. Johnson, D. Maltz, and Y-C. Hu.
The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR),RFC 4728, February 2007. http://tools.ietf.org/html/rfc4728
C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561, July 2003. http://tools.ietf.org/html/rfc3561
I. Chakeres, C. Perkins. Dynamic MANET On-demand (DYMO) Routing. draft-ietf-manet-dymo-17, March 2009. http://tools.ietf.org/html/draft-ietf-manet-dymo-17
T. Clausen et al. The Optimized Link-State Routing Protocol version 2. draft-ietf-manet-olsrv2-08, March 2009. T. Clausen and P. Jacquet.
Optimized Link State Routing Protocol (OLSR). RFC 3626, October 2003. http://www.ietf.org/rfc/rfc3626.txt
13
REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Flooding as a basic mechanism 1/615
A
B
S
H
C
E
Z
I
G
F
KN
L
J
M
D
Y
Node that just received a frame
Frame broadcasted
Node that just forwarded a frame
destination
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Flooding as a basic mechanism 2/616
A
B
S
H
C
E
Z
I
G
F
KN
L
J
M
D
Y
possible collision!!
Node that just received a frame
Frame broadcasted
Node that just forwarded a frame
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Flooding as a basic mechanism 3/617
A
B
S
H
C
E
Z
I
G
F
K
N
L
J M
D
Y
Receives the frame but does not forward it. Already done
Node that just received a frame
Frame broadcasted
Node that just forwarded a frame
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Flooding as a basic mechanism 4/618
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
Receives the frame form J and from K (which are mutually hidden) possible collision
Node that just received a frame
Frame broadcasted
Node that just forwarded a frame
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Flooding as a basic mechanism 5/619
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
D does not forward it because is the final destination
Node that just received a frame
Frame broadcasted
Node that just forwarded a frame
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Flooding as a basic mechanism 6/620
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
Flooding is over!
Node that just received a frame
Frame broadcasted
Node that just forwarded a frame
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1021 Flooding as a basic mechanism: a few
considerations Many protocols use limited flooding of the control
packets. Control packets are used to discover the routes.
Advantage: Simplicity Disadvantage: Overhead possibly very high
The established routes are then used to send packets of data.
REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1023 Dynamic Source Routing (DSR)
For networks of medium size (200 nodes), admits high speeds When node S wants to send a packet to node D, but does not
have a route to D, begins a route discovery process. Source node S floods Route Request (RREQ) packets Each node adds its own id when it forwards a RREQ.
Use of the “send buffer”
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in DSR, 1/524
A
B
S [S]
H
C
E
I
G
F
KN
J
M
D
destination
Node that just received a RREQ
IDs list added to the RREQ
Node that just forwarded an RREQ
[X,Y]
Y
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in DSR, 2/525
A
B
S
H
C [S,C]
E [S,E]
Z
I
G
F
KN
L
J
M
D
Y
Possible collision!!
Node that just received a RREQ
IDs list added to the RREQ
Node that just forwarded an RREQ
[X,Y]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in DSR, 3/526
A
B
S
H
C
E
Z
I
G [S,C,G]
F [S,E,F]
K
N
L
J M
D
Y
RREQ is not forwarded
Node that just received a RREQ
IDs list added to the RREQ
Node that just forwarded an RREQ
[X,Y]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in DSR, 4/527
A
B
S
H
C
E
Z
I
G
F
K[S,C,G,K]
N
L
J [S,E,F,J]M
D
Y
Possible collision
Node that just received a RREQ
IDs list added to the RREQ
Node that just forwarded an RREQ
[X,Y]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in DSR, 5/528
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M [S,E,F,J,M]
D
Y
Node that just received a RREQ
IDs list added to the RREQ
Node that just forwarded an RREQ
[X,Y]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Reply
Destination D, when receiving the first RREQ send a Route Reply (RREP)
RREP is sent using the route obtained by reversing the one that is in the received RREQ
29
Y
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
RREP [S,E,F,J,D]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Reply en DSR
Route Reply can be sent by reversing the route in Route Request (RREQ) only if links are guaranteed to be bi-directional To ensure this, RREQ should be forwarded only if it received on a link
that is known to be bi-directional
If unidirectional (asymmetric) links are allowed, then RREP may need a route discovery for S from node D Unless node D already knows a route to node S If a route discovery is initiated by D for a route to S, then the Route
Reply is piggybacked on the Route Request from D.
If IEEE 802.11 MAC is used to send data, then links have to be bi-directional (since Ack is used)
30
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Dynamic Source Routing (DSR)
Node S on receiving RREP, caches the route included in the RREP
When node S sends a data packet to D, the entire route is included in the packet header hence the name source routing
Intermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded
31
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Data Delivery in DSR32
Packet header size grows with route length
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
DATA [S,E,F,J,D]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1033 DSR Optimization: Route Caching (1/2)
Each node caches a new route it learns by any means When node S finds route [S,E,F,J,D] to node D, node S also learns route
[S,E,F] to node F When node K receives Route Request [S,C,G] destined for node, node K
learns route [K,G,C,S] to node S When node F forwards Route Reply RREP [S,E,F,J,D], node F learns route
[F,J,D] to node D When node E forwards Data [S,E,F,J,D] it learns route [E,F,J,D] to node D A node may also learn a route when it overhears Data packets
A
B
S
H
C
EZ
I
G
F
KN
L
JM
D
Y
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 DSR Optimization: Route Caching (2/2)
When node S learns that a route to node D is broken, it uses another route from its local cache, if such a route to D exists in its cache. Otherwise, node S initiates route discovery by sending a route request
Node X on receiving a Route Request for some node D can send a Route Reply if node X knows a route to node D
Use of route cache can speed up route discovery can reduce propagation of route requests
34
A
BS
H
C
EZ
IG
F
KN
L
JM
D
Y
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Error (RERR) J sends a route error to S along route
J-F-E-S when its attempt to forward the data packet S (with route SEFJD) on J-D fails
Nodes hearing RERR update their route cache to remove link J-D
Each node is responsible for confirming that the link can be used to transmit data. Ack del MAC (p.ej., 802.11) Passive acks DSR-specific ACK
35
Y
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
RERR [J-D]
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 DSR additional techniques
“Expading ring” technique playing with the TTL of the packets “non propagating” Route Request
“Route salvaging” technique for route maintenance Dynamic substitution of routes for intermediate ndoes
“Automatic route shortening” technique for routes optimization Based on “gratuitous” Route Reply
The “flows”
36
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 DSR: advantages and disadvantages Routes maintained only
between nodes who need to communicate reduces overhead of route
maintenance
Route caching can further reduce route discovery overhead
A single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches
Packet header size grows with route length due to source routing
Flood of route requests may potentially reach all nodes in the network
Care must be taken to avoid collisions between route requests propagated by neighboring nodes insertion of random delays before
forwarding RREQ
Increased contention if too many route replies come back due to nodes replying using their local cache Route Reply Storm problem Reply storm may be eased by
preventing a node from sending RREP if it hears another RREP with a shorter route
37
REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1039 First Back to basics : Distance Vector protocol
Basic Routing Protocol known also as Distributed Bellman-Ford or RIP
Every node maintains a routing table all available destinations the next node to reach the destination the number of hops to reach the destination
Periodically send table to all neighbors to maintain topology Bi-directional links are required!
Thanks to Raoul Reuter
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1040 First Back to basics : Distance Vector -> tables
CDest. Next Metric …
A A 1
B B 0
C C 2
Dest. Next Metric …
A A 0
B B 1
C B 3
1 2
Dest. Next Metric …
A B 3
B B 2
C C 0
BA
Thanks to Raoul Reuter
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1041 First Back to basics : Distance Vector -> update
(A, 1)(B, 0)(C, 1)
(A, 1)(B, 0)(C, 1)
CDest. Next Metric …
A A 1
B B 0
C C 1
Dest. Next Metric …
A A 0
B B 1
C B 3 2
1 21
Dest. Next Metric …
A B 3 2
B B 1
C C 0
BA
B broadcasts the new routing information to his neighbors
Routing table is updated
Thanks to Raoul Reuter
A change occurs so…
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1042 First Back to basics : Distance Vector -> new
node
(D, 0)
(A, 2)(B, 1)(C, 0)(D, 1)
(A, 1)(B, 0)(C, 1)(D, 2)
C1 1
BA D1
broadcasts to update tables of C, B, A with new entry for D
Dest. Next Metric …
A B 2
B B 1
C C 0
D D 1
Dest. Next Metric …
A A 1
B B 0
C C 1
D C 2
Dest. Next Metric …
A A 0
B B 1
C B 2
D B 3
Thanks to Raoul Reuter
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1043 First Back to basics : Distance Vector
Broken Link and consequent Loops…
(D, 2)(D, 2)
C1 1
BA D1
Dest. Next Metric …
… … …
D B 3
Dest. Next Metric …
… … …
D C 2
Dest. Next Metric …
… … …
D B 3
C1 1
BA D1
Dest.c Next Metric …
… … …
D C 2
Dest. Next Metric …
… … …
D B 3
Dest. Next Metric …
… … …
D B 1
Dest. Next Metric …
… … …
D D
Thanks to Raoul Reuter
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1044 First Back to basics : Distance Vector
… create the “Count to Infinity” problem
(D,2)
(D,4)
(D,3)
(D,5)
(D,2)
(D,4)
C1 1
BA D1
Dest. Next Metric …
… … …
D B 3, 5, …
Dest. Next Metric …
… … …
D B 3, 5, …
Dest.c Next Metric …
… … …
D C 2, 4, 6…
Thanks to Raoul Reuter
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10Ad Hoc On-Demand Distance Vector Routing
(AODV) DSR includes source routes in packet headers. Resulting large headers can sometimes degrade performance
particularly when data contents of a packet are small
AODV attempts to improve on DSR by maintaining routing tables at the nodes, so that data packets do not have to contain routes
AODV retains the desirable feature of DSR that routes are maintained only between nodes which need to communicate
45
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV
Route Requests (RREQ) are forwarded in a manner similar to DSR
When a node re-broadcasts a Route Request, it sets up a reverse path pointing towards the source AODV assumes symmetric (bi-directional) links
When the intended destination receives a Route Request, it replies by sending a Route Reply
Route Reply travels along the reverse path set-up when Route Request is forwarded
46
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in AODV47
A
B
S
H
C
E
Z
I
G
F
KN
L
J
M
D
Y
Node that just received a frame
RREQ broadcast
Node that just forwarded a frame
destination
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in AODV48
A
B
S
H
C
E
Z
I
G
F
KN
L
J
M
D
Y
Node that just received a frame
RREQ broadcast
Node that just forwarded a frame
Inverse link
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in AODV49
A
B
S
H
C
E
Z
I
G
F
K
N
L
J M
D
Y
Node that just received a frame
RREQ broadcast
Node that just forwarded a frame
Inverse link
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in AODV50
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
Node that just received a frame
RREQ broadcast
Node that just forwarded a frame
Inverse link
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in AODV51
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
Node that just received a frame
RREQ broadcast
Node that just forwarded a frame
Inverse link
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Route Request in AODV52
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
Y
Node that just received a frame
RREQ broadcast
Node that just forwarded a frame
Inverse link
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Forward Path Setup in AODV53
A
B
S
H
C
E
Z
I
G
F
K
N
L
J
M
D
YForward links are setup when RREP travels alongthe reverse path
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Concepts (2)
Local HELLO messages are used to determine local connectivity Can reduce response time to routing requests Can trigger updates when necessary
Sequence numbers are assigned to routes and routing table entries Used to supersede stale cached routing entries
Every node maintains two counters Node sequence number Broadcast ID
54
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Route Request (1)
Initiated when a node wants to communicate with another node, but does not have a route to that node
Source node broadcasts a route request (RREQ) packet to its neighbors
broadcast_iddest_addr
type flags hopcntresvd
dest_sequence_#source_addr
source_sequence_#
55
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Route Request (2)
Sequence numbers Source sequence indicates “freshness” of reverse route to the source Destination sequence number indicates freshness of route to the
destination Every neighbor receives the RREQ and either …
Returns a route reply (RREP) packet, or Forwards the RREQ to its neighbors
(source_addr, broadcast_id) uniquely identifies the RREQ broadcast_id is incremented for every RREQ packet sent Receivers can identify and discard duplicate RREQ packets
56
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Route Request (3)
If a node cannot respond to the RREQ The node increments the hop count The node saves information to implement a reverse path set up (AODV
assumes symmetrical links)Neighbor that sent this RREQ packetDestination IP addressSource IP addressBroadcast IDSource node’s sequence numberExpiration time for reverse path entry (to enable garbage collection)
57
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (1)
Node 1 needs to send a data packet to Node 7 Assume Node 6 knows a current route to Node 7 Assume that no other route information exists in the
network (related to Node 7)
14
3 52
6
7
58
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (2)
Node 1 sends a RREQ packet to its neighbors source_addr = 1 dest_addr = 7 broadcast_id = broadcast_id + 1 source_sequence_# = source_sequence_# + 1 dest_sequence_# = last dest_sequence_# for Node 7
14
3 52
6
7
59
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (3)
Nodes 2 and 4 verify that this is a new RREQ and that the source_sequence_# is not stale with respect to the reverse route to Node 1
Nodes 2 and 4 forward the RREQ Update source_sequence_# for Node 1 Increment hop_cnt in the RREQ packet
14
3 52
6
7
60
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (4)
RREQ reaches Node 6, which knows a route to 7 Node 6 must verify that the destination sequence number is less than
or equal to the destination sequence number it has recorded for Node 7
Nodes 3 and 5 will forward the RREQ packet, but the receivers recognize the packets as duplicates
14
3 52
6
7
61
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Route Reply (1)
If a node receives an RREQ packet and it has a current route to the target destination, then it unicasts a route reply packet (RREP) to the neighbor that sent the RREQ packet
dest_addrtype flags hopcntrsvd
dest_sequence_#source_addr
lifetime
prsz
62
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Route Reply (2)
Intermediate nodes propagate the first RREP for the source towards the source using cached reverse route entries
Other RREP packets are discarded unless… dest_sequence_# number is higher than the previous, or destination_sequence_# is the same, but hop_cnt is smaller (i.e., there’s
a better path) RREP eventually makes it to the source, which can use the
neighbor sending the RREP as its next hop for sending to the destination
Cached reverse routes will timeout in nodes not seeing a RREP packet
63
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (5)
Node 6 knows a route to Node 7 and sends an RREP to Node 4 source_addr = 1 dest_addr = 7 dest_sequence_# = maximum(own sequence number,
dest_sequence_# in RREQ) hop_cnt = 1
14
3 52
6
7
64
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (6)
Node 4 verifies that this is a new route reply (the case here) or one that has a lower hop count and, if so, propagates the RREP packet to Node 1 Increments hop_cnt in the RREP packet
14
3 52
6
7
65
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (7)
Node 1 now has a route to Node 7 in three hops and can use it immediately to send data packets
Note that the first data packet that prompted path discovery has been delayed until the first RREP was returned
14
3 52
6
7
Dest Next Hops7 4 3
66
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Route Maintenance
Route changes can be detected by… Failure of periodic HELLO packets Failure or disconnect indication from the link level Failure of transmission of a packet to the next hop (can detect by
listening for the retransmission if it is not the final destination) The upstream (toward the source) node detecting a failure
propagates an route error (RERR) packet with a new destination sequence number and a hop count of infinity (unreachable)
The source (or another node on the path) can rebuild a path by sending a RREQ packet
67
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Notification about a link break
A neighbor of node X is considered active for a routing table entry if the neighbor sent a packet within active_route_timeout interval which was forwarded using that entry
When the next hop link in a routing table entry breaks, all active neighbors are informed
Link failures are propagated by means of Route Error messages, which also update destination sequence numbers When node X is unable to forward packet P (from node S to node D) on
link (X,Y), it generates a RERR message Node X increments the destination sequence number for D cached at
node X The incremented sequence number N is included in the RERR When node S receives the RERR, it initiates a new route discovery for D
using destination sequence number at least as large as N
68
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 AODV Example (8)
Assume that Node 7 moves and link 6-7 breaks Node 6 issues an RERR packet indicating the broken path The RERR propagates back to Node 1 Node 1 can discover a new route
14
3 52
6
7
7
69
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 DYMO vs AODV
Answers by Ian Chakeres to the question: “could you briefly explain what are the differences between DYMO and AODV “ 8 Mar 2005
There are several differences between AODV, AODV-bis, DSR and DYMO. To list just a few.
New packet format. Generic packet handling. Unsupported element handling. Optional path accumulation. Much more.
23 Mar 2006 DYMO is a simpler version of AODV. DYMO is easier to implement and
has lower requirements (in terms of memory, code, etc.) than AODV. DYMO is close to what has been implemented for sensor networks, such as tinyAODV. AODV is no longer being explored in the MANET WG.
70
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 DYMO71
DYMO – Reactive Protocol like AODV, but with path accumulation feature
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 DYMO Path accumulation
Path accumulation definitely reduces the number of RREQs Topology information is discovered much more quickly However, it also increases the packet size
Packet size is often a burden that negates some of the benefit of path accumulation
And, the benefit is reduced if newly discovered routes are not used before being purged from the routing cache
72
REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 First Back to basics : Link-State Algorithms (1)
Each node shares its link information so that all nodes can build a map of the full network topology
Link information is updated when a link changes state (goes up or down) Link state determined by sending small “hello” packets to neighbors
Given full topology information, a node can determine the next best hop or a route from the source
74
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 First Back to basics : Link-State Algorithms (2)
Assuming the topology is stable for a sufficiently long period, all nodes will have the same topology information
A
B
C DA-BLink
B-CC-D
A-BLink
B-CC-D
A-BLink
B-CC-D
A-BLink
B-CC-D
75
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 First Back to basics : Link-State Algorithms (3)
Nodes A and C propagate the existence of link A-C to their neighbors and, eventually, to the entire network
A
B
C D
A-BLink
B-CC-D
A-C
A-BLink
B-CC-D
A-C
A-BLink
B-CC-D
A-C
A-BLink
B-CC-D
A-C
A-C A-C
A-C
76
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Optimized Link State Routing (OLSR)
Proactive scheme based on the link-state mechanism. Each node periodically floods status of its links Each node re-broadcasts link state information received from its
neighbor Each node keeps track of link state information received from other
nodes Each node uses above information to determine next hop to each
destination
The overhead of flooding link state information is reduced by requiring fewer nodes to forward the information
Does not require modifying the structure of the IP packets
77
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 OLSR v2
Compared to OLSRv1, OLSRv2 retains the same basic mechanisms and algorithms, while providing an even more flexible signaling framework and some simplification of the messages being exchanged.
OLSRv2 takes care to accommodate both IPv4 and IPv6 addresses in a compact fashion.
The message exchange format has been factored out to an independent specification Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized MANET
Packet/Message Format", work in progress. The OLSRv2 neighborhood discovery protocol using HELLO
messages has been factored out to an independent specification Clausen, T., Dean, J., and C. Dearlove, "MANET Neighborhood Discovery
Protocol (NHDP)", work in progress.
78
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 LSR vs. OLSR The overload of broadcasting the
status information on the links is reduced by limiting the number of nodes which forward this information A broadcast from node X is
forwarded only by its multipoint relays
The multipoint relays of X are its neighbors chosen so that every two-hops neighbors of X is a one-hop neighbors of at least one of its multipoint relay
Each node periodically transmits the list of its neighbors so that all nodes can know which are their two-hops neighbors, therefore being able to choose their multipoint relays
79
11 broadcasts are needed to spread the message up to three hops away
24 broadcasts are needed to spread the message up to three hops away
Sending node
Sending node
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Terminology Nodes can have various OLSR
interfaces, each with its own IP address Each node is assigned a unique
reference IP (‘main address’) neighbor: x is a neighbor of y if y can
receive x signal 2-hop neighbor: a node whose
signal is received by its neighbor. strict 2-hop neighbor:
a 2-hop neighbor which is not the node itself or a neighbor of the node, and in addition is a neighbor of a neighbor, with willingness different from WILL_NEVER, of the node.
multipoint relay (MPR): A node selected by its neighbor x,
to forward all the broadcast messages received from x, if it is not a duplicate message and if life-time is >1
multipoint relay selector (MS) A node that selected its neighbor x
as a MPR
80
S
M
X YZ
P
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Neighbor sensing Each node periodically broadcasts
Hello messages: List of neighbors with bi-directional
link List of other known neighbors.
Hello messages permit each node to learn topology up to 2 hops
Based on Hello messages each node selects its set of MPR’s
81
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 MPR selection algorithm
Each point u has to select its set of MPR. Goal: select in the 1-neighborhood of u (N1(u)) a set of nodes
as small as possible which covers the whole 2-neighborhood of u (N2(u)), in two steps : Step 1: Select nodes of N1(u) which cover isolated points of N2(u).
(That we call MPR1(u).) Step 2: Select among the nodes of N1(u) not selected at the first step,
the node which covers the highest number of points (not already covered) of N2(u) and go on till every points of N2(u) are covered.
82
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 MPR selection algorithm : example83
u
First step: select nodes in N1(u) which cover « isolated points » of N2(u).
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 MPR selection algorithm : example84
u
Second step: Consider in N1(u) only points which are not already selected at the first step MPR1(u) and points in N2(u) which are not covered by the MPR1(u). While there exists points in N2(u) not covered by the selected MPR, select in N1(u), the node which covers the highest number of non-covered nodes in N2(u).
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 MPR selection algorithm: example; final result85
u
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Multipoint Relay Selector Set
The multipoint relay selector set for Node N, MS(N), is the set of nodes that choose Node N in their multipoint relay set Only links N-M, for all M such that NMS(M) will be advertised in control
messages
MS(3) = {…, 4, …}MS(6) = {…, 4, …}
(Assuming bidirectional links)
14
3 52
6
7
86
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 HELLO Messages (1)
Each node uses HELLO messages to determine its MPR set All nodes periodically broadcast HELLO messages to their one-
hop neighbors (bidirectional links) HELLO messages are not forwarded
14
3 52
6
7
HELLO: NBR(4) = {1,3,5,6}
87
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 HELLO Messages (2)
Using the neighbor list in received HELLO messages, nodes can determine their two-hop neighborhood and an optimal (or near-optimal) MPR set
A sequence number is associated with this MPR set Sequence number is incremented each time a new set is calculated
14
3 52
6
7
At Node 4:NBR(1) = {2}NBR(3) = {2,5}NBR(5) = {3,6}NBR(6) = {5,7}
MPR(4) = {3,6}
88
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 HELLO Messages (3)
Subsequent HELLO messages also indicate neighbors that are in the node’s MPR set
MPR set is recalculated when a change in theone-hop or two-hop neighborhood is detected
14
3 52
6
7
HELLO: NBR(4) = {1,3,5,6}, MPR(4) = {3,6}
MS(6) = {…, 4,…}
MS(3) = {…, 4,…}
89
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 TC Messages
Nodes send topology information in Topology Control (TC) messages List of advertised neighbors (link information) Sequence number (to prevent use of stale information)
A node generates TC messages only for those neighbors in its MS set Only MPR nodes generate TC messages Not all links are advertised
A nodes processes all received TC messages, but only forwards TC messages if the sender is in its MS set Only MPR nodes propagate TC messages
90
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 OLSR Example (1)
14
3 52
6
7
MPR(1) = { 4 }MPR(2) = { 3 }MPR(3) = { 4 }MPR(4) = { 3, 6 }MPR(5) = { 3, 4, 6 }MPR(6) = { 4 }MPR(7) = { 6 }
MS(1) = { }MS(2) = { }MS(3) = { 2, 4, 5 }MS(4) = { 1, 3, 5, 6 }MS(5) = { }MS(6) = { 4, 5, 7 }MS(7) = { }
91
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 OLSR Example (2)
Node 3 generates a TC message advertising nodes in MS(3) = {2, 4, 5}
Node 4 forwards Node 3’s TC message sinceNode 3 MS(4) = {1, 3, 5, 6}
Node 6 forwards TC(3) since Node 4 MS(6)
14
3 52
6
7
TC(3) = <2,4,5>
92
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 OLSR Example (3)
Node 4 generates a TC message advertising nodes in MS(4) = {1, 3, 5, 6}
Nodes 3 and 6 forward TC(4) since Node 4 MS(3) and Node 4 MS(6)
14
3 52
6
7
TC(4) = <1,3,5,6>
93
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 OLSR Example (4)
Node 6 generates a TC message advertising nodes in MS(6) = {4, 5, 7}
Node 4 forwards TC(6) from Node 6 and Node 3 forwards TC(6) from Node 4
After Nodes 3, 4, and 6 have generated TC messages, all nodes have link-state information to route to any node
14
3 52
6
7
TC(6) = <4,5,7>
94
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 OLSR Example (5)
Given TC information, each node forms a topology table
A routing table is calculated from the topology table
Note that Link 1-2 is not visible except to Nodes 2 and 3
TC(3) = <2,4,5>
TC(4) = <1,3,5,6> TC(6) = <4,5,7>1
3 52
6
7
4
Dest Next Hops1 4 22 2 14 4 15 5 16 4 (5) 27 4 (5) 3
95
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Routing table
All nodes manage a routing table Its structure is:
1. R_dest_addr R_next_addr R_dist R_iface_addr2. R_dest_addr R_next_addr R_dist R_iface_addr3. ,, ,, ,, ,,
Each entry indicates that node R_dest_addr is R_dist hops away, and the first hop is through R_next_addr. This node can be reached through the local interface R_iface_addr
There is an entry for each destination in the network The table is updated each time a change is detected in:
the link set, the neighbor set, the 2-hop neighbor set, the topology set, the Multiple Interface Association Information Base,
The table is built using a shortest path algorithm
96
REDES INALÁMBRICAS Máster de Ingeniería de Computadores-DISCA
Redes Inalámbricas – Tema 3. Mobile Ad Hoc Networks
A. Specific propertiesB. Flooding as a basic mechanismC. Basic routing protocols
DSR AODV y DYMO OLSR y OLSRv2
D. Advanced protocols and techniques
Acknowledgments :Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc
Networks: Routing, MAC and Transport Issues” Available at:
http://www.crhc.uiuc.edu/wireless/tutorials.html
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10LUNAR (Lightweight Underlay Network Ad hoc
Routing) Instead of having routing protocol logic that actively
maintains and repairs existing routing paths, LUNAR always establishes paths from scratch.
LUNAR floods the network every 3 s for discovering a route. During the 3 s interval, all data packets are shipped over the
same path and no attempts are made to discover lost packets or to monitor link changes.
98
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Zone Routing Protocol (ZRP)
Zone routing protocol combines Proactive protocol: which pro-actively updates network state and
maintains route regardless of whether any data traffic exists or not Reactive protocol: which only determines route to a destination if there
is some data to be sent to the destination All nodes within hop distance at most d from a node X are
said to be in the routing zone of node X All nodes at hop distance exactly d are said to be peripheral
nodes of node X’s routing zone Intra-zone routing: Pro-actively maintain state information for
links within a short distance from any given node Routes to nodes within short distance are thus maintained proactively
(using, say, link state or distance vector protocol) Inter-zone routing: Use a route discovery protocol for
determining routes to far away nodes. Route discovery is similar to DSR with the exception that route requests are propagated via peripheral nodes.
99
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10ZRP: Example with
Zone Radius = d = 210
0
SCA
EF
B
D
S performs routediscovery for D
Denotes route request
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 ZRP: Example with d = 2101
SCA
EF
B
D
S performs routediscovery for D
Denotes route replyE knows route from E to D, so route request need not beforwarded to D from E
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 ZRP: Example with d = 2102
SCA
EF
B
D
S performs routediscovery for D
Denotes route taken by Data
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Geographic routing - GeoNet
Geographic routing applied specifically to VANETs. Uses the geographic position and movement information of vehicles to route data packets.
Each node maintains a location table including location related information for itself and a list of its neighbouring nodes.
Position information, including speed and direction, exchanged in beacon packets
Forwarding uses Greedy Perimeter Stateless Routing (GPSR) protocol
Communication modes: GeoUnicast – from a node to a known location GeoAnyCast – from a node to any node in a geographic area GeoBroadCast – from a node to all nodes in a geographic area Topo-Broadcast – from a node to all nodes a given number of hops away
103
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Geographical Routing - Basics104
Next Hop SelectionGiven a DESTINATION, the node that is holding the message selects the next hop according to 1) Its own position2) The position of the destination node3) The position of its neighbors (nodes in the Knowledge Range)DIFFERENT FORWARDING RULES ARE POSSIBLE!
DESTINATION
MESSAGE HOLDER
KNOWLEDGE RANGE
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 GPSR: Greedy Perimeter Stateless Routing
Key Assumptions: Nodes (routers) know their location
GPS, beacon, tri/multi-lateration… (Roughly) Planar Topologies Maybe: Registration/Lookup service mapping nodes to location
Sources can determine the addresses of their destinations and encode them as part of the packet(s).
Queries use the same “address-book”(Implicit: Unit-disk graph model of communication range…)
105
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 GPSR - basics106
D X
node D
Node X receives a packet, for which the destination is D
Of all the X’s neighbors, Y is closest to D=> “greedy” forwarding (decreasing the total distance)
Y
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 GPSR – basics
Q: What if the neighborhood changes (e.g., nodes deplete their energy; new nodes enter the region; …)? Periodically, each node transmits a beacon to the common, broadcast
MAC address, containing (ID, location). Hence, the neighbors can update their data…
If the time during which a beacon has not been received from a given neighbor exceeds a pre-defined time-out interval, assume failure and delete it from neighborhood-table.
Two four-Bytes fields (float) for each of X and Y coordinates… NOTE: this is pro-active… To save on communication for beaconing, location info can be
piggy-backed on the data packets All? Which ones?
107
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 GPSR – Problem(s) with the ”greedy”…108
XA B
DD
For the given network, assume thatX receives a packet to be forwardedto the node D.
IF A & B are the only ones inIts communication range, since XIs closer to D than both of themÞ the “pure” GPSR would NOTsend the packet !!!
Hence, one type of problems are due tothe, so called, VOID regions
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 GPSR – Problem(s) with the ”greedy”…109
XA B
D
C E
F G
Solution to voids:- Travel around the perimeter of the void,using as “road-segments” the edges between the nodes (view communication graph as a node) - Eventually/hopefully, get closer tothe desired destination…(e.g., X->B->E->G->D)
OK, so this is kind’a graph-theoretic…Ergo, it brings another problem: howAre edges that are intersecting to be treated (are they having an actual vertex)Solution: Enforce the PLANARITY…
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1011
0
GPSR – Problem(s) with the ”greedy”…
Desideratum: reduce the number of “active” neighbors, while preserving the connectivity of the network as a whole. This should be done in a manner to ensure min. amount of “links” to be
traveled for whatever purpose needed…
Two basic geometric techniques used for making a given graph planar, while ensuring that all the nodes that the connectivity is the same, with respect to the initial connectivity under the unit-disk model: Relative Neighborhood Graph (RNG) Gabriel Graph (GG)
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1011
1
GPSR – Planarization of Graphs:
w
vu
RNG:An edge exists between u and v, if their distance isless than the max[(u,w),(v,w)] for any other such vertex w
e.g., no “witnesses” in the luna
w
vu
GG: An edge exists between u and v, if no other vertex is inside the circle whose diameter is uv
e.g., no “witnesses” inside the circle
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Quantitative Observations…112
RNG GG
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 Back to GPRS113
OK, so given an initial network, assume that we are done withRNG-ization or GG-ization…
The typical packet can either:forward greedily;
orforward around perimeter…
For the purpose of forwarding around the perimeter, the GPSR packet header has the following fields:…
D –destination location;Lp – Location in which the packetentered the “perimeter” mode;Lf – Location on xV in which the packet entered current face (TBE);e0 – first edge traversed on the current edge;M – packet mode (G/P)
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1011
4 So, just what is “walk around perimeter”???AKA Face Routing…
And proceed “recursively”Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
10 GPSR115
Face: planar region bounded by the edges in a given graph (can be “open”)
X
D
When void encountered;- “draw” the line XD;- Pick the face at X intersected by XD;- Select the edge on that face -> LHS; -Traverse the edges on the boundaryof that face -> RHS;-At any point, if non-void (i.e., greedy-possible), do greedy;
NOTES:1. Cycles can be detected (recall the header data)2. Cycles can only happen when X and D are NOT in one connected component…
Thanks to: Peter Scheuermann Northwestern University
RED
ES IN
ALÁ
MB
RIC
AS
MIC
200
9/20
1011
6
Some Issues of GPSR…
What if mobility is part of the game? MAC failure feedback…
Promiscuous use of network interface Disable MAC address filtering (reason: every packet carries location
data…) How realistic is the assumption about symmetric links (in turn,
how good is the RNG/GG-ization of the connectivity graph)? Planarity of the graph?
Nodes move (in/out), deplete baterries => batch or incremental updates?
Thanks to: Peter Scheuermann Northwestern University