AP Location Capability

Slides:



Advertisements
Similar presentations
Doc.: IEEE /1672 STA Provided Location November 2006 Donghee Shim, et alSlide 1 STA Provided Location Notice: This document has been prepared.
Advertisements

Doc.: IEEE /0041r1 AP Location Capability January 2007 Donghee Shim et alSlide 1 AP Location Capability Notice: This document has been prepared.
FBMS Termination Date: Name Compay Address Phone
Beacon Measurement on Pilot Frames
LB84 General AdHoc Group Sept. Closing TGn Motions
LB84 General AdHoc Group Sept. Closing TGn Motions
[ Interim Meetings 2006] Date: Authors: July 2005
Emergency Call number support
London TGu Motions Authors: January 2007 Date: Month Year
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
TGp Closing Report Date: Authors: July 2007 Month Year
Attendance and Documentation for the March 2007 Plenary
Miscellaneous Updates
Motion to accept Draft p 2.0
Protected SSIDs Date: Authors: March 2005 March 2005
Descriptive Language Usage in TGv
JTC1 Ad Hoc Closing Report
TGp Motions Date: Authors: November 2005 Month Year
TGp Closing Report Date: Authors: March 2006 Month Year
Emergency Call Motion Date: Authors: January 2006
TGp Closing Report Date: Authors: May 2007 Month Year
Protection Assurance Method
CID 186, 206 and 211 resolution Date: Authors: January 2007
JTC1 Ad Hoc Mid-week Report
TGp Closing Report Date: Authors: March 2006 Month Year
Reflector Tutorial Date: Authors: July 2006 Month Year
CID#102 - Channel Allocation for P2P
TGv Redline D0.07 Insert and Deletion
TGv Redline D0.06 Insert and Deletion
IMS Emergency Call Requirements & Emergency Call number support
ADS Study Group Mid-week Report
Proposal for Diagnostics
IEEE P Wireless RANs Date:
Protection Assurance Method
TGu-changes-from-d0-01-to-d0-02
LB73 Noise and Location Categories
Extended Channel Switch Announcements
TGy draft 2.0 with changebars from draft 1.0
TGv Redline D1.04-D1.0 Insert and Deletion
TGv Redline D0.10 Insert and Deletion
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Redline of draft P802.11w D2.2 Date: Authors:
Document Motions Date: Authors: November 2005 November 2005
TGr Proposed Draft Revision Notice
Off-channel selection
TGu-changes-from-d0-02-to-d0-03
Proposed changes to the v Draft
TGu Motions Date: Authors: May 2006 May 2006
Beamforming and Link Adaptation Motions
Path Selection and Path Switch Mechanism
CID 186, 206 and 211 resolution Date: Authors: January 2007
STA Location for emergency call support in SSPN interface
Motion to go to Letter Ballot
EC Motions – July 2005 Plenary
Location Capability Negotiation
Suggested comment resolution on ATIM window parameter
Transition Nowhere Date: Authors: Sept 2005 Sept 2005
TGu-changes-from-d0-03-to-d0-04
TGu Motions Date: Authors: May 2006 May 2006
Non-AP STA Location Capability
IMS Emergency Call Requirements & Emergency Call number support
Reserve Option Contradiction
Extended Channel Switch Announcements
Proposal for Event Log Authors: Date: March 2006 Month Year
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
E911 Bits Date: Authors: May 2007 Month Year
Location Presentation
TGp Motions Date: Authors: January 2006 Month Year
Presentation transcript:

AP Location Capability Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 AP Location Capability Authors: Date: 2006-01-13 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>. Donghee Shim et al John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2007 Abstract This presentation provides a proposal on AP location capability and a recommended normative texts No change on currently defined architectures and frames for location services support is required. No specific location determination mechanism is defined or required. At the end of the presentation, there will be a motion to include proposed normative text in the 11v draft. Donghee Shim et al John Doe, Some Company

Current Location Proposal January 2007 Current Location Proposal Presence Configuration Procedure Periodic exchange of frames for the purpose of collecting the necessary data to determine location by setting Presence Parameter information in Beacon, Probe Response or Presence Configuration Request A STA periodically transmits Presence Request frame AP collects data to position the STA Establishing a location service that periodically provides location estimation by setting Presence Parameter information in Beacon, Probe Response or Presence Configuration Request (1) AP periodically transmits Presence Response frame to provide location data to the STA Presence Request Procedure Advertise STA its Presence Request STA its own location to the AP Request AP location Provide data to AP for the purpose of locating the STA Presence Response Procedure The Presence Response frame, Beacon and Probe Response frames provide presence reporting parameters to the STA by AP A Presence Response frame may be sent to provide location information to a STA or exchange frames for location calculating purposes Donghee Shim et al

Current Location Proposal – cont’ January 2007 Current Location Proposal – cont’ Current normative texts in 802.11v draft, following can be found An AP may configure the presence facility by either including a Presence Parameters information element in a Beacon or Probe Response, or by including a Presence Parameters information element in a Presence Configuration Request frame. An AP wishing to configure another peer STA to periodically transmit Presence Request frames for the purpose of collecting data to locate the client may do so by sending a Presence Parameters information element to the peer in a Beacon, Probe Response or Presence Configuration Request frame. The Presence Parameters information element shall contain the Presence Indication Parameters and Presence Indication Channels fields describing the desired behavior. An AP wishing to configure another peer STA to periodically transmit Presence Response frames for the purpose providing location data may do so by sending a Presence Parameters information element to the peer in a Beacon, Probe Response or Presence Configuration Request frame. The Presence Parameters information element shall contain a Location Service Information sub-element describing the desired behavior. If the frame used to initiate service is a unicast Presence Configuration Request frame then the peer STA shall respond with a Presence Configuration Request frame that includes a Presence Status sub-element indicating whether the request is successful. The requesting STA may use the State field in the Location Service Information element to start or stop the service Based on the texts following can be deduced, Current presence framework, the AP sends Presence Parameters in the Presence Request, Presence Response, Beacon and Probe Response when it initiates the Presence related procedures Donghee Shim et al

Current Location Proposal – cont’ January 2007 Current Location Proposal – cont’ It is clearly stated that in the current 802.11v draft as “The order of precedence for the various presence configuration methods is as follows: 1) a unicast Presence Configuration Request frame, 2) broadcast Presence Configuration Request frame, and 3) Beacon and Probe Response. When a STA receives a new presence configuration at a higher precedence than the previous it shall cancel the previous configuration and begin using the new one” Currently only Beacon and Probe Response frames have the Location Descriptor in the Presence Parameters However, the Presence Configuration Request frame take precedence over Beacon and Probe Response frames Also, from the beginning, the Presence Configuration Request to set-up location services and seems to be the right place to announce the location capability of the STA Donghee Shim et al

January 2007 Thoughts Current presence framework provides the mechanism to configure the STA to periodically transmit Presence Request or Response frames for the purpose of collecting data to locate the client or for the purpose providing location data. However, current mechanism only allows AP to include Location Descriptor in the Presence Parameters to invoke Presence related procedures So, the Location Descriptor in the Presence Parameters would be allowed to be sent to announce AP’s capability to the STAs even if there is no presence related procedures to be invoked In other words, AP should be allowed to send its location capability even if there is no specific location related requests to be sent to the STA Since Presence Configuration Request frame takes precedence over Beacon and Probe Response frames, then Location Descriptor would be added into the Presence Configuration Request to indicate the location capability of the AP Donghee Shim et al

AP Location Capability Proposal January 2007 AP Location Capability Proposal Following texts are proposed to be added in the 11v draft to allow AP to send its location capability to the STAs in the Presence Request procedures and Presence Configuration procedures, respectively The AP that supports presence capability may send an Beacon or Presence Response to provide its own location capability. The AP shall include a Location Descriptor field in Presence Parameters information element in an Beacon, Presence Response or Presence Configuration Request frame to provide its location capability. The location description value of 2 “CIVIC Preferred” or 3 “GEO Preferred” indicates that the AP is capable of supporting both CIVIC and GEO formats, but prefers the indicated format. The AP shall indicate the location resolution it can support with location resolution descriptor element. The AP that supports presence capability may send Presence Configuration Request frame to provide its own location capability. The AP shall include a Location Descriptor field in an Presence Configuration Request frame to provide its location capability. The location description value of 2 “CIVIC Preferred” or 3 “GEO Preferred” indicates that the AP is capable of supporting both CIVIC and GEO formats, but prefers the indicated format. The AP shall indicate the location resolution it can support with location resolution descriptor element. (This kind of texts are also proposed for Non-AP STA location capability contribution, so we can say just ‘The STA’ instead of ‘The AP’) Donghee Shim et al

AP Location Capability in Presence Configuration Request January 2007 AP Location Capability in Presence Configuration Request STA can indicate its location capability AP STA Presence Configuration Request (…, Location Descriptor, …) AP location capabilities can be included in Location Descriptor field in the Presence Configuration Request frame Donghee Shim et al

Location Descriptor January 2007 CIVIC 1 GEO 2 CIVIC Preferred 3 Identifier Field Name CIVIC 1 GEO 2 CIVIC Preferred 3 GEO Preferred 4 Not Supported 5 Vendor Specific 6 - 15 Reserved Donghee Shim et al

Proposal : AP Location Capability January 2007 Proposal : AP Location Capability Location Capability of AP Proposes a normative text to allow AP to send its location capabilities to the STAs with Location Descriptor element in Beacon, Probe Response or Presence Configuration Request frame Proposes to put the normative text in the proposal 11-07-xxxx-00-000v-normative-text-ap-location-capability based on the proposal in this presentation Donghee Shim et al

January 2007 Motion Move to include normative text in document 11-07-xxxx-00-000v-ap-location-capability changes to the 802.11v into the TGv draft. Mover: Seconder: Donghee Shim et al