Content for  TR 23.826  Word version:  9.0.0

Top   Top   None   None   Next
0…   6…


0  Introductionp. 5

During the course of Release 7, TS 23.206 [3] (Voice Call Continuity between CS and IMS) was developed to provides the capability to offer VCC (Voice Call Continuity) for a subscriber moving from a CS radio environment into a VoIP-capable IMS radio environment connected by an IP CAN. However, for a variety of reasons, the TS specifically excludes the capability of allowing emergency calls to be subject to domain transfer. This TR documents alternatives for how to provide such voice call continuity between the CS Domain and IP CANs for emergency calls.

1  Scopep. 6

This document contains the results of the feasibility study into the architectural requirements and alternatives for the support of active voice call continuity between Circuit Switched (CS) domain and the IP Multimedia Subsystem (IMS) for emergency calls. Considerations include overall requirements, architectural requirements, evaluation of potential architectural solutions and alternative architectures.
The Feasibility Study considers different solutions for offering voice call continuity for emergency calls when users move between the GSM/UMTS CS Domain and the IP Connectivity Access Network (e.g., WLAN interworking) with home IMS functionality. The objective is to identify an architectural solution that allows completely automatic connectivity to the correct PSAP (from the end-user point of view) as specified in TS 23.167, and allow for the possibility of a domain transfer as specified in TS 23.206 [3]. The study will also identify configuration impacts upon existing networks in order to realize the desired functionality.
Existing solutions developed by the 3GPP (e.g. 3GPP system to Wireless Local Area Network Interworking (I-WLAN)) should be reused as much as possible.

2  Referencesp. 6

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.
TR 41.001: "GSM Release specifications".
→ to date, withdrawn by 3GPP
TS 23.234: "3GPP system to Wireless Local Area Network (WLAN) interworking".
TS 23.206: "Voice Call Continuity between CS and IMS".
TS 23.167: "IMS Emergency Calls".
TS 23.226: "Global Text Telephony (GTT)".
RFC 4483:  "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages".
TR 23.892: "IMS Centralized Services".
TR 21.905: "Vocabulary for 3GPP Specifications".
RFC 4119:  "A Presence-based GEOPRIV Location Object Format".
TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2".
TS 23.271: "Functional stage 2 description of Location Services (LCS)".
TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3".
TS 23.237: " IP Multimedia Subsystem (IMS) Service Continuity; Stage 2".
TS 22.101: "Service aspects; Service principles".

3  Definitions, symbols and abbreviationsp. 7

3.1  Definitionsp. 7

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
A Remote User Agent (see TR 23.892) which resides in the serving IMS network and presents an Emergency Call established via the CS domain as an IMS Emergency Call to the E-CSCF.

3.2  Abbreviationsp. 7

For the purposes of the present document, the abbreviations given in TR 21.905 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.
Voice Call Continuity
Interworking WLAN
Wireless Local Area Network
IMS CS Control Function
Remote User Agent
Emergency RUA
Subscriber Location Report

4  Overall Requirementsp. 7

4.1  Service Characteristicsp. 7

It is intended to develop capabilities that will allow the domain transfer of emergency calls in both the CS to IMS and IMS to CS directions. A minimal requirement is the support of VCC for emergency calls originated in the home PS domain. The following characteristics also need to be evaluated:
  1. Emergency calls originated in the CS domain.
  2. Roaming scenarios.
  3. UEs that cannot be authenticated (e.g., UICC-less or with no roaming agreement).

5  Architectural Requirements and Considerationsp. 7

5.1  Basic Assumptionsp. 7

5.2  Architectural Requirementsp. 7

  1. The use of GTT device (e.g., TTY) for CS emergency call TS 23.226 needs to be considered. The solution shall not require changes to the TTY device or the interface toward the terminal.
  2. The solution shall be based on domain transfer procedures specified in Rel-07 VCC TS 23.206 [3].
  3. The solution shall consider support of domain transfers of emergency Calls in areas where multiple visited IMS networks may be available to the user.
  4. Support of the solution shall be optional in the UE and network. A UE or network that does not support the solution shall not be impacted.
  5. The solution should be able to provide continuity of location support following domain transfer by providing the PSAP with an accurate initial and updated location estimate, according to applicable regional requirements and subject to the constraints of the PSAP interface.
  6. The VCC procedure should be triggered only when both the UE and visited network (both the source and target access technology) support VCC for emergency calls.
  7. VCC for emergency shall only be attempted for intra-operator transitions (where IMS and CS core operators are the same).
  8. Emergency calls shall not be transitioned from CS to IMS.
  9. UE shall not attempt to perform transfer of an emergency call if it is not certain the relevant capabilities are supported by the network.
  10. Emergency calls are not automatically anchored for VCC unless they meet certain criteria that are to be defined.

5.3  Session Scenariosp. 8

5.3.1  Network preferences for the domain in which an emergency call is establishedp. 8

There are some basic forms of network preferences in existing IMS procedures e.g. it is possible to redirect a UE to use the CS domain for emergency calls and forbid the use of IMS for emergency calls. However, when these are considered in VCC these do not make too much sense since in order to perform VCC you must be allowed to establish emergency calls in both CS and IMS. However, a network operator may still have a preference as to which domain an emergency call ought to be on.
It is necessary to consider how these preferences relate to decision to transition from one access to the next. One key question is whether the network preferences take precedence over other typical reasons for transition e.g. degrading radio conditions. It is envisioned/assumed that device management is used to configure the different network preferences, but does this also extend to the other triggers
It is necessary to specify what are the likely trigger conditions for a transition, since this a safety critical service and needs to be error-free. The type of handover is different from normal 3GPP radio level handover since VCC is UE triggered, but still need to be equally detailed (e.g. signal strength hysteresis regimes).

5.3.2  Control of directionality of the transferp. 8

Taking a comparison with mobility in a "normal" mode of operation, it is possible to apply access restrictions during mobility. This ought to be equally true in the emergency call scenario, although the reason behind such restrictions during mobility will be different.
In direct relation to the above topic of network preferences, there may be certain scenarios where a visited operator prefers to have emergency calls in CS (due to a CS only PSAP potentially) and as such the need for CS to IMS domain transfer is unclear.
One could also consider that CS "coverage" is much greater than for the non-3GPP access that is using IMS for call establishment. Therefore the justification for CS to IMS transfers again is not so obvious.

5.3.3  UE and network capabilitiesp. 8

The ability to perform the domain transfer on any call (irrespective of whether it is emergency or not) is driven by both network and UE capabilities. For non-emergency calls, typically no CS core network functionality is required since the solution is purely IMS driven. However in contrast for emergency calls, it is likely that CS core network functionality is required due to the need to carry information necessary for support of the UICC-less UE case across to IMS for anchoring during both call establishment and during domain transfer.
Blind attempts by UEs (especially those in a limited service state i.e. no UICC or invalid credentials) to perform VCC transfer of emergency calls should be avoided where the UE cannot or has not established the status of the support of network features required. This is due to the undefined/unpredictable behaviour if the network does not support VCC features that may lead to call transfer failures or treatment as a new call establishment.

5.3.4  Decision to anchor a new emergency call for subsequent VCC proceduresp. 9

The anchoring of a call in IMS (at the E-SCC-AS) is vital to enable the transfer of the call from one domain to another. This concept does not change in VCC emergency. Anchoring of a CS call introduces call setup delay and increases network complexity (which ultimately leads to an increased probably of a failure). Therefore anchoring should not be considered to be applied for all calls but rather it should be avoided when the conditions allow for a call not to be anchored. The decision process must take into account all the points discussed in clauses 5.3.1, 5.3.2 and 5.3.3.

5.3.5  Determination of whether a call attempt is new or VCC domain transferp. 9

In (dual-radio) VCC (emergency or not), the trigger point for domain transfer is firmly at the UE. This needs to coexist with a basic principle that an initial emergency call is always established by the UE. However, when discussing this, it becomes important for the network to differentiate between any incoming call attempt as related to either a new call initiation or a domain transfer.
For initial call establishment in CS, TS12 style signalling (i.e. Service Request = Emergency) will still be used as per TS 22.101. For domain transfers, the same signalling means may be used, however, this makes determination of the nature of the call very difficult without extensions.
If a call is incorrectly identified, there is a possibility that there is no continuity and a new session / call (at user level) is established and the caller required to re-provide any information to a new operator (at the PSAP end). Furthermore, because of unexpected call termination for the old operator, they may attempt a call back which would almost certainly fail. If these potential error cases aren't avoided, there may be potential service interaction issues between 2 TS12 calls which had not been previously envisioned (even though there is a possibility for them to occur).

5.3.6  Inter-operator domain transferp. 9

Due to the duty of care residing with the operator providing initial connectivity to the emergency services, it is generally not possible to transfer that duty from one operator to another. Also different operators may connect to different PSAPs which in turn may ultimate connect to a different set of physical operators. It is suggested that VCC for emergency calls are attempted only when the UE can identify that the source and target networks belong to the same network (operator). This ensures the continuity of an emergency call when performing domain transfers.

Up   Top   ToC