1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Emergency calls related work done in IETF Gabor Bajko May 22, 2006

1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials

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• 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)


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)


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.


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


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)


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


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


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


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

Documents

1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Emergency calls related work done in IETF Gabor Bajko May 22, 2006