Tutorial on Location and Emergency Services Author Date

Tutorial on Location and Emergency Services Author: Date: 2008 -09 -10 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 , 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 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at . 1 3 rd Emergency Services Workshop, Brussels, 2007

Tutorial on Location and Emergency Services Gabor Bajko, IEEE meeting, Hawaii 2008 some of the slides from: Hannes Tschofenig 2 3 rd Emergency Services Workshop, Brussels, 2007

Emergency Services Categories Authority to Citizen • Example: Cell broadcast for Tsunami warning Authority to Authority • Example: Communication between emergency personnel Citizen to Authority Note that some SDOs use the term “individuals” instead of “citizen”. 3 3 rd Emergency Services Workshop, Brussels, 2007

Building Blocks for Citizen to Authority type of Emergency Calls 4 3 rd Emergency Services Workshop, Brussels, 2007

How is location information encoded? • Two formats exist for location information encoding: ▪ Binary Format ▪ XML-based Format • For bandwidth constraint environments a functionalityreduced 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. 5 3 rd Emergency Services Workshop, Brussels, 2007

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) – 3 rd 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, 3 G femto-cells, etc. ) • Boxes/APs have a fixed location • Devices ‘seeing’ them are in their proximity (limited coverage) • Make use of the boxes’ location 6 3 rd Emergency Services Workshop, Brussels, 2007

Location in IEEE LLDP developed in 802. 1 AB • Suitable mainly for wired environment 802. 11 k: 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. 11 v: Presence • Extends 802. 11 k with Presence functionality • Subscribe/notify mechanism to notify non-AP STA about location changes (duplicates the SIP Presence functionality) • 3 rd LB failed 802. 11 u: 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 7 3 rd Emergency Services Workshop, Brussels, 2007

Location in IETF (RFCs) RFC 3825: 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. 11 k as Location Configuration Information Report element (extended to include azimuth information) RFC 4776: 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? ? RFC 4119 ( partially revised by RFC 5139): 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’ 8 3 rd Emergency Services Workshop, Brussels, 2007

Binary Encoding of Location in 802. 11 k 9 3 rd Emergency Services Workshop, Brussels, 2007

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: – Element ▪ Encapsulates location information ▪ GML 3. 0 schema (mandatory-to-implement) ▪ Supports civic location format (optional-to-implement) – Element ▪ Used to indicate privacy preferences – Element ▪ Describes the way location information was derived or discovered. ▪ Example: gps ▪ Registry available at: http: //www. iana. org/assignments/method-tokens – Element ▪ Entity or organization that supplied this location information 10 3 rd Emergency Services Workshop, Brussels, 2007

Example: PIDF-LO with geodetic information -43. 5723 153. 21760 802. 11 www. example. com no 2003 -06 -23 T 04: 57: 29 Z https: //www. example. com/myrules These are my privacy rules 2007 -06 -22 T 20: 57: 29 Z mac: 8 asd 7 d 7 d 70 cf 11 3 rd Emergency Services Workshop, Brussels, 2007

Example: PIDF-LO with civic information US New York New York Broadway 123 Suite 75 10027 -0401 2007 -06 -22 T 20: 57: 29 Z mac: 8 asd 7 d 7 d 70 cf 12 3 rd Emergency Services Workshop, Brussels, 2007

What civic information can I express? • Initially civic location was specified for DHCP in RFC 4776* (http: //www. ietf. org/rfc 4776. 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 standardization work on PIDF-LO. 13 3 rd Emergency Services Workshop, Brussels, 2007

RFC 4119 Civic Location Information - I Label country A 1 A 2 A 3 A 4 A 5 A 6 PRD POD 14 Description The country is identified by the twoletter ISO 3166 code national subdivisions (state, region, province, prefecture) county, parish, gun (JP), district (IN) city, township, shi (JP) city division, borough, city district, ward, chou (JP) Neighbourhood, block Street Leading street direction Trailing street suffix Example US New York King's County New York Manhattan Morningside Heights Broadway N, W SW 3 rd Emergency Services Workshop, Brussels, 2007

RFC 4119 Civic Location Information –II (contd. ) Label STS HNO HNS LMK LOC FLR NAM PC 15 Description Street suffix House number, numeric part only House number suffix Landmark or vanity address Additional location information Floor Name (residence, business or office occupant ) Postal code Example Avenue, platz, Street 123 A, ½ Low Library Room 543 5 Joe’s Barbershop 10027 -0401 3 rd Emergency Services Workshop, Brussels, 2007

Constantly providing a Target with it’s current location is not efficient. What can I do? Solution: Location by Reference (Lby. R) 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. 16 3 rd Emergency Services Workshop, Brussels, 2007

Architecture Location Information Server Loc a tion Loc Ref eren ce atio Request Location Reference n In form atio n SIP, HTTP, etc. + Location Reference End Host Examples of a Location Reference • sips: 9769+357 yc 6 s 64 ceyoiuy 5 ax 3 o@ls. example. com • https: //ls. example. com: 9768/357 yc 6 s 64 ceyoiuy 5 ax 3 o 17 3 rd Emergency Services Workshop, Brussels, 2007 Location Recipient

Building Blocks 18 3 rd Emergency Services Workshop, Brussels, 2007

Identifying an Emergency Call Emergency Numbers See http: //www. sccfd. org/travel. html 19 3 rd Emergency Services Workshop, Brussels, 2007

Emergency Numbers 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 Lo. ST or device configuration http: //tools. ietf. org/html/draft-ietf-sipping-config-framework • Visited Emergency Number: Obtained dynamically via Lo. ST 20 3 rd Emergency Services Workshop, Brussels, 2007

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 RFC 5031 • Example: urn: service: sos; urn: service: sos. ambulance, urn: service: sos. police, etc. 21 3 rd Emergency Services Workshop, Brussels, 2007

Building Blocks 22 3 rd Emergency Services Workshop, Brussels, 2007

How to find the closest PSAP? Location Information Emergency Number + + Service URN + (PSAP) URI Location-to-Service Translation (Lo. ST) is a simple XML-based query and response protocol running on top of HTTP. 23 + Service Boundary 3 rd Emergency Services Workshop, Brussels, 2007

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-2 d (offers Point, Polygon, Circle, Ellipse, Arc. Band) 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 , and ) • 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. • Lo. ST 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) 24 3 rd Emergency Services Workshop, Brussels, 2007

Lo. ST Example Query with geodetic location info

37. 775 -122. 422

Lo. ST Example Response New York City Police Department urn: service: sos. police

37. 775 -122. 4194

37. 775 -122. 4194

Example: list. Services and list. Services. Response urn: service: sos 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 Request Response is a variation of that includes location in the query. 27 3 rd Emergency Services Workshop, Brussels, 2007

Building Blocks The emergency call itself is shown in the context of the architecture. It makes use of the Service URN and SIP Location Conveyance http: //tools. ietf. org/wg/sip/draft-ietf-sip-location-conveyance/ as protocol mechanisms. 28 3 rd Emergency Services Workshop, Brussels, 2007

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 29 3 rd Emergency Services Workshop, Brussels, 2007

Example: SIP Invite with Location by Value (1) Bob Alice INVITE sip: bob@192. 168. 10. 20 SIP/2. 0 Via: SIP/2. 0/TCP pc 33. atlanta. example. com ; branch=z 9 h. G 4 b. K 77 i 832 k 9 Max-Forwards: 70 To: Bob From: Alice ; tag=1928301774 Call-ID: a 84 b 4 c 76 e 6 Kr 456@pc 33. atlanta. com Geolocation: cid: alice 123@atlanta. example. com; inserted-by=alice@atlanta. example. com; recipient=endpoint Supported: geolocation CSeq: 314159 INVITE Contact: Accept: application/sdp, application/pidf-xml Content-Type: multipart/mixed; boundary=0 a 0 Content-Length: 543 Example shows location added by value. cid: points to location in the body. sdp geolocation (if as a message body) 30 3 rd Emergency Services Workshop, Brussels, 2007

Example: SIP Invite with Location by Value (2) Bob Alice INVITE --0 a 0 Content-Type: application/pidf+xml Content-ID: cid: alice 123@atlanta. example. com …. . 36. 132 N 115. 151 W …. . 802. 11 www. example. com …. . --0 a 0 -- 31 XML fragment of multipart MIME body Example geodetic location 3 rd Emergency Services Workshop, Brussels, 2007

Example: SIP Invite with Location by Value (3) Bob Alice INVITE --0 a 0 Content-Type: application/pidf+xml Content-ID: cid: alice 123@atlanta. example. com 32 . . . US Nevada Las Vegas 399 Convention Center Drive 89109 LVCC 110 . . . --0 a 0 -- XML fragment of multipart MIME body Example civic location 3 rd Emergency Services Workshop, Brussels, 2007

Example: SIP Invite with Location by Reference (1) Alice Bob INVITE 33 INVITE sip: bob@192. 168. 10. 20 SIP/2. 0 Via: SIP/2. 0/TCP pc 33. atlanta. example. com Example shows location added by ; branch=z 9 h. G 4 b. K 77 i 832 k 9 value. Max-Forwards: 70 To: Bob sips: alice 123@atlanta. example. com From: Alice ; represents the location by tag=1928301774 reference Call-ID: a 84 b 4 c 76 e 6 Kr 456@pc 33. atlanta. ecample. com Geolocation: sips: alice 123@atlanta. example. com; inserted-by=alice@atlanta. example. com; Recipient=endpoint Supported: geolocation CSeq: 314159 INVITE Contact: Accept: application/sdp, application/pidf-xml Content-Type: application/sdp Content-Length: 243 3 rd Emergency Services Workshop, Brussels, 2007

Example: SIP Invite with Location by Reference (2) Bob Alice INVITE 200 OK SIP/2. 0 200 OK Via: SIP/2. 0/TCP sip: alice@atlanta. com ; branch=z 9 h. G 4 b. K 77 i 832 k 9 To: Bob ; tag=a 6 c 85 e 3 From: Alice ; tag=1928301774 Call-ID: a 84 b 4 c 76 e 6 Kr 456@pc 33. atlanta. com Geolocation: sips: alice 123@atlanta. example. com Supported: geolocation CSeq: 314159 INVITE Accept: application/sdp, application/pidf-xml Content-Type: application/sdp Content-Length: 142 200 OK may contain either form of location delivery (message body or URI) • Since Request had appropriate Accept header (…Bob’s SDP here…) 34 3 rd Emergency Services Workshop, Brussels, 2007

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-architectureoverview-00 35 3 rd Emergency Services Workshop, Brussels, 2007

End Host Based Model Location Information Server (2) Location + Service Identifier Lo. ST Server (1) Location (0) Request (3) PSAP URI + service number (4) dialstring SOS caller INVITE Request URI: urn: service: sos To: urn: service: sos Route Header: PSAP URI (5) SIP proxy INVITE Request URI: urn: service: sos To: urn: service: sos PSAP Route Header: PSAP URI Location Information is provided by the LIS. End host uses Lo. ST to determine PSAP URI The INVITE might be sent to the PSAP directly but will typically travel via the outbound SIP proxy 36 3 rd Emergency Services Workshop, Brussels, 2007

Proxy Based Model Location Information Server Lo. ST Server (4) (3) PSAP URI Location + Service Identifier (2) Location (1) dialstring SOS caller (5) INVITE Request URI: urn: service: sos To: urn: service: sos SIP proxy INVITE Request URI: urn: service: sos To: urn: service: sos Route Header: PSAP URI < Reference to PIDF-LO> PSAP / Call Taker 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 37 3 rd Emergency Services Workshop, Brussels, 2007

End Host obtains Location Information Proxy runs (also) Lo. ST Location Information Server Lo. ST Server (1) Location (0) Request dialstring PSAP URI Location + Service Identifier SOS caller INVITE Request URI: urn: service: sos (2) To: urn: service: sos 38 (4) (3) SIP proxy (5) INVITE Request URI: urn: service: sos To: urn: service: sos Route Header: PSAP URI < PIDF-LO> 3 rd Emergency Services Workshop, Brussels, 2007 PSAP

Legacy Equipment Location Information Server (3) Mapping Server (4) PSAP URI Location + Service Identifier (2) Location (5) (1) dial 9 -1 -1 SOS caller INVITE Request URI: 911 To: 911 SIP proxy INVITE Request URI: urn: service: sos To: 911 Route Header: PSAP URI < Reference to PIDF-LO> PSAP / Call Taker Dial string recognition, location determination, route determination done by SIP proxy Really only useful for restricted environments. 39 3 rd Emergency Services Workshop, Brussels, 2007

Legacy Equipment Disadvantages • 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. 40 3 rd Emergency Services Workshop, Brussels, 2007

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. 41 3 rd Emergency Services Workshop, Brussels, 2007

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 Vo. IP provider. – The emergency caller has credentials for network access but does not have credentials for a Vo. IP provider. – The emergency caller has credentials (for either network access or it's Vo. IP 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 Vo. IP profile – SIP proxy has to be located in the access network. 42 3 rd Emergency Services Workshop, Brussels, 2007

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. 11 u allows to use Lo. ST 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. 43 3 rd Emergency Services Workshop, Brussels, 2007

Unauthenticated Emergency Services in IEEE (802. 11 u) Support for Unauthenticated Emergency Services • Case 1: ES only open network • Open SSID limited for ES usage • Case 2: Public credentials • Download credentials to authenticate then able to use the network for ES only Qo. S 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 44 3 rd Emergency Services Workshop, Brussels, 2007

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. 11 u): • 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 45 3 rd Emergency Services Workshop, Brussels, 2007