Medium access protocols for wireless mesh networks ... · Medium access protocols for wireless mesh...
Transcript of Medium access protocols for wireless mesh networks ... · Medium access protocols for wireless mesh...
Medium access protocols for wireless mesh Medium access protocols for wireless mesh networks supporting peernetworks supporting peer--toto--peer peer VoIPVoIP and IMand IM
ArupArup AcharyaAcharya, IBM Research, IBM [email protected]@us.ibm.com
2 © 2003 IBM Corporation
Overview & IssuesNetworking architecture for wireless mesh networks
► MACA-P : A MAC for Concurrent Transmissions in Multi-hop Wireless Networks (“Cellular 802.11”)
► A Label-switching Packet Forwarding Architecture for Multi-hop Wireless LANs (“Wireless Mesh Router”)
Peer-to-peer VoIP and IM on wireless mesh networks► Extend/modify Session Initiation Protocol (SIP) to operate in a infrastructure-less mode► Leverage medium access (MACA-P) and packet forwarding concepts (mesh router)
Node
Node
Node
Node
Node
NodeNode
Node NodeNode
Node
Node
Node
Node
1122
Background : multi-hop wireless LANs
Emergence of high-speed and variable rate wLANs1,2,..,11, ..,22, ..,54, 108 Mbps
Multi-hop 802.11 architecture Motivation : split a cell into (higher rate) smaller cells as nodes increaseHigher bit-rate smaller coverage area multi-hopUsage :
• Multi-hop wireless path to wireline gateway• Infrastructure for pervasive computing
Much of current research in ad-hoc networks on routing protocols and (single-cell) MAC efficiency
Our work : MAC + network layer architecture for higher throughput
1. Combine medium access with packet forwarding (wireless “router”) using MPLS
2. Enhancing the 802.11 RTS/CTS DCF MAC for Enhancing the 802.11 RTS/CTS DCF MAC for concurrent operations in neighboring cellsconcurrent operations in neighboring cells
54
A BC
Increasing parallelism in multi-hop 802.11 networks
802.11 DCF MAC based on RTS/ CTS (MACA proposal by Karn)Neighborhoods of both sender and recvr blocked out
B Q PA RTS
CTS
datadataack
BQ
time
(3)
(4)
(3)
(4)
BAQ
P
Fundamental constraint : a recvr should not be within range of >1 transmitter
MACA-P : Can MACA be enhanced to allow Parallel transmissions?
AB
PQ (2) (2)
B Q PA
(1) (1)
AB
PQ
Limitations of 802.11 : multi-hop networksWith 802.11, neighboring “cells” compete for channel access
No coordination of transmission schedulesOther transmissions not allowed in sender/ receiver neighborhood (“exposed terminal”problem)
No inherent support for multiNo inherent support for multi--hop operationhop operation
Multi-hop networks require cooperation, not competition amongst neighbors
Key observations : 802.11 MAC• a packet transfer consists of alternating
transmitter/receiver roles• no spacing between “control” and “data” phases
Spacing enables neighbors to schedule parallel Spacing enables neighbors to schedule parallel transmissions without violating fundamental transmissions without violating fundamental constraint (of constraint (of recvrrecvr not within range >1 not within range >1 txtx))
A
SS RR DD
CC
BB
AA
SenderSender ReceiverReceiver
txtx (RTS)(RTS)
rx(RTSrx(RTS))
txtx (DATA)(DATA)
txtx (CTS)(CTS)
rx(CTSrx(CTS))
rx(DATArx(DATA))
txtx (ACK)(ACK)
rx(ACKrx(ACK))
MACA-P : basic ideaMACA-P introduces a “control gap” between RTS/CTS and DATA/ACK
a transmission schedule enabling neighbors to synchronize transmission/reception
802.11 : RTS carries a single time interval to reserve channel for cts+data+ack
MACA-P : RTS carries two time intervals to inform neighbors
TDATA (cts + Control Gap) : start of DATA tx
TACK (DATA + ACK tx times) : start of ACK rx(TDATA + TACK – ACK tx period)
AB
PQ
X
Y
Q
P
AB
RTSRTS
CTSCTS
DATA DATA ACKACK
controlgap
X
Y
Synchronize DATA Synchronize DATA txtx and ACK and ACK rxrx
Synchronize Synchronize DATA DATA rxrx and and ACK ACK txtx
TTDATADATA TTACKACK
MACA-P : synchronizing senders
B gains access to channel (via RTS/CTS)B’s RTS announces start of DATA tx (Tdata) and ACK rx (TACK)to neighbors
Q hears RTS, but not CTS, can initiate a parallel data transfer Q and B will Q and B will not collide at Anot collide at A
Q sends RTS to align DATA (tx) and ACK (rx) with B• P replies with CTS if it is outside B’s range (i.e did not overhear B’s RTS)• “Followers” set inflexible bit in RTS (Q) : proposed schedule cannot be changed
AB
QP
AB
QP
Tack
T’dataRTS
CTS
CTS
Tack
RTSTdata
MACA-P :synchronizing receiversReceivers synchronize using CTS’
• Similar to CTS : carriers two time intervals (Tdata and TACK)• But, CTS’ can change schedule (Tdata and TACK) proposed by RTS
(In 802.11, same reservation interval on RTS and CTS)(In 802.11, same reservation interval on RTS and CTS)
A receiver responds with a CTS/CTS’ if no other sender in its neighborhood
RTS’ : ack CTS’ & inform neighbors of changed scheduleAlso used, if CTS is not received ( to free the channel)
AB
QP
AB
Q
P
RTSRTS’’
TTdatadata TTackack
RTSRTS
CTSCTS
RTSRTS
t2CTS`CTS`
t1
Wireless Mesh Router : MotivationA wireline router requires at least two network interfaces for packet forwarding
A router is a specialized node
A wireless node can forward packets with a single network interface card (NIC)
Node BB can reach both nodes A A and CC using the same wireless interface(Nodes A and C out of range of each other)
Any intermediate nodeAny intermediate node in a multiin a multi--hop wireless network can operate as a routerhop wireless network can operate as a routerwide-applicability for a packet forwarding architecture
AB
C
A BC
Background : Packet Forwarding using 802.11 DCF
AA
BB
CC
Transfer packet to host for IP route lookup
DIFS
RTSRTS
CTSCTS ACK
DATA
Downstream Transfer
Upstream Transfer
RTSRTS
CTSCTS
DIFS
DATA
ACKACK
Timer Expiry
Channel access by upstream node A (RTS/CTS/ DATA/ACK)
Receive packet at node B’s network interface cardTransfer packet from NIC to host memory
Remove MAC headerLookup route, next hop IP/MAC addressAdd new MAC header (destination address C)
Transfer packet from host memory to NIC
Channel access by node B (RTS/CTS/DATA/ACK)
What is a good architecture for What is a good architecture for packet forwarding ?packet forwarding ?
••Combine upstream & downstream channel Combine upstream & downstream channel accessesaccesses••Avoid packet transfer between host & NICAvoid packet transfer between host & NIC
Our proposal : a packet forwarding architecture
Architecture for packet forwarding in wireless nodes
Address lookup using a table of labels in the NICFixed-length labels enable exact matching, simple implementationPacket forwarding entirely within the NIC
Avoids packet transfer to/from hostAvoids packet transfer to/from host
Enhanced 802.11 DCF MAC : combines upstream and downstream channel accesses
A new ACK/RTS MAC control packetACK/RTS carries a label
host
NIC
bus
Label switching : conceptual operation
host
NIC
AC
Dest Next-hop LabelC B L1
MACBIP pkt L1
B
MACCL1 L2
input output
IP pkt L2MACc
hostL2
input output
IP pkt L2MACc
NIC NIC
NIC/ Host support for label switchingA label-switching table in the NIC
Enables packet fwd’ing at an intermediate node’s NICTable populated by a label distribution protocol in the host
Similar to use of MPLS (multi-protocol label switching) in wired core networks
Maps routes/destinations to labelsFirst node labels packet based on destination IPIntermediate nodes labels-switch packets in the NIC
(incoming label) (outgoing label, next-hop MAC address)
INPUTINPUTLabelLabel
OUTPUTOUTPUTMAC LabelMAC Label
NAVMACprocessing
Label switching tableLabel switching table
IP address(route entry)
MAC addr(next hop) Label
LabelDistributionProtocol
ARP
RoutingProtocol
Host
Network Interface
Radio
Data PacketTransfer
packet mac label
packet queuepacketbuffer
Enhancements to the 802.11 MACForwarding node (B) combines ACK to upstream (A) with RTS to downstream node (C)
New ACK/RTSACK/RTS control packetInclude a label in the ACK/RTS corresponding to the final destination
Allows receiver to determine next-hop : lookup label-switching table in the NIC• Eliminates the need for a host-based route lookup
A
B
RTS
SIFS
CTS
DATA
DATAA RC TK S
CTS
A RC TK S
CTS
DATAC
D
T T
DATA DRIVEN CUTDATA DRIVEN CUT--THROUGH MAC (DCMA)THROUGH MAC (DCMA)
TT
MAC addressMAC address
MAC addressMAC address (out) Label(out) Label
ACKACKFlagFlag
RTSRTSFlagFlag
ACK/RTS control packetACK/RTS control packet
15 © 2003 IBM Corporation
Peer-to-peer IM and VoIP
Scenario : an 802.11 based multi-hop ad-hoc network where many nodes have IM or IP phone capability (hardphone or softphone) e.g. a collection of wi-fi phones, or a collection of sensors that exchange IMs
An architecture/prototype for a peer-to-peer VoIP in a ad-hoc network► Fixed infrastructure support absent in ad-hoc networks► Network Topology is dynamic
Should support both Session Oriented connections (e.g voice) and Instant Messaging► Based on SIP (Session Initiation Protocol)
● SIP requires infrastructure support such as proxies, location service, redirect servers to locate users and establish connections
How do we support SIP in a adHow do we support SIP in a ad--hoc network? hoc network?
16 © 2003 IBM Corporation
Leveraging medium access protocols
Once a VoIP connection is setup, voice packets (UDP/RTP) must traverse multiple 802.11 hops
Present-day 802.11 medium access protocols are basically designed for single-cell operation
►► For efficient media transport, e.g. voice packets, leverage mediFor efficient media transport, e.g. voice packets, leverage medium access um access protocols suitable for multiprotocols suitable for multi--hop 802.11 environment such as MACAhop 802.11 environment such as MACA--P and P and mesh router concepts discussed earliermesh router concepts discussed earlier
17 © 2003 IBM Corporation
Leverage ad-hoc routing schemes to discover location, reachability and route to SIP endpoints, e.g.
– DSDV : exchange SIP URIs instead of IP addresses – AODV : On-demand discover route to a SIP endpoint
► Link forwarding of SIP signaling messages with route discovery
Extend current work on multi-hop MAC protocols to setup voice paths
– High-performance architectures for IP-based multihop 802.11 networks, IEEE Wireless Communications, Oct 2003, Acharya, Misra and Bansal
– D-LSMA : Distributed Link Scheduling Multiple Access Protocol for QoS Support in Ad-hoc Wireless Networks, Wu and Rayachaudhuri, Submitted for publication
Instant Message : discover route to and location of endpoint; send IM next in a hop-by-hop cut-through fashion
Preliminary Approach
18 © 2003 IBM Corporation
Summary
Need cooperative medium access protocols for wireless mesh networks to increase parallelism in the network (capacity)
Combination of IP forwarding and medium access access schemes for a “wireless mesh router”
Design of VoIP/ IM for a ad-hoc environment
Status :► Joint work with Archan Misra, IBM Research and Sorav Bansal, Stanford
Univ on MACA-P and mesh router– Papers available at http://www.research.ibm.com/people/a/arup
► Working with faculty/students of WINLAB on ad-hoc MAC and VoIP/IM (Zhibin, Sachin, Shankar)
19 © 2003 IBM Corporation
Work Packages for ORBIT
Ad hoc networking in 802.11x WLAN scenarios [Raychaudhuri, Seskar; Rutgers & Acharya; IBM]Message-based multimedia delivery [Schulzrinne, Columbia; Yates, Rutgers]XML-based content multicasting for mobile information services [Ott, Raychaudhuri; Rutgers]Location-based mobile network services [Schulzrinne; Columbia]Pervasive computing software models for sensor networks [Parashar, Zhang; Rutgers]Security protocols for next-generation wireless networks [Kobayashi; Princeton & Trappe; Rutgers]Intelligent network middleware (INM) for mobile services [Paul; Lucent Bell Labs]Peer-to-peer infrastructure for VoIP and IM [Acharya, Saha; IBM Research]Power/bandwidth efficient media delivery to portable platforms [Ramaswamy, Wang; Thomson R&D]