Location Determination and Emergency Services support in IEEE 802.11

1
Location Determination and Emergency Services
support in IEEE 802.11

• Gabor Bajko
• ESW5 workshop
• October 22, 2008, Wien

2
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

3
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
• Its 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

4
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?

5
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?

6
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

7

• Questions?