Special Topics in Computer

Engineering

Wireless NetworksBy: Mohammad Nassiri

Bu-Ali Sina University, Hamedan

Access method in Wireless Ad-hoc

Networks

Ad-hoc mode in 802.11

Basically, ad-hoc mode in 802.11 does not support multi-hop transmission. However, there are a lot of mechanisms to provide the multi-hop transmission with the help of Layer-3, namely, IP layer.

Ad HocSimplestRapid

deploymentPeer-to-peerNo

administration

Multi-hop Ad-hoc Networks An Ad-hoc network Direct transmission with

neighboring nodes Each node can be router

and so it can relay traffic. B relays packet from A to C

Self-configuration, Self-healing

In this lecture, MAC issues in Wireless Ad-hoc Networks

Recall Rx = Reception

Range CS = Carrier

Sensing Range A can communicate

to B C can only sense a

transmission emitted from A

D cannot overhear A

RTS/CTS for hidden problem

D and C are hidden to A

D is within CSR of B A sends to B, D sends

to B, collision is possible. RTS/CTS fails to resolve hidden terminal in this case

RTS/CTS for exposed nodes ?

RTS/CTS cannot handle exposed node problem The left-hand scenario

Masked node C cannot decode CTS

from B It’s NAV is not up to

date. Later it can collide the

transmission of A to B by sending an RTS.

C is masked by B and D

9

Blocked nodes in 3 pairs We consider blocked nodes in the

scenario of three parallel pairs node in the middle has almost no

possibility to access the channel

Studied by Chaudet et al. 2005

e.g. each pair in a room

A, C and E are emitters

Emitter C is starved by transmissions of A and E.

10

A

C

E

DATA

DATA DATA

DATA

DATA

DATA

C is starved by A and E

DATA

DATA

How does legacy DCF work in this scenario when A and E are transmitting ?

DIFS EIFS Backoff Busy Channel

DATADATA

Three pairs

11

Three pairs

A

C

E

DIFS EIFS Backoff Busy Channel

Long term Unfairness

DATA DATA DATA

DATA

DATA

How does legacy DCF work in this scenario when C is transmitting ?

DATADATA

DCF evaluation in a chain

Throughput for chain with different length

Claude Chaudet: IEEE com. Magazine 2005

Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks?

Shugong XuTark SaadawiJune, 2001

IEEE Communications Magazine(Adapted from

mnet.cs.nthu.edu.tw/paper/jbb/010704.pps)

Next 5 slides from

Serious Unfairness – (1)

2 TCP Connections First session starts at 10.0s ( 6 4 ) Second session starts 20.0s later ( 2 3 )

1 2 3 4 5 6

Source

Destination

Destination

Source

Serious Unfairness – (2)

First session start

Second session start

Serious Unfairness – (3)

The throughput of the first session is zero in most of its lifetime after the second session starts.

There is not even a chance for it to restart.

The loser session is completely shutdown even if it starts much earlier.

Serious Unfairness – (6)

Discussion: Node5 cannot reach node4 when

• Node2 is sending (collision)• Node3 is sending ACK (defer)

1 2 3 4 5 6

Source

Destination

Destination

Source

Conclusion

The hidden terminal problem still exists in multihop networks.

The exposed terminal problem will be more harmful in a multihop network and there is no scheme in IEEE 802.11 standard to deal with this problem.

The binary exponential backoff scheme always favors the latest successful node. It will cause unfairness.

Multiple Channels for Wireless Networks

20

Traditional Ad Hoc Network: Single Channel

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

Motivation

Exploit multiple channels to improve network throughput’ … why ?

Greater parallel communication is possible

1

defer

1

2

22

Typical Wireless Networks

t=0frequencySender 1

t=1frequencySender 2

t=2frequencySender 3

Each network uses 1 channel only.

Channel 1 Channel 2 Channel 3

: :

Can we do better?

PowerDensity

23

Can we do better?

t=0frequency

PowerDensity

Sender 1

Simultaneous sending on different channels?

Channel 1 Channel 2 Channel 3

Sender 3

t=1frequencySender 2 Sender 1 Sender 4

Sender 4

t=2frequencySender 3

: :

Sender 2Sender 4

24

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

25

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

26

M-Channel Schedule example

27

M-Channel Schedule example

28

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

Multi-channel Hidden Terminals

Multi-channel Hidden Terminals

Observations

1. Nodes may listen to different channels2. Virtual Carrier Sensing becomes difficult3. The problem was absent for single channel

31

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 ()

32

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 ...

33

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

34

Protocol (3): Common Hopping

Ch3

Ch2

Ch1

Time

Channel Key: 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

A MAC protocol based on Split Phase

802.11 PSM (Power Saving Mode)

Doze mode – less energy consumption but no communicationATIM – Ad hoc Traffic Indication Message

A

B

C

Time

Beacon

ATIM Window

Beacon Interval

802.11 PSM (Power Saving Mode)

A

B

C

Time

Beacon

ATIM

ATIM Window

Beacon Interval

802.11 PSM (Power Saving Mode)

A

B

C

Time

Beacon

ATIM

ATIM-ACK

ATIM Window

Beacon Interval

802.11 PSM (Power Saving Mode)

A

B

C

Time

Beacon

ATIM

ATIM-ACK

ATIM-RES

ATIM Window

Beacon Interval

802.11 PSM (Power Saving Mode)

A

B

C

Time

Beacon

ATIM

ATIM-ACK

DATAATIM-RES

Doze Mode

ATIM Window

Beacon Interval

802.11 PSM (Power Saving Mode)

A

B

C

Time

Beacon

ATIM

ATIM-ACK

DATA

ACK

ATIM-RES

Doze Mode

ATIM Window

Beacon Interval

802.11 PSM (Power Saving Mode) Summary

All nodes wake up at the beginning of a beacon interval for a fixed duration of time (ATIM window)

Exchange ATIM during ATIM window

Nodes that receive ATIM message stay up during for the whole beacon interval

Nodes that do not receive ATIM message may go into doze mode after ATIM window

MMAC : Assumptions

All channels have same BW and none of them are overlapping channels

Nodes have only one transceiver

Transceivers are capable of switching channels but they are half-duplex

Channel switching delay is approx 250 us, avoid per packet switching

MMAC : Steps

Divide time into beacon intervals

At the beginning, nodes listen to a pre-defined channel for ATIM window duration

Channel negotiation starts using ATIM messages

Nodes switch to the agreed upon channel after the ATIM window duration

MMAC

Preferred Channel List (PCL)

For a node, PCL records usage of channels inside Tx range

HIGH preference – always selected

MID preference – others in the vicinity did not select the channel

LOW preference – others in the vicinity selected the channel

MMAC

Channel Negotiation

Sender transmits ATIM to the receiver and includes its PCL in the ATIM packet

Receiver selects a channel based on sender’s PCL and its own PCL

Receiver sends ATIM-ACK to sender including the selected channel

Sender sends ATIM-RES to notify its neighbors of the selected channel

MMAC

A

B

C

DTime

ATIM Window

Beacon Interval

Common Channel Selected Channel

Beacon

MMAC

A

B

C

D

ATIM

ATIM-ACK(1)

ATIM-RES(1)

Time

ATIM Window

Common Channel Selected Channel

Beacon

MMAC

A

B

C

D

ATIM

ATIM-ACK(1)

ATIM-RES(1)

ATIM-ACK(2)

ATIM ATIM-RES(2)

Time

ATIM Window

Common Channel Selected Channel

Beacon

MMAC

ATIM

ATIM-ACK(1)

ATIM-RES(1)

ATIM-ACK(2)

ATIM ATIM-RES(2)

Time

ATIM Window

Beacon Interval

Common Channel Selected Channel

Beacon

RTS

CTS

RTS

CTS

DATA

ACK

ACK

DATA

Channel 1

Channel 1

Channel 2

Channel 2

A

B

C

D

Experimental Parameters

Transmission rate: 2MbpsTransmission range: 250mTraffic type: Constant Bit Rate (CBR)Beacon interval: 100ms

Packet size: 512 bytesATIM window size: 20msDefault number of channels: 3 channels

Compared protocols802.11: IEEE 802.11 single channel protocolDCA: Wu’s protocolMMAC: Proposed protocol

WLAN - Throughput

Multi-hop Network - Throughput

Analysis

For MMAC:

ATIM window size significantly affects performance

ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead

ATIM window size can be adapted to traffic load

Discussions

MMAC requires a single transceiver per host to work in multi-channel ad hoc networks

MMAC achieves throughput performance comparable to a protocol that requires multiple transceivers per host

Beaconing mechanism may fail to synchronize in a multi-hop network – probabilistic beaconing may help

Starvation can occur with common source and multiple destinations

Multi-interface Multi-channel

Each node has multiple interfaces

References J. So, N. Vaidya; ``

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver''; Proc. ACM MobiHoc 2004

S.-L.Wu, C.-Y. Lin, Y.-C. Tseng, and J.-P. Sheu.  "A new multichannel MAC protocol with on-demand channel assignment for multi-hop mobile ad hoc networks."; In Int’l Symp. on Parallel Architectures, Algorithms and Networks (I-SPAN), 2000.

C. Chaudet, D. Dhoutaut, I. G. Lassous, Performance issues with IEEE 802.11 in ad hoc networking , IEEE Communications magazine, Volume 43, Number 7; Pages: 110-116, July 2005

S. Xu, T. Saadawi, Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks?, IEEE Communications magazine, June 2001

Review 1-60