Wireless Sidelink Protocol July 2002 WiSP Wireless Sidelink Protocol Wim Diepstraten Gerrit Hiddink Agere Systems

July 2002 WARP functionality The WARP protocol is a new mechanism in the draft standard. Its intent is to allow the Stations in Infrastructure mode an option to send frames to stations within the same BSS directly. Saving bandwidth by not going via the AP Dealing with remote stations in Power Save mode.

Existing WARP Consist of: July 2002 Existing WARP Consist of: The “Direct Communication Setup” procedure Registration procedure Location discovery procedure Direct negotiation procedure The “Status change notification” procedure The “Wake notify” procedure With 12 WARP Action Codes And various fields and elements This is considered much more complex than needed.

July 2002 WiSP Alternative The Wireless Sidelink Protocol (WiSP) is a much simpler alternative: It uses a “Wakeup Action” request and response frame in the “Wakeup” procedure. With 4 possible status codes And uses existing directed Probe request and response frames in the “location Discovery” procedure.

WiSP: “Wakeup Action” phase July 2002 WiSP: “Wakeup Action” phase QSTA-1 send “Wakeup Action” request frame to QSTA-2 AP will forward the request to QSTA-2 when it is in the same BSS. If QSTA-2 is in Power Save mode, then this will be done in the appropriate way by buffering the frame, and announce the pending traffic in the TIM, so that QSTA-2 can retrieve it as desired. Else: If QSTA-2 not in the BSS, then AP returns “Wakeup Action” response with status code “Not present” Else: If STA-2 is a legacy station, then AP returns “Wakeup Action” response with status code “incapable”. QSTA-2 upon the request will respond with a “Wakeup Action” response destined to QSTA-1, with a status “Succesfull” if it wants to engage in side traffic, and will stay awake for a minimum timeout period. If it does not want to engage in side traffic, then QSTA-2 will respond with status code “Denied”. The AP will forward this “Wakeup Action” response frame to QSTA-1 as appropriate.

WiSP: “Location discovery” phase July 2002 WiSP: “Location discovery” phase After QSTA-1 receives a response indicating “Succesfull” It can enter the “Location Discovery” phase, to find out whether the remote station is indeed in direct communication range. QSTA-1 will send a directed “Probe Request” frame to QSTA-2 at a rate determined by QSTA-1. QSTA-2 will respond with a directed “Probe Response” frame to QSTA-1 at the same rate at which it received the Probe Request. The Probe request and response frames do contain all the information needed by each station to understand each others capabilities. This allows the stations to decide whether it wants to continue using the side channel, and can determine the appropriate rate. QSTA-2 will if it was in Power Save mode, stay awake for a “no-activity” timeout period after every reception. QSTA-1 can assume that QSTA-2 is awake within such a timeout period, and send all data to QSTA-2 via the side channel. QSTA-1 can judge from the “Pwr Mgt” bit in the Frame Control word whether QSTA-2 is indeed in power save mode, and will return to sleep after the timeout period. Both sides can assume that both sides are awake during the timeout period. Stations maintain a cache with the side channel capabilities on a per destination basis.

July 2002 WiSP cont’d After the timeout period has elapsed, stations can use the “Wakeup Action” procedure to wakeup the remote station again. And can send data without having to go through the “Location discovery” procedure. The “Location discovery” procedure is in itself optional, as stations can directly start with sending data. The “no-activity” timeout period can be a MIB parameter, with a defined default.

July 2002 Evaluation The proposed procedure is simple and adequate, and uses a minimum of new frames. It is envisioned that the “WiSP” will only be used for high bandwidth bulk traffic. So Power Save sensitive applications may not want to use it. We believe that the described provisions are sufficient for side channel operation. Stations engaged in side link traffic, have to deal with changes in the link, that require rate changes, and they can even go out of range (while it is still in the same BSS). So those stations that do not receive an Ack on multiple retries, should conclude that the remote station is gone, so that it should direct all traffic destined to that station via the AP again. Stations roaming away to another BSS is an other possible situation, that can be dealt with using a similar algorithm. No additional status change mechanisms are felt needed, but can easily be included.

Possible enhancements July 2002 Possible enhancements AP’s can monitor the “Wakeup Action” response frames, and register that QSTA-1 and 2 are “Sidelink capable” It can send unsolicited “Wakeup Action” responses with status “Not Present” when it discovers that one of the stations has roamed away. Remote stations that do want to go back into sleep mode, can send a directed Data-null frame to the remote station to signal that the station goes back into sleep mode. Instead of the “Wake-up timeout”, the stations can use the “More” bit to keep the remote station awake during the desired time. This timeout period could however also be an extra field in the “Wakeup Action” request/response frames. While a zero could identify “No Power Save” mode.

July 2002 WiSP Conclusion WiSP is a simple yet adequate solution to allow stations to use Side channel in an infrastructure environment. And uses only one additional “Action request/Response” pair. With status codes “Succesfull”,”Not Present”, “Denied” It is much simpler than WARP. WiSP should be adopted to replace WARP.

Issues What enhancements are needed for security purposes? July 2002 Issues What enhancements are needed for security purposes? Some protocol may be needed to aid in the key distribution. Can we use the option to do sidelink traffic using the common BC/MC key? Do we need to add something in the Wakeup Action frame to signal this?

Straw-Polls In order to start drafting normative text for WiSP July 2002 Straw-Polls In order to start drafting normative text for WiSP StrawPoll Question: Who wants WiSP to replace WARP? Should WiSP be enhanced in any way?

July 2002 How to merge?