1 3rd emergency services workshop, brussels, 2007 tutorial on location and emergency services...

1 3rd Emergency Services Workshop, Brussels, 2007

Tutorial onLocation and Emergency Services

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 <[email protected]> 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 <[email protected]>.

Date: 2008-09-10

Name Company Address Phone email Gabor Bajko Nokia Mountain

View, CA +1 972 894 5000

[email protected]

Author:


Tutorial onLocation and Emergency Services

Gabor Bajko, IEEE meeting, Hawaii 2008

some of the slides from:Hannes Tschofenig


Authority to Citizen

• Example: Cell broadcast for Tsunami warning

Authority to Authority

• Example: Communication between emergency personnel

Citizen to Authority

Emergency Services Categories

Note that some SDOs use the term “individuals” instead of “citizen”.


LocationEmergency

Call

Determine correct PSAP

IdentifyEmergencyCalls

Building Blocks for Citizen to Authority type of Emergency Calls


How is location information encoded?

• Two formats exist for location information encoding:▪ Binary Format

▪ XML-based Format

• For bandwidth constraint environments a functionality-reduced binary encoding is used (e.g., link layer protocols or DHCP) and for application protocols the XML encoding is used.

• The XML encoding is based on the Presence Information Data Format (PIDF) for Location Objects (LO) as defined in the Geopriv Working Group of IETF (simply PIDF-LO)

• PIDF-LO uses the Geography Markup Language (GML) developed by OGC for describing geodetic information.


Location Determination

Very limited scope or unused: •TDOA (cellular networks)•LLDP•DHCP•HELD (http-based)•Applic. using PIDF-LO, etc.What is really used (especially in mobile devices): GPS

– Requires GPS signal from at least 4 satellites (at least 3 in case of A-GPS)– 3rd dimension (altitude) calculation is difficult and inaccurate. Consumer GPS

devices only work with longitude/latitude– Extremely slow: takes 2 min or more to calculate the coordinates – DOES NOT WORK INDOOR

▪ This is why GPS will not monopolize the location determination

There is a tendency for having almost-full indoor coverage using low range network boxes (802.11 AP, 3G femto-cells, etc.)• Boxes/APs have a fixed location• Devices ‘seeing’ them are in their proximity (limited coverage)• Make use of the boxes’ location


Location in IEEE

LLDP developed in 802.1AB• Suitable mainly for wired environment

802.11k: Location Measurements• Download of AP location by the non-AP STA (where are you?)• Measurement of location accuracy (where am I relative to you?)• It does not specify how the measurements are done

802.11v: Presence• Extends 802.11k with Presence functionality• Subscribe/notify mechanism to notify non-AP STA about location changes

(duplicates the SIP Presence functionality)• 3rd LB failed

802.11u: download AP location without association and/or authentication to the AP•AP location capability indication in the beacon•If bit set to 1, non-AP STA can request the location of the AP without association/authentication•Provides almost instantaneous location configuration


Location in IETF (RFCs)

RFC3825: DHCP Option for Geodetic location– Features altitude specification in both ‘above sea level’ and floor #– The binary encoding used in the RFC is copy pasted to 802.11k as Location

Configuration Information Report element (extended to include azimuth information)

RFC4776: DHCP Option for Civic Location– Defines Civic Address types (CAtype)– There is no equivalent binary encoding available in 802.11– Question: should there be one??

RFC4119 ( partially revised by RFC5139): extension of PIDF to carry location (PIDF-LO)

– XML- based– Focuses too much on privacy while in many cases location is an application

enabler, rarely is exchanged between clients and thus orthogonal to privacy▪ The ‘usage rules’ element is mandatory▪ When APs make their location available to anyone unconditionally, privacy is not

relevant– Geodetic location: It imports a GML schema, where altitude is a geodetic

variable, means ‘above sea level’


Binary Encoding of Location in 802.11k


XML encoding of location: PIDF-LO (RFC 4119)

• Presence Information Data Format (PIDF) is an XML-based format for presence (RFC 3863)

• PIDF document contains identity information (as part of the entity attribute).

• Extends PIDF to accommodate new elements:– <location-info> Element

▪ Encapsulates location information▪ GML 3.0 <feature.xsd> schema (mandatory-to-implement)▪ Supports civic location format (optional-to-implement)

– <usage-rules> Element▪ Used to indicate privacy preferences

– <method> Element▪ Describes the way location information was derived or discovered. ▪ Example: <method>gps</method>▪ Registry available at: http://www.iana.org/assignments/method-tokens

– <provided-by> Element▪ Entity or organization that supplied this location information


Example: PIDF-LO with geodetic information <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:[email protected]"> <dm:device id="mikepc"> <status> <gp:geopriv> <gp:location-info> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>-43.5723 153.21760</gml:pos> </gml:Point> </gp:location-info> <method>802.11</method> <provided-by>www.example.com</provided-by> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry> <ruleset-reference>https://www.example.com/myrules</ruleset-reference> <note-well>These are my privacy rules</note-well> <gp:usage-rules/> </gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> </dm:device> </presence>


Example: PIDF-LO with civic information <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml“ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:[email protected]"> <dm:device id="mikepc"> <status> <gp:geopriv> <gp:location-info>

<cl:civicAddress> <cl:country>US</cl:country> <cl:A1>New York</cl:A1> <cl:A3>New York</cl:A3> <cl:A6>Broadway</cl:A6> <cl:HNO>123</cl:HNO> <cl:LOC>Suite 75</cl:LOC> <cl:PC>10027-0401</cl:PC> </cl:civicAddress> </gp:location-info> <gp:usage-rules/>

</gp:geopriv> </status> <timestamp>2007-06-22T20:57:29Z</timestamp> <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> </dm:device> </presence>


What civic information can I express?

• Initially civic location was specified for DHCP in RFC 4776* (http://www.ietf.org/rfc/rfc4776.txt)

• This format is a binary format.

• With RFC 4119* (PIDF-LO) for some of the RFC 4776 civic elements an XML encoding was specified.

*: Note that the content of RFC 4776 was developed before the work on PIDF-LO (RFC 4119). It was, however, faster to finish the standardizationwork on PIDF-LO.


RFC 4119 Civic Location Information - I

Label Description Example

country The country is identified by the two-letter ISO 3166 code

US

A1 national subdivisions (state, region, province, prefecture)

New York

A2 county, parish, gun (JP), district (IN) King's County

A3 city, township, shi (JP) New York

A4 city division, borough, city district, ward, chou (JP)

Manhattan

A5 Neighbourhood, block Morningside Heights

A6 Street Broadway

PRD Leading street direction N, W

POD Trailing street suffix SW


RFC 4119 Civic Location Information –II (contd.)

Label Description Example

STS Street suffix Avenue, platz, Street

HNO House number, numeric part only 123

HNS House number suffix A, ½

LMK Landmark or vanity address Low Library

LOC Additional location information Room 543

FLR Floor 5

NAM Name (residence, business or office occupant )

Joe’s Barbershop

PC Postal code 10027-0401


Constantly providing a Target with it’s current location is not efficient. What can I do?

Solution: Location by Reference (LbyR) Concept

Instead of retrieving location information per value a reference is obtained. This reference can be resolved to a location object several times and provides up-to-date location information. Access control can also be enforced.

The reference plays the role of an generalized identifier.


Architecture

SIP, HTTP, etc.

+ Location Reference Location Recipient

Location Reference

End Host

Location Information Server

Request

Location ReferenceLocation Information

Examples of a Location Reference

• sips:[email protected]

• https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o


Determine Location

Emergency Call



Building Blocks


Identifying an Emergency Call

Emergency NumbersSee http://www.sccfd.org/travel.html


Emergency numbers vary in countries

• Example: 911 for North America, 112 for Europe

• some countries use separate numbers for ambulance/police/fire; others don’t

Required to support both home and visited emergency number

• e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency

Configuration of emergency numbers and dial strings important

• Home Emergency Number: User can learn this number through LoST or device configuration

http://tools.ietf.org/html/draft-ietf-sipping-config-framework

• Visited Emergency Number: Obtained dynamically via LoST

Emergency Numbers


Identifying an Emergency Call

• Emergency numbers are entered into the user interface

• On the protocol level an emergency number independent scheme used to mark a call as an emergency call. Service URNs

• Why?– To mark call as emergency call and thereby to request special call

handling

– For Mapping Protocol: To resolve to PSAP URI

• Service URN registry established in RFC5031

• Example: urn:service:sos; urn:service:sos.ambulance, urn:service:sos.police, etc.


Determine Location

Emergency Call



Building Blocks


Service URN

Location Information

How to find the closest PSAP?

+

(PSAP) URI

Service URN

Service Boundary

+

+

Emergency Number

+

Location-to-Service Translation (LoST) is a simple XML-based query and response protocol running on top of HTTP.


Features

•Protocol specification available in http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ •Satisfies the requirements for mapping protocols:

– http://tools.ietf.org/html/draft-ietf-ecrit-requirements• Supports extensible location profiles. Currently 2 profiles are available:

– geodetic-2d (offers Point, Polygon, Circle, Ellipse, ArcBand) and civic (based on http://tools.ietf.org/html/draft-ietf-geopriv-revised-civic-lo )

• Provides civic address validation– Returns XML tag names of components (classified into <valid>, <invalid> and

<unchecked>)• Offers recursive and iterative query resolution• Returns PSAP URI, emergency dial string, service boundary information and supplementary information• Service boundary may be returned via reference or by value.• Functionality for listing services and listing services per location. • LoST server discovery procedure

– via DNS (defined in http://tools.ietf.org/html/draft-ietf-ecrit-lost )– Via DHCP (defined in http://tools.ietf.org/html/draft-ietf-ecrit-dhc-lost-discovery)


LoST Example<findService> Query with geodetic location info

<?xml version="1.0" encoding="UTF-8"?><findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value" recursive="true">

<location id="6020688f1ce1896d" profile="geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> </location> <service>urn:service:sos.police</service>

</findService>


LoST Example<findService> Response<?xml version="1.0" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="geodetic-2d"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> … <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:[email protected]</uri> <uri>xmpp:[email protected]</uri> <serviceNumber>911</serviceNumber> </mapping> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="6020688f1ce1896d"/> </findServiceResponse>


Example:listServices and listServicesResponse<?xml version="1.0" encoding="UTF-8"?><listServices xmlns="urn:ietf:params:xml:ns:lost1"> <service>urn:service:sos</service></listServices>

<?xml version="1.0" encoding="UTF-8"?> <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> <serviceList> urn:service:sos.ambulance urn:service:sos.animal-control urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.marine urn:service:sos.physician urn:service:sos.poison urn:service:sos.police urn:service:sos.suicide </serviceList></listServicesResponse>

Request

Response

<listServicesByLocation> is a variation of <listServices> that includes location in the query.


Determine Location

Emergency Call



Building Blocks

The emergency call itself is shown in the context of the architecture. It makes use of the Service URN and SIP Location Conveyancehttp://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/ as protocol mechanisms.


How do I carry location information or references between the Target/Proxy and an Location Recipient/Application Server?

• The GEOPRIV WG calls this a using protocol.• SIP is such a using protocol relevant in this context, as defined in

http://tools.ietf.org/html/draft-ietf-sip-location-conveyance• Defines the Geolocation header:

– Points to location per value (using a cid:) or contains a reference (e.g., sips:)• Geolocation header may contain additional parameters:

– inserted-by parameter: Indicates which entry added location to the message ("endpoint" or "server“)

– used-for-routing parameter: Used when location was used for routing– recipient parameter: Indicates intended recipient ("endpoint“, "routing-entity“ or "both“)

• New geolocation option tag: To indicate support for the this extension by UAs in Require, Supported and Unsupported headers (RFC 3261)

• New error message (424 Bad Location Information) – Contains addition error value – Node identification of the entity that experienced the location-based error– Human readable error text pre-defined in the draft

• Defines sip/sips/pres as a dereference scheme


Alice

Example: SIP Invite with Location by Value (1)Bob

Example shows location added by value. cid: points to location in the body.

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9Max-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>; tag=1928301774Call-ID: [email protected] Geolocation: cid:[email protected];[email protected];

recipient=endpoint Supported: geolocation CSeq: 314159 INVITEContact: <sip:[email protected]>Accept: application/sdp, application/pidf-xmlContent-Type: multipart/mixed; boundary=0a0Content-Length: 543

INVITE

geolocation (if as a message body)

sdp


--0a0Content-Type: application/pidf+xmlContent-ID: cid:[email protected] ….. <gml:location> <gml:coordinates>36.132N 115.151W </gml:coordinates> </gml:location> ….. <method>802.11</method> <provided-by>www.example.com</provided-by/> …..--0a0--

Alice

Example: SIP Invite with Location by Value (2)

Bob

INVITE

XML fragment of multipart MIME body

Example geodetic location


Alice

Example: SIP Invite with Location by Value (3)

Bob

INVITE

--0a0Content-Type: application/pidf+xmlContent-ID: cid:[email protected]

... <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>US</cl:country> <cl:A1>Nevada</cl:A1> <cl:A3>Las Vegas</cl:A3> <cl:HNO>399</cl:HNO> <cl:A6>Convention Center</cl:A6> <cl:STS>Drive</cl:STS> <cl:PC>89109</cl:PC> <cl:LMK>LVCC</cl:LMK> <cl:RM>110</cl:RM> <cl:civilAddress> <gp:location-info> ...--0a0--

XML fragment of multipart MIME body

Example civic location


Alice

Example: SIP Invite with Location by Reference (1)

Bob

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9Max-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>; tag=1928301774Call-ID: [email protected] Geolocation: sips:[email protected];[email protected]; Recipient=endpointSupported: geolocation CSeq: 314159 INVITEContact: <sip:[email protected]>Accept: application/sdp, application/pidf-xmlContent-Type: application/sdpContent-Length: 243

INVITE

Example shows location added by value.

sips:[email protected] represents the location by reference


Alice Bob

200 OK

200 OK may contain either form of location delivery (message body or URI)• Since Request had appropriate

Accept header

SIP/2.0 200 OKVia: SIP/2.0/TCP sip:[email protected] ;branch=z9hG4bK77i832k9To: Bob <sip:[email protected]>; tag=a6c85e3From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected] Geolocation: sips:[email protected] Supported: geolocation CSeq: 314159 INVITEAccept: application/sdp, application/pidf-xmlContent-Type: application/sdpContent-Length: 142

(…Bob’s SDP here…)

INVITE

Example: SIP Invite with Location by Reference (2)


Architectural Models

•An emergency call is treated like any other call– Reduces interoperability problems

• Two major architectural models based on today’s communication models:

– End Host Based Model: Location information is provided to End Host. Emergency dial strings and PSAP URIs are determined by End Host

– Proxy Based Model: Location information is attached by a Proxy

• A couple of variations possible.

• See also where a strong focus is given on the description of model 1:

http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-00


End Host Based Model

Location Information is provided by the LIS.End host uses LoST to determine PSAP URIThe INVITE might be sent to the PSAP directly but will typically travel via the outbound SIP proxy

LoST Server

SIP proxy PSAP

(1) Location

Location + Service Identifier

(2)

PSAP URI + service number

(3)

(4)(5)

dial dialstringSOS caller


(0) Request

INVITERequest URI: urn:service:sosTo: urn:service:sos

Route Header: PSAP URI <PIDF-LO>


Route Header: PSAP URI <PIDF-LO>


PSAP / Call Taker

LoST Server

SIP proxySOS caller

(2) Location


(3)

PSAP URI

(4)

(1) (5)

dial dialstring

Proxy Based Model

Assumes that SIP proxy is able to determine the end hosts location information. This assumes a close relationship between the IAP/ISP and the SIP proxy




Route Header: PSAP URI < Reference to PIDF-LO>


End Host obtains Location InformationProxy runs (also) LoST

SIP proxy PSAP

(1) Location


<PIDF-LO>

(2)


Route Header: PSAP URI < PIDF-LO>

(5)dial dialstring

SOS caller


(0) Request Location + Service Identifier

(3) (4)

LoST Server

PSAP URI


PSAP / Call Taker

Mapping Server

SIP proxySOS caller

(2) Location


(3)

PSAP URI

(4)

INVITE Request URI: 911 To: 911

(1)

(5)

dial 9-1-1

Legacy Equipment


Dial string recognition, location determination, route determination done by SIP proxyReally only useful for restricted environments.

INVITERequest URI: urn:service:sosTo: 911

Route Header: PSAP URI < Reference to PIDF-LO>


Legacy EquipmentDisadvantages

• When the emergency call is not recognized by the User Agent then the following features cannot be disabled:

– Call Waiting– Call Transfer– Three Way Call– Flash hold– Outbound Call Blocking

• Callbacks from the PSAP may be blocked.– Call Waiting, Do Not Disturb, Call Forward should be disabled.

• Privacy settings might prevent disclosure of identity and location information might not be added to the call.

• Other call features may not be supported, such as REFER (for conference call and transfer to secondary PSAP) or GRUU.

• May violate other parts of the phone BCP document.• Updating the end points to support emergency services is very important.


Notes on Media Traffic

•RTP based media traffic RFC 3550 mandatory •Minimum requirements for interoperability:

– Audio codec: G.711 Silence suppression not used.

– IM: RFC 3428 or RFC 3920– Real-time text: RFC 4103 – Video: H.264 RFC 3984

• Better features can be negotiated via SIP offer/answer RFC 3264.

• Testing: INVITE requests to a service urn with a urn parameter of "test" indicates a request for an automated test.

– Example: "urn:service.sos.fire;test“– Response may include a text body (text/plain) with PSAP identity, the

requested service, and the location reported with the call.


Unauthenticated Emergency Services

• Reference http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-access

• Cases:

– The emergency caller does not have credentials for access to the network but it may have credentials for his VoIP provider.

– The emergency caller has credentials for network access but does not have credentials for a VoIP provider.

– The emergency caller has credentials (for either network access or it's VoIP provider) but they are not authorization to make a call.

• Work assumes lower-layer procedures for omitting network access authentication.

• High-level Impact:– End host has to implement a specific VoIP profile

– SIP proxy has to be located in the access network.


What information may be needed in unauthenticated state?

•Local emergency dialstring

•PSAP URI corresponding to the desired emergency type and at the specific location

•802.11u allows to use LoST in state-1, which allows to obtain these information. If the network type is ‘emergency’, then a SIP call to the PSAP can also be placed.


Unauthenticated Emergency Services 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

QoS features:

• Expedited bandwidth request

It’s not a complete solution, needs a backend system behind

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


Authority to Citizen type of Emergency Calls

Example services:

•Emergency Alert Systems

•Public Warning Systems (PWS)

•Earthquake and Tsunami Warning Systems (ETWS)

•Commercial Mobile Alert Service (CMAS)

Support for it in IEEE (802.11u):

• 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

1 3rd emergency services workshop, brussels, 2007 tutorial on location and emergency services...

Documents

rd emergency services

ieee meeting

emergency services notice

statement ieee standards

emergency personnel

emergency services gabor

patent policy

location information