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

2. 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

3. Interoperability with existing infrastructure
DLS setup is part of the ‘e’ amendment of the 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

4. 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

5. 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

6. 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 can always occur
Power saving is supported only in Scheduled DLS mode.
Both modes are negotiated during a setup phase.
Support to multi-channel solutions
STMicroelectronics

7. 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
DLS setup transmissions can occur during a DL_SI only in case of Scheduled DLS; at any time in case of Unscheduled DLS.
DL_SI
MIXED_SI
DLS Setup/Tear Down
DLS and Infrastructure DATA transmission
TBTT
TBTT
STMicroelectronics

8. 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

9. 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

10. 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

11. 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.
Beacon Interval is an indication relative to the next beacon interval.
Note: this frame can be sent at any time during a beacon interval.
STMicroelectronics

12. DLS Setup
A DLS_Req frame must be sent during the DL_SI (at any time in case of Unscheduled DLS) 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 DLS_Timeout (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
ACK
QSTA - B
DLS_Resp
ACK
STMicroelectronics

13. 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

14. 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
The intention of the offset (at least for this single channel approach) is not to create a 'real scheduled access'. The idea is to allow a station to avoid DLS receptions in a certain period of the beacon interval because, for example, it wants to use that time for other operations like scanning. The presence of an offset also is in the direction of a further multiple-channel approach since that time can be used to allow a station to perform channel switching operations.
In this current proposal the TXOP is just an amount of time the DLS Initiator can use per beacon interval: it is not necessarily contiguous and the channel access is still contention-based. This approach allow the DLS Receiver to  either accept or reject DLS sessions based on the amount of time it wants to sleep per beacon interval (or based on any other policies) as well as to understand when it can go to sleep during a beacon interval
OFFSET2
TXOP2
STA3
TBTT
TBTT
May go to Power Save mode or transmit in Infrastructure mode
STMicroelectronics

15. 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

16. Backup slides
STMicroelectronics

17. Multi-channel Support
FlexWiFi scheduled DLS proposal can be easily extended to support a multi-channel 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

18. Multi-channel 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

19. 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