Path Selection and Path Switch Mechanism Date: 2007-11-13 Name Compay Address Phone E-mail Jiyoung Huh LG Electronics jyhuh@lge.com 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>. Jiyoung et al.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.