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  TS 23.216  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.2.4…   4.2.6…   5…   5.2.4…   5.3…   6…   6.2…   6.2.2.2…   6.3…   6.3.2.2   6.4…   6.5…   7…   A… 
4 High level Principles and Concepts  4.1 High level Principles  4.1.1 Architectural Principles for 3GPP2 1xCS SRVCC  4.1.2 Architectural Principles for SRVCC and vSRVCC to 3GPP UTRAN/GERAN  4.1.3 Architectural Principles for SRVCC to 3GPP E-UTRAN/UTRAN (HSPA)  4.1.4 Architectural Principles for 5G-SRVCC to UTRAN 
...

 

4  High level Principles and Concepts  p. 11

4.1  High level Principles  p. 11

4.1.1  Architectural Principles for 3GPP2 1xCS SRVCC  p. 11

The solution for SRVCC fulfils the requirements of TS 22.278 and the following architectural principles:
  1. The solution shall allow coexistence and be compatible with the 1xCS procedures specified in the 3GPP2 VCC specification, X.S0042 [4].
  2. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs.
  3. The solution shall be transparent to E-UTRA only terminal or network.
  4. The solution shall minimize the coupling between the E-UTRAN and the 3GPP2 access. In particular, the solution shall allow the cdma2000 1xRTT specification to evolve without necessitating a modification to the E-UTRAN specifications.
  5. RAT change and domain selection should be under network control.
  6. In roaming cases, the Visited PLMN should control the RAT change and/or domain selection while taking into account any related HPLMN policies.
  7. The solution shall not impact cdma2000 RAT.
  8. The solution shall not impact cdma2000 CS CN.
  9. All IMS sessions that may be subject to SRVCC shall be anchored in the IMS (VCC Application).
  10. When SRVCC is deployed, QCI=1:
    • shall not be used for IMS sessions that are not anchored in the IMS (VCC Application); and
    • shall only be used for the voice bearer.
Up

4.1.2  Architectural Principles for SRVCC and vSRVCC to 3GPP UTRAN/GERAN  p. 12

The solution for (v)SRVCC fulfils the requirements of TS 22.278 and the following architectural principles:
  1. The solution shall allow coexistence and be compatible with TS 23.292 and TS 23.237.
  2. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs.
  3. RAT change and domain selection should be under network control.
  4. E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN CS handover for SRVCC is triggered by the same radio handover conditions and mechanisms as for an E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN PS handover.
  5. The Video Call by IMS over E-UTRAN is the IMS session with bi-directional video and voice media e.g. IMS Multimedia Telephony as defined in TS 22.173 which uses separate EPS bearers for video and voice components, respectively.
  6. In roaming cases, the VPLMN shall be able to control the RAT/domain selection change while taking into account any related HPLMN policies for IMS sessions with bi-directional video and voice media e.g. IMS Multimedia Telephony as defined in TS 22.173.
  7. All IMS sessions that may be subject to (v)SRVCC shall be anchored in the IMS (SCC AS).
  8. When SRVCC is deployed, QCI=1 / traffic-class 'Conversational' with Source Statistics Descriptor ='speech':
    • shall not be used for IMS sessions that are not anchored in the IMS (SCC AS); and
    • shall only be used for the voice bearer.
Up

4.1.3  Architectural Principles for SRVCC to 3GPP E-UTRAN/UTRAN (HSPA) |R11|  p. 12

The solution for CS to PS SRVCC fulfils the following architectural principles in addition to the ones defined in clause 4.1.2:
  • A CS to PS SRVCC procedure shall be possible for CS call that is originated from UTRAN/GERAN.
  • After transfer from CS to PS SRVCC, it shall support moving the session back to UTRAN/GERAN CS domain if SRVCC from E-UTRAN/HSPA PS-domain is supported.
  • A CS to PS SRVCC procedure shall be possible after SRVCC from E-UTRAN/HSPA PS-domain to CS domain has occurred.
  • Emergency session is not subjected to CS to PS SRVCC procedure.
A prerequisite for the CS to PS SRVCC procedure to take place is that the UE is registered in IMS and has at least one PS bearer (usable for SIP signalling).
Up

4.1.4  Architectural Principles for 5G-SRVCC to UTRAN |R16|  p. 13

The solution for 5G-SRVCC fulfils the requirements of TS 22.278 and the following architectural principles:
  1. The solution shall not require UE with multiple RATs capability to simultaneously signal on two different RATs.
  2. RAT change and domain selection should be under network control.
  3. NG-RAN to UTRAN CS handover for 5G-SRVCC is triggered by radio handover conditions.
  4. All IMS sessions that may be subject to 5G-SRVCC shall be anchored in the IMS (SCC AS).
  5. In roaming cases, the VPLMN shall be able to control the RAT/domain selection and change while taking into account any related HPLMN policies for IMS sessions with voice media.
  6. SRVCC is not applicable for IMS Data Channel. Only associated voice and/or video media may get transferred to UTRAN.
Up

Up   Top   ToC