doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 1 Communications with a target AP prior to roaming. 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, 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. Date: Authors:

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 2 Abstract This presentation: Presents solution options for communications with a target AP prior to roaming. The options include “over the air” or “over the DS” communications Two alternatives for “over the DS” communications are presented. Addresses the protocol for (pre-)allocation of resources (QoS, Security, future requirements, etc.)

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 3 Solution Requirements A STA needs some assurance that resources at the target AP are available prior to roaming. The STA needs to communicate with the target AP to query or reserve resources. The communications between the STA and the target AP can either take place “over the air”, or “over the DS” through its current AP. For the purpose of presentation, the query or (pre-) allocation is transported using a “Resource Request” frame.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 4 Solution Description A roaming-enabled AP will advertise whether it accepts “over-the-air” or “over-the-DS” requests The STA will use the method advertised by the AP for communications.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 5 “Over the Air” Pros: –The STA can use this method with any AP it can “see” –The STA can obtain RF link measurements with the target AP at the same time it is requesting resource availability. However fluctuations in link measurements still require updated measurements prior to transition –“Over the DS” reachability issues are avoided –Pre-allocation policy is enforced physically by transmission range Cons: –Could require significant time “off channel” Off-air time increases with each roaming candidate AP Could cause jitter or packet loss if “off-channel” time is significant More off-channel time requires more battery power –Need to determine how to address security “over the air”

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 6 “Over the DS” Pros: –The STA does not have to go off-channel –The STA can use its existing security relationship –Don’t need a “come back later” response –Can use power-efficient traffic delivery method (APSD) –Reduced air time at the target AP Cons: –Reachability – can the target AP be reached over the DS from the current AP? –The STA still needs to go off-channel to determine RF characteristics of the target AP –Need policy enforcement to limit the number of outstanding pre- allocations –Increased air time at the current AP

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 7 Solution Components Capabilities Advertisement Definition of a Mobility Domain “Over the Air” mechanism Alternative “Over the Wire” mechanisms –Direct Method –Broker Method

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 8 Capabilities Advertisement The AP will advertise its reservation/query capabilities in its Beacon, Probe, Association, and Re-association Response messages. Un-protected pre-allocation of resources is not allowed The pre-allocation capabilities are advertised using capabilities bits: –Resources allocation/pre-allocation are always supported “over the air” –Reservation - “Over the DS” capability – yes or no –Query - “Over the DS” capability – yes or no The capabilities could be advertised in a Roaming IE

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 9 Mobility Domain Definition The mobility domain defines the bounds for roaming for a Mobile Unit (Mobile Station) The mobility domain is advertised by the AP in the Beacon and Probe Response messages All APs in the mobility domain must be reachable “over the DS” The Mobility Domain Identifier format is TBD –For example, it could be the Key Circle ID or the NAS ID The Mobility Domain Identifier is advertised in the Roaming IE, or somewhere else.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 10 “Over the air” Communications Features/Requirements –The STA needs to be in RF range of the target AP –The STA should go into power-save mode when it goes off- channel to communicate with the target AP –The time that a STA remains off-channel should be minimized.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 11 “Over the Air” Communications Steps required by STA 1.STA ensures AP knows it’s in power save mode 2.STA switches to target AP’s channel, waits for CCA and backoff, sends resource request/reservation 3.STA waits for AP response (could be “come back later”) 4.STA switches back to serving channel and either waits for next Beacon to discover buffered frames, issues PS-Poll or APSD trigger 5.If target AP issued “come back later” response, steps 1 through 4 are repeated at a later time The STA would synchronize its off-channel time with periodic traffic (VoIP, e.g.) to avoid dropped frames or excessive latency

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 12 “Over the DS” Communications Features/Requirements –A STA can communicate “over the DS” to any AP that advertises the same “mobility domain” and the AP advertises “over the DS” capability. –Could use a new Ethertype to identify the Resource Request. –An Action Frame type could be used as an alternative to a Data Frame if management frames were protected –Define a new SAP, which is part of the AP SME, to terminate Resource Request communications –This document presents two alternatives for “over the DS” communications: direct method and broker method.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 13 Direct Method The STA generates a Data Frame with the Resource Request information directed to the BSSID of the Target AP. Data Frame is bridged to the DS by the Current AP The Data Frame is received by the Resource Request SAP at the Target AP. The Target AP builds the response and directs it back to the STA over the DS.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 14 Direct Method for “Over the DS”

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 15 Broker Method The STA generates a Resource Request Data Frame directed to its current AP (could be an Action Frame) The STA provides the BSSID of the target AP. The Resource Request SAP transmits the request to the target AP. The Broker would enforce pre-allocation/query policy A Local Policy Server (a logical entity) could be used to broker the request. Transport mechanism between Resource Request SAP’s could be L2 or L3 and would be documented as a recommended practice. Broker Method could be extended to support a list of BSSID’s.

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 16 Broker Method for “Over the DS”

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 17 Questions? Comments?

doc.: IEEE /0201r0 Submission March 2005 Michael Montemurro and Matt SmithSlide 18 References TAP (Transition Acceleration Proposal) 11-04/1542r0 Just-in-time 2 Phase Association 11-04/1486r0