Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TR 23.885  Word version:  11.0.0

Top   Top   None   None   Next
1…   5… 
1 Scope  2 References  3 Definitions and abbreviations  4 Requirements and Assumptions 
...

 

1  Scope  p. 7

The objective of the feasibility study is to investigate a solution for supporting Single Radio Voice Call Continuity (SRVCC) from 3GPP UTRAN/GERAN CS access to 3GPP E-UTRAN/HSPA access, for voice call initiated in LTE/HSPA access and previously handed over to UTRAN/GERAN CS access, as well as for the voice call directly initiated in UTRAN/GERAN CS access.
This Technical Report investigates solutions for SRVCC for voice calls that are anchored in the IMS.
Coordination between the SRVCC for voice call and the handover of non voice PS bearers is also covered.
Up

2  References  p. 7

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 22.278: "Service requirements for the Evolved Packet System (EPS)".
[3]
TS 23.292: "IP Multimedia System (IMS) centralized services; Stage 2".
[4]
TS 23.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 2".
[5]
TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
[6]
TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[7]
TS 23.216: " Single Radio Voice Call Continuity (SRVCC): Stage 2".
[8]
TR 23.856: "Feasibility study of SR-VCC enhancements".
[9]
TS 23.221: "Architectural requirements (Release 9)".
[10]
TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3".
[11]
TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
[12]
TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling".
[13]
TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol".
[14]
TS 29.280: "Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and SGSN to MSC) for SRVCC".
Up

3  Definitions and abbreviations  p. 8

3.1  Definitions  p. 8

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.
Reverse Single Radio Voice Call Continuity:
Voice call continuity from UTRAN/GERAN access to IMS over E-UTRAN/HSPA access for calls that are anchored in IMS when the UE is capable of transmitting/receiving on only one of those access networks at a given time. This is also referred to as Single Radio Voice Call Continuity from E-UTRAN/HSPA to UTRAN/GERAN in this technical report.
Single Radio Voice Call Continuity:
Voice call continuity from IMS over E-UTRAN/HSPA access to UTRAN/GERAN access for calls that are anchored in IMS when the UE is capable of transmitting/receiving on only one of those access networks at a given time. This is also referred to as Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA in this technical report.
Service Continuity:
see TS 22.278.
Up

3.2  Abbreviations  p. 8

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.
rSRVCC
Reverse Single Radio Voice Call Continuity
SRVCC
Single Radio Voice Call Continuity

4  Requirements and Assumptions  p. 8

4.1  Assumptions  p. 8

For SRVCC from 3GPP UTRAN/GERAN CS access to 3GPP E-UTRAN/HSPA access shall re-use existing functions defined for SRVCC from E UTRAN/HSPA to UTRAN/GERAN in TS 23.216 as much as possible. The solution shall minimize impacts to Rel 8 SRVCC mechanisms. The results of the study on performance enhancements in TR 23.856 shall be taken into account in this study. The following scenarios shall be studied:
  • SRVCC from GERAN without DTM support to E-UTRAN.
  • SRVCC from UTRAN/GERAN with PS HO support to E-UTRAN.
  • SRVCC from GERAN without DTM support to UTRAN (HSPA).
  • SRVCC from UTRAN/GERAN with PS HO support to UTRAN (HSPA).
It is assumed that the support of IMS voice over PS Session is homogeneous in the E-UTRAN network.
Up

4.2  Architectural requirements  p. 8

  • The rSRVCC solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs.
  • Impact on user service quality experience, e.g. QoS, call drop, interruption time, should be minimized.
  • Overall duration of the 3GPP UTRAN/GERAN CS access to 3GPP E-UTRAN/HSPA access handover procedure shall be minimized.
  • RAT/domain selection change shall be network initiated and under network control.
  • In case where the UE has disabled its E-UTRAN capability due to mismatch with the voice capabilities of the network, it shall be able for the UE to re-enable its E-UTRAN capability.
  • It shall be possible to restrict RAT/domain selection change to specific access systems and specific subscribers, depending on operator policies (for example restrict handover of voice calls from UTRAN/GERAN CS access to PS domain)and capabilities of the network and the UE, and these shall be network initiated and under network control .
  • In roaming cases, the VPLMN shall be able to control the RAT/domain selection change while taking into account any related HPLMN policies. In particular, the HPLMN shall be able to restrict handover to PS domain for a given VPLMN.
  • E-UTRAN shall not be required to convert any CS specific RAB information for rSRVCC operation.
  • Handovers from UTRAN/GERAN CS access to E-UTRAN/HSPA for voice call initiated in LTE and previously handed over to UTRAN/GERAN CS access as well as for voice calls directly initiated in UTRAN/GERAN CS access shall be supported, provided that the calls have been anchored in IMS at the time of their establishment (for example in the case of voice calls directly initiated in UTRAN/GERAN CS access the MSC Server has been enhanced for ICS).
  • The signalling to the HPLMN for inter-domain handover in the VPLMN should be minimized.
  • Impacts to Rel-10 SRVCC mechanisms shall be minimized.
  • For calls that have been handed over from PS via SRVCC, provided that the UE and the network support rSRVCC procedures, rSRVCC should be possible no matter which SRVCC Release 10 procedure applied:
    • ATCF with media anchored in the ATGW
    • ATCF without media anchored in the ATGW
    • ATCF not included at registration or no ATCF (i.e. SRVCC Release 9 architecture)
  • In case of active PS bearer(s) on UTRAN/GERAN, PS bearer handover to E-UTRAN/HSPA shall be handled as specified in TS 23.401 in conjunction with SRVCC to E-UTRAN/HSPA as specified in TS 23.216. The rSRVCC solution shall not impact the PS bearer handover.
  • The solution shall be applicable to networks where UTRAN/GERAN PS domain cannot provide IMS voice service.
  • After transfer from UTRAN/GERAN CS domain to E-UTRAN/HSPA PS-domain, it shall support moving the session back to UTRAN/GERAN CS domain..
  • The solution shall support the MSC to initiate reverse SRVCC due to traffic reasons (e.g., for capacity reason, re-enabling high speed broadband access when LTE is available)
  • The solution shall support the UE to return to the source BSS/RAN when HO failed and shall not cause any audible disruption on the voice call.
Up

4.3  Performance requirements  p. 9

The RAT change procedure executed to enable Service Continuity for an established voice call shall target an interruption time not higher than 300 ms.

4.4  Reverse SRVCC deployment scenarios  p. 10

This section details the most likely reasons that can lead operators to deploy rSRVCC, and the handover scenarios which are most important in the different cases:
  1. Providing users better service:
    As packet services are better provided over E-UTRAN/HSPA, the operator deploys rSRVCC to make sure that users get service on E-UTRAN/HSPA as soon as E-UTRAN/HSPA becomes available (i.e. typically when the E-UTRAN/HSPA cell quality is better than a given threshold).
  2. Optimizing network usage:
    The operator wants to minimize the CS core network usage and to optimize the radio network usage, so it chooses to handover calls to PS as soon as E-UTRAN/HSPA becomes available. (i.e. typically when the E-UTRAN/HSPA cell quality is better than a given threshold)
  3. Enhancing coverage:
    The operator wants to enhance its radio coverage by adding the possibility to handover calls to E-UTRAN where GERAN/UTRAN coverage is getting weak.
    It could either be that the E-UTRAN cell quality is getting better than the GERAN/UTRAN cell quality, or that the GERAN/UTRAN cell quality gets worse than a given threshold, while the E-UTRAN cell quality is better than another one.
It is expected that scenarios 1) and 2) will be the most common, and consequently, that even if coverage triggered rSRVCC handovers are expected to occur, they should not be the most frequent.
Up

Up   Top   ToC