1. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 Jiyoung et al. Path Selection and Path Switch Mechanism 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2007-11-13 NameCompayAddressPhoneE-mail Jiyoung HuhLG Electronicsjyhuh@lge.com Yongho SeokLG Electronicsyhseok@lge.com

2. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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.

3. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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 AP STA1STA2 Link ① ② ③ ④ ⑤ ⑥ Two parts are defined for the path selection in TDLS –Radio Measurement (Link RCPI Request/Report) –Path Switch Mechanism

4. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 Jiyoung et al. Link RCPI Request/Report Link RCPI RequestLink RCPI Report BSSID STA Address Octets66 BSSIDRCPI1 STA Address RCPI2 Octets6161 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. AP STA1STA2 Link ① ③ ⑤

5. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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 STA1STA2 Link RCPI Request Periodically? Randomly? After receiving several NAKs?

6. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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

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

8. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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.

9. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 Jiyoung et al. Tx Path Switch Request/Response AP STA1STA2 ① ③⑤ ① : Direct Link ③ + ⑤ : AP-Path RCPI1: RCPI of ⑤ RCPI2: RCPI of ① RCPI3: RCPI of ③ Tx Path Switch Response RCPI2 (Optional) RCPI1 (Optional) ResultPath Dialog Token Link Identifier Tx Path Switch Response Reserved ~3 Reject because of Link ① / ⑤ state 2 Accept0 Reject because of entering power save mode1 ExplanationResult Tx Path Switch Request RCPI3 (Optional) ReasonPath Dialog Token Link Identifier Tx Path Switch Request The state of Link ③ is very good 2 Reserved3~ The state of Link ③ is very terrible 1 Request for stopping the PS mode0 ExplanationReason

10. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 Jiyoung et al. Rx Path Switch Request/Response AP STA1STA2 ① ③⑤ ① : Direct Link ③ + ⑤ : AP-Path RCPI1: RCPI of ⑤ RCPI2: RCPI of ① RCPI3: RCPI of ③ RCPI2 (Optional) RCPI1 (Optional) ReasonPath Dialog Token Link Identifier Rx Path Switch Request Reserved ~3 The state of Link ⑤ is better than ① ’s 2 Request for entering the PS mode0 The state of Link ① is better than ⑤ ’s 1 ExplanationReason Rx Path Switch Request RCPI3 (Optional) ResultPath Dialog Token Link Identifier Rx Path Switch Response Reserved2 ~ Accept0 Reject because of Link ③ state 1 ExplanationResult Rx Path Switch Response

11. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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.

12. doc.: IEEE 802.11-07/2797r00 Submission Oct 2007 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: