design of a multi-channel mac protocol for ad hoc wireless networks h. wilson so uc berkeley /...

Design of a Multi-Channel MAC Protocol for Ad Hoc Wireless Networks

H. Wilson SoUC Berkeley / Siemens TTB

EE 228A Lecture2/21/2006

2

Traditional Ad Hoc Network: Single Channel

Each device has 1 radio. All radios are tuned to the same channel.

3

Typical Wireless Networks

t=0frequencySender 1



Each network uses 1 channel only.

Channel 1 Channel 2Channel 3

: :

Can we do better?

PowerDensity

4

Can we do better?

t=0frequency

PowerDensity

Sender 1

Simultaneous sending on different channels?

Channel 1 Channel 2Channel 3

Sender 3

t=1frequencySender 2 Sender 1 Sender 4

Sender 4


: :

Sender 2Sender 4

5

Goal Given a wireless network where:

M (>1) channels are available each node has 1 tunable radio each node has many neighbors

Design a Multi-Channel MAC protocol: increases total network throughput achieves low average delay robust, practical

6

Scope of Project Single hop network (but as a

potentinal building block for multi-hop networks)

Ignore multi-hop forwarding / routing

No QoS guarantee

7

Outline Indroduction

Why Multi-Channel MAC? Choose best approach

Classify / Compare (analysis, sim) Protocol design Implementation

Platform / Challenge / Results Conclusion

8

Why Multi-Channel MAC? Why do we:

create multiple channels and then

design a MAC that uses multiple channels?

Two points of view: Theoretical Engineering

9

Why Multi-Channel MAC?

t=0

t=1

frequency

frequency

Sender 1

Sender 2 Sender 1

Sender 3

Sender 4

Sender 4

t=0

t=1

frequency

frequency

Sender 1

Sender 2

Single “Super” Channel

Multi-Channel MAC

10

Optimal M-Channel Schedule

Given some traffic demand. Schedule S gives optimal throughput.

11

Optimal M-Channel Schedule

Given some traffic demand. Schedule S gives optimal throughput.

12

Convert S (M-channel) into

S’(1 wide channel)

t=1

t=2

S Ch 1 Ch 2 ...

...

...

Ch M

1->3, 4->7,16->8, ...

5->2, 13->9,...

10->12,14->15, ...

S’

t=1t=2t=3t=4t=5

13

Summary: Why Multi-Channel?

Theory: no gain to use multiple channels. Engineering: frequency management

and hardware limits give rise to multiple channels.

Conclusion: Channel should be as wide as practical. Multi-channel MAC can always take advantage

of additional spectrum to increase throughput.

14



Joint work with Prof. Jeonghoon Mo, ICU, Korea



15

Core Design Issues

Q1: Which channel is receiver Y listening on?

Q2: Is channel i free?

time=t

time=t

frequency

frequencyFree ?

receiver Y

? ? ?

Chan i

16

Multi-Channel MAC Protocols

(1) Dedicated Control Channel (2 radios) Dedicated control radio & channel for all control

messages DCA [Wu2000], DCA-PC [Tseng2001], DPC [Hung2002].

(2) Split Phase Time divided into alternate (i) channel negotiation phase

on default channel & (ii) data transfer phase on all channels

MMAC [J.So2003], MAP [Chen et al.]

(3) Common Hopping Sequence All idle nodes follow the same channel hopping sequence HRMA [Tang98], CHMA, CHAT [Tzamaloukas2000]

(4) Parallel Rendezvous Each node follows its own channel hopping sequence SSCH [Bahl04], McMAC (our own proposal)

17

Protocol (1): Dedicated Control Channel

Ch3(data)

Ch2(data)

Ch1(Ctrl)

Time

Channel

RTS(2,3)

CTS(2)

RTS(3)

CTS(3)

Data Ack

Keys: 2 Radios/Node; Rendezvous on 1 channel; No time sync

Legend: Node 1 Node 2 Node 3 Node 4

Data

AckData

Ack ...

18

Protocol (2): Split-Phase

Ch3

Ch2

Ch1

Time

Channel

Hello(1,2,3)

Ack (1)

Keys: 1 Radio; Rendezvous on a common channel; Coarse time sync

Control Phase Data TransferPhase

...

...

...Data AckRts Cts

DataRts Cts Ack ...

Hello(2,3)

Ack (2)

Unused

19

Protocol (3): Common Hopping

Ch3

Ch2

Ch1

Time

ChannelKey: 1 radio; Non-busy nodes hop together; Tight time sync

Ch4

1 2 3 4 5 6 7 8 9 10 11

Data/Ack ...

Enough for RTS/CTS

RTS+CTS

20

Potential Limitation of Approaches (1), (2), (3)

All nodes must contend on one channel at a time. Problem: contention channel saturates when:

(i) many short data packets and (ii) channels are numerous.

t=1 2 3 4 5 6 ...

ContentionChannel

Ch 1

Ch 2

: :

Slow contention => Many wasted channels !!!

21

Protocol (4): Parallel Rendezvous e.g. McMAC (simplified)

t=1 2 3 4 5 6 ...

Ch 1

Ch 2

Ch 3

Ch 4

Sender needs to know the home channel of the receiver.

? ?

22

McMAC (with hopping)

t=1 2 3 4 5 6 7 8 9

Ch1

Ch2

Original schedule

23

McMAC (with hopping)

t=1 2 3 4 5 6 7 8 9

Ch1

Ch2

1. Data arrives 4. Hopping

resumes3. Hopping stopped during data transfer

2. RTS/ CTS/ Data

Original schedule

24

Analytical Model Assumptions Discrete Time All pairs backlogged After rendezvous, each data

transfer lasts a geometric number of slots

Medium contention algorithm is slotted aloha w/ tx prob. p

Single collision domain Packet loss due to collision only

25

Models: (1) Dedicated Channel & (3) Common Hopping Markov Model: # of ongoing

transfers as a function of time. Up: successful rendezvous (limited

by collisions and # channels) Down: existing transfer finishes

(affected by average transfer length)

Limiting distribution: yields the average throughput

26

Model: (2) Split Phase Control Phase Model: How many

channel agreements can be made? Affected by: duration of control

phase

Data Phase Model: How much data is transferred on each channel?

Affected by: # of agreements in control phase, avg. transfer length.

27

Model: (4) Parallel Rendezvous McMAC Markov Model: # of current

transfers as a function of time. Similar to (1) Dedicated Channel &

(3) Common Hopping ... but channel agreements can

happen simultaneously on many channels.

28

Example Scenarios Scenario (B)

802.11b 2 Mbps x 3

channels 20 devices Avg transfer size:

1KB or 10KB Channel

switching: 100us

Scenario (A) 802.11a

6 Mbps x 12 channels

40 devices Avg transfer size:

1KB or 10KB Channel switching:

100us

29

Analytical Results: 802.11b

Sim

Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)

30

Analytical Results: 802.11a

Sim


31

Throughput vs. Num of Channels

Short Packets Long Packets

Control Channel Congestion

Control Channel Congestion Delayed


32

Simulation Model

More realistic than analytical models

Can check packet delaysAnalytical Model

■ Symmetric Traffic

■ No Queueing

TEXT

Simulation Model

■ Variable degree of communication■ Queueing of Packets

33

Simulation Results Highlight

Effects of Back-to-back Packets: Mixed real-time traffic + bulk transfer Delay of all traffic decreases with

increasing medium occupancy limits

34

Medium Occupancy Limit: Delay vs. Throughput (802.11a)

3.3 ms max. 10.5 ms max.

32Mbps 40 Mbps

35

Summary of Comparison Single control channel eventually

saturates.

Parallel rendezvous protocols (using 1 radio) perform surprisingly well compared to dedicated control channel

36





37

Protocol Components Random Channel Hopping

Discovery

Synchronization

Rendezvous and Scheduling

38

Challenge 1: Synchronization Challenge 1: Cannot assume

perfectly synchronized time slots

Option 1: Synchronize globally

Option 2: Synchronize pair-wise

39

Challenge 2: Discovery (i) Discover existing nodes (ii) Discover a newcomer

Primary: beacon on channel 1 once every T1 seconds

Backup: nodes beacon every T2 seconds while hopping randomly. Takes: M * ln(N) * T2 (seconds)

40




Joint work with Giang Nguyen Platform / Challenge / Results

Conclusion

41

Implementation Why implement?

To prove that McMAC is pratical To uncover any hidden difficulty /

complexity Plan:

Choose a platform Evaluate the platform Implement subset of McMAC

42

Platform: Mote (Telos) MCU: Ti MSP430

4MHz, 16-bit, 10K RAM

Radio: CC2420, 802.15.4 DSSS, 250Kbps

Peripherals: USB, 32KHz Crystal, sensors, LEDs

SW: TinyOS Cost: ~$80

Picture of TelosPhoto Credit: www.Moteiv.com

43

4-Node Long Term Clock Drift

+9 ppm

-8 ppm

-0.3 ppm

Node 3’sClock

Good News! Almost a straight line!!

44

Short Term Clock Instability

45

SynchronizationSender’s Time Stamps

Receiver’s Time Stamps

Beacons received

46

Regression: k Most Recent Time Stamps

Max. “Std Erro

r of E

stimatio

n”

Among 16x15 pairs

Using 5 Minutes of History

Median “Std Erro

r of E

stimatio

n”

Among 16x15 pairs

Std

. E

rr.

of

Est

imati

on

(3

0.5

us

tick

s)

47

Practical Issues Keeping 30 points requires

240Bytes/neighbor. Can we use less memory?

Yes, by recursive estimation. Idea: give geometrically decreasing

weights to earlier time stamps. 8 numbers are enough to summarize history.

48

Sync. Algorithm : receiver’s time stamp : sender’s time stamp : estimated sender’s time stamp

Minimize Error:

49

Sync. Algorithm States

50

Using Recursive EstimationS

td.

Err

. of

Est

imati

on

(30

.5u

s ti

cks)

Max. “Std Error of Estimation”

Among 16x15 pairsMedian “Std Error of Estimation”

Among 16x15 pairs

51

Sync. Algorithm Details Problem: Overflow of sums Solution: Change of variable

Let y’ = y - k x’ = x - c Pick k, c carefully to avoid overflow. Repeat this for every sample.

52

Implementation Techniques

Nbr 1

Nbr 3

Nbr 2

Recvr’ sLocal Clock

(i) Nbr 1’s Clock –Local Clock

(ii) Use approx. Receiver’s Clock

X X

X

XX

X

(iii) Outlier detection

53

Experimental Setup No. of Nodes: 4, 8, or 16 No. of channels: 8 Beacon: every 1s or 5s Automatic discovery & sync.

Synchronization Metric: % beacons within 3 ticks (90us) % beacons within 6 ticks (180us)

54

Time Slot Structure Mote Clock: 32,678Hz Tick = 30.5 us (i.e., 1/32768Hz) Big Slot (3.9 ms) = 128 ticks Small Slot (30.5us) = 1 tick

55

Demo 8 nodes 4 channels ~1 minute timeout 3 sec between beacons

56

Time Sync. Results

1s 1s 1s5s 5s 5s[ 4 Nodes] [ 8 Nodes][ 16 Nodes]

Beacon Interval:

57





58

Conclusion Multi-channel MAC complements wide-

band radios. McMAC is practical!

~95% pkts delivered, >92% acked (light load)

Implementation is non-trivial!! Good throughput requires:

Good time stamps Fast controller Fine tuning

59

Looking Forward McMAC as a building block for a multi-

hop ad hoc network! Challenges:

Hidden-nodes QoS guarantees Broadcast

Next 2 years: turning McMAC into a real product at Siemens, Berkeley.

60

Thank You!! Wilson So [email protected]

design of a multi-channel mac protocol for ad hoc wireless networks h. wilson so uc berkeley /...

Documents