Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.868  Word version:  9.0.0

Top   Top   None   None   Next
0…   5…

 

0  Introductionp. 4

The solution for support of IMS Emergency calls defined for Rel-7 in TS 23.167 has a number of limitations and potential limitations. These include restriction only to certain IP-CANs, restriction only to cases where at least part of the IP-CAN and visited IMS belong to the same operator, possible non-alignment with the various allowed IETF solutions and possible performance limitation. While it is possible that none of these limitations will be significant for some deployments of this service, it is not certain that this will apply to all deployments. Therefore it has been decided to evaluate both the service defined in TS 23.167 and possible extensions that might overcome these limitations.
Up

1  Scopep. 5

The present document provides a study investigating possible limitations of the solution for IMS emergency calls defined for Rel-7 in TS 23.167, as well as possible extensions of that solution to reduce or eliminate some or all of the identified limitations.
The study item is expected mainly to concern IMS although some aspects of IP-CAN support may also be included. The study item has the following objectives
  • Evaluate the feasibility of supporting IMS emergency calls for combinations of IP access network A and IMS core network B not supported in Rel-7 including but not limited to the following cases:
    • A is any IP access network and B is the home 3GPP compliant IMS network for any emergency calling UE with adequate security credentials
    • A is any IP access network and B is a visited 3GPP compliant IMS network for any emergency calling roaming UE with adequate security credentials
      Additional user cases may also be proposed and evaluated during the SI if deemed applicable.
  • Evaluate other enhancements to the solution for IMS emergency calls in Release 7 that may improve performance and/or reduce complexity
  • Evaluate the feasibility of better aligning the solution in TS 23.167 with applicable IETF standards and draft standards (e.g. from the Ecrit and Geopriv working groups)
  • Any enhancement to the support of IMS emergency calls shall remain backward compatible to the solution in Rel-7 from the perspective of the UE and any 3GPP network element. Furthermore, any enhancement should be based on the solution in Rel-7 and should avoid unnecessarily adding new network entities, protocols and interfaces and moving existing functions from one entity to another.
The study item is expected to enable SA WG2 to decide which of the above objectives if any may be worth supporting in Rel-8 and which extensions to the current solution would then be appropriate.
Up

2  Referencesp. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions".
[3]
draft-ietf-ecrit-framework-05:  "Framework for Emergency Calling using Internet Multimedia".
[4]
draft-ietf-ecrit-phonebcp-04:  "Best Current Practice for Communications Services in support of Emergency Calling".
[5]
draft-ietf-sip-location-conveyance-09:  "Location Conveyance for the Session Initiation Protocol".
[6]
RFC 4119:  "A Presence-based GEOPRIV Location Object Format".
[7]
RFC 3856:  "A Presence Event Package for the Session Initiation Protocol (SIP)".
[8]
draft-ietf-geopriv-http-location-delivery-05:  "HTTP Enabled Location Delivery (HELD)".
[9]
draft-winterbottom-geopriv-deref-protocol-00:  "An HTTPS Location Dereferencing Protocol Using HELD".
[10]
ANSI/TIA-1057: "Link Layer Discovery Protocol - Media Endpoint Discovery".
[11]
RFC 3825:  "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information".
[12]
RFC 4676:  "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information".
[13]
TS 23.271: "Functional stage 2 description of Location Services (LCS)".
[14]
RFC 5222:  "LoST: A Location-to-Service Translation Protocol".
[15]
TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
Up

3  Definitions and abbreviationsp. 6

3.1  Definitionsp. 6

For the purposes of the present document, the terms and definitions given in TR 21.905 and TS 23.167 apply.

3.3  Abbreviationsp. 6

For the purposes of the present document, the abbreviations given in TR 21.905, TS 23.167 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 or TS 23.167.
CP
Control Plane
DHCP
Dynamic Host Configuration Protocol
E-SLP
Emergency SLP
HELD
HTTP Enabled Location Delivery
LIS
Location Information Server
LLDP-MED
Link Layer Discovery Protocol - Media Endpoint Discovery
SLP
SUPL Location Platform
SUPL
Secure User Plane Location
UP
User Plane
V-SLP
Visited SLP
Up

4  Overall Requirementsp. 6

4.1  Solution Characteristicsp. 6

It is intended to extend the solution currently defined in Rel-7 so that it can support, as far as possible and within the limitations defined in clause 1 above, any IP based emergency call made from any access as long as both the network providing emergency call handling and the UE are 3GPP IMS compliant. Preferred characteristics of this extended solution are listed below. Some of these preferences (e.g. (1)) could be considered as requirements.
  1. Support existing interfaces to a PSAP accessed via the PSTN.
  2. Support a single interface to a PSAP accessed via IP from a call perspective and a single interface from a location access perspective. Variants of either single interface may be permitted (e.g. needed to support different regional requirements) although it is preferred to subsume all variants within a single standard in each case. If this is not possible, a single call related standard and a single location related standard should be the goal for each world region.
  3. Make use of existing OMA and IETF standards where possible and appropriate for new protocols, network elements and signalling objects - as a preference to creating new 3GPP definitions.
  4. Minimize the number of different location solutions and location related network elements and protocols that need to be supported (on the network as opposed to PSAP side) subject to attaining the various other requirements defined here.
  5. Support reduced call establishment delay through elimination or reduction of potential sources of high delay such as interaction with a home network (e.g. to support registration and multiple registration attempts) and location retrieval (e.g. for routing purposes).
  6. Use a single interface between the serving IMS network and the IP-CAN from a call perspective and a single interface from a location access perspective that can be reused for any IP-CAN (e.g. any wireless access network) - or at least for as many IP-CAN types as possible.
  7. Use a single interface between the serving IMS network and the UE from a call perspective and a single interface from a location access perspective that is applicable for any IP-CAN (e.g. any wireless access network) - or at least for as many IP-CAN types as possible.
Up

Up   Top   ToC