FlexWiFi – A Distributed DLS Date: 2006-10-03 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>. STMicroelectronics

General Issues This presentation proposes a solution, called FlexWiFi, to address some of the issues related to the use of DLS: Interoperability with existing infrastructure Power Save mode BW management STMicroelectronics

Interoperability with existing infrastructure DLS setup is part of the ‘e’ amendment of the 802.11 standard and requires the AP to be ‘11e capable’ to be supported Very few existing APs are ‘11e capable’ and consequently they cannot operate with DLS We need a solution that supports DLS without requiring existing APs to be replaced or upgraded STMicroelectronics

Power saving The problem with DLS is that each client doesn’t know when its peer station is awake or in PS mode. This imposes stations to keep their radio on whenever they have a DLS session active. We need a protocol to avoid this situation. STMicroelectronics

BW Management DLS is really effective for applications like video distribution in a home environment if it works together with some bandwidth management protocols. Such approaches will allow a more efficient use of the medium as well as better power savings. STMicroelectronics

FlexWiFi Main Features AP legacy compatibility No modification to legacy AP required Power Saving Support and Efficiency Improvement. Two DLS modes supported: Scheduled DLS: the direct link communication with a peer station is negotiated on a per-flow basis and is characterized by a duration (TXOP duration) and a starting time (offset) Unscheduled DLS: the direct link communication with a peer station may be always used Power saving is supported only in Scheduled DLS mode. Both modes are negotiated during a start-up phase. Support to multi-channel solutions STMicroelectronics

DLS and Infrastructure DATA transmission FlexWiFi Timings DL_SI : time interval, starting at the TBTT (Target Beacon Transmission Time) and having a well-known and fixed duration, when ‘FlexWiFi Capable’ stations must be awake. This period is used: To receive beacons To start/negotiate a DLS session with another ‘FlexWiFi Capable’ station MIXED_SI: Application frame exchange period (Infrastructure and/or DLS mode) Beacon Interval DL_SI MIXED_SI DLS Setup/Tear Down DLS and Infrastructure DATA transmission TBTT TBTT STMicroelectronics

Action Frames DLS_Req : action management frame sent by a ‘FlexWiFi Capable’ station to negotiate a DLS session DLS_Resp : action management frame sent as response to a previously received DLS_req in order to accept a DLS session DLS_Rej : action management frame sent as response to a previously received DLS_req in order to reject a DLS session DLS_Trd : action management frame sent to tear down a DLS session either temporarily (for a certain number of beacon intervals) or definitely STMicroelectronics

DLS_Req format The DLS_Req action management frame includes the following fields: Action Category: it indicates the specific action frame Dialog Token: the DL session id. It identifies the DL session under current negotiation TXOP: it is an indication of the maximum amount of time the sender will transmit in DL to its peer, per beacon interval. The TXOP duration is a per-flow calculation, based on QoS requirements and network conditions. It is different from 0 only for Scheduled DLS. A value of zero indicates that frame transmissions can occur at any time during the remaining beacon interval (i.e. Unscheduled DLS) Offset: the time interval between the TBTT and the start of the DLS TXOP. The minimum allowed value is DL_SI in case of Scheduled DLS, zero otherwise Channel ID: the PHY channel to be used during DL communication Supported PHY rates: the list of supported PHY rates STMicroelectronics

DLS_Resp format The DLS_Resp action management frame includes the following fields: Action Category: it indicates the specific action frame Dialog Token: it is the same value as in the relative DLS_Req frame TXOP: it is the same value as in the relative DLS_Req frame in case the receiver supports a Scheduled DLS, zero otherwise Offset: it is the same value as in the relative DLS_Req frame in case the receiver supports a Scheduled DLS, zero otherwise Channel ID: the same value as in the relative DLS_Req frame Supported PHY rates: the list of supported PHY rates STMicroelectronics

DLS_Trd format The DLS_Trd action management frame includes the following fields: Action Category: it indicates the specific action frame Dialog Token: it is the same value as in the relative DLS_Req frame Beacon Intervals: it indicates the number of beacon intervals the STA will not be available for communications. A value of zero indicates a definitive tear down. Note: this frame can be sent at any time during a beacon interval. STMicroelectronics

DLS Setup A DLS_Req frame must be sent during the DL_SI using a DL (Direct Link) format (i.e. the packet is received by the intended station and ignored by the AP) The reception of either a DLS_Resp or a DLS_Rej within a SIFS (to be evaluated) from the transmission of a DLS_Req frame is intended by the sender as an indication that the receiver is ‘FlexWiFi Capable’ A DLS_Rej frame may be sent by the DLS Receiver in order to reject a request for a DLS session DLS_Req QSTA - A QSTA - B DLS_Resp STMicroelectronics

The DLS operation Once a DLS setup phase has succeeded, the DLS Initiator is allowed to transmit: the overall transmission time during a beacon interval does not exceed the TXOP value; there is no constraint in case of Unscheduled DLS. Once the DLS initiator either exceeds the TXOP value or runs out of frames, it will set the EOSP flag in the last frame sent to the DLS Receiver in order to allow it to go to sleep (this is an indication that no other transmissions belonging to the same DLS session will occur within the current beacon interval). The EOSP flag will never be set in case of Unscheduled DLS (since both STAs are always awake) The DLS Receiver can go to sleep (till the end of the current beacon interval) regardless of the EOSP indication whenever the time limit for a specific DLS session is reached. Obviously this is not true in case of Unscheduled DLS. STMicroelectronics

Example of TXOP allocation during Scheduled DLS STA2 has two different DLS sessions active with STA1 and STA3 respectively: DL_SI MIXED_SI OFFSET1 STA1 TXOP1 EOSP = 1 EOSP = 1 STA2 TXOP1 TXOP2 OFFSET2 TXOP2 STA3 TBTT TBTT May go to Power Save mode or transmit in Infrastructure mode STMicroelectronics

When a Scheduled DLS is allowed Both DLS Initiator/Responder support per-flow buffering (in case of bi-directional flows) Just the DLS Initiator supports per-flow buffering (in case of unidirectional flows) STMicroelectronics

When an Unscheduled DLS is allowed Either the DLS Initiator or the DLS Receiver do not support per-flow buffering (in case of bi-directional flows) The DLS Initiator does not support per-flow buffering (in case of unidirectional flows) STMicroelectronics

Backup slides STMicroelectronics

Multi-channel Support FlexWiFi scheduled DLS proposal can be easily extended to support a multichannel communication The scheduled DLS communication can be performed over a different PHY channel established during the negotiation phase DLS initiator and receiver must communicate to the AP their intention to go in power save before starting a DLS scheduled communication STMicroelectronics

Multichannel Support (cont.) DL_SI MIXED_SI STA1 TXOP1 EOSP = 1 STA2 TXOP1 STA1 communicates to the AP that is going in power saving. Then switch channel Switch to infrastructure channel STA1 may communicate to the AP that is powered on and that can receive frames TBTT STMicroelectronics

How to perform scanning (informative) A ‘FlexWiFi Capable’ station can always send a DLS_trd frame to its DLS peer in order to suspend a Scheduled DLS session. A packet with the PS flag set will be also sent to the AP to suspend transmissions in infrastructure mode. This approach can be suitable to perform operations like scanning for link quality or other available channels Temporary tear down operations should be avoided with Unscheduled DLS since the transmitter couldn’t be able to buffer data directed to the STA that is temporarily unavailable, thus causing: Packet losses in case the choice is to transmit in DL mode only (i.e. packets are dropped whenever the receiver is unavailable since in PS mode) Wrong packet sequencing at the receiver in case transmissions are relayed through the AP (i.e. there is no guarantee that buffered traffic from the AP is relayed before the new one from the peer STA) STMicroelectronics