1. Ad-hoc Networks

2. Announcements… Preliminary presentations next week
By default, I will assume that you have completed the “recommended milestones” I have discussed with you during the project definition

3. Ad-hoc Networks
Infrastructure-less wireless networks dynamically formed using only mobile hosts (no routers)
Network topology dynamic as all hosts are mobile!
Mobile hosts themselves double up as routers!!
Multi-hop paths …
Highly resource constrained
Extreme case of network mobility…

4. Applications Military applications Disaster-relief applications
Sensor Networks
Coverage extensions
Capacity, Energy arguments

5. Illustration A B C D

6. Protocols … Channel allocation Topology control MAC layer
Routing Layer
Transport layer

7. Medium Access Control
Requirements: hidden/exposed terminal problems, shared channel, low overheads, wireless errors
Most approaches use CSMA/CA based schemes
IEEE used in most related works
Is IEEE good for ad-hoc networks?
node-fairness vs. flow fairness
spatial re-use characteristics
multi-hop environment

8. IEEE 802.11 Unicast transmissions Broadcast transmissions
Sender sends RTS to receiver
Receiver sends CTS to sender
Sender sends DATA to receiver
Receiver sends ACK to sender
Broadcast transmissions
Only carrier sensing

9. Routing Protocols Proactive approaches Reactive approaches
DSDV (destination sequenced distance vector), LSR (link state routing), OLSR (optimized link state routing)
Reactive approaches
DSR (dynamic source routing), AODV (ad-hoc on-demand distance vector)
Hybrid approaches
ZRP (zone routing protocol), CEDAR (Core extraction distributed ad-hoc routing)

10. Proactive routing protocols…
Unsuitable for such a dynamic n/w
For example, consider link-state routing that sends out network-wide floods for every link-state change …
Even in the absence of any existing connections, considerable overhead spent in maintaining “network state”

11. Goals Low overhead route computation
Ability to recover from frequent failures at low-cost
Scalable (with respect to mobility and number of hosts)
Robust

12. Reactive (On-demand) protocols
Compute routes only when needed
Even if network state changes, any re-computation done only when any existing connections are affected
Example:
Dynamic source routing (DSR)
Ad-hoc On-demand Distance Vector (AODV)

13. Dynamic Source Routing
Based on source routing
On-demand
Route computation performed on a per-connection basis
Source, after route computation, appends each packet with a source-route
Intermediate hosts forward packet based on source route

14. DSR – Basic Operation
When higher layer gives DSR a packet to transmit, and there exists no route in the route-cache, route computation is performed
Source S floods the network with a RREQ (route request) packet for the destination D
Every host I that receives the RREQ packet checks to see if I=D. If not, I adds its identifier to the RREQ packet header and forwards the packet

15. DSR – Basic Operation (contd.)
Each forward is a local broadcast (unlike in a wireline network where a flood would entail multiple local transmissions)
When D receives packet, the RREQ message contains the list of identifiers it traversed through
D responds to the sender S with an RREP (route reply) message containing the route in the RREQ – How?

16. DSR – RREP propagation
If MAC layer assumes bi-directionality (e.g.?), D has to use the same route (reversed) that is being conveyed to S
If not, and if network can have asymmetric links (why?), D has to use an explicitly computed route from D to S
Infinite loop possible?

17. DSR (Contd.)
When S receives the RREP message, it starts using it from thereon
Every packet from S to D has the route in its header
Intermediate hosts merely forward based on the source route

18. DSR – Route Maintenance
Consider path S-X-Y-Z-D
Let Y-Z link break (why?)
Y initiates a route error (RERR) message back to S conveying the link failure
When S receives the RERR, it switches to an alternate route (or re-issues another RREQ if none available)

19. Additional Mechanisms - 1
Caching overheard routes
Every host caches routes that it overhears (how?)
Such routes are later used if needed
Cached routes also used in the next mechanism

20. Additional Mechanisms - 2
Replying to route requests using cached routes
When an intermediate host I receives a route request for D, and has a cached route for D, it replies to the source with the cached route+the route thus far from S-I
Reduces route computation latency
Provides source with multiple route options
Cons?

21. Additional Mechanisms - 3
Preventing route reply storms
Too many route replies can be generated if reply-from-cache is enabled
Each node waits for a period t (proportional to the hop-count of cached path) before it replies
Reply suppressed if source starts using new route

22. Additional Mechanisms - 4
Expanding ring search
Instead of network wide flood, send RREQ with TTL=1
If no reply, send RREQ with TTL=2, and so on …
Reduces route computation overhead
Trade-offs?

23. Additional Mechanisms - 5
Packet salvaging
If Y-Z fails in S-X-Y-Z-D, Y sends back RERR
Y also tries to salvage packets by using any cached route it might have for D

24. Additional Mechanisms - 6
Route shortening
Consider path S-X-Y-Z-D
If Y moves within range of S (and still remains connected to Z & D), Y issues an unsolicited route reply to S conveying shorter route (S-Y-Z-D)

25. AODV Ad-hoc on-demand distance vector
Hop-by-hop routing as opposed to source routing
On-demand
When RREQ propagates, routing tables updated at intermediate nodes (for route to source of RREQ)
When RREP is sent by destination, routing tables updated at intermediate nodes (for route to destination), and propagated back to source
Trade-offs?

26. Comparison Link state Local Low maintenance overhead
Low update overhead
High access overhead
Dynamic networks
Local
Low maintenance overhead
Low access overhead
High update overhead
Static networks
Link state

27. Transport Layer UDP? TCP problems:
Wireless losses
Mobility induced losses
Why different from the mobility in the Internet?

28. Transport Layer (Contd.)
Wireless errors: Solutions
Reliable link layer
IEEE inherently has an ACK scheme
Any issues?
Mobility induced losses: Solutions
ELFN: Explicit link failure notification

29. Three broad classes of works
Simple extensions to TCP to enhance TCP performance over ad-hoc networks
Layer integrated approach to enhance TCP performance over ad-hoc networks
New transport protocols for reliable transport over ad-hoc networks

30. TCP - ELFN
Cellular wireless networks – random wireless errors with occasional handoffs
Ad-hoc networks – random wireless errors and mobility related losses equally important
Can TCP be made to recognize losses due to mobility?

31. TCP-ELFN (contd.) Route failure detection?
When upstream node of failed link infers a link failure
Node upstream of failure sends an ELFN (explicit link failure notification) to source
TCP source, when it receives the ELFN, freezes TCP state and enters “probe” mode
When response to probe received, sender de-freezes state and proceeds as normal
Sender does not cut down congestion window due to mobility related losses

32. TCP-ELFN (contd.)
MAC layer (CSMA/CA) recovers from random wireless losses
TCP is notified upon route failures and hence does not react adversely to route failure induced packet losses
Is everything then perfect?

33. Other factors … Losses MAC failure detection time
Failure notification latency
Route computation time

34. Losses
ELFN does not prevent losses from occurring in the network due to route failure
It merely hides the impact of such losses from TCP
Why are losses bad?
Wastage of resources and possible impact on TCP

35. MAC Failure Detection Time (FDT)
A MAC protocol such as has to go through multiple transmissions before it can infer a link failure
Under heavy load conditions, this latency can be of the order of several round-trip times!
TCP would have pumped in an entire window worth of packets before failure is detected
Timeouts possible even before the ELFN reaches the TCP sender

36. Link Failure Notification Latency
In DSR, RERR is sent only to the source whose packet experiences a route failure
What about other sources that are using that link ?
Such sources will have to wait till one of their packets experiences a route failure

37. Route Computation Latency
Once a source is informed of a path failure, a new route needs to be re-computed
Route computation latency can increase with increasing load in the network
For example, in a 100 second simulation with 25 TCP-ELFN connections and 20m/s mobility, each connection spent an average of 15 seconds(!) in route re-computation
Under-utilization and timeouts!

38. Reduce # of Route Failures?
The choice of forward and reverse paths for a TCP connection is left to DSR, which can end up using different paths!
Why is this bad?
Probability of a route failure for the connection increases to 1-(1-p)(h1+h2) where p is the link failure probability, and h1&h2 are the hop-counts of the forward and reverse paths
Solution: perform symmetric route pinning – pin the ACK path to the DATA path

39. Reduce Losses and MAC FDT
Predict link failures in advance?
Solution: Signal strength can be used as an indication of the distance between two nodes
Monitor the progression of signal strengths on a per-packet basis
If the progression indicates an impending link failure, issue a proactive link failure prediction to the source!
Source re-computes route before current route fails

40. Reduce Failure Notification Latency
Maintain a cache of flows currently traversing link
When a link failure is inferred, issue notification to all sources

41. Why NOT to use TCP
What if TCP mechanisms are fundamentally inappropriate for ad-hoc networks?
TCP mechanisms
Window based transmissions
Slow-start
Loss based congestion detection
Linear increase multiplicative decrease
Self-clocking (reliance on ACKs)

42. Why use TCP? Backward compatibility & deployment issues
Are these real problems for ad-hoc networks?
Maybe not!

43. Window Based Transmissions - Burstiness
Why is burstiness bad?
Varying round-trip times and RTO inflation!!
Higher induced load can pose a problem under heavy load conditions

44. Window Based Transmissions (Contd.)

45. Slow Start Exponential growth to available capacity
But, still “slow” – Under-utilization of network resources if connections stay in slow-start for their entire lifetime
Unfairness a problem as in the case of satellite network environments

46. Slow start (contd.)

47. Loss Based Congestion Indication
TCP detects congestion through the occurrence of losses
Losses in ad-hoc networks can occur either due to congestion or due to route failures
Significant portion of losses “perceived” to be due to route failures

48. Loss Based Congestion Indication (contd.)

49. Linear Increase Multiplicative Decrease
TCP performs loss detection through occurrence of losses
Losses can be due to route failures
Is it right to perform LIMD after a route failure?
NO!

50. LIMD (Contd.)

51. Dependence on ACKs
TCP relies on self-clocking for correct progression of its congestion window adaptation
# of ACKs ~ # of DATA packets
Reverse path can induce congestion (if the same path is used) or increase probability of route failures!

52. A Reliable Transport Protocol for Ad-hoc Networks (ATP)
Layer coordination
Rate based transmissions
Decoupling of congestion control and reliability
Assisted congestion control
TCP friendliness & fairness

53. Topology control
Given a physical layout of nodes in an ad-hoc network, what is the optimal logical topology?
Transmission range adjustment used to change logical topology
Most approaches rely on min-power optimality assumption
Optimal transmission range depends upon load, density of nodes, # of nodes

54. Puzzle You have a deck of 52 cards
You draw out 5 cards randomly and look at the cards
You can now show 4 of the cards to a friend, and the friend should identify the 5th card
How do you do this?

55. Recap Ad-hoc networks MAC layer Routing layer Transport layer
Topology control