Performance comparison of RTS/CTS and ‘Express Forwarding’ for mesh April 2008 Performance comparison of RTS/CTS and ‘Express Forwarding’ for mesh Date: 2008-04-15 Authors: Name Address Company Phone Email Mathilde Benveniste 233 Mt Airy Road Basking Ridge, NJ 07920, US Avaya Labs-Research 973-761-6105 benveniste@ieee.org Kaustubh Sinkar 1 Telcordia Drive, Piscataway, NJ 08854, US Telcordia Technologies 732-699-4547 ksinkar@telcordia.com Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. M. Benveniste (Avaya Labs)

April 2008 Performance comparison of RTS/CTS and ‘Express Forwarding’ for mesh Mathilde Benveniste Kaustubh Sinkar M. Benveniste (Avaya Labs)

April 2008 Abstract Latency on single-channel mesh can far exceed a hop-count nultiple of the latency seen in WLANs Multi-hop flows cause the latency on other flows (either on mesh or co-channel WLANs) to increase as well Among the causes are hidden node collisions Q: Can RTS/CTS remedy the problem? A: No, RTS/CTS may exacerbate the problem M. Benveniste (Avaya Labs)

April 2008 Introduction Express Forwarding and Express Retransmission have been proposed to alleviate delay increases caused by multi-hop transmissions in a single channel mesh [2]-[3] They enable the co-existence of mesh with WLANs as they also improve the performance of all traffic flows that are not express forwarded Increasing the contention window size following a collision helps avoid hidden node collision on retry Performance studies of Express Forwarding covered meshes with both long and short multi-hop flows [4] [8] We compare here Express Forwarding to the use of RTS/CTS in a mesh network with multi-hop flows M. Benveniste (Avaya Labs)

Express Forwarding – Review Ref Doc 11-07/2452, 2453 April 2008 Express Forwarding – Review Ref Doc 11-07/2452, 2453 ‘Express forwarding’ on a single-channel mesh reduces the end-to-end delay of selected frames by granting forwarding nodes immediate access to the channel Criteria for express forwarding frames include: Time sensitive QoS [TSQ] frames – e.g. VO/VI Frames on paths traversing more than a specified number of hops Single-hop frames are not express-forwarded How it works Forwarding delay is reduced by reserving the channel for a forwarded transmission longer, in order to enable the forwarding node to seize the channel Reservation is done with no additional frames Immediate access is thus given to nodes forwarding QoS traffic on a multi-hop path Because neighbor nodes refrain from transmitting when a frame is forwarded, the collision rate is reduced M. Benveniste (Avaya Labs)

Express Forwarding Illustration April 2008 Express Forwarding Illustration DT0 Channel busy at receiving node NAV setting at all other neighbor nodes Value in Duration field of TSQ frame Channel 1-2 Frame ACK 2-3 3-4 time 5 3-hop path 1-4 1 2 3 4 ANIMATED The Duration field is set at value longer than usual when a TSQ frame is transmitted to a forwarding node of a multi-hop path; the increment DT0 >= 1 timeslot + max{0, (IP processing delay – AckTime – SIFS)} The forwarding nodes, 2 and 3, adjust the Duration value on the received frame by subtracting the increment DT0 when setting their NAV The non-forwarding neighbor nodes (e.g. 5) set NAV according to Duration field M. Benveniste (Avaya Labs)

Express Retransmission April 2008 Express Retransmission Retransmission of a failed transmission typically involves backoff using a wider contention window With express retransmission, a frame is retransmitted by dispensing with backoff and transmitting after SIFS following AckTimeout An express forwarded frame is less likely to collide on retransmission because of its prioritization Only the first retransmission attempt receives priority treatment Prevents two express-forwarded frames from colliding repeatedly Subsequent retransmission attempts less likely to lead to collision when using large CWmax DT0 Frame + ACK time NAV setting at all other neighbor nodes Value in Duration field of TSQ frame Channel TSQ TSQ time Frame Retransmission ACKtimeout M. Benveniste (Avaya Labs)

Performance Study _______ April 2008 802.11a Network 3 WLANs co-channel with a nearby single-channel mesh Mix of wide and narrow contention windows WLAN AC_VI parameters: CWmin=15, CWmax=31 Mesh parameters: CWmin=15, CWmax=1023 (reduce recurrence of hidden node collision) Scenarios Studied* EF Disabled: business as usual – EF disabled and RTS/CTS disabled EF Disabled (RTS): EF disabled and RTS/CTS enabled for video flows EF Enabled: EF and ERTX enabled and RTS/CTS disabled _______ *All scenarios consider only high-priority traffic (VOIP and Video) OPNET Modeler used for simulations M. Benveniste (Avaya Labs)

Parameters April 2008 Parameter Value PHY 11a Slot Time 9 usec Sifs Time 16 usec Phy_CWmin 15 Phy_CWmax 31 or 1023 PLCP overhead control 20 usec PLCP overhead data Control Data Rate 24 Mbps Difs Time sifs + 2*slot_time = 34 usec Eifs_time difs + sifs + ACK @ 24 Mbps aifsn 2 Aifs [ac] aifsn[ac] * slot_time + sifs_time = 34 usec ACK tx rate DATA tx rate 54 Mbps M. Benveniste (Avaya Labs)

802.11a Mesh (3 hops max) April 2008 Physical layer rates 17 18 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 Data @ 54 Mbps ACK @ 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, 0.16 Mbps payload size: 200 bytes, inter-arrival 20 ms WLAN devices Mesh points M. Benveniste (Avaya Labs)

Average ETE Delay (sec) April 2008 Average ETE Delay (sec) M. Benveniste (Avaya Labs)

Express Fwd Disabled (RTS) Express Fwd with Exp Rtx April 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)

ETE Delays CDF: Portal to Node 3 April 2008 ETE Delays CDF: Portal to Node 3 Portal -> Node3 Delay Node3 -> Portal Delay M. Benveniste (Avaya Labs)

ETE Delays CDF: Portal to Node 6 April 2008 ETE Delays CDF: Portal to Node 6 Portal -> Node6 Delay Node6 -> Portal Delay M. Benveniste (Avaya Labs)

ETE Delays CDF: Portal to Node 12 April 2008 ETE Delays CDF: Portal to Node 12 Portal -> Node12 Delay Node12 -> Portal Delay M. Benveniste (Avaya Labs)

April 2008 Dropped Frames M. Benveniste (Avaya Labs)

April 2008 Retransmissions M. Benveniste (Avaya Labs)

Summary of Results April 2008 RTS/CTS impact At faster data rates (11g/a/n), differences in the size of data part become less significant The increased number of transmissions becomes most relevant 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 Express forwarding (with express retransmission) benefits ETE delay for all 3-hop VOIP flows is reduced by at least 90% All other flows (both on the mesh or in neighboring BSS) also enjoy substantial delay reduction Express Forwarding causes fewer frames to be dropped Express Retransmission reduces retransmissions and end-to-end delay further Traffic concentration at Portal The flows going thru the portal experience very long delays if no express forwarding is allowed Express forwarding (with express retransmission) on the multi-hop flows reduces delays substantially on all flows thru the portal, both multi-hop and single-hop flows M. Benveniste (Avaya Labs)

April 2008 Conclusions Use of RTS/CTS cannot alleviate the negative impact of multi-hop flows of a single-channel mesh In fact, it can exacerbate this impact It causes flows with short frame interarrival times to become unstable on fast channels – e.g. 11a/g/n Express Forwarding reduces end-to-end delay and jitter of the multi-hop flows substantially causes fewer frames to be dropped Other (not express forwarded) traffic also benefits substantially Express Retransmission further enhances these benefits Express Forwarding and Express Retransmission enable multi-hop QoS traffic to get through a single-channel mesh fast with minimum impact on other traffic (WLAN and mesh) M. Benveniste (Avaya Labs)

April 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 802.11-07-2452r2 “Draft Text Changes for ‘Express Forwarding’ in a Mesh, M. Benveniste”, IEEE Doc 802.11-07-2453r4 “Performance Evaluation of ‘Express Forwarding’ for a Single-Channel Mesh”, M. Benveniste and K. Sinkar, IEEE Doc 802.11-07-2454r1 “Performance Implications of ‘Express Forwarding’ for a Single-Channel Mesh”, M. Benveniste, IEEE Doc 802.11-07-2814r1 “Effect of Contention Window Size on Express Forwarding Performance for Single-Channel Mesh”, M. Benveniste and K. Sinkar, IEEE Doc 802.11-07-2886r0 “Coexistence issues for single-channel wireless mesh”, M. Benveniste, IEEE Doc 802.11-08-0075r0 “More on Performance Evaluation of ‘Express Forwarding’ for Mesh”, M. Benveniste and K. Sinkar, IEEE Doc 802.11-08-0142r0 M. Benveniste (Avaya Labs)