Download INFOCOM2009 - Prasant Mohapatra`s Research Group

Soft-TDMAC: A Software TDMA-based
MAC over Commodity 802.11 Hardware
Petar Djukic, Carleton University ([email protected])
Prasant Mohapatra, UC Davis ([email protected])
Why Research Scheduled MACs?
• 802.11 de-facto wireless mesh standard, but
– CSMA not good for multi-hop
– CSMA not good for long-distance links
• Scheduled MACs solve these problems
– Guaranteed channel access (MAC layer point-of-view)
– Semi-persitent scheduling decreases overhead
– Scheduled MACs don’t preclude CSMA
• So, scheduled multi-hop MACs are in vogue
–
–
–
–
802.11s DMA (TDMA based)
802.16d mesh (TDMA-OFDM based)
802.16j mmr (OFDMA based)
Next generation LTE relays (OFDMA based)
How to Research Scheduled MACs?
• Simulation (ns2, opnet)
– Been there done that, need more information
• New hardware (802.11s, 802.16j, LTE)
– Proprietary, undocumented
– Bigger problem: MAC fixed
• Custom Hardware (WARP)
– Open, documented, highly customizable
– Expensive
– Long learning curve
• Commodity (802.11) Hardware + Software
– 802.11 hardware widely available
– Linux widely available, includes full network stack
• But is running TDMA over CSMA a square peg in a round hole?
– No! Use 802.11 QoS to disable CSMA
– Tight Synchronization becomes the main problem
SoftTDMAC Architecture
TDMA
Software
Abstraction
Layer
Userspace
Hardware
Abstraction
Layer
Link Scheduling
Abstraction
RT Linux Timer
Routine
Data Plane
(Concatenation,
Fragmentation,
Forwarding)
Data Queues
Network Layer
Routines
IP Stack
Synchronization
Algorithms
Radio Abstraction
Radio Routines
802.11 Hardware
(Atheros)
SoftTDMAC
Protocol
Control Protocols
(Network entry,
Routing)
Linux Kernel
High Resolution
Timers
(RT Linux)
Main Problem: Tight Synchronization
•
Require tight synchronization to decrease transmission overhead
– Overhead from spacing of transmissions to avoid collisions
– Must cover synchronization error with spacing transmissions
– Previous work: 1ms-20ms per transmission, due to lack of tight synchronization
•
•
We build network wide synchronization from pair-wise synchronization
Pair-wise synchronization
– Pairs exchange timing offsets (like NTP) and synchronize to each other
– But, depends on deterministic round-trip times
•
Deterministic 802.11 transmission timing (easy)
– Control timing with 802.11 QoS parameters
– Eliminate 802.11 back-off (not needed since transmissions scheduled)
– Done in previous works (Atheros, Prism54 hardware)
•
Deterministic software timers (harder)
– Achilles heel of previous work (e.g. using Atheros hardware timers)
– We use real-time Linux, which has deterministic OS timers
– Some tuning still required
•
Tight synchronization + precise transmission timing = efficient scheduled MAC
Transmission Timing
HW Hiccups ms variability (rare)
802.11 HW Transfer ~5-10μs variability
RT Timer Processing ~1μs variability
A Bound on Transmission Time
The Testbed
Synchronize
Synchronize
1
DATA
2
DATA
3
4
• 4 laptops, 802.11 Atheros HW
• All overhear each other, but forced to
– Synchronize :1→ 2→ 3→ 4
– Route: 1→ 2, 2→ 3, 2→ 4, 3 → 4
• So 3-hop synchronization, 3-hop data forwarding
Network Wide Synchronization
10% with 0μs synchronization error
Only one hop? 16μs separation
Only two hops? 32μs separation
One-Hop TCP Performance
Multi-hop TCP Performance
33%
57%
57%Time,
Time,18
6 Mbps
Mbps
1
2
33% Time, 6 Mbps
19%
3
33% Time, 6 Mbps
19%
4
Odd-Even Scheduling
Min-delay
(equalScheduling
time uplink and downlink)
Multi-Hop Delay (ICMP)
Summary
• Built Software TDMA MAC protocol
– Multi-hop synchronization protocol/algorithm
– Network entry
– Multi-hop routing and scheduling
• Tight synchronization in µs
– Allows for efficient TDMA schedules (small spacing)
• Lesson 1: Real-time code easy to write
– POSIX timers + RT Linux
– Atheros driver somewhat well documents
• Lesson 2: Hardware integration hard
– Undocumented Atheros “features”
– Undocumented Linux code
– E.g. Lid on or off?
• Software download: http://spirit.cs.ucdavis.edu/SoftTDMAC