Download www.winlab.rutgers.edu

Wireless Mesh Networking
Shweta Jain
WINLAB, Rutgers University
Credits for the slides
Prof Samir R. Das
Stony Brook University, SUNY
Idea and Applications
What is a Mesh Network?
WLAN Access
Points
Clients
Wired Backbone
• “Wireless Paradox” : WLAN Access Points are
typically wired.
2
© Samir R Das, Stony Brook University, 2006
What is a Mesh Network?
WLAN Access
Points/ Routers
Clients
Wired Backbone
• Get rid of the wires from wireless LAN.
• Access Points double as “wireless routers.”
• Wireless routers form a backbone network.
© Samir R Das, Stony Brook University, 2006
3
Mesh Networking Advantage
• Very low installation and maintenance cost.
– No wiring! Wiring is always expensive/labor intensive, time
consuming, inflexible.
• Easy to provide coverage in outdoors and hard-to-wire
areas.
– Ubiquitous access.
• Rapid deployment.
• Self-healing, resilient, extensible.
© Samir R Das, Stony Brook University, 2006
4
Community Mesh Network
© Samir R Das, Stony Brook University, 2006
6
Community Mesh Network
• Grass-roots wireless network for
communities.
• Share Internet connections via gateway.
• Peer-to-peer neighborhood applications.
• Serious opportunities in developing
countries, rural areas.
© Samir R Das, Stony Brook University, 2006
7
Metro-Scale Mesh Network
Photo Credit:
Mesh Dynamics
[Source: http://muniwireless.com]
• Covers an entire metropolitan area.
© Samir R Das, Stony Brook University, 2006
8
Public Safety
[Source: www.meshdynamics.com]9
© Samir R Das, Stony Brook University, 2006
Intelligent Transportation System
Real Time
Information
Bus Stops
[Source: Intelligent
Transport Systems
City of Portsmouth,
IPQC Mesh
Networking Forum
presentation, 2005]
I+
Information
Kiosk
© Samir R Das, Stony Brook University, 2006
10
Addressing the Digital Divide
Source: ITU
Source: ITU
• Internet penetration positively correlated
with per capita GNP.
• Need affordable and fast last mile
connectivity.
• Tremendous opportunities in developing
countries. © Samir R Das, Stony Brook University, 2006
11
Many Service Models
• Private ISP (paid service)
• City/county/municipality efforts
• Grassroots community efforts
• May be shared infrastructure for multiple uses
– Internet access
– Government, public safety, law enforcement
– Education, community peer-to-peer
© Samir R Das, Stony Brook University, 2006
12
Similar Ideas in History
• Packet Radio and Mobile Ad Hoc Networks
1972: Packet Radio NETwork (PRNET)
1980s: SURvivable Adaptive Radio Network (SURAN)
Early 1990s: GLObal MObile Information System (&
NTDR)
Research agenda mostly set by DoD. Applications
mostly military.
Mid 1990s: IETF MANET. Applications
military/tactical, emergency response, disaster
recovery, explorations, etc. Goal: standardize a set
of IP-based routing protocols.
• Scenarios too specific. Little commercial impact in
spite of 30 years of research.
© Samir R Das, Stony Brook University, 2006
14
History (contd.)
• However, great strides in several fronts in ad hoc
networking research
– Understanding routing in dynamic networks.
– Understanding MAC protocols for wireless multihop
networks.
• Can we simply borrow from history?
– Yes. But some issues are different in mesh.
– Size, power, applications.
© Samir R Das, Stony Brook University, 2006
15
Research Challenges
• Routing
– Routing metric
• Multiple access
– Dealing with multihop interference
– Fairness
• Capacity
– Understanding capacity
– Improving capacity
• Transport
– TCP over wireless multihop
© Samir R Das, Stony Brook University, 2006
16
Routing Protocols
Unicast Routing
18
How is Dynamic Routing in
Ad Hoc Networks Different ?
• Topological change may have unfamiliar
characteristics
– Link failure/repair due to mobility usually have different
characteristics than those due to other causes.
• Rate of topological change may be high
• Bandwidth is low in wireless networks
– Routing overhead must be kept low.
19
Routing Protocols
• Proactive protocols (traditional)
– Traditional distributed shortest-path protocols.
– Based on periodic updates. High routing overhead.
– Link-state and distance vector protocols.
• Reactive or on-demand protocols (newer)
– Maintain routes on an as-needed basis.
– Uses a source-initiated route discovery technique.
• Hybrid protocols (combination).
• Geographically based protocols.
20
Assumptions and
Terminologies
21
•
Underlying Radio and MAC
Models
Symmetric radio links
– If node A has a link to node B, node B also has a link to
node A.
• Contention-based MAC (CSMA)
– A packet transmitted is heard by ALL nodes in the
neighborhood.
– Two types of packets.
– Broadcast: No specified next-hop address. All nodes in
the neighborhood picks up and processes the packet.
– Unicast: Has an intended next-hop address. Only that
node picks up and processes the packet.
– Unicast packets still cause contention for the other
nodes. Also, other nodes may snoop on such packets .
22
Hop-by-Hop Routing
Dest. Next Hop #Hops
Dest. Next Hop #Hops
D
A
D
3
S
DATA
A
B
2
B
Dest. Next Hop #Hops
D
D
D
1
Routing Tables
on each node for
hop-by-hop routing
D
• Routing table on each node contains the next hop
node and a cost metric for each destination.
• Data packet only has the destination address.
23
Source Routing
S
A
B
D
payload S-A-B-D
• In source routing, the data packet has the
complete route (called source route) in the header.
• Typically, the source node builds the whole route
• The data packet routes it self.
24
Reactive or On-demand
Protocols
25
Dynamic Source Routing (DSR)
[Johnson-Maltz-96,
Broch et. al. 98-00]
• When node S wants to send a packet to node D, but
does not know a route to D, node S initiates a route
discovery.
• Source node S floods the network with route request
(RREQ) packets (also called query packets).
• Each node appends its own address in the packet
header when forwarding RREQ.
26
Route Discovery in DSR
[S]
S
RREQ broadcast
E
F
A
C
G
D
B
represents a node that has received RREQ for D from S.
[X,..,..]
Represents list of addresses appended to RREQ.
A node receiving a RREQ rebroadcasts it exactly once.
27
Route Discovery in DSR
[S,E]
S
[S,A]
RREQ broadcast
E
F
A
C
[S,C]
G
D
B
represents a node that has received RREQ for D from S.
[X,..,..]
Represents list of addresses appended to RREQ.
A node receiving a RREQ rebroadcasts it exactly once.
28
Route Discovery in DSR
S
RREQ broadcast
E
F
A
[S,E,F]
C
G
[S,A,B]
D
B
[S,C,G]
Destination D receives RREQ via G and F.
It does not broadcast it further.
29
Route Discovery in DSR
• Destination D on receiving the first RREQ, sends a
Route Reply (RREP).
• RREP is sent on a route obtained by reversing the
route appended to received RREQ.
• RREP includes the reverse route from S to D on which
RREQ was received by node D.
30
Route Reply in DSR
S
RREP Unicast
E
F
A
C
G
[D,F,E,S]
D
B
Reverse route
in the header
of RREP
31
Route Caching in 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.
32
Data Delivery in DSR
DATA [S,E,F,D]
Cache on S:
[S,E,F,D]
S
E
F
A
DATA packet
Unicast
C
G
D
B
Source route size grows with route length.
33
Route Error
DATA [S,E,F,D]
Cache on S:
[S,E,F,D]
S
E
F
A
DATA packet
Unicast
C
G
D
B
• If the next hop link is broken when a data
packet is being forwarded, a Route Error
(RERR) is generate and propagated backwards.
34
Route Error
RERR [F,E,S] [Failed link = FD]
Cache on S:
[S,E,F,D]
S
E
F
A
RERR is
Unicast
C
G
D
B
• If the next hop link is broken when a data
packet is being forwarded, a Route Error
(RERR) is generate and propagated backwards.
• RERR contains the failed link info.
35
Route Error
RERR [F,E,S] [Failed link = FD]
Cache on S:
[S,E,F,D]
S
E
F
A
RERR is
Unicast
C
G
D
B
• When S receives RERR, it erases any cached
route with the failed link.
36
Aggressive Route Caching
• Each node caches a new route it learns by any
means
• When node S finds route [S,E,F,D] to node D, node
S also learns route [S,E,F] to node F and so on.
• When node G receives RREQ [S,C] destined for
node D, node G learns route [G,C,S] to node S and
so on.
• When node F forwards RREP [D,F,E,S], node F
learns route [F,D] to node D and so on.
• Basically, when forwarding any packet, the node
learns a route to all nodes in the source route
contained in the packet.
37
Contents of Caches on Selected
Nodes After one RREQ-RREP
Cycle
S
E
F
A
[F,E,S]
[F,D]
[F,G,C,S]
C
G
B
D
[D,F,E,S]
[D,G,C,S]
• [P,Q,R] represents cached route at a node P.
• More than one routes may be cached for the same
destination.
• Compact data structures may be used to implement
route caches (e.g., tree).
38
Use of Route Caching
• Salvaging: 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
• Reply from Cache: Node X on receiving a RREQ
for some node D can send a Route Reply if node X
knows a route to node D.
• Aggressive use of route cache
– can speed up route discovery.
– can reduce propagation of route requests.
39
Route Caching: Beware!
• Stale caches can adversely affect performance.
• With passage of time and host mobility, cached
routes may become invalid.
• All cached routes containing a failed link are not
erased by route error (RERR).
– Only that route is erased that is attempted to be used
• A sender host may try several stale routes (obtained
from local cache, or replied from cache by other
nodes), before finding a valid route.
40
Dynamic Source Routing:
Advantages
• Source routing: no special mechanism needed to
eliminate loops.
• On demand routing: 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.
– Useful when route breaks.
41
Dynamic Source Routing:
Disadvantages
• Not scalable: Packet header size grows linearly
with route length due to source routing.
• Network-wide flood: Flood of route requests may
potentially reach all nodes in the network. Too
much overhead.
• Collision: Care must be taken to avoid collisions
between route requests propagated by neighboring
nodes
– insertion of random delays before forwarding RREQ
• Reply storm problem: Increased contention if too
many route replies come back due to nodes
replying using their local cache
– Reply storm may be eased by preventing a node from
sending RREP if it hears another RREP with a shorter
route.
42
Dynamic Source Routing:
Disadvantages
• Stale cache problem: An intermediate node may
send Route Reply using a stale cached route, thus
polluting other caches.
• This problem can be eased if some mechanism to
purge (potentially) invalid cached routes is
incorporated.
• Current research: how to invalidate caches
effectively.
– Example: Timer-based. Or propagate the route error
widely.
43
Ad Hoc On-Demand Distance
Vector Routing (AODV)
[Perkins-Royer-Das 99,00]
• AODV retains the desirable feature of DSR that
routes are maintained only between nodes which
need to communicate.
• AODV attempts to improve on DSR by maintaining
routing tables at the nodes, so that data packets do
not have to contain routes.
• No caches are used.
– Only one route per destination in the routing table.
– Only maintain the freshest route, if multiple possibilities.
44
AODV
• Route Requests (RREQ) are forwarded in a manner
similar to DSR.
• When a node re-broadcasts a RREQ, it sets up a
reverse path pointing towards the source.
– This is so that the RREP can get back to the source.
• When the intended destination receives a RREQ,
it replies by sending a RREP.
• RREP travels along the reverse path set up when
RREQ is forwarded.
45
AODV Route Discovery
S
RREQ broadcast
E
F
A
C
G
D
B
• Source floods route request (RREQ) in the
network.
• Reverse paths are formed when a node hears a
route request.
• Each node forwards the request only once (pure
flooding).
46
AODV Route Discovery
S
Reverse Path
E
F
A
C
G
D
B
• Source floods route request in the network.
• Reverse paths are formed when a node hears a
route request.
• Each node forwards the request only once (pure
flooding).
47
AODV Route Discovery
S
RREQ broadcast
E
F
A
Reverse Path
C
G
D
B
• Uses hop-by-hop routing.
• Reverse paths are formed when a node hears a
route request.
• Each node forwards the request only once (pure
flooding).
48
AODV Route Discovery
S
E
F
A
Reverse Path
C
G
D
B
• Uses hop-by-hop routing.
• Reverse paths are formed when a node hears a
route request.
• Each node forwards the request only once (pure
flooding).
49
AODV Route Discovery
S
E
F
A
Reverse Path
C
G
D
B
• Route reply (RREP) is forwarded via the reverse
path.
50
AODV Route Discovery
S
Forward Path
E
F
A
Reverse Path
C
G
D
B
• Route reply is forwarded via the reverse path …
thus forming the forward path.
• The forward path is used to route data packets.
51
Route Expiry on Timeout
• A routing table entry maintaining a reverse path is
invalidated after a timeout interval
– Timeout should be long enough to allow RREP to come back
• A routing table entry maintaining a forward path is
also invalidated if unused for certain interval.
– This means unused routes are purged.
– Note that the route may still be valid.
52
Route Expiry
S
E
F
A
Forward Path
C
G
D
B
• Unused reverse paths expire based on a timer.
53
Link Failure Detection
• Hello messages: Neighboring nodes periodically
exchange hello or keep-alive messages.
• Absence of any hello message for some time is used
as an indication of link failure.
• Alternatively, failure to receive several link-layer
ACK for a transmitted packet may be used as an
indication of link failure.
• Note DSR needs to use one of the above as well.
54
Route Error
• When a node X is unable to forward packet P (from
node S to node D) on link (X,Y), it generates a RERR
message back to S.
• How to forward the RERR to S? X may not have a
route to S.
• RERR is broadcast. Any node having an active route to
D, rebroadcasts RERR after invalidating that route.
55
Route Error Propagation
S
E
F
A
C
G
D
B
• Link breakage on an active route triggers route
error (RERR).
56
Route Error Propagation
S
RRER broadcast
E
F
A
C
G
D
B
• F invalidates the route to D, and broadcasts RERR.
• E notes that it has a route to D via F, and it
continues the process.
57
Route Error Propagation
S
E
F
A
C
G
D
B
• F invalidates the route to D, and broadcasts RERR.
• E notes that it has a route to D via F, and it
continues the process.
58
Route Error Propagation
S
E
F
A
C
G
D
B
• The entire upstream route is erased.
• S starts fresh route discovery if needed.
59
Possibility of Routing Loops!
• Useful optimization: An intermediate node with a
route to D can reply to route request.
– Faster operation.
– Quenches route request flood.
• Wireless reality: Routing messages can get lost.
• It can be shown that above can cause long-term
routing loops.
60
Possibility of Routing Loops!
A
B
C
D
E
• Assume that A does not know about failure of link
C-D because route error sent by C is lost.
• Now C performs a route discovery for D. Node A
receives the route request (say, via path C-E-A)
• Node A will reply since A knows a route to D via
node B
• Results in a loop (for instance, C-E-A-B-C )
61
Possibility of Routing Loops!
A
B
C
D
E
• Assume that A does not know about failure of link
C-D because route error sent by C is lost.
• Now C performs a route discovery for D. Node A
receives the route request (say, via path C-E-A)
• Node A will reply since A knows a route to D via
node B
• Results in a loop (for instance, C-E-A-B-C )
62
Use of Sequence Numbers in
AODV
• Each node X maintains a sequence number and
increments it at suitable intervals.
• Seq. no. acts like a logical clock.
• Each node Y with a route to X in the routing
table, also maintains a destination sequence
number for X, which is Y’s latest knowledge of
X’s sequence number.
• Destination sequence no. can be used to order
routing updates.
63
Use of Sequence Numbers in
AODV
Has a route to D
Needs a route
RREQ carries 10
to D
Y
?
X
Dest seq no. = 10
Dest seq no. = 7
Y does not reply, but
forwards the RREQ
D
Seq. no. = 15
• Loop freedom: The protocol maintains the
invariant that the destination sequence number
for any destination D never decreases along any
valid route.
– No routing info is accepted from by a node X from any
node Y, where Y’s destination seq. no. for D is less than
X’s destination seq. no. for D.
• Freshest route: Given a choice of multiple routes,
the protocol always chooses the one with the
highest sequence number.
64
How Using Sequence Numbers
can Avoid Loop?
9
A
B
C
D
9
7
E
5
10
All seq no’s are for D
(called destination seq.
no.)
• Link failure increments the destination seq. no. at
C (now is 10).
• If C needs a route to D, RREQ carries the current
dest. seq. no. (10).
• A does not reply as its own dest. seq. no. is less
than 10.
65
Summary: AODV
• No source routing. Based on routing tables.
• Use of sequence numbers to prevent loops.
• At most one route per destination maintained at each
node
– Only the freshest one is maintained (via destination seq. no.)
– Stale route problem is less severe.
– After link break, all routes using the failed link are erased.
• Unused routes expire even if valid.
66
Flood Control Optimizations for
DSR and AODV
• Note that the whole network is flooded by
Route Request (RREQ) packets when route is
needed.
– Large overhead.
– Intermediate nodes with routes may quench the flood,
but not guaranteed and may not happen in all
directions.
• Need techniques to control flood.
• Two different sets of techniques
– Limit the extent of flood to a region where the
destination is likely to be found.
– Eliminate redundant broadcasts.
67
Flood Control Optimizations
68
Route Discovery
D
S
69
Query Flooding
D
S
70
Query Flooding
D
S
71
Query Flooding
D
S
72
Query Flooding
D
S
73
Whole Network is Flooded
D
S
74
Use of Max Hop Count (TTL)
Field
D
S
• Limits query propagation within
a certain number of hops from
the source.
• Expanding ring search.
• Can still flood a substantial
part of the network if
destination is far away.
75
Use of Max Hop Count (TTL)
Field
D
S
• Limits query propagation within
a certain number of hops from
the source.
• Expanding ring search.
• Can still flood a substantial
part of the network if
destination is far away.
76
Using Location Information
• Uses geographic location info to
direct query propagation
towards destination (LAR).
[Ko-Vaidya-98]
D
S
• Or flood data packets directly
in the cone rooted at source
(DREAM).
[Basagni-Chlamtac-Syrotiuk-98]
• Needs additional hardware
(GPS).
77
Query Localization
[Das-Castenada-99]
D
S
• Exploit “spatial locality.”
• Propagate query only in a
topological neighborhood of
the last valid route between S
and D.
• Several heuristics to define
neighborhood possible.
78
Broadcast Storm Problem
[Ni et. al. – 98]
D
B
C
A
• When node A broadcasts a Route Request, nodes B
and C both receive it
• B and C both rebroadcasts (forwards) the request.
• D receives two copies – from B and C. One is
sufficient.
• Since B and C can hear each other, can they
coordinate so that only one will rebroadcast?
79
D
Coverage Question
Now a different topology!
E
B
C
F
A
• Suppose, B decides not to rebroadcast after hearing
C’s rebroadcast.
• RREQ will never reach D.
• B need to be somewhat confident that C’s
rebroadcast is covering all of B’s neighbors before
deciding not to rebroadcast.
• How?
80
Idea: Incremental Coverage is
Small
2
1
5
3
4
• Suppose, node 1 broadcasts a
RREQ.
• Additional nodes randomly
located in the coverage area
of node 1 will only
incrementally add to the
total coverage.
• Benefit very small beyond 5
nodes.
• Idea: need not rebroadcast
the RREQ if already heard a
few broadcasts for the same
RREQ in the neighborhood.
81
Solution for Broadcast Storm
• Counter-Based Scheme: If node X hears more
than k neighbors broadcasting a given route
request, before it can itself rebroadcast it, then
node X will not forward the request
• Intuition: k neighbors together have probably
already forwarded the request to all of X’s
neighbors. Thus re-broadcasting by X will not have
any added benefit.
• Heuristic parameters: Value of k, how long to wait
before rebroadcasting?
82
Proactive Protocols
83
Link State Routing
• Each node floods the network with the status of
its links
– Flood can be periodic.
– Or, when a neighborhood change is detected.
• Each node keeps track of link state information
received from other nodes
– Thus builds its own view of the network connectivity.
• Each node uses its view of network connectivity to
construct a routing table for each destination.
– For example, each node can run a shortest-path
algorithm (e.g., Dijkstra’s) on its own view of the
connectivity graph.
– Different nodes can use different objective for routing.
84
Overhead Reduction in LinkState Protocols
• Pure flooding is high overhead. Do not use pure
flooding. How?
• Method 1: Flood all nodes. But require fewer nodes
to do the forwarding. For example, maintain a tree
structure rooted at the source of the update.
• Method 2: Flood only a connected dominating set
of nodes and maintain routes only among this
dominating set.
– Dominating set: A subset of nodes such that each node in
the network is in this set or a neighbor of some node in
the set.
85
TBRPF: Topology Broadcast
with Reverse Path Forwarding
[Bellur-Ogier-Templin-99,00]
E
B
D
A
C
Source of update
• Send link-state updates only via the minimum-hop
spanning tree rooted at the source of the update.
• Little cost for maintaining the spanning tree. In a
link-state protocol each node has the network
connectivity information.
86
TBRPF: Topology Broadcast
with Reverse Path Forwarding
[Bellur-Ogier-Templin-99,00]
B
E
2 transmissions
instead of 4
D
C
A
Source of update
• Send link-state updates only via the minimum-hop
spanning tree rooted at the source of the update.
• Little cost for maintaining the spanning tree. In a
link-state protocol each node has the network
connectivity information.
87
OLSR: Optimized Link-State
Routing
[Jacket, Qayyaum et. al.-99-01]
• Only multipoint relays (MPR) participate in routing.
Similar to connected dominating set.
• Multipoint relays of node X are its neighbors such
that each two-hop neighbor of X is a one-hop
neighbor of at least one multipoint relay of X.
– Each node transmits its neighbor list in periodic beacons, so
that all nodes know their 2-hop neighbors, in order to choose
the multipoint relays.
– Select as few multipoint relays as possible.
• Only multipoint relays are used for routing.
88
Multipoint Relays
24 retransmissions
needed to flood
the network
89
Multipoint Relays (contd.)
11 retransmissions
needed to flood
the network
90
Optimized Link State Routing
(OLSR)
• OLSR floods link-state information only through
multipoint relays.
• Routes used by OLSR only include multipoint relays
as intermediate nodes .
– Routes are still optimal!
• Each node maintains information about its MPR
(multipoint relay) selector set, i.e., set of neighbors
that have selected itself as MPR.
• Each node with non-empty MPR selector set
periodically floods the network with topology
control (TC) messages containing own MPR selector
set.
– This information is used to construct the topology
database used for routing calculations.
91
Distance Vector Routing
• Each node maintains <next hop, #hops> for each
destination. This is called distance vector. Same as
routing table.
• Each node exchanges its distance vector with its
neighbors periodically.
• Upon receiving the distance vector from a neighbor,
each node updates its own distance vector.
• Example: Distributed Bellman Ford.
92
Characteristics of Distance
Vector Routing
• Typically cheaper update cost than link-state.
– In generic link-state routing, each update needs to be sent
to ALL nodes.
• Counting to Infinity Problem
– Takes too long to determine that a destination is unreachable
or to an alternative, but much longer route.
• Loops possible because of lack of synchronism in
update propagation.
• Both problems can be handled by exchanging
additional information or by enforcing
synchronization.
93
Destination-Sequenced
Distance-Vector (DSDV)
[Perkins-Bhagwat-94]
• Uses sequence numbers to avoid counting to
infinity or looping problems.
• Each node increments and appends its own
sequence number when broadcasting its distance
vector.
• Each distance vector also includes the destination
sequence no.
– <next hop, #hops, dest. seq. no.> for each destination.
• No update if the dest. seq. no. in the distance
vector in the incoming packet is less than the
dest. seq. no. in the node’s own distance vector.
94
Further Refinement
ETT: Expected Transmission Time
• Adjust ETX for bandwidth.
• Probe size = S, link bandwidth = B
– Each transmission lasts for S/B time.
• ETT = (S/B)*ETX
• Can add channel access delay to this.
– This delay includes any channel sensing delay, backoff.
• Cost of path = sum of constituent link ETTs.
[Draves-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
95
Medium Access Control
Protocols
Wireless Interference
• A radio interface either transmits or receives (halfduplex).
• A receiver must get a minimum SINR for successful
reception
– This means no other transmitter (interferer) in vicinity.
– If untrue -> collision (SINR insufficient).
• Quintessential MAC problem
– Schedule transmissions on links conflict-free.
© Samir R Das, Stony Brook University, 2006
97
Example
A
B
C
D
• Concurrent transmissions A->B and C->D will
cause collision at B.
• How to schedule transmissions conflict free?
© Samir R Das, Stony Brook University, 2006
98
Example
A
B
C
D
• Concurrent transmissions A->B and C->D will
cause collision at B.
• How to schedule transmissions conflict free?
© Samir R Das, Stony Brook University, 2006
99
TDMA: Time Division
Multiple Access
• Use slotted time.
• Schedule conflicting transmissions at
different time slots.
• Problem equivalent to graph coloring
– Optimal solution is computationally hard.
• Significant research since the days of packet
radio.
• Often not deemed practical
– Hard to compute good schedules in a distributed
fashion.
– Schedule needs to be traffic dependent.
– Need synchronized clocks in hardware to implement
slots.
100
© Samir R Das, Stony Brook University, 2006
Carrier Sense Multiple Access
(CSMA)
• Transmit when ready
– Use a combination of carrier-sense and randomization to
avoid conflict.
– Not foolproof.
• Carrier sense not foolproof
– Propagation delay (also a problem in wireline).
– Can sense only at transmitter; but collision happens at
receiver (a wireless problem).
© Samir R Das, Stony Brook University, 2006
101
Hidden Terminal Problem
A
B
C
D
• C cannot sense A’s transmission.
• A is “hidden” from C.
[Tobagi-Kleinrock-75]
© Samir R Das, Stony Brook University, 2006
102
Sense Carrier at Receiver
• Busy Tone Multiple Access (BTMA)
– Receiver sounds a tone when busy receiving.
– Carrier sense on busy tone before transmission.
– Perfect solution. But need a busy tone channel and extra
interface. Channel gains on data and busy tone channels may
be different.
• “In band” solution
– Use virtual carrier sensing. Used in 802.11
[Tobagi-Kleinrock-75]
© Samir R Das, Stony Brook University, 2006
103
Virtual Carrier Sensing (802.11)
A
B
C
RTS
D
RTS
CTS
DATA
E
CTS
DATA
ACK
ACK
• Any node hearing RTS or CTS sets up their NAV
(network allocation vector) until end of ACK.
• NAV set -> node silent (act as if carrier busy).
© Samir R Das, Stony Brook University, 2006
104
Detailed Timeline (802.11)
RTS
Transmitter
DIFS
Receiver
SIFS SIFS
DATA
CTS
ACK
SIFS
Nodes that hear
transmitter
Nodes that hear
receiver
DIFS
NAV (RTS)
NAV (CTS)
Defer access
t
Random
backoff
Another
transfer
• If carrier busy (physical or virtual), schedule
transmission after a random backoff when
carrier is free.
• Average backoff interval is doubled for each
failed attempt.
© Samir R Das, Stony Brook University, 2006
105
Exposed Terminal Problem
Reserved floor
A
B
C
RTS
D
RTS
CTS
DATA
E
CTS
DATA
ACK
ACK
• Because of bi-directional transmission (due to ACK),
transmitter also has to be protected.
– Node B is silent during C->D transfer.
• Node B is exposed terminal. An ideal protocol should
allow exposed terminals to proceed.
© Samir R Das, Stony Brook University, 2006
106
More on Interference
Interference/carrier
sense range
Transmit/receive
range
• Recall that SINR must be sufficient for successful
reception.
• A node can interfere sufficiently at a distance longer
than its transmit range.
• Carrier sense threshold is usually adjusted so that the
node can sense any potential interferer.
© Samir R Das, Stony Brook University, 2006
107
Fairness
Fairness
• Many views of fairness. Can happen in any layer.
• Issues unique for mesh networks happen..
– In the MAC layer.
– In the interface between MAC and packet forwarding.
© Samir R Das, Stony Brook University, 2006
109
Fairness in Random Access MAC
• Quite fundamental. MAC attempts to
provides packet level fairness; not flow level
fairness.
• So-called “capture” phenomenon.
– Happens even on Ethernet. Property of binary
exponential backoff (BEB) algorithm.
– The winner of two contending flows has a higher
chance to win later contentions.
– Reason: Each packet competes afresh. Backoff
interval on the packets for winning flow stays
smaller.
© Samir R Das, Stony Brook University, 2006
110
New Problems with
802.11-based Mesh
• Interference levels are different at different
links.
– Because neighborhoods are different.
• Highly interfered flows can be drowned easily.
– Harder to be fair.
• We will discuss two basic problems:
– Information asymmetry.
– Flow in the middle problem.
© Samir R Das, Stony Brook University, 2006
111
Information Asymmetry
1
A
2
a
B
b
• The senders of two contending flows may have
different sets of information.
• Example:
– Sender of flow 2 is aware of flow 1 (via CTS , e.g.).
– Sender of flow 1 is not aware of flow 2.
[Gambiroza-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
112
Information Asymmetry
1
2
A
a
B
b
1
2
2
2
• Flow 2 knows how to contend.
• Flow 1 is clueless – it is forced to timeout and
double its contention window.
– Eventually may be forced to drop packet.
– Large access delay may also cause overflow in the
interface queue.
© Samir R Das, Stony Brook University, 2006
113
Information Asymmetry
1
A
•
•
•
•
2
a
B
b
Happens even when RTS/CTS are not used.
Flow 1 collides at a. Flow 2 is successful.
Upstream links still suffer.
Information asymmetry can be solved by
receiver-initiated protocols.
– Receiver “invites” transmissions when free.
[Talucciet-al-PIMRC-97, Garcia-Luna-Aceves-Tzamaloukas-Mobicom99]
© Samir R Das, Stony Brook University, 2006
114
Flow-in-the-Middle Problem
1
1
2
2
3
time
3
• A flow (2) contends with several flows (1,3)
that do not contend with each other.
– Typically a flow in the middle.
• May suffer from lack of transmission
opportunity.
© Samir R Das, Stony Brook University, 2006
115
Fairness Problem above MAC
• Mixing of local and forwarded traffic.
• Similar to a parking lot scenario.
Example from
[Gambiroza-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
116
Parking Lot Example
Example from
117
[Gambiroza-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
Parking Lot Example
Example from
118
[Gambiroza-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
Parking Lot Example
Example from
119
[Gambiroza-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
Two Node Analysis
G
G
GW
1
2
S1
S2
Ideal
• S2 needs two
transmissions; S1 needs
one transmission.
• MAC allows only one
transmission in the
neighborhood at one time.
Real
[Jun-Sichitiu-Wireless-Comm-Mag-03]
© Samir R Das, Stony Brook University, 2006
120
Two Node Analysis
Local traffic
• At high load the locally
generated traffic fills up
the queue at a faster rate
than forwarded traffic.
MAC
© Samir R Das, Stony Brook University, 2006
121
Two Node Analysis
Local traffic
• At high load the locally
generated traffic fills up
the queue at a faster rate
than forwarded traffic.
MAC
© Samir R Das, Stony Brook University, 2006
122
Two Node Analysis
Local traffic
• At high load the locally
generated traffic fills up the
queue at a faster rate than
forwarded traffic.
• Solution: Rate control for
local traffic.
• But need to calculate the fair
shares.
MAC
© Samir R Das, Stony Brook University, 2006
123
Addressing Fairness Problems
• Rate limiting above MAC layer
– Compute “fair” link flow rates. [Huang-BensaouMobihoc-01]
– Packets for different flows are passed on to MAC
only when “eligible.” [Sarkar-Tassiulus-IEEE-TAC-05]
– Legacy MAC OK.
• New MAC protocols
– Use additional “coordinations” to control
transmissions. [Kanodia-et-al-Mobihoc02, Luo-et-el-IEEETMC-04]
– Essentially distributed scheduling.
• Both topics of active research!
© Samir R Das, Stony Brook University, 2006
124
Transport Protocols
TCP over Wireless
• TCP interprets any packet loss as a sign of
congestion.
– TCP sender reduces congestion window.
• On wireless links, packet loss can also occur
due to random channel errors, handoffs or
route changes.
– Not due to congestion.
– Reducing window may be too conservative.
– Leads to poor throughput.
• How to distinguish loss due to congestion from
loss due to other wireless/mobility reasons?
© Samir R Das, Stony Brook University, 2006
126
Broad Approaches
• Mask wireless loss from the TCP sender.
– TCP sender will not reduce congestion window
• Explicitly notify the TCP sender about cause
of packet loss.
– TCP sender will not reduce congestion window for
wireless losses.
• Solutions may be at the sender, at the
receiver, or at an intermediate node
(basestation).
[Vaidya-Tutorial-MobiCom-99]
© Samir R Das, Stony Brook University, 2006
127
Single Hop Solution
Correspondent
host
(CH)
Internet
Wired (k hops)
Access point/
base station
(BS)
Mobile host
(MH)
Wireless
(1 hop)
• The edge device (BS) masks the loss on the wireless
hop or notifies the CH.
– Sometimes with help from MH.
– Sometimes MH does this without help from BS.
© Samir R Das, Stony Brook University, 2006
128
Masking Packet Losses
Correspondent
host
(CH)
Internet
Access point/
base station
(BS)
Mobile host
(MH)
Wired (k hops)
• Split-connection approaches:
Wireless
(1 hop)
– Split the TCP connection into two independent connection at
BS. Example: I-TCP [Bakre-Badrinath-ICDCS-95]
• Snoop TCP approach:
– BS acks the CH. Copies packet. Retransmits locally on the
wireless hop in case of loss. [Balakrishnan-et-al-ACMWinet-95].
• Need to maintain
state on BS.
© Samir R Das, Stony Brook University, 2006
129
Using TCP’s Persist Mode
Correspondent
host
(CH)
Internet
Wired (k hops)
Access point/
base station
(BS)
Mobile host
(MH)
Wireless
(1 hop)
• Proactively freeze the congestion window at CH by
advertising zero receiver window during handoff.
• Either BS or MH can do this depending on exact
protocol.
• Example: M-TCP [Brown-Singh-ACM-CCR-97], Freeze-TCP
[Goff-et-al-infocom-00].
© Samir R Das, Stony Brook University, 2006
130
Explicit Notification-Based
Approach
• Motivated by the ECN (Explicit Congestion
Notification) approach [Floyd-ACM-CCR-94].
• BS marks dupacks after a missing segment if
it knows that the loss is on the wireless hop.
– Marked dupacks initiates retransmission, but no
change in congestion window [Balakrishnan-KatzGlobecomm-98].
– Recall that TCP sender ordinarily interprets 3
consecutive dupacks as a sign of packet loss.
• Similar notification possible before/after
handoff, random link failure on wireless hop.
© Samir R Das, Stony Brook University, 2006
131
TCP on Multihop Wireless:
Single Flow Case
• First sign of problem: TCP throughput drops with
increase in #hops.
• Reason: Each hop adds additional self-contention.
– Also, more delay, more variability in delay, and more chance
of packet loss.
– They increase RTO.
[Gerla-et-al-WMCSA-99,
Holland-Vaidya-MobiCom-99]
© Samir R Das, Stony Brook University, 2006
132
Impact of MAC Unfairness:
Single Flow Case
• Upstream hops cannot transmit because of
information asymmetry.
• Leads to packet drop due to max retry count
exceeded. Interface queue overflow for
larger window sizes. Can in turn lead to route
failure.
• Instantaneous throughput often drops to
zero.
• Small max window limit improves performance.
[Xu-Saadawi-IEEE-Comm-Mag-01]
© Samir R Das, Stony Brook University, 2006
133
TAP3
TAP2
TAP1
Obj.
Ethernet
Ethernet
Ethernet
Ethernet
Impact of MAC Unfairness:
Multiple Flow Case
Basic
TAP4
RTS/CTS
Goodput [kb/sec]
1600
1247
1200
1177
1000
988
1058.7
800
400
0
320.5
320.5
320.5
• Notations: Obj =
Objective throughput
for fair sharing. Basic =
Basic access without
RTS/CTS.
• Two longer flows
starve.
– Similar effect regardless
whether RTS/CTS are
used.
ACK Traffic
2
3
TA(1)
38.5 48 40.7
20 27
TA(2)
TA(3)
TA(4)
Total
[Source: Gambiroza-et-al-Mobicom-04]
© Samir R Das, Stony Brook University, 2006
134
Issues with Mobility
• Think of a TCP session where one end point is
a mobile.
• Route recomputations cause interruptions
often longer than RTO.
– Source doubles RTO.
– Large original RTO or longer interruptions
especially vulnerable.
• Explicit notifications have been found to be
useful.
– Explicit route failure and route reconnect
notifications to TCP source.
[Holland-Vaidya-MobiCom-99]
135
© Samir R Das, Stony Brook University, 2006
Testbeds
MIT Roofnet
• Experimental
outdoor testbed
with real users.
• 40-60 nodes.
• Research focus on
link layer
measurements and
routing studies.
• Open source software for Prism and Atheros
platforms.
• http://pdos.csail.mit.edu/roofnet/doku.php 137
© Samir R Das, Stony Brook University, 2006
Wireless Mesh Networking in
Microsoft Research
• Indoor testbed.
• Mesh connectivity layer (MCL) software
– Implemented in between layer 2 and 3.
– Acts as a virtual interface to layer 3.
• Current research focus routing, multiradio/multichannel studies.
• Future visions of self-organizing neighborhood mesh
network.
• http://research.microsoft.com/mesh/
© Samir R Das, Stony Brook University, 2006
138
ORBIT Radio Grid at
WinLab/Rutgers
• 400 node indoor radio
grid.
• Custom hardware
platform with Atheros
802.11a/b/g radios
– More control on the radio
than typical.
• Distributed signal
generators producing
interference
– Brings up noise floor.
• Goal: Remotely accessible laboratory-based wireless
network emulation.
• http://www.winlab.rutgers.edu
© Samir R Das, Stony Brook University, 2006
139
ORBIT Hardware Organization
[Source: http://www.winlab.rutgers.edu]
© Samir R Das, Stony Brook University, 2006
140
Testbeds at Stony Brook
• MiNT
– Uses attenuators to cut down signal strengths (enables
multihoping in limited space).
– Uses a robotic platform to position nodes (to create
different topologies).
• iMesh
– Fast handoff.
– Experiments with handoff latency.
[De-et-al-Infocom-05,
© Samir R Das, Stony BrookNavda-wowmom-05]
University, 2006
141
Handoff and Routing on iMesh
Mesh network cloud of APs
• Layer 2 handoff triggers routing updates in
the mesh backbone (Layer 3 handoff).
• 10-20ms additional latency in Layer 3 for upto
5 hop route changes. [navda-wowmom-05]
© Samir R Das, Stony Brook University, 2006
142
Build Your Own Testbed
Router boards with multiple interfaces
running embedded Linux. Several manufacturers
143
© Samir R Das, Stony Brook University, 2006
(Soekris, Routerboard)
Open Issues
Security
• Already a difficult issue in WLAN!
• Further aggravated in mesh networks as node
cooperation is assumed for routing.
• Two types of problem: Misbehavior to gain unfair
access vs. malicious behavior (e.g., DoS attack).
• Possible in all layers:
– MAC – modify carrier sensing, backoff, inter-frame spacing.
– Routing – drop packets, advertise bad routes.
© Samir R Das, Stony Brook University, 2006
145
Network Management and Monitoring
• Monitor general health of the network
– Coverage problems
– Load imbalance
– Intrusion detection?
• Understand performance for better future design.
• Challenges: What information to gather? How to
aggregate/collate and relay information to a central
station? Entirely distributed architecture?
[DAMON: Ramachandran-SECON-04]
146
© Samir R Das, Stony Brook University, 2006
Homework
© Samir R Das, Stony Brook University, 2006
147
Questions?