lecture 13: mobile ad hoc networks. 2 contents introduction ad-hoc typical applications ...
TRANSCRIPT
Lecture 13:
Mobile Ad Hoc Networks
2
Contents
Introduction Ad-Hoc typical applications Characteristics and requirements Routing Protocols Ad-Hoc performance Conclusion
3
Introduction
Two types of wireless networks: Infrastructured network:
base stations are the bridges a mobile host will communicate with th
e nearest base station handoff is taken when a host roams fro
m one base to another
4
Ad hoc network: infrastructureless: no fixed base stations without the assistance of base stations for c
ommunication Due to transmission range constraint,
two MHs need multi-hop routing for communication
quickly and unpredictably changing topology
5
Infrastructured network
6
MANET = Mobile Ad Hoc Networks a set of mobile hosts, each with a transceiver no base stations; no fixed network infrastructure multi-hop communication needs a routing protocol which can handle changing
topology
7
Single-Hop Ad Hoc
8
Multi-hop Ad Hoc
9
Single-hop Vs. Multi-hop systems
10
Ad-Hoc typical applications
Personal area networking cell phone, laptop, ear phone, wrist watch
Military environments soldiers, tanks, planes
Civilian environments car network
meeting rooms sports stadiums boats, small aircraft
Emergency operations search-and-rescue policing and fire fighting
11
Peer-to-Peer
12
Multi-hop Peer-to-Peer
13
Multi-hopping via Wireless Router
14
Hopping on the Network
15
Supports Mobility
16
Supports Non Line-of-Sight
17
Military applications Situational Awareness (SA) and Command and Con
trol (C2) for military.
18
Nokia RoofTop Wireless Routing A wireless broadband solution for residential marke
ts, based on a multihop Ad-Hoc (mesh) networking.
19
Related Research
IEEE 802.11 for Wireless LANs MAC PHY
IETF manet group to stimulate research and discuss possible standards in t
his area
Routing Protocols: unicast – AODV, DSR, ZRP, TORA, CBRP, CEDAR multicast – AMRoute, ODMRP, AMRIS
20
Characteristics and requirements
Distributed operation Dynamic network topology Fluctuating link capacity Low-power devices
21
Challenges Broadcast nature of the wireless medium
Hidden terminal problem Packet losses due to transmission errors Mobility-induced route changes Mobility-induced packet losses Battery constraints Potentially frequent network partitions Ease of snooping on wireless transmissions
(security hazard) Quality of Service
22
Routing Protocols
We need a new routing and multicasts protocols that perform the following functions :
Ensure routing in a dynamic, Ad-Hoc network through automatic detection of new or missing links.
Automatically select the highest quality, least congested paths.
Provide an efficient multicast mechanism across the wireless broadcast channel.
23
Overview of Current Routing Protocols
24
On-demand vs. Table-driven
Table-Driven Routing Protocol: proactive!! continuously evaluate the routes attempt to maintain consistent, up-to-date routing
information when a route is needed, one may be ready
immediately when the network topology changes
the protocol responds by propagating updates throughout the network to maintain a consistent view
Example DSDV
25
On-Demand Routing Protocol: reactive!! on-demand style: create routes only when it is desired
by the source node route discovery: invoke a route-determination
procedure the procedure is terminated when
a route has been found no route is found after all route permutations are
examined longer delay: sometimes a route may not be ready for
use immediately when data packets come Example AODV
26
Table-Driven Routing Protocols
DSDV (Destination Sequence Distance Vector)
“Highly Dynamic Destination-Sequence Distance-Vector Routing (DSDV) for Mobile Computers”
Charles E. Perkins & Pravin Bhagwat Dated: 1994 Computer Communications Review, ‘94 pp. 234-244
27
DSDV
Based on the Bellman-Ford algorithm Each node keeps a routing table to all other
nodes. based on next-hop routing
Path discovery through packet caching and header examination.
Entries have a sequence number. Incremental updates possible.
28
A
B
1B
1A
>B
>AC
2C
1C1B
2A
>B
>B
>B>C
D
3D
2D1D
2B
1C
3A
>B
>D
>C>C
>C
>C
3
3E
A
2B
2D
1C
2E1E
2E E
>B
>D
>C
>C
>C
>C>C
>C
Routing TableRouting Table broadcast broadcast
Node
29
Once its routing table changes, a node broadcasts its table to other nodes.
30
31
32
On-Demand Routing Protocol
Ad-Hoc On-Demand Distance Vector (AODV) Routing
Protocol overview and objectives Path Discovery Reverse Path Setup Forward Path Setup Route Table Management Path Maintenance Local Connectivity Management
33
Outline of Basic Functions of a Node
AODV Nodes Status
Source Node Intermediate Node Destination Node
34
AODV UNICSAT ROUTE ROUTE ESTABLISHMENT
Source Node
•Initiate a path discovery process by broadcasting a RREQ packet to its neighbors.
•Reinitiate the path discovery process when it moves.
•Reinitiate the path discovery process when it receives a failure notification message from nodes along the path to the destination.
35
Intermediate Nodes•Reply to the RREQ packet by unicasting a RREP packet back t
o the source, only when they have a route to the destination whose seq. # is greater or equal to the seq. # contained in the RREQ packet.
•Store in their routing tables the address of the neighbor from which the RREQ is received, thereby establishing a reverse path back to the source.
•Discard additional copies of the same RREQ latter received ( Broadcast ID and source IP address uniquely specify the RREQ packet).
•Send failure notification messages to the source (route erase ) when moving away.
36
Destination Node
•Respond to the RREQ packet by unicasting a route reply (RREP) packet back to the neighbor it has first received a RREQ packet. This packet is routed along the already established reverse path.
•Reinitiate the path discovery process when it moves.
•Reinitiate the path discovery process when it receives a failure notification message from nodes along the path to the destination.
37
Basic Functions of a Node
• Maintain route information in its route table.
• Information obtained through RREQ & RREP messages is kept with other routing information in the route table.
• Update the Seq. # to eliminate unused routes
• Manage aging process of routes with old seq. #
38
AODV Route Discovery
• Initiated by a node wishing to communicate. Reinitiate the RREQ for rreq_retries incase of a lost RREQ
• Route Request packets are broadcast• RREQ format
< source_addr, current source_sequence-# , broadcast_id, dest_addr, dest_sequence_#, hop_cnt >
• RREQ uniquely identified by <source_addr , broadcast_id>
39
• Broadcast ID is incremented with every RREQ
• Set a timer to wait for a reply.
• Neighboring nodes maintain a record of every RREQ for a specified period of time.
• Setup a reverse path entry for the source node. This entry contains the source IP, Source_Seq.#, #hops to the source and IP’s addresses of neighbor from which it received the RREQ.
40
• Set a lifetime for the reverse path.• Neighboring nodes satisfy RREQ by sending RRE
P or broadcast RREQ after incrementing hop_cnt• In summary, each intermediate node keeps the fol
lowing information for a particular RREQ– Destination Address and Seq.#
– Source node’s sequence number and IP address– # hops to the source and the IP’s of neighboring
nodes– Broadcast_ID
– Expiration time for reverse path entry
41
Route Discovery Flow Chart (1)
Existence of active route
Yes No
A source wishing to transmit
Check the route table
Forward packet
to next hop
Initiate a Route
Discovery Process
Create RREQ
packet
Broadcast RREQ &
Set the timer for a reply
42
(2)
Check its record to see if It had seen it.
Intermediate node receiving the RREQ
Record the RREQ Information & broadcast
Setup reverse route entry
Discard the packet
Unicast a REPP
Increment hop count and broadcast
Did it see the RREQ before?
NoYes
Reverse path expired
Yes
No
43
D
S
X
XX
UNICAST AODV
44
Optimization: Expanding Ring Search
• Route Requests are initially sent with small Time-to-Live (TTL) field, to limit their propagation.
• If no Route Reply is received within the ttl_start value, then larger TTL is tried unlit the threshold value is reached, beyond which the RREQ is broadcast through the entire network to rreq_retries.
• After the route is established, distance to the destination is used to reinitiate TTL to this value.
45
• RREQ arrives at a node that has current route to the destination ( larger/same sequence number).
• Unicast request reply (RREP)<source_addr, dest_addr, dest_sequence_#, hop_cnt,lifetime> to neighbor from which it has received the RREQ.
• Intermediate node respond the same but with hop_cnt set to its distance from the destination.
• RREP travels back to the source along the reverse path
• Each upstream node updates dest_sequence_#, sets up a forward pointer to the neighbor who transmit the RREP
AODV Forward Path Setup
46
• Updates information in the forward path entry of subsequent on reception RREPs.
• Multiple arrivals of RREPs at a node will be discarded provided that their sequence # are less than the destination seq. of the first RREP or have higher hops count.
• Source can begin transmission as soon as it receives the first RREP.
47
Forward Path Setup in AODV
Forward links are setup when RREP travels alongthe reverse path
Represents links on Reverse Path
Represents a link on the forward path
N1
S
D
N11
N2
N3
N4
N5
N6
N7
N8
N10
N9
48
AODV Reverse Path Setup
• Source sequence number is used to maintain freshness about reverse route to the source
• Destination sequence number specified for freshness of route before accepted by source
• Reverse path setup by having link to neighbor from which it received RREQ
49
AODV Route Table Management
• Route Request Expiration Timer for purging reverse paths which do not lie on source-destination route
• Route Caching Timeout for time after which the route is considered invalid
• Active_timeout Period used to determine if neighboring node is active
50
AODV Route Table Management Cont.
• Route Table entry – Destination– Next Hop– Number of hops (metric)– Sequence numbers of Destination– Active Neighbors for this route– Expiration time for the route table entry
51
AODV Route Maintenance
• Node movement affect only the routes containing these nodes.
• Source movement reinitiates the path discovery process
• When destination node or intermediate node moves a Route Error (RERR) message, initiated from upstream nodes of the source node , is sent to the affected source nodes.
• When next hop become unreachable the upstream node propagates RERR to neighbor with fresh sequence number and hop cnt
• restart route discovery process from source on receipt of RERR
52
Summary of Route Error
• When a node is unable to forward packet (from node S to node D) on link (L), it generates a RERR message
• The node increments the destination sequence number for D cached at its route information
• The incremented sequence number N is included in the RERR
53
When node S receives the RERR, it initiates a new route discovery for D using destination sequence number at least as large as N
When node D receives the route request with destination sequence number N, node D will set its sequence number to N, unless it is already larger than N
54
S
N1N2
N3
N3’
D
N4N5
RERRRERR
AODV Route Maintenance
S- Source Node
D- Destination Node
55
S
N1N2
N3
N3’
D
N4N5
AODV Route Maintenance Cont.
New Route Found through Node 4
X
X
S- Source Node
D- Destination Node
56
AODV Local Connectivity Management
• Node learn of their neighbors in following way– on receipt of broadcast message, the node
updates the lifetime associated with that neighbor.
– on receipt of hello message
•Hello messages are only local (TTL=1) and it contains <IP_Address, Noed_Sequence_#>
•Failure to receive Hello message during (hello_interval) indicate that the route information of the neighbor need to be updated.
•Hello messages are sent from neighbor during an active path
57
Local Link Failure Detection
• Hello messages: Neighboring nodes periodically exchange hello message
• Absence of ((1+allowed_hello_loss)*hello_lifetime) of hello message is used as an indication of link failure
58
AODV Rebooting
To prevent routing loops during node rebooting, the node will wait for delete_period, during which it does not respond to any routing packet.
Update its Seq.# whenever it receives a RREQ from its neighbor
59
Link Failure Reporting
• A neighbor of node N is considered active for a routing table entry if the neighbor sent a packet within active_route_timeout interval
• 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
60
Ad-Hoc performance
Simulation Environment
Simulation tools used: GloMoSim
Size of Network: 50,100,250,500
Fixed area L*L:1*1km:1.5*1.5km: 2.4*2.4:3.45:3.45km
Range: 250 meters
Data rate: 2Mbps
Packet size: 64bytes
Node Speed: 0~10 m/s
61
Rest period at the random spot: 60~300 second Carrier sensing is performed by each node prior
to transmission Simulation time: 300 second
62
Simulation Results
Fig.1 Neighbors vs. Speed
63
Fig.2 Packets Delivered vs. Speed
64
Fig.2 Packets Delivered vs. Speed
65
Fig.4 Route Acquisition vs. Speed
66
Comparison Of Table Driven Routing Protocols
Parameters DSDV CGSR WRP
Time Complexity O(d) O(d) O(h)
Route Complexity O(x = N) O(x = N) O(x = N)
Route Philosophy Flat Hierarchical Flat
Loop Free Yes Yes Yes, but instantenous
Multicast Capability No No No
Required Tables 2 2 4
Freq Of Updated Transmission Periodically and as needed
Periodically Periodically and as needed
Updates Transmitted to Neighbors Neighbors and cluster heads
Neighbors
Utilize Seq. No / Hello Packets Yes/No Yes/No Yes/Yes
Critical Nodes No Yes(cluster head) No
Routing Metric Shortest path Shortest path Shortest path
67
Comparison Of On Demand Protocols
Performance Parameters AODV DSR TORA ABR
Time Complexity (start) O(2d) O(2d) O(2d) O(d+x)
Time Complexity (after fail) O(2d) O(2d) or 0(cache hit)
O(2d) O(l+x)
Communication Complexity O(2N) O(2N) O(2N) O(N+y)
Communication Complexity O(2N) O(2N) O(2x) O(x+y)
Routing / Loop Free Flat / Yes Flat / Yes Flat / Yes Flat / Yes
Multicast Capability Yes No No No
Beaconing Requirements No No No Yes
Multiple Route Possibilities No Yes Yes No
Route Reconfiguration Erase Route, Notify Source
Erase Route, Notify Source
Link reversal, route repair
Localized broadcast query
Route Maintained in Route table Route cache Route table Route table
Routing Metric Fresh and shortest
Shortest Shortest Associativity and shortest
path
68
Comparison of On-Demand v/s Table Driven Routing
Parameters On Demand Table Driven
Availability of Routing Information
Available when needed Always available regardless of need
Routing Philosophy Flat Mostly Flat except for CGSR
Periodic route updates Not Required Yes
Coping with Mobility Using Localized route discovery in ABR
Inform other nodes to achieve consistent routing
tables
Signaling Traffic Generated
Grows with increasing mobility of active nodes
as in ABR
Greater than that of On Demand Routing
QoS Support Few Can Support QoS Mainly Shortest Path as QoS Metric