1. Special Topics in Computer Engineering
Wireless Networks
By: Mohammad Nassiri
Bu-Ali Sina University, Hamedan

2. Access method in Wireless Ad-hoc Networks

3. Ad-hoc mode in 802.11 Ad Hoc Simplest Rapid deployment Peer-to-peer
No administration
Basically, ad-hoc mode in 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.

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

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

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

7. RTS/CTS for exposed nodes ?
RTS/CTS cannot handle exposed node problem
The left-hand scenario

8. 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. WLAN QoS
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.
C cannot correctly interpret packets emitted from A and E

10. WLAN QoS
Three pairs
How does legacy DCF work in this scenario when A and E are transmitting ?
DIFS
EIFS
Backoff
Busy Channel
DATA
DATA A C E
DATA
DATA
DATA
DATA
C cannot correctly interpret packets emitted from A and E, at the end of any transmission from A or E, C waits for a EIFS while A and C wait for DIFS.
DATA
DATA
DATA
DATA
C is starved by A and E

11. WLAN QoS
Three pairs
How does legacy DCF work in this scenario when C is transmitting ?
DIFS
EIFS
Backoff
Busy Channel
DATA
DATA A C E
DATA
DATA
DATA
DATA
DATA
Long term Unfairness

12. DCF evaluation in a chain
Throughput for chain with different length
Claude Chaudet: IEEE com. Magazine 2005

13. Next 5 slides from
Does the IEEE MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks?
Shugong Xu
Tark Saadawi
June, 2001
IEEE Communications Magazine
(Adapted from mnet.cs.nthu.edu.tw/paper/jbb/ pps)

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

15. Serious Unfairness – (2)
First session start
Second session start

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

17. 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
There is no chance to restart TCP session

18. 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 standard to deal with this problem.
The binary exponential backoff scheme always favors the latest successful node. It will cause unfairness.

19. 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.
In a traditional multi-hop ad hoc network ...
each node has 1 radio (either listen or transmit)
to ensure maximum connectivity, each radio is tuned to the same channel

21. Motivation
Exploit multiple channels to improve network throughput’ … why ?
Greater parallel communication is possible 1
defer 1 2

22. Typical Wireless Networks
Each network uses 1 channel only.
Power
Density
t=0
Sender 1
frequency
Can we do better?
t=1
frequency
Sender 2
t=2
frequency
Sender 3 : :
Channel 1
Channel 2
Channel 3

23. Can we do better? Simultaneous sending on different channels? t=0
Power
Density
t=0
Sender 1
Sender 4
Sender 3
frequency
t=1
frequency
Sender 2
Sender 1
Sender 4
t=2
frequency
Sender 3 :
Sender 2
Sender 4
Channel 1
Channel 2
Channel 3

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? Multi-Channel MAC t=0 frequency t=1
Sender 1
Sender 2
Sender 3
Sender 4
Single “Super” Channel
t=0
Sender 1
frequency
t=1
Sender 2
frequency

26. M-Channel Schedule example
The problem is that when node density increases ...
medium in the same neighborhood is shared by more and more nodes.
Given a fixed link speed, it is now shared by many devices.

27. M-Channel Schedule example
The problem is that when node density increases ...
medium in the same neighborhood is shared by more and more nodes.
Given a fixed link speed, it is now shared by many devices.

28. Core Design Issues Q1: Which channel is receiver Y listening on?
Q2: Is channel i free?
time=t ? ? ?
frequency
receiver Y
time=t
Free ?
frequency
Chan i

29. Multi-channel Hidden Terminals29

30. Multi-channel Hidden Terminals
Observations
Nodes may listen to different channels
Virtual Carrier Sensing becomes difficult
The problem was absent for single channel 30

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 ()
We have classified existing multi-channel MAC protocols that have been proposed into 4 categories.
I’ll go in to the details very soon.

32. Protocol (1): Dedicated Control Channel
Keys: 2 Radios/Node; Rendezvous on 1 channel; No time sync
Ch3
(data)
Data
Ack
Ch2
(data)
Data
Ack
Ack ...
Ch1 (Ctrl)
1 of the channels is used for control messages.
Each node has 2 radios.
Suppose red wants to send a pkt to blue...
RTS and CTS both include a NAV to indicate the duration of the transfer.
RTS (2,3)
CTS (2)
RTS (3)
CTS (3)
Time
Legend: Node 1 Node 2 Node 3 Node 4

33. Protocol (2): Split-Phase
Keys: 1 Radio; Rendezvous on a common channel; Coarse time sync
Channel
Ch3
...
Unused
Data
Ack
Rts
Cts
...
Ch2
...
Ch1
Hello (1,2,3)
Ack (1)
Hello (2,3)
Ack (2)
...
Instead of having separate control and data channels, time is divided into alternating control and data phases.
Notice that depending on the duration of the control phase, it is possible to have more channel agreements than the number of channels.
Time
Data Transfer Phase
Control Phase

34. Protocol (3): Common Hopping
Key: 1 radio; Non-busy nodes hop together;
Tight time sync
Channel
Ch4
Ch3
RTS+CTS
Data/Ack ...
Ch2
All the idle devices cycle through all the available channels synchronously.
Suppose at time 3 that the red wants to talk to the green node.
Ch1 1 2 3 4 5 6 7 8 9 10 11
Time
Enough for RTS/CTS

35. 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
...
Contention Channel
Ch 1
Ch 2
: :
Slow contention => Many wasted channels !!!

36. Protocol (4): Parallel Rendezvous e.g. McMAC (simplified)2 3 4 5 6
...
Ch 1
Ch 2
Ch 3
Ch 4 ? ?
Sender needs to know the home channel of the receiver.

37. McMAC (with hopping)
Original schedule
t=1 2 3 4 5 6 7 8 9
Ch1
Ch2

38. A MAC protocol based on Split Phase

39. 802.11 PSM (Power Saving Mode)
Doze mode – less energy consumption but no communication
ATIM – Ad hoc Traffic Indication Message A B C
Time
Beacon
ATIM Window
Beacon Interval

40. 802.11 PSM (Power Saving Mode)B C
Time
Beacon
ATIM
ATIM Window
Beacon Interval

41. 802.11 PSM (Power Saving Mode)B C
Time
Beacon
ATIM
ATIM-ACK
ATIM Window
Beacon Interval

42. 802.11 PSM (Power Saving Mode)B C
Time
Beacon
ATIM
ATIM-ACK
ATIM-RES
ATIM Window
Beacon Interval

43. 802.11 PSM (Power Saving Mode)B C
Time
Beacon
ATIM
ATIM-ACK
DATA
ATIM-RES
Doze Mode
ATIM Window
Beacon Interval

44. 802.11 PSM (Power Saving Mode)B C
Time
Beacon
ATIM
ATIM-ACK
DATA
ACK
ATIM-RES
Doze Mode
ATIM Window
Beacon Interval

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

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

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

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

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

50. MMAC A B C D Time ATIM Window Beacon Interval Common Channel
Selected Channel
Beacon

51. MMAC A B C D Time Common Channel Selected Channel ATIM- RES(1) ATIM
Beacon B
ATIM-
ACK(1) C D
Time
ATIM Window

52. MMAC A B C D Time Common Channel Selected Channel ATIM- RES(1) ATIM
Beacon B
ATIM-
ACK(1)
ATIM-
ACK(2) C D
ATIM
ATIM-
RES(2)
Time
ATIM Window

53. MMAC A B C D Time Common Channel Selected Channel ATIM- RES(1) ATIM
RTS
DATA
Channel 1 A
Beacon
Channel 1 B
ATIM-
ACK(1)
CTS
ACK
ATIM-
ACK(2)
CTS
Channel 2
ACK C
Channel 2 D
ATIM
ATIM-
RES(2)
RTS
DATA
Time
ATIM Window
Beacon Interval

54. Experimental Parameters
Transmission rate: 2Mbps
Transmission range: 250m
Traffic type: Constant Bit Rate (CBR)
Beacon interval: 100ms
Packet size: 512 bytes
ATIM window size: 20ms
Default number of channels: 3 channels
Compared protocols
802.11: IEEE single channel protocol
DCA: Wu’s protocol
MMAC: Proposed protocol

55. WLAN - Throughput

56. Multi-hop Network - Throughput

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

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

59. Multi-interface Multi-channel
Each node has multiple interfaces

60. 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 in ad hoc networking , IEEE Communications magazine, Volume 43, Number 7; Pages: , July 2005
S. Xu, T. Saadawi, Does the IEEE MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks?, IEEE Communications magazine, June 2001
Review