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 Researcharup@us.ibm.comarup@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]