1

Location Determination and Emergency Services support in IEEE 802.11

Gabor Bajko

ESW5 workshop

October 22, 2008, Wien

© 2008 Nokia

Location in 802.11• 802.11k:

– Defines a binary encoding for geo-location, re-using the encoding from RFC3825 and enhancing it with Azimuth information

– It does NOT specify how the geo-location coordinates, the resolution indicators or the azimuth values are determined

– Defines a mechanism which allows: - the download of AP location by the non-AP STA (where are you?)

- request a measurement for location determination of a STA by the AP (where am I relative to you?)

- with only geo-location format supported

- It does NOT specify any measurement methods

• 802.11v: – Adds support for civic location format– It does not define any encoding for civic location, it re-uses the binary encoding from RFC4776

– Adds presence functionality by defining a subscribe/notify like mechanism to notify non-AP STAs about location changes (similar to SIP Presence functionality)

– It adds the capability of reporting relative civic address (relative to the boundary of the CA), without details on what the reference point is

– No parts of this amendment have been approved yet by IEEE-SA

• 802.11u:

– The AP has a location capability indication in the beacon, which is set when the AP has its location configured

– A query/response mechanism which can be used in pre-association state to download the AP location

– Provides almost instantaneous location configuration, without requiring any credentials

© 2008 Nokia

Emergency Call support in IEEE 802.11u•Support for Unauthenticated Emergency Services

– Case1: ES only open network•Open SSID limited for ES usage

– Case2: Public credentials•Download credentials to authenticate then able to use the network for ES only

– It’s not a complete solution, needs a backend system which enforces the ES only usage

•Currently no regulation, it is done for the help of mankind

•Local Emergency DialStrings can be downloaded from the APs in pre-association state

•STAs can make LoST protocol queries in pre-association state to LoST servers

© 2008 Nokia

QoS requirements for a network to be identified as ES

•Currently, 802.11u requires that in order for a network to be identified as an ES network, the following conditions have to be met:– QoS is enabled on the air interface

– Network supports end-to-end QoS from non-AP STA to all APs within the network, all the way to PSAPs

•Are these requirements reasonable?

•Should a standard document impose at all such conditions, or should these be rather specified by the regulatory body in charge in the area where the AP is operated?

© 2008 Nokia

EAS support in 802.11•802.11u has Emergency Alert System support:

– a bit in the beacon indicating the existence of an alert, detectable at scanning phase

– Alert can be fetched without authenticating to the AP

– Uses CAP inside the .11 frames

•Challenges:– How to indicate the presence of a new EAS message?

– How would a re-associating STA know if the EAS message available at that AP is an old or new one, if there is one or many available?

– Does an EAS message have an “expiration time”?

© 2008 Nokia

IEEE 802.11 TGp•Supports Intelligent Transportation Systems (ITS)

applications. This includes (telematics) data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz.

•ES from vehicles to authority (eCALL blackbox)

•ES data exchange between vehicles for multiple purposes– E.g. pre-deploying airbags

– Not categorized yet, but It could be considered as a “Citizen to citizen type of EA message”

© 2008 Nokia

Questions?