1. Path Selection and Path Switch Mechanism
Date:
Name
Compay
Address
Phone
Jiyoung Huh
LG Electronics
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
Jiyoung et al.

2. Abstract
The direct link assumes that STAs using direct link can use one of AP-Path and DL-Path and the path switch is caused by the link state (e.g., Link RCPI), or PSM.
This proposal combines the Link RCPI Request/Report and the Path Switch Request/Response in order to resolve the limitation of the Link RCPI Request/Report and make the Path Selection and Switch more efficient.
The direct link assumes that STAs using direct link can use one of AP-Path and DL-Path and the path switch can be caused by the link state, PSM, or something like that.
This proposal points out the problem of Link RCPI Request/Report defined in TDLS and suggests to combine the path switch mechanism defined in TDLS with the function of Link RCPI Request/Report in order to resolve the problem of the Link RCPI Request/Report and make the Path Selection and Switch more efficient.
Jiyoung et al.

3. Path Selection and Switch Mechanism
The Path Selection & Switch Mechanism is required for the following:
Entering a power save state
Using the better one of the two paths (i.e, AP-Path or Direct Link)
The better path is decided based on the quality of the following links
AP-Path Link = Sending STA to AP (a) + AP to Receiving STA (b)
Direct Link = Sending STA to Receiving STA (c)
※ Each Link state can be known to ending STA of the links
Two parts are defined for the path selection in TDLS
Radio Measurement (Link RCPI Request/Report)
Path Switch Mechanism AP
STA1
STA2
Link ① ② ③ ④ ⑤ ⑥
Jiyoung et al.

4. Link RCPI Request/Report
Link RCPI Report
BSSID
STA Address
Octets 6
BSSID
RCPI1
STA Address
RCPI2
Octets 6 1
A STA may transmit a Link RCPI Measurement Request to an (intended) peer STA to obtain an indication of the RCPI values at the peer STA. The Link RCPI measurement request and report are sent to the peer STA directly. The RCPI information may be used to decide whether to switch over to a direct link for communication with the peer STA.
Jiyoung et al.

5. Concern about Link RCPI Request/Report
When should STA send the Link RCPI Request?
The link status changes frequently and randomly.
The requesting STA (STA1) never know when the link status changes.
The only requested STA (STA2) can always know the link status changes AP
STA1
STA2
Link RCPI Request
Periodically?
Randomly?
After receiving several NAKs?
Jiyoung et al.

6. Path Switch Mechanism (Cont.)
Four frames are defined to request path switch and respond to the request in Rx and Tx side and have Link Identifier, Dialog Token, and Path information
Tx Path Switch Request/Response
A sending STA sends request to peer STA to switch to Direct Link
The peer STA SHALL enable the direct link and respond to the request by sending response frame
Rx Path Switch Request/Response
A receiving STA sends request to switch to DL or AP path
The Peer STA SHALL use the AP-Path if the request indicates a switch to AP-Path.
The Peer STA can use the DL or not if the request indicates a switch to DL
Jiyoung et al.

7. Concern about Path Switch Mechanism
The Path Switch Request/Response frame cannot indicate why the path switch is requested and whether the request is acceptable or not AP
STA1
STA2 ① ③ ② ④ ⑤ ⑥
①: Direct Link
③+⑤: AP-Path
There may be several reasons for the request
Tx Path Switch Response ?
Rx Path Switch Response
Tx Path Switch Request
Rx Path Switch Request
There may be several reasons that cannot accept the request
Jiyoung et al.

8. Suggestion
A STA that can know the link state requests the path switch including the information such as the reason for the request and, if necessary, link state.
The STA receiving the request can decide whether the link should be changed or not based on the information included in the request and itself.
Jiyoung et al.

9. Tx Path Switch Request/Response① ③ ② ④ ⑤ ⑥
①: Direct Link
③+⑤: AP-Path
RCPI1: RCPI of ⑤
RCPI2: RCPI of ①
RCPI3: RCPI of ③ AP
STA1
STA2
Tx Path Switch Request
RCPI3 (Optional)
Reason
Path
Dialog Token
Link Identifier
The state of Link ③ is very good 2
Reserved 3~
The state of Link ③ is very terrible 1
Request for stopping the PS mode
Explanation
Tx Path Switch Response
RCPI2 (Optional)
RCPI1 (Optional)
Result
Path
Dialog Token
Link Identifier
Reserved ~ 3
Reject because of Link ①/⑤ state 2
Accept
Reject because of entering power save mode 1
Explanation
Jiyoung et al.

10. Rx Path Switch Request/Response① ③ ② ④ ⑤ ⑥
①: Direct Link
③+⑤: AP-Path
RCPI1: RCPI of ⑤
RCPI2: RCPI of ①
RCPI3: RCPI of ③ AP
STA1
STA2
RCPI2 (Optional)
RCPI1 (Optional)
Reason
Path
Dialog Token
Link Identifier
Rx Path Switch Request
Reserved ~ 3
The state of Link ⑤ is better than ①’s 2
Request for entering the PS mode
The state of Link ① is better than ⑤’s 1
Explanation
Result
RCPI3 (Optional)
Result
Path
Dialog Token
Link Identifier
Rx Path Switch Response
Reserved
2 ~
Accept
Reject because of Link ③ state 1
Explanation
Reason
Jiyoung et al.

11. Conclusion
Link RCPI Request/Report is suggested for the best path selection, but sometimes unnecessary or overhead.
If Path Switch Request/Response frame includes the link state information instead of Link RCPI Request/Report, unnecessary Link RCPI request/report is not sent and the best path selection is performed more efficiently.
Jiyoung et al.

12. Straw Poll
Do you think that suggested path switch request/response can make the path selection and switch more efficient?
Yes:
No:
I don’t know:
Jiyoung et al.