Best Current Practice for IP-based In-Vehicle Emergency Calls
draft-rosen-ecrit-ecall-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 8, 2009.

Abstract

This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Profile
4.  Data Profile
5.  Example
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative references
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Emergency calls made from vehicles can assist with the objective of significantly reducing road deaths and injuries. Unfortunately, drivers often have a poor location-awareness, especially on urban roads (also during night) and abroad. In the most crucial cases, the victim(s) may not be able to call because they have been injured or trapped.

In Europe the European Commission has launched the eCall initiative that may best be described as a "user instigated or automatic system to provide notification to 'Public Safety Answering Point's (PSAP), by means of cellular communications, that a vehicle has crashed, and to provide coordinates, a defined minimum set of data, and where possible a voice link to the PSAP.". The current specifications being developed to offer the eCall solution are defined to work with circuit switched telephony. This document details how the same functionality can be accomplished using IP-based mechanisms. Since cellular systems are being replaced with IP-based infrastructure this document complements the ambigous goal to provide widespread availability of in-vehicular emergency services solutions.

This document is organized as follows: Section 2 (Terminology) defines the terminology, Section 3 (Protocol Profile) illustrates the required protocol functionality, Section 4 (Data Profile) indicates the required data that has to be transmitted within a PIDF-LO and Section 5 (Example) shows an example message exchange. This document concludes with the security consideratoins in Section 6 (Security Considerations) and IANA considerations in Section 7 (IANA Considerations).

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document re-uses a lot of the terminology defined in Section 3 of [9] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” January 2008.).

3.  Protocol Profile

The usage of in-vehicular emergency calls does not require the usage of a Location Configuration Protocol since GPS is used. Furthermore, since the GPS receiver is permanently turned on it can even provide useful information in cases where the car entered a tunnel. Consequently, there is no need to discover any LIS.

Since the emergency call within the car is either triggered by a button or, in most cases, automatically thanks to sensors mounted in the car there is no need to learn a dial string. This document registers a separate Service URN, namely 'urn:service:ecall', used specifically for emergency calls that are triggered by vehicles.

The following list provides information about the sections and requires of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) that are relevant to this specification:

Identifying an emergency call:

Emergency calls are detected at the end point, i.e., by the vehicle, and the Service URN 'urn:service:ecall' MUST be implemented by the end point and recognized by the VSP. The requirements listed in Section 5 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) are therefore irrelevant to this specification, as they deal with identifying an emergency call based on dial strings.

Location:

The encoding of the PIDF-LO [3] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) is described in Section 4 (Data Profile). In an emergency, the end point adds the available location information to the initial SIP INVITE emergency call message. In special cases a location update may be provided, using the procedure described in requirement ED-38 of Section 6.8 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.); all other aspects of Section 6.8 from that document are not applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 6.4, 6.5 and 6.6 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) are not applicable to this document. For location conveyance in SIP [4] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” March 2009.) MUST be used. Further aspects that are not relevant for this document are multiple locations (Section 6.9 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.)), location validation (Section 6.10 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.)), default location (Section 6.11 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.))

LoST:

Emergency call routing support, for example utilizing LoST, is provided by VSP. As such, the description in Section 8 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) is applicable to this document, except for requirement SP-25 and SP-26 regarding legacy devices.

Signaling of emergency calls:

Section 9 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) is applicable to this document with the following exceptions: video and real-time text are not supported by the end device, ED-60/AN-25 is not applicable as HELD is not used. Additionally, ED-62 dealing with "SIP signaling requirements for User Agents" is simplified as follows. The initial SIP signaling method is an INVITE request with the following setting:

1. The Request URI MUST be the service URN 'urn:service:ecall'.
2. The To header MUST be a service URN 'urn:service:ecall'.
3. The From header MUST be present and SHOULD be the AoR of the caller.
4. A Via header MUST be present.
5. A Contact header MUST be present which MUST be globally routable to permit an immediate call-back to the specific device which placed the emergency call.
6. Other headers MAY be included as per normal SIP behavior.
7. A Supported header MUST be included with the 'geolocation' option tag [4] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” March 2009.).
8. The device MUST include location by-value into the call.
9. A normal SDP offer SHOULD be included in the INVITE. If voice is supported the offer SHOULD include the G.711 codec, if a voice channel can be established based on the equipment in the car.
10. If the device includes location-by-value, the UA MUST support multipart message bodies, since SDP will likely be also in the INVITE.
11. The UAC MUST include a "inserted-by=endpoint" header parameter on all Geolocation headers. This informs downstream elements which device entered the location at this URI (either cid-URL or location-by-reference URI).
12. SIP Caller Preferences [5] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) MAY be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. SIP Caller Preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the call.

Call backs:

The description in Section 10 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) is not relevant for this document.

Mid-call behavior:

The description in Section 11 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) is fully applicable to this document.

Call termination:

[This item is for further discussion.]

Disabling of features:

The description in Section 13 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) is fully applicable to this document.

Media:

Real-time text and video are not supported. If voice calls are supported then the description in Section 14 is applicable to this document.

Testing:

The description in Section 15 of [2] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” January 2010.) is fully applicable to this document.

4.  Data Profile

Due to the requirement for a built-in GPS receiver only geodetic location information will be sent within an emergency call. Furthermore, the number of location shapes is is restricted. Hence, the following location shapes of [6] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.) MUST be implemented: 2d and 3d Point (see Section 5.2.1 of [6] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.)), Circle (see Section 5.2.3 of [6] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.)), and Ellipsoid (see Section 5.2.7 of [6] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.)). The coordinate reference systems (CRS) specified in [6] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.) are also mandatory for this document. Furthermore, the direction of travel of the vehicle is important for dispatch and hence it MUST be included in the PIDF-LO. The <bearing> element specified in [7] (Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, “Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO),” March 2010.) MUST be supported.

5.  Example

Figure 1 (Example of In-Vehicular Emergency Call Message Flow) shows an emergency call placed from a vehicle whereby location information information is directly attached to the SIP INVITE message itself. The call is marked as an emergency call using the 'urn:service:ecall' service URN and the PSAP of the VoIP provider determines which PSAP to contact based on the provided location information. As shown in the figure, this route determination may be based on LoST. Then, the emergency call continues towards the PSAP and in this example it hits the ESRP, as the entry point to the PSAP operators emergency services network. Finally, the emergency call will be received by a call taker and first reponders will be dispatched.

                 +--------+
                 | LoST   |
                 | Servers|
                 +--------+
                     ^                         +-------+
                     |                         | PSAP2 |
                     |                         +-------+
                     v
                 +-------+     +------+     +-------+
  Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
                 +-------+     +------+     +-------+

                                               +-------+
                                               | PSAP3 |
                                               +-------+

The following example, in Figure 2 (Example of In-Vehicular Emergency Call Message Flow), shows location information encoded in a PIDF-LO that is being conveyed in such an emergency call.

                   <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:vehicle-identification@example.com">
       <device id="123">
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>42.5463 -73.2512</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   850.24
                 </gs:radius>
               </gs:Circle>
               <gml:bearing>
                <gml:DirectionVector>
                 <gml:vector> 270.0 -60.0</gml:vector>
                </gml:DirectionVector>
               </gml:bearing>
             </gp:location-info>
             <gp:usage-rules/>
             <method>GPS</method>
           </gp:geopriv>
       </device>
     </presence>

6.  Security Considerations

This document does not raise security considerations beyond those described in [10] (Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, “Security Threats and Requirements for Emergency Call Marking and Mapping,” January 2008.).

7.  IANA Considerations

IANA is requested to register the URN 'urn:service:ecall' under the sub-services 'sos' registry defined in Section 4.2 of [8] (Schulzrinne, H., “A Uniform Resource Name (URN) for Emergency and Other Well-Known Services,” January 2008.).

urn:service:ecall

This service identifier reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency related to accidents of vehicles.

8.  Acknowledgements

We would like to thank Michael Montag and Ulrich Dietz for their feedback.

9.  References

9.1. Normative References

9.2. Informative references

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.