1. 1 3rd Emergency Services Workshop, Brussels, 2007 Tutorial on Location 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, 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2008-09-10 Author:

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

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

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

5. 5 3rd 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 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.

6. 6 3rd 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, 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

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

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

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

10. 10 3rd 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-tokenshttp://www.iana.org/assignments/method-tokens – Element ▪ Entity or organization that supplied this location information

11. 11 3rd Emergency Services Workshop, Brussels, 2007 Example: PIDF-LO with geodetic information <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:mike@seattle.example.com"> -43.5723 153.21760 802.11 www.example.com no 2003-06-23T04:57:29Z https://www.example.com/myrules These are my privacy rules 2007-06-22T20:57:29Z mac:8asd7d7d70cf

12. 12 3rd Emergency Services Workshop, Brussels, 2007 Example: PIDF-LO with civic information <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:mike@seattle.example.com"> US New York Broadway 123 Suite 75 10027-0401 2007-06-22T20:57:29Z mac:8asd7d7d70cf

13. 13 3rd 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/rfc4776.txt)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 standardization work on PIDF-LO.

14. 14 3rd Emergency Services Workshop, Brussels, 2007 RFC 4119 Civic Location Information - I LabelDescriptionExample countryThe country is identified by the two- letter ISO 3166 code US A1national subdivisions (state, region, province, prefecture) New York A2county, parish, gun (JP), district (IN)King's County A3city, township, shi (JP)New York A4city division, borough, city district, ward, chou (JP) Manhattan A5Neighbourhood, blockMorningside Heights A6StreetBroadway PRDLeading street directionN, W PODTrailing street suffixSW

15. 15 3rd Emergency Services Workshop, Brussels, 2007 RFC 4119 Civic Location Information –II (contd.) LabelDescriptionExample STSStreet suffixAvenue, platz, Street HNOHouse number, numeric part only123 HNSHouse number suffixA, ½ LMKLandmark or vanity addressLow Library LOCAdditional location informationRoom 543 FLRFloor5 NAMName (residence, business or office occupant ) Joe’s Barbershop PCPostal code10027-0401

16. 16 3rd 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 (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.

17. 17 3rd Emergency Services Workshop, Brussels, 2007 Architecture SIP, HTTP, etc. + Location Reference Location Recipient Location Reference End Host Location Information Server Request Location Reference Location Information Examples of a Location Reference sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o

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

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

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

21. 21 3rd 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 RFC5031 Example: urn:service:sos; urn:service:sos.ambulance, urn:service:sos.police, etc.

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

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

24. 24 3rd Emergency Services Workshop, Brussels, 2007 Features Protocol specification available in http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/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 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 )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. LoST server discovery procedure – via DNS (defined in http://tools.ietf.org/html/draft-ietf-ecrit-lost )http://tools.ietf.org/html/draft-ietf-ecrit-lost – Via DHCP (defined in http://tools.ietf.org/html/draft-ietf-ecrit-dhc-lost-discovery)http://tools.ietf.org/html/draft-ietf-ecrit-dhc-lost-discovery

25. 25 3rd Emergency Services Workshop, Brussels, 2007 LoST Example Query with geodetic location info <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value" recursive="true"> 37.775 -122.422 urn:service:sos.police

26. 26 3rd Emergency Services Workshop, Brussels, 2007 LoST Example Response <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"> New York City Police Department urn:service:sos.police 37.775 -122.4194 … 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911

27. 27 3rd Emergency Services Workshop, Brussels, 2007 Example: listServices and listServicesResponse <listServices xmlns="urn:ietf:params:xml:ns:lost1"> urn:service:sos <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> 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.

28. 28 3rd 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/ http://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/ as protocol mechanisms.

29. 29 3rd 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 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

30. 30 3rd Emergency Services Workshop, Brussels, 2007 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:bob@192.168.10.20 SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9 Max-Forwards: 70 To: Bob From: Alice ; tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: cid:alice123@atlanta.example.com;cid:alice123@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=0a0 Content-Length: 543 INVITE geolocation (if as a message body) sdp

31. 31 3rd Emergency Services Workshop, Brussels, 2007 --0a0 Content-Type: application/pidf+xml Content-ID: cid:alice123@atlanta.example.com ….. 36.132N 115.151W ….. 802.11 www.example.com ….. --0a0-- Alice Example: SIP Invite with Location by Value (2) Bob INVITE XML fragment of multipart MIME body Example geodetic location

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

33. 33 3rd Emergency Services Workshop, Brussels, 2007 Alice Example: SIP Invite with Location by Reference (1) Bob INVITE sip:bob@192.168.10.20 SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9 Max-Forwards: 70 To: Bob From: Alice ; tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.ecample.com Geolocation: sips:alice123@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 INVITE Example shows location added by value. sips:alice123@atlanta.example.com represents the location by reference

34. 34 3rd Emergency Services Workshop, Brussels, 2007 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 OK Via: SIP/2.0/TCP sip:alice@atlanta.com ;branch=z9hG4bK77i832k9 To: Bob ; tag=a6c85e3 From: Alice ;tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: sips:alice123@atlanta.example.com Supported: geolocation CSeq: 314159 INVITE Accept: application/sdp, application/pidf-xml Content-Type: application/sdp Content-Length: 142 (…Bob’s SDP here…) INVITE Example: SIP Invite with Location by Reference (2)

35. 35 3rd 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-architecture- overview-00

36. 36 3rd Emergency Services Workshop, Brussels, 2007 End Host Based Model Location Information is provided by the LIS. End host uses LoST to determine PSAP URI The 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 dialstring SOS caller Location Information Server (0) Request INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI

37. 37 3rd Emergency Services Workshop, Brussels, 2007 PSAP / Call Taker LoST Server SIP proxy SOS caller (2)Location Location + Service Identifier (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 Location Information Server INVITE Request URI: urn:service:sos To: urn:service:sos INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI

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

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

40. 40 3rd 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.

41. 41 3rd 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.

42. 42 3rd 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 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.

43. 43 3rd 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.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.

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

45. 45 3rd 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.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