1. Can RTS/CTS remedy problems caused by single-channel wireless meshes?
February 2008
Can RTS/CTS remedy problems caused by single-channel wireless meshes?
Date:
Authors:
Name
Address
Company
Phone
Mathilde Benveniste
233 Mt Airy Road
Basking Ridge, NJ 07920, US
Avaya Labs-Research
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
M. Benveniste, Avaya Labs

2. Can RTS/CTS remedy problems caused by single-channel wireless meshes?
February 2008
Can RTS/CTS remedy problems caused by single-channel wireless meshes?
Mathilde Benveniste
M. Benveniste, Avaya Labs

3. February 2008
Abstract
Latency on wireless meshes operating on a single channel can exceed the latency seen in WLANs, even when adjusted for the number of hops in a multi-hop path. Multi-hop flows can cause excessive latencies on both meshes and WLANs. The prevalence of hidden nodes and the interaction of contention-based access with multi-hop flows are among the causes of such behavior. The question asked here is whether RTS/CTS can remedy the problem. The answer is that RTS/CTS makes things worse. The performance of RTS/CTS is compared to (i) doing nothing and (ii) using ‘Express Forwarding’.
M. Benveniste, Avaya Labs

4. ‘Hidden node’ collisions with a single-channel mesh
February 2008
‘Hidden node’ collisions with a single-channel mesh
Characteristics of mesh networks using a single channel
A mesh point will typically not be able to hear most of the mesh points other than its neighbors
The neighbor of a neighbor is likely a hidden node
A grouping without hidden nodes might be covered as well by a single BSS
Such a mesh experiences more hidden node collisions than a WLAN system
A single WLAN experiences hidden node collisions on uplink transmissions only
WLANs with overlapping coverage areas can avoid cross collisions by using different channels
WLANs sharing same channel are separated by longer distances than mesh nodes
Such a mesh causes hidden node collisions for nearby WLAN devices
The mesh neighbors of a mesh node near a WLAN are hidden nodes for the WLAN as they all use the same channel
M. Benveniste, Avaya Labs

5. Impact of hidden nodes February 2008
Hidden nodes increase collision rate
Carrier sensing fails to alert potential interferers
High rates of dropped frames
Collisions repeat on retransmission if nodes cannot hear each other
When the ‘retry limit’ is reached frames are dropped
Throughput reduction
High dropped frame rates lead to data rate reduction and low throughput with adjustable data rates
Long delays
Hidden nodes cause collisions, which put a WLAN or mesh node at a disadvantage relative to transmissions attempted for the first time (because of the longer retry backoff)
If the failed transmission is near a multi-hop flow, it may have to wait for the entire multi-hop flow to complete before retransmission is possible
Applications with short frame inter-arrival times (e.g. HDTV) risk going unstable if near multi-hop flows
M. Benveniste, Avaya Labs

6. RTS/CTS Mechanism February 2008 1 3 6 4 2 RTS/CTS for hidden nodes
An RTS is sent before a frame to head off a collision and, if successful to reserve the channel
The CTS sent in return notifies ‘hidden’ neighbors of the receiving node to refrain from transmitting
RTS/CTS benefits
Long frames on a slow channel benefit from RTS/CTS
Instead of a collision involving the frame, collision with the shorter RTS frame saves channel time
RTS/CTS penalties
Using RTS causes more frames to be transmitted taking up channel time and increasing probability of collision
For frames with short transmission times, the benefit of avoiding collision with a shorter RTS is outweighed by the additional number of frames
RTS/CTS does not help on faster channels
At faster data rates, differences in the size of data part become less significant
The increased number of transmissions becomes more relevant C
RTS 1 Tx 3
ACK 6 4
CTS 2 D
Transmissions
M. Benveniste, Avaya Labs

7. Hidden nodes: RTS/CTS does not prevent dropped frames
February 2008
Hidden nodes: RTS/CTS does not prevent dropped frames X
No RTS-CTS Tx
Nodes A and F cannot hear one another
A and F transmit simultaneously
Both B and E experience collisions
Collisions likely to repeat on re-transmission
When retry limit is reached, frames are dropped
RTS/CTS provides no added protection E F A B C X Tx X
RTS
With RTS-CTS E F A B C X
RTS
With RTS-CTS
M. Benveniste, Avaya Labs

8. More transmissions/longer delays with RTS/CTS
February 2008
More transmissions/longer delays with RTS/CTS Tx 3
No RTS-CTS
Hidden nodes: Nodes A and F cannot hear each other
They each transmit a data frame
B can hear F; E can hear A
A completes transmission before F starts
No collisions
More transmissions with RTS/CTS
Longer delays with RTS/CTS
Score: Two data frames transmitted
NO RTS/CTS: 4 frames
[two data frames + two ACKs]
With RTS/CTS: 8 frames
[two RTS + two CTS + two data frames + two ACKs] E F
Transmissions
ACK 4
ACK 2 Tx 1 A B C 7 Tx
RTS 5
With RTS-CTS E F
Transmissions 8
ACK
CTS 6
ACK 4
CTS 2
RTS 1 3 Tx A B C
M. Benveniste, Avaya Labs

9. More transmissions/longer delays/more collisions with RTS/CTS
February 2008
More transmissions/longer delays/more collisions with RTS/CTS A A
ACK Tx X 3 Tx 4
ACK 5 6 X
RTS
ACK
CTS 3 X
RTS
RTS 7 Tx 9
ACK 10
CTS 8
Hidden nodes: A and D cannot hear each other
They each transmit a frame
C cannot hear A; B cannot hear D
A transmits after D, but simultaneously with ACK/CTS
Twice as many transmissions with RTS/CTS
Longer delays with RTS/CTS
Twice as many collisions with RTS/CTS
Score: To get two data frames transmitted
NO RTS/CTS: 5 frames, 1 collision
[three data frames + two ACKs]
With RTS/CTS: 10 frames, 2 collisions
[four RTS + two CTS + two data frames + two ACKs] B B
No RTS-CTS
With RTS-CTS C C Tx 1
RTS 1 Tx 4 D D
Transmissions
M. Benveniste, Avaya Labs

10. February 2008
Co-channel Mesh and WLAN: More transmissions/longer delays/more collisions with RTS/CTS 3
ACK Tx X 9 Tx
ACK 6 Tx X
No RTS-CTS E F
F cannot hear A and B and vise versa
Mesh flow A-D and WLAN flow F-E start ‘almost’ simultaneously
In both cases (No/With RTS-CTS) the WLAN flow completes after mesh flow
Twice as many transmissions with RTS/CTS
Longer delays with RTS/CTS
Twice as many collisions with RTS/CTS
Score: To get two flows transmitted
NO RTS/CTS: 10 transmissions; 2 collisions
[six data tx + four ACKs]
With RTS/CTS: 20 transmissions; 4 collisions
[eight RTS + four CTS + four data tx + four ACKs]
Transmissions
ACK 10 Tx 7 1 Tx 4 Tx
ACK 8 A B C D 6
ACK
RTS X
ACK 12
RTS X
RTS X
CTS 3 17
RTS 19 Tx 9
CTS
RTS X
With RTS-CTS E F
Transmissions 18
CTS
ACK 20
RTS 13
CTS 14 Tx 15
ACK 16
RTS 1 10 Tx 4 Tx
RTS 7
Mesh
WLAN A B C D
M. Benveniste, Avaya Labs

11. Conclusion re: RTS/CTS Mechanism
February 2008
Conclusion re: RTS/CTS Mechanism
RTS/CTS on fast channels (11g/a/n)
At faster data rates, differences in the size of data part become less significant
The increased number of transmissions becomes most relevant
RTS/CTS hurts performance
More frames are transmitted taking up channel time
The number of collisions increases as a consequence
Delay in successfully completing transmission increases
RTS/CTS offers no advantage with wireless meshes on faster channels
M. Benveniste, Avaya Labs

12. Other possible remedies
February 2008
Other possible remedies
Large retry window
Avoids dropped frames
Using a large backoff retry window reduces the probability of repeating a hidden node collision on retransmission
Express forwarding
Channel reservation for a forwarded frame reduces collision rate and benefits all
Expedited transmission reduces latency of all expedited flows
Non-expedited transmissions involved in collisions benefit as they will now wait a shorter time for nearby multi-hop flows to complete
M. Benveniste, Avaya Labs

13. ‘Express Forwarding’ Mechanism
February 2008
‘Express Forwarding’ Mechanism
Measures for shortening multi-hop delays
Express Forwarding (EF) and Express Retransmission (ERTX) have been proposed to alleviate delay increases caused by multi-hop transmissions in a single channel mesh [2]-[3]
Increasing the contention window size following a collision helps avoid hidden node collision on retry
Measures may shorten delays for co-channel WLANs
The delay of traffic flows that are not express forwarded often improves
No major delay increases introduced
Performance confirmed by simulations
Simulation studies covered meshes with both long and short multi-hop flows [4] [8]
M. Benveniste, Avaya Labs

14. February 2008
‘Express Forwarding’ Reference: “‘Express’ Forwarding for Single-Channel Wireless Mesh”, M. Benveniste, IEEE Doc r2
EF is a prioritization method for multi-hop transmissions
Can be used selectively for VoIP/multi-media
Prioritization thru next hop reservation
The Duration field on the frame and returned ACK is extended to keep all other neighbors silent long enough for forwarding to occur contention-free
Tx Hop 1
Channel reservation
Tx Hop 2
time
M. Benveniste, Avaya Labs

15. ‘Express Retransmission’
February 2008
‘Express Retransmission’
ERTX expedites first retransmission attempt
In the event of collision, frame is retransmitted following AckTimeout without backoff
Allowed first retry only, to prevent two express-forwarded frames from colliding repeatedly
Retransmission less likely to collide
No contention from neighbors due EF protection
Collision with transmission from hidden node less likely due to backoff delay difference
No ACK X
Tx Hop 1
Channel reservation
ReTx Hop 1
time
M. Benveniste, Avaya Labs

16. ‘Express Forwarding’ Examples
February 2008
‘Express Forwarding’ Examples
Two examples of the same setting of a single-channel mesh and nearby WLANs illustrate:
How EF remedies the negative impact of hidden nodes and multi-hop flows
Possible impact of EF on flows that are not express forwarded
Two WLAN flows and one 3-hop mesh flow use same channel
Starting at the time of transmission of first mesh frame, channel access is monitored for one mesh multi-hop frame and two consecutive frames from each WLAN flow
The examples differ w.r.t. the time of arrival of one of the WLAN frames
Earlier arrival
Later arrival
M. Benveniste, Avaya Labs

17. 1. Express Forwarding: Fewer transmissions/shorter average delays
February 2008
1. Express Forwarding: Fewer transmissions/shorter average delays
EDCA (No RTS-CTS) Tx X 12 Tx X 10 Tx X 6 X Tx 25 Tx X 2 Tx X 2 26 Tx Tx X 4 Tx 14 Tx X 8
Express Forwarding Tx 10 Tx 14
Transmissions E F E F
Transmissions 17 Tx 24 Tx X 20
ACK 18
ACK 23 Tx 28 27
ACK
ACK 29
ACK 10 16
ACK 10 12 Tx 22
ACK 10 16
ACK 21 3 Tx
ACK 4 Tx 5
ACK 6 Tx 7
ACK 8 A B C D A B C D G G H H
Offered Load:
F-E, 2 data frames: completed at 8 and 17 tx
G-H, 2 data frames: completed at 8 and 12 tx
A-D (3 hops), 1 data frame: complete after 19 tx
Score: 29 transmissions (22 data frames + 7 Acks)
Offered Load:
F-E, 2 data frames: completed at 9 and 11 tx
G-H, 2 data frames: completed at 9 and 11 tx
A-D (3 hops), 1 data frame: complete after 7 tx
Score: 16 transmissions (9 data frames + 7 Acks)
M. Benveniste, Avaya Labs

18. February 2008
2. Express Forwarding: Fewer transmissions/shorter delays/no dropped frames
EDCA (No RTS-CTS) Tx X 10 Tx X 14 Tx X 12 Tx X 2 Tx X 8 Tx X 4 Tx X 6
Express Forwarding Tx 14 Tx X 2 19 Tx Tx 10
Transmissions E F E F
Transmissions Tx 15
ACK 18 20
ACK Tx 17
ACK 10 16
ACK 10 16 Tx 5 3 Tx
ACK 4
ACK 10 12 Tx 7
ACK 6
ACK 8 A B C D A B C D G G H H
Offered Load:
F-E, 2 data frames: one dropped, other completed at 13 tx
G-H, 2 data frames: completed at 9 and 11 tx
A-D (3 hops), 1 data frame: dropped after 7 tx
Score: 20 transmissions (17 data frames + 3 Acks)
Offered Load:
F-E, 2 data frames: completed at 9 and 11 tx
G-H, 2 data frames: completed at 9 and 11 tx
A-D (3 hops), 1 data frame: completed after 7 tx
Score: 16 transmissions (9 data frames + 7 Acks)
M. Benveniste, Avaya Labs

19. Observations on ‘Express Forwarding’
February 2008
Observations on ‘Express Forwarding’
With EDCA, one of the WLAN frames becomes involved in recurring hidden node collisions with the mesh flow
In Example 1, a frame from the WLAN breaks the cycle of collisions between the mesh flow and the other WLAN through neighborhood capture; no frames dropped
In Example 2, the two frames involved in collisions exceed retry limit and are dropped before any neighborhood capture intervention
Express forwarding gives better performance than either EDCA example
No frames dropped
Fewer retransmissions
Each flow experiences shorter mean delay
EF can increase the delay of non-express forwarded frames, but the increase is small relative to overall delay reduction
M. Benveniste, Avaya Labs

20. February 2008
Simulation Study Reference: “More on Performance Evaluation of ‘Express Forwarding’ for Mesh” M. Benveniste and K. Sinkar, IEEE Doc r0
802.11a Mesh
Mix of multi-hop and single-hop VoIP calls and video users transmitting on the same channel as 3 independent WLANs
At most 3 hops on multi-hop flows
Single mesh portal
Data rate 54 Mbps; Ack rate 24 Mbps
Scenarios
EF Disabled – RTS/CTS disabled and EF disabled
EF Disabled (RTS) – EF disabled and RTS/CTS enabled for video flows
EF Enabled – EF and ERTX enabled and RTS/CTS disabled
M. Benveniste, Avaya Labs

21. 802.11a Mesh (3 hops max) February 2008 Physical layer rates17 10 21 1 2 3 26 25 4 5 6 11 12 33 34 32 31 14 22 29 30 20 27 28
VIDEO (L)
VOIP
VIDEO (H) 19
TOTAL LOAD: 23 Mbps
Network configuration
TX RANGE: 25 m
next-hop neighbors don’t hear each other
Physical layer rates
54 Mbps
24 Mbps
Traffic description
VIDEO (L): Low Resolution, 1.4 Mbps
payload size: 1464 bytes, inter-arrival 8 ms
VIDEO (H): High Resolution, 4.2 Mbps
payload size: 1464 bytes, inter-arrival 2.83 ms
VOIP : G711, Mbps
payload size: 200 bytes, inter-arrival 20 ms
WLAN devices
Mesh points
M. Benveniste, Avaya Labs

22. Average ETE Delay (sec)
February 2008
Average ETE Delay (sec)
M. Benveniste, Avaya Labs

23. Express Fwd Disabled (RTS) Express Fwd with Exp Rtx
February 2008
Average ETE Delay (ms)
Express Fwd Disabled
Express Fwd Disabled (RTS)
Express Fwd with Exp Rtx
node_0 --> node_3 22 44 2
node_0 --> node_6
2,698
8,610 3
node_0 --> node_12
3,583
13,728 6
node_3 --> node_0 19 31
node_6 --> node_0
2,562
7,756
node_12 --> node_0
3,448
10,506 7
node_17 --> node_18 12 11
node_20 --> node_19 92 4
node_21 --> node_22
node_22 --> node_14
node_25 --> node_26
node_27 --> node_19 8
2,200 5
node_28 --> node_26
node_29 --> node_30 9
node_30 --> node_29
node_31 --> node_32
node_33 --> node_34 28
349
Express-forwarded
flows
WLAN flows
M. Benveniste, Avaya Labs

24. February 2008
Conclusions
Even relatively short multi-hop flows (e.g. 3 hops max) can cause severe delays and/or dropped frames to both mesh and WLAN traffic
In a fast channel (e.g. 11a), use of RTS/CTS exacerbates delays and causes flows with short frame interarrival times to become unstable
Express Forwarding (with Express Retransmission) produces end-to-end latencies that can meet QoS requirements for mesh and WLAN flows
M. Benveniste, Avaya Labs

25. February 2008
References
“Wireless mesh networks: Performance implications for WLANs,” M. Benveniste, Interop New York, Oct 2007
“‘Express’ Forwarding for Single-Channel Wireless Mesh, M. Benveniste”, IEEE Doc r2
“Draft Text Changes for ‘Express Forwarding’ in a Mesh, M. Benveniste”, IEEE Doc r4
“Performance Evaluation of ‘Express Forwarding’ for a Single-Channel Mesh”, M. Benveniste and K. Sinkar, IEEE Doc r1
“Performance Implications of ‘Express Forwarding’ for a Single-Channel Mesh”, M. Benveniste, IEEE Doc r1
“Effect of Contention Window Size on Express Forwarding Performance for Single-Channel Mesh”, M. Benveniste and K. Sinkar, IEEE Doc r0
“More on Performance Evaluation of 'Express Forwarding' for Mesh”, M. Benveniste and K. Sinkar, IEEE Doc r0
“Performance comparison of RTS/CTS and ‘Express Forwarding’ for mesh”, M. Benveniste and K. Sinkar, IEEE Doc r0
M. Benveniste, Avaya Labs