1 / 10

Emergency calls related work done in IETF

Emergency calls related work done in IETF. Gabor Bajko May 22, 2006. The Issues. Component Issues How to identify that the call is for emergency service How to discover the locally significant emergency identifiers How to determine caller location How to represent the location

laszlo
Download Presentation

Emergency calls related work done in IETF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Emergency calls related work done in IETF Gabor Bajko May 22, 2006

  2. The Issues • Component Issues • How to identify that the call is for emergency service • How to discover the locally significant emergency identifiers • How to determine caller location • How to represent the location • How to route the call to the correct destination based on caller location • How to carry location within the signaling • How to indicate priority and what is it used for • Architectural Issues • Who does each of the steps above • Meta Issues • How to verify the authenticity/integrity of caller location • How to treat the caller authentication (or the lack of it)

  3. IETF Work Organization • Signaling Protocol Agnostic Items • How to identify that the call is for emergency service  ECRIT WG • How to discover the locally significant emergency identifiers  ECRIT WG problem space (protocols done elsewhere, e.g. DHC WG, SIPPING WG) • How to determine caller location  GEOPRIV WG problem space (protocols done in various places, e.g. in DHC WG, IEEE, 3GPP, …) • How to represent the location  GEOPRIV WG • How to route the call to the correct destination based on caller location  ECRIT WG • Signaling Protocol Specific Items • How to carry location within the signaling  SIPPING WG (for SIP) • How to indicate priority and what is it used for  SIP WG (for SIP)

  4. Service URN • Current draft: draft-ietf-ecrit-service-urn-03.txt. Recently put in WGLC • It defines the “service” URN namespace with sub-services • These URNs are supposed to be protocol elements and not text describing the service (and not necessarily shown to the user) • There are a number of sub-services defined under the URN:service:sos, with global meaning. The terminal would probably need to have an interpreter which recognises the services provided in that network and displays e.g. the icon and/or the name of it in the user’s language on the GUI. • Service URNs are NOT routable, they need to be translated into routable addresses • It is hierarchical: If "URN:service:" 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs. If the queried service ‘x.y.z’ does not exists, the resolution for ‘x.y’ or eventually ‘x’ could be returned as a matching result • The client would do the query well before emergency is needed, and keep the info up-to-date in terminals’ cache.

  5. Service URN - cont • Example service URNs proposed by the draft to be registered: • urn:service:sos – this is proposed to be the default one • 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 • urn:service:counseling • urn:service:counseling.mental-health • urn:service:counseling.children

  6. LoST (draft-hardie-ecrit-lost-00.txt) • LoST: Location-to- Service Translation Protocol (name might change) • It is an early draft, many details still missing • XML-based protocol for mapping service identifiers and geospatial or civic location information (PIDF-LO) to service contact URIs (carrying protocol to be chosen) • It requires the client to know the address of the LoST server. • The ultimate goal is that the LoST server provides the client with a concrete address to contact (which could be a service contact URI –PSAP URI-, a tel. number, IP address, etc.) • It recommends that when the LoST server is contacted and the requested service does not exist, then the resolution of the more specific service is returned (on the e-mail exploder it was suggested that in this case the service URN itself to be returned too). E.g.: in case urn:service:sos.fire does not exists, the address of the server hosting urn:service:sos would be returned. • Finding LoST server address: • A new S-NSPTR application service tag is defined: SURN; and a new label is registered: “SURN.sos” E.g.: the S-NAPTR query is made to SURN.sos:LoST (and this would return a result containing the URI to contact using LoST protocol for emergency services)  all this to find the LoST server (adv: dynamic, DDDS could be used)

  7. Location – GEOPRIV WG • How to determine caller location • DHCP for coordinate based location: RFC 3825 • DHCP for civic location: draft-ietf-geopriv-dhcp-civil (in RFC Editor Queue) • A separate query protocol (based on IP address): draft-linsner-geopriv-lcp • A similar HTTP-based protocol: draft-winterbottom-geopriv-held-sighting • Location can be provided by value or by reference • draft-winterbottom-location-uri • How to represent location • PIDF-LO: RFC 4119 • Several drafts now on PIDF-LO usages and clarifications

  8. Questions • How would a roaming user find out what kind of emergency sub-services (e.g. sos.poison) are supported by the network it just attached to (or country it just roamed to)? • How to download the list of these sub-services? • How could this situation be handled: • A european comes to US and dials 112 instead of 911

  9. Steps to be performed with LoST • After attachment the terminal should somehow find out the emergency services available in the network it attached to (how??) • It stores the services in the cache • When needed, it picks up the emergency service type it needs and makes an S-NAPTR query to find a server to contact (LoST server) • Using LoST protocol, it provides the emergency service URN and its location info to get a resolution (the nearest PSAP hosting that service) • Contact the PSAP returned in response using the protocol specified

  10. Ecrit work usage in MMD – possible solution • In 3GPP: when the client places an emergency call, the P-CSCF has to identify it as an emergency (tbd how)  possible solution: put the service URN somewhere into the SIP request??? And let the P-CSCF detect itOR rather let the client to do a NAPTR query using the emergency URN and then send the SIP request to the address returned. P-CSCF would need to know the emergency URIs from NAPTR in order to detect emergency • In 3GPP: Once P-CSCF identified the call as emergency, routes it to an E-CSCF • In 3GPP: E-CSCF determines the closest PSAP using the client’s location information by querying a database (tbd how)  possible solution: LoST protocol could be used by the E-CSCF to query a LoST server and find out the closest PSAP hosting the required emergency service • E-CSCF could be preconfigured or use DHCP for LoST server address • Service URN resolution to routable URI would not be needed by the client, the E-CSCF could do it • If there is no direct match, E-CSCF could do a best guess, user would not be involved

More Related