Concerns Regarding CCF November 2006 doc.: IEEE 802.11-06/xxxxr0 November 2006 Concerns Regarding CCF Date: 2006-11-14 Authors: 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>. Michelle Gong, Cisco Michelle Gong, Cisco

Concerns Concerns that can be resolved November 2006 Concerns Concerns that can be resolved Devices have different Channel Switch Delays Low bandwidth utilization efficiency Common channel bottleneck A concern that we don’t know how to resolve Co-existence problem Michelle Gong, Cisco

November 2006 Operation of CCF MPs exchange channel information on the common channel A pair of MPs switch to the agreed-upon data channel for data transmission RTX  DIFS Switching Delay CTX SIFS RTX  DIFS CTX SIFS CTX SIFS DIFS DATA Switching Delay Common Channel RTX ACK SIFS DATA Switching Delay DIFS Data Channel n Data Channel m ACK SIFS Michelle Gong, Cisco

Concern 1: Different Channel Switch Delay November 2006 Concern 1: Different Channel Switch Delay For each data packet exchange, a device needs to switch channel twice. After each channel switch, hardware needs settling time, aka channel switch delay Channel switch delay is usually implementation dependent and non-negligible A typical channel switch delay is about ~1ms Some products can achieve hundreds of us delay Because devices have different channel switch delays, if a transmitter/receiver pair do not know each others’ channel switch delays, then correct operation is unlikely An extra field in RTX/CTX 2 6 4 Frame Control Duration RA TA Destination Channel Information FCS RTX frame 2 6 4 Frame Control Duration RA Destination Channel Information FCS CTX frame Michelle Gong, Cisco

Concern 2: Low Bandwidth Utilization Efficiency November 2006 Concern 2: Low Bandwidth Utilization Efficiency High overhead per data packet exchange For each packet, CCF needs a RTX/CTX exchange, which takes about 100us at 24Mbps Channel switch delay ranges from 1ms to hundreds of us A typical TCP packet is 552 bytes and the packet transmission and ACK takes about ~270us over a 24Mbps wireless link In this case, overhead is larger than the transmission time. With a channel switch delay of 400us, the CCF efficiency is only 23% This compares poorly with 2 WLAN networks independently using 1 channel each Michelle Gong, Cisco

Concern 3: Common Channel Bottleneck November 2006 Concern 3: Common Channel Bottleneck Common channel bottleneck All MPs in the neighborhood share the same common channel The common channel is also shared with non-CCF devices All multi-cast and broadcast traffic is sent on the common channel (another concern) TXOP doesn’t solve Concerns 2 & 3 completely and TXOP for data can be harmful to QoS traffic However, without TXOP, CCF suffers very low efficiency and the common channel becomes a bottleneck Michelle Gong, Cisco

Concern 4: Co-existence Problem November 2006 Concern 4: Co-existence Problem When non-CCF devices share the same channel with CCF devices, the channel availability information becomes inaccurate Collisions and CCA-busy on the data channel are very costly to CCF devices Because the transmitter/receiver pair stay on the data channel for some time plus channel switch delay, after the pair switch back to the common channel, they no longer have up-to-date channel information Thus, they have to wait up to multiple ms until the start of the next channel coordination window (CCW) Michelle Gong, Cisco

Concern 4: Co-existence Problem (Cont.) November 2006 Concern 4: Co-existence Problem (Cont.) When CTX is not received, the transmitter stays on the common channel and keeps backing off and re-transmitting. But the receiver is on the data channel and will only return after 2 * Channel-switch-delay + DIFS + aSlotTime, which is about 1 to 2ms This problem also occurs when two CCF networks choose different common channels Michelle Gong, Cisco

Concern 4: Co-existence Problem (Cont.) November 2006 Concern 4: Co-existence Problem (Cont.) A CCF device switches from one channel to another frequently. Every time it switches to a new channel, it performs CCA for DIFS time It is highly likely that a CCF device misses any medium information, such as a preamble or virtual carrier sense, occurring before the CCF device arrives on the data channel If a packet’s preamble is missed, the CCA sensitivity level is -62dBm as defined in the subclause 17.3.10.5 of 802.11ma. Such a high CCA sensitivity level means CCA is unlikely to be triggered in most practical situations Virtual carrier sensing is an important way of avoiding collisions in 802.11, and respecting virtual carrier sensing is mandatory in the standard Michelle Gong, Cisco

Concern 4: Co-existence Problem (Cont.) November 2006 Concern 4: Co-existence Problem (Cont.) Missing virtual carrier sense and preambles is damaging to both CCF devices and non-CCF devices Collisions cost much more for CCF devices than for non-CCF devices Not being compatible with the 802.11 protocol means a large number of negative comments during LB, which have to be resolved for us to move forward Michelle Gong, Cisco

Conclusions Concerns that can be resolved November 2006 Conclusions Concerns that can be resolved Different channel switch delays Low bandwidth utilization efficiency Common channel bottleneck A concern that we don’t know how to resolve Co-existence problem Other presentation: 11-06/1777r0 The proposed solutions such as lowering the CCA sensitivity level need changes to the 802.11 PHY and thus changes to the TGs PAR. The group has already decided not to make the change There is no existing solution to fix the current problems Michelle Gong, Cisco

November 2006 Any Questions? ? Michelle Gong, Cisco

November 2006 Remove or modify the following sections in the Draft P802.11s – D0.04.pdf Remove all references to CCF from D0.04, including Section 4: page 4, remove line 15, 17, 34, and 38 Section 5.2.7.3: remove the section Section 7.1.3.1.2: page 13, Table 1, remove RTX/CTX type Section 7.2.1.9: remove the section Section 7.2.1.10: remove the section Section 7.3.2.36: page 22, Figure s16 and Table s1, remove “Multi-channel capability” element. Page 24, remove line 5 to 13 and Figure s20. Section 7.3.2.51: remove the section Section 11A.1.7: remove the section Michelle Gong, Cisco

November 2006 Motion Do you think that we should adopt the changes shown in this document 11-06/1716r2? Moved: Second: Yes No Abstain Michelle Gong, Cisco