1. Can RTS/CTS remedy problems caused by single-channel wireless meshes?
March 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?
March 2008
Can RTS/CTS remedy problems caused by single-channel wireless meshes?
Mathilde Benveniste
M. Benveniste, Avaya Labs

3. March 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. March 2008
‘Hidden node’ collisions with a single-channel mesh Background: “Coexistence issues for single-channel wireless mesh”, M. Benveniste, IEEE Doc r0
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 March 2008 Increased 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 March 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
March 2008
Hidden nodes: RTS/CTS does not prevent dropped frames X
No RTS-CTS Tx
Nodes A and F cannot hear one another
Transmissions by A and F overlap
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
M. Benveniste, Avaya Labs

8. More transmissions/longer delays with RTS/CTS
March 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
March 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’s transmission overlaps with with ACK/CTS from D
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]
Note: RTS is retransmitted after backoff countdown; for 11a backoff<8, A’s 2nd RTS collides with a VoIP ACK from C backoff<25, A’s 2nd RTS collides with a Video ACK from C B B
No RTS-CTS
With RTS-CTS C C Tx 1
RTS 1 Tx 4 D D
Transmissions
M. Benveniste, Avaya Labs

10. March 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
Initial frames of mesh flow A-D and WLAN flow F-E overlap
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
March 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
March 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 TXOP -- a time-space  extension of the TXOP [2]–[3]
Multiple frames are transmitted with a single contention
First node on a multi-hop flow, i.e. the initiator of the EF-TXOP, accesses channel by contention
Remaining nodes along a multi-hop path can transmit contention-free
Each transmission reserves the channel for the next hop
Limits may be imposed on length of EF sequence
Express retransmission (with EF) [2]–[3]
First retransmission attempt is sent contention free
Helps avoid repeat hidden node collision on retry
M. Benveniste, Avaya Labs

13. ‘Express Forwarding’ benefits
March 2008
‘Express Forwarding’ benefits
Mesh benefits
Channel reservation for a forwarded frame reduces collision rate and benefits all
Latency of all expedited flows of a mesh is reduced
Non-expedited transmissions of a mesh benefit from reduced contention; those involved in collisions now wait a shorter time for nearby multi-hop flows to complete
Shorter delays for co-channel WLANs
Like mesh flows that are not express forwarded, co-channel WLAN flows often experience improved latencies
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. March 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’
March 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
March 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
The initial frame of the mesh flow overlaps with one of the WLAN frames
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
March 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. March 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’
March 2008
Observations on ‘Express Forwarding’
With EDCA, one of the WLAN frames became 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 hidden node collisions exceed retry limit and are dropped before any neighborhood capture intervention
EF-TXOPs give better performance than either EDCA example
No frames dropped
Fewer retransmissions
Each flow experiences shorter mean delay
EF-TXOPs can increase the delay of non-express forwarded frames, but the increase is small relative to overall delay reduction
M. Benveniste, Avaya Labs

20. March 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) March 2008 Physical layer rates17 18 21 1 2 3 26 25 4 5 6 11 12 33 34 31 14 22 29 30 20 27 28
VIDEO (L)
VOIP
VIDEO (H) 19
TOTAL LOAD: 23 Mbps 32
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)
March 2008
Average ETE Delay (sec)
M. Benveniste, Avaya Labs

23. Express Fwd Disabled (RTS) Express Fwd with Exp Rtx
March 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. March 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. March 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
“Coexistence issues for single-channel wireless mesh”, M. Benveniste, IEEE Doc r0
M. Benveniste, Avaya Labs

26. Questions and Answers March 2008
Q1: Is mesh traffic given priority over WLAN traffic?
A1: No. Mesh traffic that is not part of an EF-TXOP accesses the channel just like WLAN traffic.
Q2: Do EF-TXOPs cause longer latencies for traffic that is not express-forwarded?
A2: In general, non-express forwarded traffic experiences lower latencies with EF-TXOPs due to the reduced contention and the shorter multi-hop delays that may impact latencies of other flows. Occasionally, frame latency may increase, but the increase is minimal and delay jitter is lower.
Q3: What happens if all traffic consists of express-forwarded multi-hop flows?
A3: Throughput still benefits. Like traditional TXOPs, there is the possibility of collisions between two EF-TXOPs. If EF nodes can hear one another, they will avoid collision through carrier sensing. A forwarding node must sense the channel idle for AIFS before transmitting. Backoff is invoked on (second) retry. Use of large CWmax (i.e., wide contention window) will avert repeated collisions when the sources are hidden nodes.
Q4: What is the benefit of express retransmission (EXRTX)?
A4: EXRTX expedites transmission and helps resolve hidden node collisions fast. The examples on slides 17 and 18 show how repeated collisions are avoided thanks to EXRTX. EXRTX is attempted once only, in case of collision between two EF transmissions. If all traffic is express forwarded, EXTRX should be disabled.
M. Benveniste, Avaya Labs

27. Questions and Answers March 2008
Q5: Why does RTS/CTS result in the poor performance shown in the simulation here?
A5: RTS/CTS is beneficial only if RTS takes substantially less time to transmit than the frame it protects. That is true for slow channels. However, for faster channels like 11a/g/n, frame header overhead makes frame-size differences less important. The added load penalty from RTS and CTS frames causes more adverse effects than benefits, as seen in the simulation.
Q6: Can EF avert hidden node collisions with transmissions from down the path of a flow, the way RTS/CTS has been used?
A6: No, the purpose of EF is to reduce contention through channel reservation and to help resolve hidden node collisions. RTS/CTS has been used to head off a collision of a frame by letting the RTS experience the collision instead of the frame. One can attain this kind of protection for slow channels, by using EF for the RTS [see ref 2]. However, for faster channels like 11a/g/n, the RTS/CTS overhead would be too high.
Q7: To implement EF, the Duration field of a frame would have to ‘lie’ about the transmission duration. Can we do that?
A7: There is no ethics code when defining the function of a field on a frame. In the present standard, the Duration field ‘lies’ when providing protection for a TXOP.
Q8: Is using EF-TXOPs in the mesh ‘unfair’ to WLAN traffic?
A8: No. Unfairness would arise if WLAN traffic were denied access, or if access were delayed. To the contrary, use of EF-TXOPs for mesh multi-hop flows reduces overall collisions and delays, and thus WLAN traffic performs better with EF than without, as seen in simulations. EF provides both per node fairness and per(multi-hop) flow fairness.
M. Benveniste, Avaya Labs

28. Questions and Answers March 2008
Q9: All the traffic in your scenario is high priority. Would the results be different if a mix of priorities were considered?
A9: If some of the total traffic load was changed to lower priority, the delays might be shorter, but EDCA would not be as effective as in a BSS due to the hidden nodes. The difference in AIFS length would not be heard by hidden nodes.
Q10: Suppose there are no installed WLANs; all wireless networks are mesh. Would Express Forwarding be needed?
A10: Yes. Without EF, multi-hop flows would experience long delays and would cause single-hop flows to be delayed. Express Forwarding enables QoS for real-time multimedia applications to be served by the mesh.
M. Benveniste, Avaya Labs