Download Emergency calls as envisaged in IETF

Emergency calls
related work done in IETF
Gabor Bajko
May 22, 2006
1
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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)
2
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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
•
How to determine caller location
•
How to represent the location
•
How to route the call to the correct destination based on caller location
 ECRIT WG problem space (protocols done elsewhere, e.g. DHC
WG, SIPPING WG)
 GEOPRIV WG problem space (protocols done in various places,
e.g. in DHC WG, IEEE, 3GPP, …)
 GEOPRIV WG
 ECRIT WG
• Signaling Protocol Specific Items
• How to carry location within the signaling
 SIPPING WG (for SIP)
•
3
© NOKIA
How to indicate priority and what is it used for
 SIP WG (for SIP)
Presentation_Name.PPT / DD-MM-YYYY / Initials
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.
4
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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
5
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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 email 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)
6
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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-geoprivlcp
• 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
7
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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
8
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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
9
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials
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 it
OR 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 ECSCF
• 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
10
© NOKIA
Presentation_Name.PPT / DD-MM-YYYY / Initials