Adaptive Rate Control NAV Setting July 2005 July 2005 Jan 2006 Adaptive Rate Control NAV Setting Date:2006-Jan-28 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>. Feng Li, ZTE Corporation & CATR Feng Li, ZTE Corporation

July 2005 July 2005 Jan 2006 Abstract This document contains an outline of the method of setting and resetting for Adaptive Rate Control (ARC) proposal (doc#: 11-06/0342r0) in support of Adaptive Rate Control objective in accordance with REQ2100. Feng Li, ZTE Corporation & CATR Feng Li, ZTE Corporation

Jan 2006 A method of setting and resetting the NAV for ARC should be recommended To improve the performance as date rate upgraded during frame sequence exchanging. To avoid the collision caused by hidden STA as date rate degraded during frame sequence exchanging. To avoid the collision in IBSS or ESS when ARC mechanism is used. To be used for IEEE802.11n, especially for immediate response link adaptation. Feng Li, ZTE Corporation & CATR

A method of setting and resetting the NAV for ARC Jan 2006 A method of setting and resetting the NAV for ARC A NAVI is defined as the new NAV record belonging to a definite frame exchange sequence. Correspond to every frame exchange sequence, each STA shall update its NAVI as receiving a valid frame only when the frame is not addressed to the receiving STA. Each STA supporting ARC shall maintain a NAVI list for all frame exchange sequence. Each STA shall select the maximum NAVI from its NAVI list to update NAV. Feng Li, ZTE Corporation & CATR

Jan 2006 NAVI in BSS Figure 1 shows a BSS in which only a frame sequence exchange could be detected. In this case, NAV is same as NAVI The next immediately frame rate suggested by respond frame shall be adopt by source, in order to allow the respond frame indicate the NAV with accuracy. Figure 1 Feng Li, ZTE Corporation & CATR

Jan 2006 Rate upgraded NAVI Figure 2 shows an example of NAV setting when the data rate is upgraded. Figure 2 Feng Li, ZTE Corporation & CATR

Jan 2006 Rate degraded NAVI Figure 3 shows an example of NAV setting when the data rate is degraded. Figure 3 Feng Li, ZTE Corporation & CATR

Jan 2006 NAVI in ESS or IBSS(1) Figure 4 shows the case of IBSS or ESS in which two or more frame sequence exchanging could be detected Figure 4 Feng Li, ZTE Corporation & CATR

NAVI in ESS or IBSS(2) Jan 2006 NAVI list of STA3 contains TWO items (NAVI 1 and NAVI 2) as TWO frame sequence exchanging being detected. STA3 select the maximum one from the items of NAVI list (NAVI1 and NAVI2 at the moment) to update NAV. Figure 5 Feng Li, ZTE Corporation & CATR

Jan 2006 Feedback? Feng Li, ZTE Corporation & CATR

Backup Jan 2006 July 2005 July 2005 Feng Li, ZTE Corporation & CATR

Jan 2006 Defect (1) The efficiency should not be improved based on current NAV setting and resetting method even if the date rate having been upgraded during frame sequence exchanging. Feng Li, ZTE Corporation & CATR

Jan 2006 Defect (2) Duration would be prolonged as the date rate degraded. If the destination is not sure the definite rate of next immediate data, the collision caused by hidden STA within a BSS would be increased based on existing NAV setting and resetting method. Feng Li, ZTE Corporation & CATR

Jan 2006 Defect (3) The collision caused by hidden STA within a BSS could be avoided by set NAV long enough in the beginning, and finally, reset NAV by the last sent frame or respond frame. However, this method would lead to collision in IBSS or ESS when data rate is adjusted during a frame sequence exchanging . Feng Li, ZTE Corporation & CATR