TS 123 292 - V13.2.0 - Digital cellular telecommunications ... · PDF file7.2 Registration ......

ETSI TS 1

Digital cellular telecommUniversal Mobile Tel

IP Multimedia Subs

(3GPP TS 23.2

TECHNICAL SPECIFICATION

123 292 V13.2.0 (2016

mmunications system (Phase elecommunications System (

LTE; bsystem (IMS) centralized ser

Stage 2 .292 version 13.2.0 Release 13

ION

16-03)

e 2+) (GSM); (UMTS);

ervices;

13)

ETSI

ETSI TS 123 292 V13.2.0 (2016-03)13GPP TS 23.292 version 13.2.0 Release 13

Reference RTS/TSGS-0223292vd20

Keywords LTE, GSM, UMTS

ETSI

650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88

Important notice

The present document can be downloaded from: http://www.etsi.org/standards-search

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any

existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx

Copyright Notification

No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.

The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.

All rights reserved.

DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and

of the 3GPP Organizational Partners. GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

http://www.etsi.org/standards-search

http://portal.etsi.org/tb/status/status.asp

https://portal.etsi.org/People/CommiteeSupportStaff.aspx

ETSI


Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https://ipr.etsi.org/).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.

Modal verbs terminology In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

https://ipr.etsi.org/

http://webapp.etsi.org/key/queryform.asp

http://portal.etsi.org/Help/editHelp!/Howtostart/ETSIDraftingRules.aspx

ETSI


Contents

Intellectual Property Rights ................................................................................................................................ 2

Foreword ............................................................................................................................................................. 2

Modal verbs terminology .................................................................................................................................... 2

Foreword ............................................................................................................................................................. 7

1 Scope ........................................................................................................................................................ 8

2 References ................................................................................................................................................ 8

3 Definitions and abbreviations ................................................................................................................. 10

3.1 Definitions ........................................................................................................................................................ 10

3.2 Abbreviations ................................................................................................................................................... 11

4 High level principles and requirements .................................................................................................. 11

4.1 General ............................................................................................................................................................. 11

4.2 Service consistency .......................................................................................................................................... 12

4.3 Service continuity ............................................................................................................................................. 12

4.4 Session scenarios .............................................................................................................................................. 12

4.4.1 Overview .................................................................................................................................................... 12

4.4.2 ICS UE Session Scenarios .......................................................................................................................... 12

4.5 Service settings data management .................................................................................................................... 12

4.6 Identities ........................................................................................................................................................... 13

4.6.1 Identities used by an ICS UE ...................................................................................................................... 13

4.6.2 Identities used by an MSC Server enhanced for ICS .................................................................................. 13

4.7 Coexistence of an ICS UE and a non ICS UE .................................................................................................. 13

4.8 Routing of originated calls to IMS ................................................................................................................... 13

4.9 Void .................................................................................................................................................................. 13

5 Architecture model and reference points ................................................................................................ 14

5.1 Overview .......................................................................................................................................................... 14

5.2 Reference architecture ...................................................................................................................................... 14

5.3 Functional Entities ............................................................................................................................................ 14

5.3.1 SCC AS ....................................................................................................................................................... 14

5.3.2 UE enhanced for ICS .................................................................................................................................. 16

5.3.3 MSC Server enhancements for ICS ............................................................................................................ 17

5.4 Reference points ............................................................................................................................................... 17

5.4.1 Reference Point UE – SCC AS (I1) ............................................................................................................ 17

5.4.2 Reference Point MSC Server – CSCF (I2) ................................................................................................. 17

5.4.3 Reference Point MSC server – CS-MGW (Mc) ......................................................................................... 17

5.4.4 Reference Point MSC Server - TAS (I3) .................................................................................................... 18

6 Functional description ............................................................................................................................ 18

6.1 Common IMS Functions .................................................................................................................................. 18

6.1.1 P-CSCF procedures..................................................................................................................................... 18

6.1.2 IMS ALG procedures.................................................................................................................................. 18

6.1.3 S-CSCF procedures..................................................................................................................................... 18

6.1.4 IBCF procedures ......................................................................................................................................... 18

7 Procedures and flows.............................................................................................................................. 18

7.0 General ............................................................................................................................................................. 18

7.1 Signalling and bearer paths .............................................................................................................................. 18

7.1.1 Sessions established using the Gm or I1 reference point ............................................................................ 18

7.1.2 Sessions established using CS call control and MSC Server ...................................................................... 20

7.2 Registration ...................................................................................................................................................... 21

7.2.1 IMS registration via CS access ................................................................................................................... 21

7.2.1.1 Overview ............................................................................................................................................... 21

7.2.1.2 Registration using I2 reference point .................................................................................................... 22

7.2.1.3 Deregistration using I2 reference point ................................................................................................. 23

ETSI


7.2.1.4 Registration after Deregistration using I2 reference point .................................................................... 24

7.2.1.5 Registration before Deregistration using I2 reference point ................................................................. 25

7.2.2 IMS Registration via IP-CAN ..................................................................................................................... 26

7.3 Originations ...................................................................................................................................................... 27

7.3.1 Originating sessions that use PS media....................................................................................................... 27

7.3.2 Originating sessions that use CS media ...................................................................................................... 27

7.3.2.1 Non ICS UE originating sessions that use CS media ............................................................................ 27

7.3.2.1.1 Overview ......................................................................................................................................... 27

7.3.2.1.2 Origination using I2 reference point ................................................................................................ 27

7.3.2.1.3 Origination when using an MSC Server .......................................................................................... 28

7.3.2.2 ICS UE Originating sessions that use CS media ................................................................................... 30

7.3.2.2.1 Overview ......................................................................................................................................... 30

7.3.2.2.2 Originations with CS media when using I1 ..................................................................................... 31

7.3.2.2.3 Originations with CS media when not using I1 ............................................................................... 36

7.3.2.2.4 Originations with CS media using the Gm reference point ............................................................. 36

7.4 Terminations ..................................................................................................................................................... 39

7.4.1 Terminating sessions that use PS media ..................................................................................................... 39

7.4.1.1 Full duplex speech via PS ..................................................................................................................... 39

7.4.1.2 Void....................................................................................................................................................... 39

7.4.1.3 Void....................................................................................................................................................... 39

7.4.2 Terminating sessions that use CS media ..................................................................................................... 39

7.4.2.1 Non ICS UE terminating sessions that use CS media ........................................................................... 39

7.4.2.1.1 Overview ......................................................................................................................................... 39

7.4.2.1.2 Termination using I2 reference point .............................................................................................. 40

7.4.2.1.3 Termination to non ICS UE not registered in IMS .......................................................................... 41

7.4.2.2 ICS UE Terminating sessions that use CS media .................................................................................. 42

7.4.2.2.1 Overview ......................................................................................................................................... 42

7.4.2.2.2 Terminations with CS media using the Gm reference point ............................................................ 42

7.4.2.2.3 Terminations with CS media using the I1 reference point .............................................................. 47

7.4.2.2.4 Terminations with CS media using CS control with I1 augmentation............................................. 52

7.4.2.2.5 Terminations with CS media when not using Gm or I1 .................................................................. 52

7.4.2.2.6 Void ................................................................................................................................................. 52

7.4.2.2.7 Terminating access network reselection – fallback to alternate access ........................................... 52

7.4.3 Terminating sessions over Gm rejected by the UE ..................................................................................... 53

7.5 Service continuity ............................................................................................................................................. 55

7.5.1 Service continuity for ICS UE .................................................................................................................... 55

7.5.1.1 Service continuity while maintaining the use of CS access for the media ............................................ 55

7.5.1.1.1 IMS sessions established using Gm reference point ........................................................................ 55

7.5.1.2 Service continuity when transferring the media of IMS sessions between PS and CS access .............. 56

7.5a Addition of Gm service control to existing call................................................................................................ 56

7.5a.1 Overview .................................................................................................................................................... 56

7.5a.2 Augmentation call flow .............................................................................................................................. 56

7.6 Consistency of Supplementary Services ........................................................................................................... 57

7.6.0 General ........................................................................................................................................................ 57

7.6.1 Supplementary Services for ICS UE ........................................................................................................... 57

7.6.1.1 Overview ............................................................................................................................................... 57

7.6.1.2 IMS sessions using CS bearer ............................................................................................................... 58

7.6.1.2.1 Overview ......................................................................................................................................... 58

7.6.1.2.2 Use of Gm reference point............................................................................................................... 58

7.6.1.2.3 Use of I1 reference point ................................................................................................................. 66

7.6.1.2.4 When use of Gm or I1 reference point is not possible due to VPLMN limitations ......................... 76

7.6.1.3 User configuration of Supplementary Services ..................................................................................... 76

7.6.2 Supplementary service invocation using the MSC Server enhanced for ICS ............................................. 76

7.6.2.1 Overview ............................................................................................................................................... 76

7.6.2.2 Line ID Services (OIP, OIR, TIP, TIR) ................................................................................................ 76

7.6.2.3 Communication Diversion Services ...................................................................................................... 76

7.6.2.3.1 Communication Forwarding Unconditional (CFU) ......................................................................... 76

7.6.2.3.2 Communication Forwarding Busy (CFB) ....................................................................................... 76

7.6.2.3.3 Communication Forwarding No Reply (CFNR) ............................................................................. 77

7.6.2.3.4 Communication Forwarding on Not Logged-in (CFNL) ................................................................. 77

7.6.2.3.5 Communication Deflection (CD) .................................................................................................... 77

7.6.2.3.6 Communication Forwarding on Subscriber Not Reachable (CFNRc) ............................................. 77

ETSI


7.6.2.3.7 Communication Diversion Notification (CDIVN) .......................................................................... 77

7.6.2.3.8 Diversion notifications to originating users ..................................................................................... 77

7.6.2.4 Communication Barring ........................................................................................................................ 77

7.6.2.5 Communication Hold/Resume .............................................................................................................. 77

7.6.2.6 Communication Waiting ....................................................................................................................... 79

7.6.2.7 Explicit Communication Transfer ......................................................................................................... 80

7.6.2.8 Conferencing ......................................................................................................................................... 85

7.6.2.9 User configuration of communication service settings ......................................................................... 87

7.6.2.9.1 TAS procedures ............................................................................................................................... 87

7.6.2.9.2 UE supporting multimedia telephony .............................................................................................. 87

7.6.2.9.3 MSC Server enhanced for ICS ........................................................................................................ 87

7.6.2.10 Customized Alerting Tone (CAT) ......................................................................................................... 87

7.6.2.11 Communication Completion on Busy Subscriber/No Reply/Not Logged In ........................................ 87

7.6.2.11.1 Communication Completion Terminated at Served User ................................................................ 87

7.6.2.11.2 Communication Completion Originated at Served User ................................................................. 89

7.6.3 Service consistency for non ICS UE when attached to an MSC Server not enhanced with ICS ................ 90

7.6.3.1 Line ID Services (OIP, OIR, TIP, TIR) ................................................................................................ 90

7.6.3.2 Communication Diversion Services ...................................................................................................... 90

7.6.3.2.1 Communication Diversion services; CFU, CFNL ........................................................................... 90

7.6.3.2.2 Communication Diversion services; CFNR, CFB ........................................................................... 90

7.6.3.2.2a Communication Diversion services; CFNRc ................................................................................... 90

7.6.3.2.3 Communication Diversion services; Communication Deflection ................................................... 90

7.6.3.3 Communication Barring ........................................................................................................................ 90

7.6.3.4 Communication Hold/Resume .............................................................................................................. 90

7.6.3.5 Explicit Communication Transfer ......................................................................................................... 91

7.6.3.6 Conferencing ......................................................................................................................................... 91

7.6.3.7 User configuration of Supplementary Services ..................................................................................... 91

7.6.3.7.1 UE not supporting multimedia telephony ........................................................................................ 91

7.6.3.7.2 UE supporting multimedia telephony .............................................................................................. 91

7.6.3.8 Customized Alerting Tone (CAT) ......................................................................................................... 91

7.6.3.9 Communication Waiting ....................................................................................................................... 91

7.6.3.10 Communication Completion on Busy Subscriber/No Reply/Not Logged In ........................................ 91

7.6.3.10.1 Communication Completion Terminated at Served User ................................................................ 91

7.6.3.10.2 Communication Completion Originated at Served User ................................................................. 93

7.7 Session Release ................................................................................................................................................ 94

7.7.1 Session Release for ICS UE ........................................................................................................................ 94

7.7.1.1 General Gm Procedures ........................................................................................................................ 94

7.7.1.2 Session Release for Gm and I1 ............................................................................................................. 94

7.7.1.3 Release of the Service Control Signalling Session when using I1 ........................................................ 95

7.7.1.3.1 ICS UE Initiated Release ................................................................................................................. 95

7.7.1.3.2 Network Initiated Release ............................................................................................................... 96

7.7.1.3.3 Far End Initiated Release ................................................................................................................. 97

7.7.2 Session Release for MSC Server enhanced for ICS ......................................................................................... 98

7.7.2.1 General .................................................................................................................................................. 98

7.7.2.2 Session Release by served UE .............................................................................................................. 98

7.7.2.3 Session Release by far-end .................................................................................................................... 99

7.7.2.4 Network initiated Session Release ........................................................................................................ 99

7.8 Loss of Gm capability .................................................................................................................................... 100

7.9 Addition/Removal of video media flow ......................................................................................................... 101

7.9.1 Addition/Removal of video media flow for Non ICS UE ......................................................................... 101

7.9.1.1 Overview ............................................................................................................................................. 101

7.9.1.2 Addition/Removal of video media flow through SCUDIF using I2 reference point ........................... 101

7.9.1.3 Addition/Removal of video media flow through SCUDIF via the MSC Server not enhanced for ICS ...................................................................................................................................................... 102

7.9.2 Addition/Removal of video media flow for ICS UE ................................................................................ 103

7.9.2.1 Overview ............................................................................................................................................. 103

7.9.2.2 Addition/Removal of video media flow through SCUDIF using Gm Reference Point ...................... 103

7.9.2.3 Addition/Removal of video media flow through SCUDIF using I1 Reference Point ......................... 103

7.9.2.4 Addition/Removal of video media flow through redial using Gm Reference Point ............................ 104

7.9.2.5 Addition/Removal of video media flow through redial using I1 Reference Point .............................. 106

8 Charging ............................................................................................................................................... 109

ETSI


8.1 General description......................................................................................................................................... 109

8.2 Offline charging ............................................................................................................................................. 109

8.3 On-line charging ............................................................................................................................................. 109

9 Security Considerations ........................................................................................................................ 109

9.1 Access security ............................................................................................................................................... 109

9.2 Network Domain Security .............................................................................................................................. 109

Annex A (informative): Service Consistency...................................................................................... 111

Annex B (informative): ICS functions in different deployment scenarios ...................................... 112

Annex C (informative): Communication Deflection support when call has been delivered using CS call control .................................................................................... 114

Annex D (informative): Conditional Call Forwarding support when call has been delivered using CS call control .................................................................................... 115

Annex E (informative): Using MRF for media process .................................................................... 116

Annex F (informative): Call diversion from CS to IMS ................................................................... 117

F.1 General ................................................................................................................................................. 117

F.2 Implementation options for call diversion from CS to the IMS ........................................................... 117

F.3 Implementation options for prevention of circular looping of CS Terminations ................................. 118

Annex G: Change history .................................................................................................................... 120

History ............................................................................................................................................................ 121

ETSI


Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

ETSI


1 Scope This document specifies the architectural requirements for delivery of consistent services to the user regardless of the attached access type (e.g. CS domain access, or IP-CAN). This is achieved by implementing the services in the IP Multimedia Subsystem (IMS).

Consideration is given to how to access specified IMS-based services (see clause 22.4 of TS 22.101 [9]) whilst still allowing other, bespoke services to be offered by the home operator.

IMS control of services related to those defined in clause 22.4 of TS 22.101 [9] are part of the present scope of this specification. However, IMS control of all other types of calls, including emergency calls that utilise TS12, are outside the scope of the present release of this specification.

The scope of the specification includes:

- Session establishment when using CS access for media transmission for an IMS service.

- Support of Service Continuity as specified in TS 23.237 [12].

- Support of Single Radio Voice Call Continuity as specified in TS 23.216 [36].

- Access Domain Selection (ADS).

- IMS control of services where the media is transported via the CS network (e.g. managing of mid-call services).

- Service data management.

The solution is applicable for UEs with or without ICS functionality, and is applicable for the following deployment scenarios:

- An operator who supports for their subscribers only UEs that have ICS functionality.

- An operator who supports for their subscribers only UEs that do not have ICS functionality.

- An operator who supports for their subscribers UEs which do and do not have ICS functionality (to different subscribers and the same subscribers) ensuring the coexistence of UEs that have and do not have ICS functionality.

- Inbound roaming subscribers on an operator's network that supports either the same or different ICS functionality that the inbound roaming subscriber is using, ensuring the coexistence of UEs that have and do not have ICS functionality.

2 References 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] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[2] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS)".

[3] 3GPP TS 23.002: "Network architecture".

ETSI


[4] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services".

[5] 3GPP TS 23.003: "Numbering, addressing and identification".

[6] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3".

[7] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2".

[8] 3GPP TS 24.173: "IMS Multimedia Telephony Communication Service and Supplementary Services; Stage 3".

[9] 3GPP TS 22.101: "Services Aspects; Service Principles".

[10] 3GPP TS 23.221: "Architectural requirements".

[11] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks".

[12] 3GPP TS 23.237: "IP Multimedia Subsystem (IMS) service continuity".

[13] 3GPP TS 24.081: "Line Identification Supplementary Services - Stage 3"

[14] 3GPP TS 24.082: "Call Forwarding supplementary service; Stage 3".

[15] 3GPP TS 24.072: "Call Deflection (CS) Supplementary Service; Stage 3".

[16] 3GPP TS 24.088: "Call Barring (CB) Supplementary Service - Stage 3".

[17] 3GPP TS 26.114: "A IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction".

[18] 3GPP TS 24.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 3".

[19] 3GPP TS 24.091: "Explicit Call Transfer (ECT) supplementary service; Stage 3".

[20] 3GPP TS 24.084: "Multi Party supplementary service - Stage 3".

[21] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3".

[22] 3GPP TS 23.009: "Handover Procedures".

[23] 3GPP TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling"

[24] OMA-ERELD-DM-V1_2-20060602-C: "Enabler Release Definition for OMA Device Management, Candidate Version 1.2".

[25] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions".

[26] 3GPP TS 24.604: "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem Protocol specification".

[27] 3GPP2 C.S0001-D: "Introduction to cdma2000 Spread Spectrum Systems - Revision D".

[28] 3GPP TS 24.611: "Anonymous Communication Rejection (ACR) and Communication Barring (CB); using IP Multimedia (IM) Core Network (CN) subsystem Protocol specification".

[29] 3GPP TS 24.096: "Name identification supplementary services; Stage 3".

[30] 3GPP TS 24.010: "Mobile radio interface layer 3 Supplementary services specification; General aspects".

[31] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3".

[32] 3GPP TS 33.203: "Access security for IP-based services".

ETSI


[33] 3GPP TS 33.210: "Network Domain Security; IP network layer security".

[34] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".

[35] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description".

[36] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".

[37] 3GPP TS 23.172: "Technical realization of Circuit Switched (CS) multimedia service; UDI RDI fallback and service modification; Stage 2".

[38] 3GPP2 C.S0042: "Circuit-Switched Video Conferencing Services".

[39] 3GPP TR 23.903: "Redial solution for voice-video switching".

[40] Void.

[41] 3GPP TS 22.004: "General on supplementary services".

[42] 3GPP TS 24.182: "IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT)".

[43] 3GPP TS 29.292: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and MSC Server for IMS Centralized Services (ICS)".

[44] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2".

[45] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".

[46] 3GPP TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 2".

[47] 3GPP TS 24.093: "Completion of Calls to Busy Subscriber (CCBS); Stage 3".

[48] 3GPP TS 29.328: "IP Multimedia (IM) Subsystem Sh Interface; Signalling flows and message contents".

[49] 3GPP TS 23.018: "Basic call handling; Technical realization".

3 Definitions and abbreviations

3.1 Definitions For the purposes of the present document, the terms and definitions given in TR 21.905 [1] 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 [1].

Access Leg: The call leg between the UE and the SCC AS.

Correlation MSISDN: An MSISDN used for correlation of sessions.

CS Bearer Control Signalling Path: Signalling path used to control the call established to set up the CS media bearer between the UE and IMS.

CS domain Routing Number (CSRN): A CS Domain Routing Number (CSRN) is a routable number that is used to route a call from the IM CN subsystem to the UE in the CS domain. See TS 23.003 [5] for more information.

ICS UE: An IMS capable UE with additional ICS-specific functionality.

ICS User: An ICS user is an IMS subscriber that receives communication services centralized in IMS, regardless of the attached access type (e.g. CS domain access, or IP-CAN).

IMS Centralized Services: See definition in TS 22.101 [9].

IP Multimedia Routing Number (IMRN): See definition in TS 23.237 [12].

ETSI


MSC Server enhanced for ICS: An MSC Server that supports the network based ICS functionality.

Remote Leg: The call leg formed between the SCC AS and the remote end for presentation of the SIP UA behaviour to IMS on behalf of the UE. The TAS, and other Application Servers are invoked on the Remote Leg.

Service Control Signalling Path: Signalling path established between the UE and the SCC AS, either directly via an IP-CAN or via CS network elements for service control signalling.

3.2 Abbreviations For the purposes of the present document, the abbreviations given in TR 21.905 [1] 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 [1].

ADS Access Domain Selection CAA CS Access Adaptation CGI Cell Global Identifier C-MSISDN Correlation MSISDN CSRN CS domain Routing Number. DN Directory Number (e.g. MSISDN) ICS IMS Centralized Services IMRN IP Multimedia Routing Number. IN Intelligent Network IUA ICS User Agent MMTel Multimedia Telephony SAI Service Area Identification SCC AS Service Centralization and Continuity Application Server T-ADS Terminating ADS TAS Telephony Application Server UE T-ADS UE assisted Terminating ADS

4 High level principles and requirements

4.1 General IMS Centralized Services (ICS) provides communication services such that all services, and service control, are only based on IMS mechanisms and enablers. It enables IMS services when using CS access (e.g. TS 24.008 [6], 3GPP2 C.S0001-D [27]) for the media bearer.

With ICS, the user services are provided by IMS only. User sessions are controlled in IMS via PS or CS access and can be any of those defined in clause 22.4 of TS 22.101 [9].

When using a CS access network, or when using a PS access network that does not support the full duplex speech/video component of an IMS-based service, the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions. The transmission of both bidirectional and unidirectional real-time video media flows shall be supported.

NOTE: The establishment of unidirectional real-time video media flow for originating sessions requires the ICS UE capabilities.

If the PS access network does support the full duplex speech component of an IMS service then existing IMS session procedures are used as specified in TS 23.228 [2].

ICS provides mechanisms to support the use of CS media bearer for IMS sessions. With ICS, IMS sessions using CS media are treated as standard IMS sessions for the purpose of service control and service continuity.

ICS defines signalling mechanisms between the UE and IMS for transport of information required for service continuity when using CS access for media transport.

ETSI


4.2 Service consistency IMS services as defined in clause 22.4 of TS 22.101 [9] shall be consistently provided when using a CS or a PS access network for the media of the IMS service subject to the capability of the UE and the access network.

4.3 Service continuity Service continuity shall be provided when underlying mobility results in a change of access network capabilities, e.g. support of Gm reference point in conjunction with CS bearer may not be possible after handover from UTRAN to GERAN.

4.4 Session scenarios

4.4.1 Overview

4.4.2 ICS UE Session Scenarios

When a user accesses IMS services over a CS network, or a PS network which does not support the full duplex speech or video media flow component of an IMS service, the following IMS session scenarios shall be supported according to the procedures specified in TS 23.228 [2], along with the solution specified in this document.

- Basic voice or voice and video service origination and terminating sessions.

- Voice or voice and video origination and termination service sessions with Line ID services (e.g. OIP, OIR, TIP, TIR) controlled in IMS.

- Voice or voice and video origination and termination service sessions with Communication Barring services controlled in IMS.

- Voice or voice and video termination service sessions with Communication Diversion services controlled in IMS.

- Voice or voice and video origination and termination service sessions with mid-call services (e.g. Hold/Resume, Conferencing, CW, ECT) controlled in IMS.

- Communication services setting modifications (e.g., changing forwarding info or activating barring services, etc).

- The solution shall provide for an ICS UE, generic capabilities to enable introduction of new IMS services utilizing CS bearers without further standardisation.

- Adding/removing real time video media flow over CS access to/from an IMS session (see TS 22.173 [4]).

4.5 Service settings data management An ICS UE supporting multimedia telephony shall manage the IMS multimedia telephony communication service settings data as specified in TS 24.173 [8].

For a UE not supporting multimedia telephony, the MSC Server enhanced for ICS may implement a communication service setting conversion function between CS signalling (e.g., as described in TS 24.010 [30]) and communication service setting procedures (e.g. as defined in TS 24.173 [8]); see also clause 7.6.2.9.

NOTE: A downloadable application can enable a UE not supporting multimedia telephony to perform service data management.

For a UE not supporting multimedia telephony, if the MSC Server enhanced for ICS does not implement a communication service setting conversion function or if the UE is connected to an MSC server not enhanced for ICS, refer to clause 7.6.3.7.1.

ETSI


Mechanisms that allow data to be synchronized between the HSS and the TAS when legacy CS signalling is used towards the HSS for service settings data management are not specified.

4.6 Identities

4.6.1 Identities used by an ICS UE

Identities for the ICS UE are handled according to clause 4.3.3 of TS 23.228 [2].

4.6.2 Identities used by an MSC Server enhanced for ICS

For registration to IMS, the MSC Server enhanced for ICS shall use only a Private User Identity and Public User Identity specifically reserved for IMS registrations from an MSC Server. For systems with a CS domain access based on TS 24.008 [6], the subscriber identity used shall be as defined in clause 20.3 of TS 23.003 [5].

NOTE 1: This is to avoid conflicts in IMS registration by a UE and an MSC Server enhanced for ICS registering on behalf of the same subscriber.

Similar to the temporary Public User Identity (see clause 13.4 of TS 23.003 [5]), the ICS specific Public User Identity shall be prohibited from being used to originate sessions and shall be prohibited from being used to identify a terminating subscriber for incoming sessions.

An MSC Server shall use only those Public User Identities representing E.164 numbers from the subscriber's IMS profile to originate and terminate calls.

NOTE 2: The subscriber's IMS profile will need to be provisioned with a Tel URI, either as the default Public User Identity or associated with it, equivalent to a DN (e.g. MSISDN) in the subscriber's CS profile associated with speech/audio (e.g. TS11).

4.7 Coexistence of an ICS UE and a non ICS UE It shall be possible to provide ICS for an ICS UE and a non ICS UE in home and in visited networks.

Home and visited networks with an MSC Server enhanced for ICS shall support call originations and terminations for ICS UEs and non ICS UEs.

The MSC Server enhanced for ICS avoids conflicts with other IMS registrations (which includes that used by an ICS UE) by using a Private User Identity and Public User Identity specifically reserved for use by MSC Server registrations. See clause 4.6.2 for more information. An IMS operator who provides services for its subscribers, using both ICS UE"s and MSC Servers enhanced for ICS needs to make the following provisions in order to avoid registration conflicts:

- Configure the ICS specific Private User Identity, as defined in clause 4.6.2 to point to the subscriber's implicit registration set; and

- Add the ICS specific Public User Identity, as defined in clause 4.6.2 to the subscriber's implicit registration set.

4.8 Routing of originated calls to IMS When the ICS UE establishes the Service Control Signalling Path over I1 or Gm prior to the establishment of the CS Bearer Control Signalling Path, the ICS UE shall use the routing number provided by the network in response to service control signalling as the B-Party number for establishing the CS Bearer Control Signalling Path.

4.9 Void

ETSI


5 Architecture model and reference points

5.1 Overview ICS enables IMS services when using CS access for media transport. Users are provided with a consistent experience of services.

When using PS access networks which support the full duplex speech media component of an IMS service, procedures defined in TS 23.228 [2] are used to provide IMS services.

For other access networks, media established via the CS domain is used in conjunction with IMS service control. When using a UE that has been enhanced for ICS, IMS service control is enabled by a transparent control channel (the Service Control Signalling Path) between the UE and IMS. When using a UE which has not been enhanced for ICS, IMS service control can be enabled by an MSC Server enhanced for ICS.

For systems with a CS domain access based on TS 24.008 [6], CAMEL shall be used for implementing the IN triggers.

5.2 Reference architecture Figure 5.2-1 provides the reference architecture for IMS sessions established using CS bearers.

Figure 5.2-1: IMS Service Centralization and Continuity Reference Architecture

The architecture introduces the following:

- The SCC AS, which provides functions specific to IMS Service Centralization and Continuity.

- Enhancements to the MSC Server for ICS.

- Enhancements to the UE for ICS

Not all of the above are required in a network implementing ICS.

5.3 Functional Entities

5.3.1 SCC AS

The SCC AS is a home network based IMS Application that provides functionality required to enable IMS Centralized Services. The SCC AS is inserted in the session path using originating and terminating iFCs; it is configured as the first

ETSI


AS in the originating iFC and as the last AS in the terminating iFC chain. The SCC AS may also be invoked through the use of PSI termination procedures when using CS access.

The SCC AS implements one or more of the following functionalities:

- ICS User Agent (IUA): The ICS User Agent (IUA) function provides SIP UA behaviour on behalf of the UE for setup and control of IMS sessions using CS bearers that are established with or without the use of Gm or I1 between the UE and the SCC AS. For sessions established using Gm or I1 between the ICS UE and the SCC AS the IUA combines the service control signalling with the description of the bearer, e.g. SDP, established via the CS access to present a standard IMS session on behalf of the UE. An SCC AS may support I1 reference point. If supporting the I1 reference point, and before initiating an I1 Service Control Signalling Path flow, the SCC AS shall ensure that the ICS UE supports I1 and the PLMN the UE is in supports transport of network initiated I1 signalling.

- CS Access Adaptation (CAA): The CS Access Adaptation (CAA) is an adaptation function for the service control signalling communicated transparently via the CS domain between the UE and the SCC AS. The CAA processes the service control signalling received via the CS access for interworking with other IMS functional elements. The CAA is only used when using the CS network for communication of service control signalling.

- Terminating Access Domain Selection (T-ADS): Terminating Access Domain Selection (T-ADS) provides:

- Directs an incoming session to an ICS User;

- For one or more UEs of an ICS User:

- Influences the selection of one or more contacts amongst the registered contacts and;

- Influences the selection of an access network for delivery of the incoming session to the selected contact, or;

- Performs breakout to the CS Domain by fetching the CSRN.

T-ADS shall take into account the access network's capabilities, UE capabilities, IMS registration status, CS status, existing active sessions, user preferences, operator policies such as access network specific voice domain preferences and the media component types, and whether there is an ongoing IMS voice over PS session. In addition, T-ADS may take into account the access network information provided directly by the UE.

The UE may assist the T-ADS. The UE assisted T-ADS (UE T-ADS), based on configuration that takes into account operator policy, user preferences and local access network capabilities, performs the following:

- Detect media that is candidate for delivery over the CS domain associated with an incoming session.

- Identify the domain in which the session is to be established (CS or PS).

- Determines the mechanism to complete the establishment (origination or termination) - applicable to sessions to be established in the CS domain only.

- Notifies the SCC AS of the mechanism the establishment will be completed on - if possible.

For delivery of an incoming session to an ICS User, the T-ADS shall perform the following:

1. Assists in delivery of an incoming session, whether to:

- Deliver all media via PS.

- Deliver speech media via CS and use Gm for service control.

- Deliver speech media via CS and use I1 for service control.

- Deliver speech media via MSC Server enhanced for ICS.

- Deliver speech media via MSC Server not enhanced for ICS.

2. It assists in selection of an access network for delivery of the incoming session to the ICS User contact address(es). Selection criteria as specified in TS 23.221 [10] clause 7.2b, Access Domain Selection for terminating sessions are used for access network selection.

ETSI


For 3GPP PS access networks and for incoming sessions with bi-directional speech media destined to a selected contact, the SCC AS shall retrieve from the serving PLMN via the HSS the most recent access network capabilities ("IMS voice over PS Session Supported Indication", current RAT type) unless there is, for the same UE, an existing IMS voice over PS session or an existing speech session using the CS bearer that is not using the Gm service control signalling path. If the most recent access network capabilities can be retrieved, then:

- If the most recently used PS access network indicates that IMS voice over PS is supported then bi-directional speech media can be delivered on this access.

- If the most recently used PS access network indicates that IMS voice over PS is not supported, then bi-directional speech media shall not be delivered on this access.

- If the current RAT type indicates that simultaneous transfer on PS and CS domains is supported, then speech media can be delivered via CS and Gm can be used for service control.

- If the current RAT type indicates that simultaneous transfer on PS and CS domains is not supported, then Gm shall not be used for service control.

If there is an existing speech session using the CS bearer that is not using the Gm service control signalling path then Gm shall not be used for service control.

3. For delivery of incoming sessions to the UE registered in CS domain via standard MSC Server, it fetches the CSRN for breakout to the CS domain.

If a UE has an ongoing IMS voice over PS session, the T-ADS shall select the PS domain when delivering an incoming session to the same UE.

When using Gm reference point, T-ADS for ICS UE sessions may be executed in the ICS UE in conjunction with the network, based on user preferences, operator policy and taking into account its own capabilities and those of the access network.

5.3.2 UE enhanced for ICS

The ICS UE is an IMS UE that has additional ICS-related capability, which includes the following functions:

- Communication with the SCC AS for service control signalling.

- Establishment of the Bearer Control Signalling Path to setup the media through the CS domain.

- Execution of ADS for originating sessions as specified in TS 23.221 [10] clause 7.2a.

- Assisting the SCC AS in the execution of T-ADS when Gm is used.

The ICS UE supports the Gm reference point (as defined in TS 23.228 [2]) and shall use the Gm reference point when using the PS network for service control signalling.

NOTE 1: Since an ICS UE is based on an IMS UE, the Gm reference point is always supported on an ICS UE.

The ICS UE may support the I1 reference point (as defined in clause 5.4.1). If the ICS UE supports the I1 reference point, it shall be used only when:

- the home operator has preconfigured it to be used; and

- use of the Gm reference point is not possible due to the PS network not being available (e.g. due to the ICS UE camping on a GERAN with no DTM available).

Otherwise, the Gm reference point or standard CS procedures shall be used.

If the ICS UE supports Gm ICS and has a single call for which CS procedures are being used and Gm is not being used for service control then it may add the Gm service control signalling path, as described in clause 7.5a. If the ICS UE that supports Gm ICS does not add the Gm service control signalling path then it shall continue to use CS procedures for service control and for establishing additional calls until all ongoing calls end.

ETSI


NOTE 2: An ICS UE that supports Gm ICS may have a call for which Gm is not being used for service control if, for example, a handover has occurred from an access network that doesn't support Gm, or after CSFB, as described in TS 23.272 [44].

5.3.3 MSC Server enhancements for ICS

The MSC Server (e.g. as described in TS 23.002 [3]) may be enhanced for the support of ICS.

In addition to the standard MSC Server behaviour, an MSC Server that has been enhanced for ICS shall provide the following for an identified ICS user:

- Processes the user-network signalling received over the CS access (e.g. A/Iu and E interface) for interworking with IMS SIP and vice versa.

- Controls the MGW functions described in TS 23.002 [3] to enable the interworking between CS access and RTP bearers.

- Performs the interworking to support multimedia call in ICS.

- May implement a communication service setting conversion function between CS signalling (e.g. as described in TS 24.010 [30] for systems based on TS 24.008 [6]) and communication service setting procedures (as defined in TS 24.173 [8]).

- Disregard any supplementary services or IN (e.g. CAMEL) triggers that may be present in the user profile.

NOTE: These can be present in the user profile for the case where the user is served by an MSC Server not enhanced for ICS.

- Adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to IMS signalling.

For subscribers not identified as ICS users and for subscribers identified as ICS users but using a media type not listed in clause 22.4 of TS 22.101 [9] and TS 22.173 [4], the MSC Server functionality is unchanged.

MSC Server enhancements for ICS are not required for the support of an ICS UE.

5.4 Reference points

5.4.1 Reference Point UE – SCC AS (I1)

The I1 reference point is used between the UE and the SCC AS for service control signalling over CS access. All I1 Service Control Signalling Path flows shall be uniquely identifiable from other signalling flows on the same bearer.

The I1 reference point performs the following functions:

- optional session set up via CS access for mobile originating and terminating sessions;

- optional signalling for additional IMS parameter exchange during session setup;

- IMS services control via CS access.

5.4.2 Reference Point MSC Server – CSCF (I2)

The I2 reference point shall be used to route service control signalling between the MSC Server enhanced for ICS and the home IMS. The Mw reference point specified in TS 23.228 [2] together with ICS specific extensions shall be used over the I2 reference point.

5.4.3 Reference Point MSC server – CS-MGW (Mc)

The Mc reference point, as defined in TS 23.002 [3], is established between the MSC Server enhanced for ICS and the CS-MGW.

ETSI


5.4.4 Reference Point MSC Server - TAS (I3)

The I3 reference point shall be used between the MSC Server enhanced for ICS and the TAS to interwork CS signalling (e.g. as described in TS 24.010 [30] for systems based on TS 24.008 [6]) and communication service setting procedures (as defined in TS 24.173 [8]).

6 Functional description

6.1 Common IMS Functions

6.1.1 P-CSCF procedures

If CS media is present as part of the SIP/SDP message, the P-CSCF shall not use this information when allocating resources for the media.

6.1.2 IMS ALG procedures

If CS media is present as part of the SIP/SDP message, the IMS ALG shall not use this information for media related functions such as IP address translation.

6.1.3 S-CSCF procedures

If CS media is present as part of the SIP/SDP message, the S-CSCF shall allow such media to be used for the service.

6.1.4 IBCF procedures

If CS media is present as part of the SIP/SDP message, the IBCF used in roaming scenarios shall not allocate resources for the media. The IBCF shall take CS media into account in other media control related functions.

7 Procedures and flows

7.0 General This clause details the procedures and flows for network based ICS and UE based ICS.

In the flows that pertain to I1 it is assumed that:

- both the ICS UE and SCC AS support, and are configured to use I1; and

- transport of I1 signalling is supported by the MSC Server.

7.1 Signalling and bearer paths

7.1.1 Sessions established using the Gm or I1 reference point

A Service Control Signalling Path is used to transport service control signalling between the ICS UE and the SCC AS, for enabling IMS services when using CS or PS access. The Service Control Signalling Path is used when needed, e.g. on session establishment and/or service control of IMS sessions using CS voice bearers.

For ICS UE sessions, the SCC AS combines the service control signalling received over the Service Control Signalling Path with the description of the bearer established via the CS network to present an IMS session on behalf of the UE. The service control signalling elements from Gm / I1 such as A party address shall be used together with the bearer description signalling received via CS bearer control signalling path to construct the signalling for the remote leg.

ETSI


The Service Control Signalling Path is established via the PS or CS network.

Figure 7.1.1-1 illustrates how signalling and bearer paths established by the ICS UE are combined at the SCC AS when the Service Control Signalling Path is established via the PS network using the Gm reference point.

Figure 7.1.1-1: ICS UE session signalling and bearer path using Gm over PS network for Service Control Signalling Path

Upon session initiation, the ICS UE or the SCC AS establishes the Service Control Signalling Path for communication of service control signalling via the PS network using the Gm reference point.

The ICS UE also sets up the CS Bearer Control Signalling Path using standard CS network procedures to establish the circuit media.

The SCC AS combines the service control signalling received over the Service Control Signalling Path with the description of the bearer established using the CS Bearer Control Signalling Path by acting as a B2BUA as below:

- Access Leg: The Access Leg is formed with a combination of the Service Control Signalling Path and the CS Bearer Control Signalling Path.

- Remote Leg: The Remote Leg is presented by the SCC AS to the CSCF as an IMS session using IMS SIP signalling on behalf of the UE.

The TAS and other Application Servers are executed on the Remote Leg as part of standard service execution logic at the CSCF.

The SIP UA at the UE maintains the SIP/SDP state machine with the SCC AS also maintaining a copy of the state data.

Figure 7.1.1-2 illustrates how signalling and bearer paths established by the UE are combined at the SCC AS when the Service Control Signalling Path is established via the CS network using the I1 reference point.

ETSI


Figure 7.1.1-2: ICS UE session signalling and bearer path using I1 over CS network for Service Control Signalling Path

Upon session initiation, the ICS UE or the SCC AS establishes the Service Control Signalling Path for communication of service control signalling via the CS network using the I1 reference point. In parallel, the ICS UE or the SCC AS sets up the CS Bearer Control Signalling Path using standard CS network procedures to establish the circuit media. The SCC AS combines the Service Control Signalling Path with the bearer established using the CS Bearer Control Signalling Path by acting as a B2BUA as described above for the case of Service Control Signalling Path established via the PS network.

7.1.2 Sessions established using CS call control and MSC Server

Figure 7.1.2-1 illustrates signalling and bearer paths for sessions which are established using standard CS call control procedures and MSC Server .

Figure 7.1.2-1: Session signalling and bearer path using CS call control

Upon session initiation, the UE or the remote end sets up a call and the call is directed to IMS using standard CS procedures; IN (e.g. CAMEL) triggers are used to redirect CS originated calls to IMS. The SCC AS acts a B2BUA for presentation of the UA behaviour on behalf of the UE to IMS.

The TAS and other Application Servers are executed on the Remote Leg as part of standard service execution logic at the CSCF.

ETSI


7.2 Registration

7.2.1 IMS registration via CS access

7.2.1.1 Overview

The UE may register (attach) in the CS domain whenever in CS coverage. The existing mobility management mechanisms are used in the UE and the CS network.

When performing a successful Location Update for the UE, the MSC Server has received the subscriber data from the HSS/HLR. This subscriber data may include an optional flag per VPLMN.

An MSC Server that is enhanced for ICS shall then perform the following:

- If the flag is received and is supported by the MSC Server, then the MSC Server shall analyse the value of the flag as follows:

- If the flag is set to true and optionally if the MSC Server is configured to know that the VPLMN has a suitable roaming agreement with the HPLMN of the UE, the MSC Server shall attempt the IMS registration using the I2 reference point.

- If the flag is set to false, the MSC Server shall not attempt the IMS registration.

- If the flag is not received or is not supported, the MSC Server may perform some pre-screening (e.g. IMSI range analysis) based on operator-policy in order to determine whether or not to attempt IMS registration for this subscriber.

NOTE 1: Exact pre-screening procedures are operator specific.

NOTE 2: An MSC Server that is not enhanced for ICS will ignore the flag and thus will continue normal CS operation.

If the MSC Server decides not to perform registration in the IMS, the MSC Server falls back to the behaviour of an MSC Server that is not enhanced for ICS.

If the network is in NMO I configuration, the mobility management procedures using Gs interface triggers the MSC Server enhanced for ICS to perform IMS registration.

When attempting initial IMS registration on behalf of the ICS User, the MSC Server shall derive a home IMS domain name using the identity of the subscriber (e.g. IMSI). This domain name identifies the node (e.g. I-CSCF or IBCF) to which the MSC Server shall send the IMS registration. The MSC Server shall also derive IMS user identities required for the registration from this identity. The MSC Server shall derive these identities in a manner that prevents collisions with other identities automatically derived from the same subscriber identity. See clause 4.6.2 of the present document for more information on the identities used.

The MSC Server then initiates a registration on behalf of the ICS User towards the home IMS indicating support for GRUU and including an InstanceID. If a GRUU is received, the MSC Server shall store it. The MSC Server shall not apply the mechanism for multiple simultaneous registrations.

NOTE 3: IMS authorization of registrations from an MSC Server enhanced for ICS is defined in clause 9.

The MSC Server shall indicate in the registration the media capabilities that it supports (as listed in TS 22.101 [9]).

The routing of the registration messaging is performed by standard IMS routing procedures. The S-CSCF shall perform 3rd party registration towards the SCC AS. The SCC AS shall obtain from the S-CSCF the necessary information related to the contact address for performing T-ADS.

If IMS registration is successful, then subsequent IMS sessions described in clause 4.4.2 shall be supported in IMS using the MSC Server procedures described in this specification.

The success or failure of the IMS registration shall not impact the CS attach status of the UE.

The MSC Server enhanced for ICS shall initiate IMS re-registration as necessary to maintain an active IMS registration during the period of time in which the UE is attached to the CS domain.

ETSI


NOTE 4: Due to the MSC Server not applying the mechanism for multiple simultaneous registrations, this results in the behaviour of when a UE attaches to a new MSC Server enhanced for ICS and the old MSC Server enhanced for ICS has not deregistered the user, the new registration over-writes the existing one in the S-CSCF.

After successful initial IMS registration, the MSC Server enhanced for ICS shall subscribe to the registration event package described in TS 23.228 [2] on behalf of the ICS User. The MSC Server shall use the default Public User Identity received during initial IMS registration for subscription to this package. The MSC Server enhanced for ICS shall refresh this subscription as necessary during the period of time in which its IMS registration on behalf of the ICS User is active.

The MSC Server enhanced for ICS shall initiate IMS deregistration on behalf of the ICS User upon receipt of any indication that the UE is no longer considered active at this MSC Server (e.g. Location Cancellation procedure, Purge MS procedure, etc.). In order to ensure that the registration request from the target MSC Server arrives at the S-CSCF prior to the deregistration request from the source MSC Server, the MSC Server should delay the deregistration procedure, such as by starting a timer. If the S-CSCF finds an existing binding upon receiving the deregistration request as specified in TS 24.229 [31] and identifies that is a request initiated by the MSC Server enhanced for ICS on behalf of the ICS User, the S-CSCF shall compare the contact address in the deregistration request with the contact address in the existing binding using the URI comparison rules. If it agrees, the S-CSCF will remove the existing binding. Otherwise, the de-registration request fails. Per operator policy, the MSC Server enhanced for ICS shall also initiate IMS re-registrations to obtain additional temporary-GRUUs as need.

Upon receipt of a network-initiated deregistration from the IMS, the MSC Server enhanced for ICS shall remove all registration details relating to the Public User Identities contained in the deregistration. Network-initiated deregistration from IMS shall not impact the UE"s CS registration status.

7.2.1.2 Registration using I2 reference point

Figure 7.2.1.2-1 describes how IMS registration is performed by the MSC Server enhanced for ICS upon receiving of a Location Update Request.

Figure 7.2.1.2-1: Initial IMS Registration via CS Access

1. The UE sends a Location Update Request towards the CS network.

ETSI


NOTE 1: Combined RA/LA Update Request (as specified in TS 23.060 [35]) can be used instead when the network is in MNO I configuration.

NOTE 2: Combined TA/LA Update procedure (as specified in TS 23.272 [44]) can be used instead when the network supports EMM combined procedures.

2. The MSC Server enhanced for ICS performs standard CS location update, authentication and obtains subscriber data.

3. A Location Area Update Accept is returned to the UE.

NOTE 3: If Combined RA/LA Update Request is used in Step 1, the MSC Server enhanced for ICS does not return Location Area Update Accept to the UE but returns Location Update Accept to SGSN, as specified in TS 23.060 [35].

NOTE 4: If Combined TA/LA Update procedure is used in Step 1, the MSC Server enhanced for ICS does not return Location Area Update Accept to the UE but returns Location Update Accept to MME, as specified in TS 23.272 [44].

4. The MSC Server enhanced for ICS decides to initiate IMS registration for this subscriber. If the subscriber is already registered via this MSC Server enhanced for ICS, no IMS registration is sent.

5. The MSC Server enhanced for ICS derives a domain name from the subscriber"s identity (e.g. IMSI) and discovers the address of the appropriate I-CSCF/IBCF.

6. The MSC Server enhanced for ICS sends a SIP REGISTER to the IMS with a private and temporary Public User Identity derived from the subscriber"s IMSI as well as an InstanceID. The REGISTER also contains information indicating the capabilities (e.g. media types) supported and characteristics of the MSC Server as a SIP User Agent Client. The I-CSCF verifies that the incoming REGISTER origins from a trusted MSC Server (in the same way it would check that a normal REGISTER origins from a trusted P-CSCF).

7. The I-CSCF initiates standard procedures for S-CSCF location/allocation.

8. The I-CSCF forwards the REGISTER to the S-CSCF.

9. The S-CSCF identifies the REGISTER as being from the MSC Server. The S-CSCF skips any further authentication procedures and performs registration procedures with the HSS.

10. The S-CSCF performs standard service control execution procedures. Filter criteria directs the S-CSCF to send a REGISTER to the SCC AS.

11. IMS registration procedures are completed.

7.2.1.3 Deregistration using I2 reference point

Figure 7.2.1.3-1 describes how IMS deregistration is performed by an MSC Server enhanced for ICS upon detection of the Location Cancellation procedure. In this scenario, the UE is moving away from an MSC Server enhanced for ICS to an MSC Server not enhanced for ICS. Identical IMS deregistration procedures are initiated by the source MSC Server enhanced for ICS upon receiving of any other indication that the UE is no longer considered registered.

ETSI


Figure 7.2.1.3-1: IMS Deregistration via CS Access by source MSC Server enhanced for ICS when moving to an MSC Server not enhanced for ICS

1. The UE initiates standard location updating procedures toward the CS network.

2. The CS network performs standard CS location updating and authentication procedures.

3. The HSS initiates location cancellation procedures towards the source MSC Server that is enhanced for ICS.

4. On receipt of the Cancel Location, the source MSC Server should delay the deregistration procedure for a short period of time, e.g. by starting a timer.

NOTE: The delay mentioned in step 4 is used to reduce the signalling at S-CSCF when UE moves between MSC Servers enhanced for ICS (see clause 7.2.1.4). The delay needs to be long enough to ensure that the deregistration request from the source MSC Server arrives at the S-CSCF after the registration request from target MSC Server enhanced for ICS.



7. The S-CSCF identifies the REGISTER as being from an MSC Server enhanced for ICS that is a trusted network node. The S-CSCF skips any further authentication procedures and performs deregistration procedures with the HSS.

8. The S-CSCF performs the procedures as described in clause 7.2.1.1. As the contact address in the REGISTER is the same with the contact address in the existing binding, the S-CSCF performs standard service control execution procedures. Filter criteria directs the S-CSCF to send a REGISTER to the SCC AS.

9. IMS deregistration procedures are completed.

7.2.1.4 Registration after Deregistration using I2 reference point

Figure 7.2.1.4-1 describes how IMS deregistration is performed by the MSC Server enhanced for ICS upon detection of the Location Cancellation procedure. In this scenario, the UE is moving between two MSC Servers enhanced for ICS. Identical IMS deregistration procedures are initiated by the source MSC Server enhanced for ICS upon receiving of any other indication that the UE is no longer considered registered. The registration request from the target MSC Server enhanced for ICS arrives at the S-CSCF after the deregistration request from the source MSC Server enhanced for ICS.

ETSI


UE MSC Server (source)

I-CSCF S-CSCFHSS/HLR SCC AS

1. Location Updating

MSC Server (target)

4. IMS De-registration Signaling

2. CS Location Update and Authentication procedures

5. IMS Registration Signalling

3. Cancel Location

Figure 7.2.1.4-1: IMS Deregistration via CS Access by source MSC Server enhanced for ICS when moving to a target MSC Server enhanced for ICS

1. The UE initiates standard location updating procedures towards the CS network.

NOTE 1: Combined RA/LA Update Request (as specified in TS 23.060 [35]) can be used when the network is in MNO I configuration.



3. The HSS initiates location cancellation procedures towards the source MSC Server enhanced for ICS.

4. The source MSC Server enhanced for ICS initiates IMS de-registration as described in clause 7.2.1.3. The S-CSCF removes the existing binding related to the source MSC Server enhanced for ICS.

5. The target MSC Server that is also enhanced for ICS initiates IMS registration as described in clause 7.2.1.2. The S-CSCF establishes a new binding related to the target MSC Server enhanced for ICS.

NOTE 3: If step 5 is performed before step 4, the de-registration of the source MSC Server enhanced for ICS does not affect the new registered contact of the target MSC Server enhanced for ICS.

7.2.1.5 Registration before Deregistration using I2 reference point

Figure 7.2.1.5-1 describes how IMS deregistration is performed by the MSC Server enhanced for ICS upon detection of the Location Cancellation procedure. In this scenario, the UE is moving between two MSC Servers enhanced for ICS. Identical IMS deregistration procedures are initiated by the source MSC Server enhanced for ICS upon receiving of any other indication that the UE is no longer considered registered. The registration request from the target MSC Server enhanced for ICS arrives at the S-CSCF before the deregistration request from the source MSC Server enhanced for ICS.

ETSI


Figure 7.2.1.5-1: IMS Deregistration via CS Access by source MSC Server enhanced for ICS when moving to a target MSC Server enhanced for ICS

1. The UE initiates standard location updating procedures towards the CS network.

NOTE 1: Combined RA/LA Update Request (as specified in TS 23.060 [35]) can be used when the network is in MNO I configuration.



3. The HSS initiates location cancellation procedures towards the source MSC Server enhanced for ICS.

4. The target MSC Server that is also enhanced for ICS initiates IMS registration as described in clause 7.2.1.2. The S-CSCF updates a existing binding related to the source MSC Server enhanced for ICS.

5. The source MSC Server that is enhanced for ICS initiates IMS deregistration for this subscriber.



8. The S-CSCF identifies the REGISTER as being from an MSC Server enhanced for ICS that is a trusted network node. The S-CSCF skips any further authentication procedures and performs deregistration procedures as described in clause 7.2.1.1. As the contact address in the REGISTER differs from the contact address in the existing binding related to the target MSC Server, the S-CSCF returns an error response to the source MSC Server enhanced for ICS.

7.2.2 IMS Registration via IP-CAN

Whenever the ICS UE acquires IP connectivity via an IP-CAN, the UE shall register in the IMS if not already registered in IMS. Registration with IMS is in accordance with the procedure as defined in TS 23.228 [2].

3rd-party registration shall be performed by the S-CSCF via the ISC interface towards the SCC AS. This supports ADS functionality in the SCC AS.

1. The UE registers in the IMS as described in clause 5.2.2.3 of TS 23.228 [2] indicating its abilities to use ICS.

NOTE: Access networks capabilities could be taken into account when sending any indications.

2. The S-CSCF informs the SCC AS about the registration, using the procedures defined in clause 6.3 of TS 23.218 [7].

ETSI


IMS registration via IP-CAN is performed independently of the UE's CS state.

Information regarding home network support of ICS shall be configured in the ICS UE, e.g. via OMA DM [24].

7.3 Originations

7.3.1 Originating sessions that use PS media

When the ICS UE has access to a PS network that supports the full duplex speech component of an IMS service, the originating IMS procedures (as described in clause 5.6 of TS 23.228 [2]) shall be used to set up the session. The S-CSCF shall insert the SCC AS in the IMS session path using originating initial filter criteria. The SCC AS shall be the first AS inserted into the session path.

7.3.2 Originating sessions that use CS media

7.3.2.1 Non ICS UE originating sessions that use CS media

7.3.2.1.1 Overview

Originating sessions that use CS media made by non ICS UEs that have been successfully registered in IMS by the MSC Server can utilize IMS service control. The non ICS UE initiates a standard CS originating session toward the MSC Server enhanced for ICS, which in turn can initiate an IMS originating session using the I2 reference point.

For these sessions, the MSC Server shall perform interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.008 [6]). The MSC Server shall also control a CS-MGW using the Mc reference point to perform interworking between CS access bearers and RTP bearers on the Mb reference point. For emergency sessions, the MSC Server shall not perform this interworking and shall perform existing MSC Server emergency call handling procedures instead.

For video call originating sessions that use CS media, the MSC Server enhanced for ICS shall also, after the multimedia connection is established, perform the video codec negotiation for the non ICS UE and set up the video media bearer based upon the procedures defined in TS 29.163 [11] for 3GPP systems and based on procedures defined in 3GPP2 C.S0042 [38] for 3GPP2 systems.

The SCC AS shall be inserted in the IMS session path using the iFC.

7.3.2.1.2 Origination using I2 reference point

Figure 7.3.2.1.2-1 describes how IMS originations are performed via CS access for non ICS UE. This call flow also applies for an ICS UE CS origination with CS media without use of I1 and with use of an MSC server enhanced for ICS, as specified in clause 7.3.2.2.3.

ETSI


Figure 7.3.2.1.2-1: IMS Origination via CS Access for non ICS UE

1. The UE A sends a CS call setup message containing the B-party number to the MSC Server enhanced for ICS according to standard CS originating procedures.

2. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the B-party number. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or a public-GRUU if privacy has not been requested. The INVITE also contains SDP received from the CS-MGW. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE. For a roaming user, when the Roaming Architecture for Voice over IMS with Local Breakout is supported according to clause 4.15a of TS 23.228 [2], the MSC Server may, based on operator policy, add a reference to the preferred Transit and Roaming Function.

3. The S-CSCF performs standard service control execution procedures. Filter criteria direct the S-CSCF to send the INVITE to the SCC AS.

4. The SCC AS invokes a B2BUA, terminating the UE A Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of UE A. The SCC AS creates an INVITE containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice or voice and video media. The INVITE request is routed from the SCC AS to the S-CSCF.

5. The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B-party.

6. Completion of the session and bearer control setup procedures. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.1.1 applies.

7.3.2.1.3 Origination when using an MSC Server

Figure 7.3.2.1.3-1 describes how IMS originations are performed via CS access for non ICS UE attached to a legacy MSC or MSC-Server which has not been enhanced for ICS. This call flow also applies for an ICS UE CS origination with CS media without use of I1 and with use of an MSC server, as specified in clause 7.3.2.2.3.

ETSI


Figure 7.3.2.1.3-1: IMS Origination via CS Access for non ICS UE

1. The UE A originates a call in the CS domain to party-B according to standard origination procedures.

2. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling Path.

3. The MSC-Server fetches an IP Multimedia Routing Number (IMRN) via IN (e.g. CAMEL) and routes the call towards the user's home IMS network using the IMRN via an MGCF.

4. The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating ICS user.

5. The I-CSCF routes the INVITE based on one of the following standard procedures specified in "PSI based Application Server termination - direct and PSI based Application Server termination – indirect" procedures in TS 23.228 [2] either directly to the SCC AS or via the S-CSCF.

6. When the INVITE arrives at the SCC AS, it invokes a B2BUA, terminating the UE A leg and originating the Remote Leg for presenting an IMS session towards the B-party on behalf of UE A. The SCC AS creates an INVITE containing the SDP received from MGCF, indicating CS voice or voice and video media. The original called number and the calling party number are used to setup the outgoing call leg to party-B in accordance with the AS origination procedure defined in clause 5.6.5 of TS 23.228 [2]. If required the SCC AS adds User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE. The SCC AS sends the INVITE back to S-CSCF.

NOTE 1: The method for discovery of original called number and calling party number at the SCC AS if ISUP does not provide this information is implementation dependant. This can be realized by interactions between the SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this specification.

NOTE 2: The method for determining User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information at the SCC AS is implementation dependant. This can be realized by interactions between the SCC AS and the SCF (e.g. gsmSCF). The SCC AS can also retrieve the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information from the MSC via the HSS as specified in TS 29.328 [48] and as described in clause 4.2.4a of TS 23.228 [2].

7-8. The S-CSCF sends the INVITE further for completion of the call toward the remote end. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.1.1 applies.

ETSI


7.3.2.2 ICS UE Originating sessions that use CS media

7.3.2.2.1 Overview

IMS service control is used for ICS UE originated sessions that use a CS media bearer.

When using the Gm reference point, the ICS UE initiates a standard IMS originating session indicating use of CS media bearer for the session. The SCC AS is inserted in the IMS session path using originating iFC. The ICS UE also sets up a standard CS originated session addressing a PSI DN associated with the SCC AS to establish the CS bearer if a CS bearer is not available for the ICS UE. The CS bearer shall be reused if already established using the Gm reference point. The service control signalling is combined with the description of the CS bearer at the SCC AS for presentation of the IMS originating session to the S-CSCF over the Remote Leg.

When a subsequent session origination with different CS bearer requirement occurs (i.e. CS audio bearer is changed to CS video bearer, or vice versa), the CS bearer shall be updated if possible through SCUDIF or redial (refer to clause 7.9.2).

The ICS UE should be able to detect an emergency session establishment request. If the ICS UE using a CS access detects the request for the establishment of an emergency session, the ICS UE shall attempt to initiate a CS emergency call.

If the ICS UE could not detect an emergency call and originates the session with CS media using Gm reference point, it will forward an IMS session establishment request to the P-CSCF. If the P-CSCF detects such an emergency call, it rejects the request with an indication that this is for an emergency session as described in TS 23.167 [25].

NOTE: If the P-CSCF is not ICS aware, it is assumed that some other node in the emergency session path will detect the unsupported media and reject it or the call will be delivered to the PSAP without voice media component. Normal error handling applies in this case.

As described in TS 23.167 [25], an ICS UE that initiated a non UE detectable emergency session will receive an indication in responses from which it can deduce that the session is for emergency. Upon receiving an emergency session rejection or session rejection with this indication, the ICS UE shall fall back to CS according to TS 23.167 [25].

When not using the Gm reference point, the following apply:

- For sessions originated using a B party"s SIP URI (not using user = phone), the ICS UE initiates a dialogue with the SCC AS over the I1 reference point indicating session origination. The ICS UE also sets up a CS originated session addressing a PSI DN associated with the SCC AS to establish the CS bearer. The service control signalling is combined with the description of the CS bearer at the SCC AS for presentation of the IMS originating session to the S-CSCF over the Remote Leg.

- For all other cases, the ICS UE initiates a standard CS originating call using B party"s E.164 number. The call is routed to IMS via a standard MSC Server using IN (e.g. CAMEL) based redirection or an MSC Server enhanced with ICS. If the B party number is detected by the MSC Server as an emergency number then it will be handled as per existing MSC Server call handling procedures. Additionally, the ICS UE may use the I1 reference point for communication of additional parameters.

For video call originating sessions that use CS media, the following apply:

- When the ICS UE is attached to the MSC Server enhanced for ICS, after the multimedia connection is established, the MSC Server enhanced for ICS shall perform the video codec negotiation for the ICS UE and set up the video media bearer based upon the procedures defined in TS 29.163 [11] for 3GPP systems and based on the procedures defined in 3GPP2 C.S0042 [38] for 3GPP2 systems;

- When the ICS UE is attached to the MSC Server not enhanced for ICS, the MGCF/IMS-MGW shall perform the video codec negotiation for the ICS UE and set up the video media bearer as specified in TS 29.163 [11] for 3GPP systems and as specified in 3GPP2 C.S0042 [38] for 3GPP2 systems.

The following clauses show pairs of flows, one for an ICS UE when using an MSC Server and the other for an MSC Server enhanced for ICS. They are for the most part identical except that in the case of an MSC Server enhanced for ICS the INVITE towards the SCC AS is sent directly from the MSC Server whereas an MSC Server sends an ISUP IAM and the MGCF interworks this to an INVITE towards the SCC AS.

ETSI


A "Gm origination with CS media" policy may be provisioned by the operator and communicated to the ICS UE during initial provisioning or via OMA Device Management [24].

NOTE 1: Operators who choose to make use of ICS UEs may update this policy in order to optimize the user experience depending on knowledge of the capabilities of the Home PLMN and Visited PLMN (if roaming), in particular whether the MSC Server is enhanced for ICS, whether IN re-routing is possible and whether the ICS UE may be handed over to a non DTM-enabled GERAN.

For originating sessions that use CS media, when the use of the Gm reference point is possible, the ICS UE shall behave as follows, depending on the "Gm origination with CS media" policy:

- if this policy is set to "Gm disabled", then the ICS UE shall not use the procedure specified in clause 7.3.2.2.4.

- if this policy is set to "Gm enabled but not preferred", then:

- if the destination is a Tel URI or a SIP-URI representing a telephone number, and the exchange of additional SIP parameters is not required, then the ICS UE shall not use the procedure specified in clause 7.3.2.2.4;

- otherwise, the ICS UE shall use the procedure specified in clause 7.3.2.2.4.

- if this policy is set to "Gm enabled", then the ICS UE shall use the procedure specified in clause 7.3.2.2.4.

NOTE 2: When setting the "Gm origination with CS media" policy to the ICS UE, the home operator is able to consider whether the MSC in VPLMN has been enhanced for ICS or not, and in the latter case the operator can enable the Gm reference point for ICS service control. When roaming, the Home operator can update this policy depending on the VPLMN, e.g. based on roaming agreements.

7.3.2.2.2 Originations with CS media when using I1

7.3.2.2.2.1 Originations to a SIP URI

Figure 7.3.2.2.2.1-1 provides an example flow for a session origination by an ICS UE when a SIP-URI is used to address the called party and when the ICS UE is attached to an MSC Server enhanced for ICS and the user is identified as an ICS user.

ETSI


I/S-CSCF

IMS Bearer

4. CS call setup (SCC AS PSI DN)

SCC ASMGWICS UE A

2. Allocate SCC AS

PSI DN

1. I1: ICS Call Initiation (UE-B)

6. INVITE (SCC AS PSI, SDP-MGW)

7. INVITE (SCC AS PSI, SDP-MGW )

UE B

8. INVITE (B, SDP-MGW )

9. INVITE (B, SDP-MGW )

5. Call Proceeding

10. Completion of the session and bearer set-up procedures

CS Domain Bearer

MSC Server

3. I1: ICS Call Initiation Result (SCC AS PSI DN)

Figure 7.3.2.2.2.1-1: ICS UE Origination with CS media addressing a SIP-URI when using an MSC Server enhanced for ICS

NOTE 1: 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the CS Service Control Signalling Path.

1. The ICS UE A initiates a call by sending an ICS Call Initiation Request over the I1 reference point containing the UE B address.

2. The SCC AS performs the necessary adaptation of the signalling received over the I1 reference point. The SCC AS allocates a PSI DN and sends it to the ICS UE A.

3. The SCC AS sends the SCC AS PSI DN to the UE over the I1 reference point.

4. The ICS UE A uses standard CS originating procedures to establish a CS Bearer Control Signalling Path with the SCC AS by sending a SETUP message to the MSC Server containing the SCC AS PSI DN.


6. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the SCC AS PSI. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or public-GRUU if privacy has not been requested. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

7. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS. The SCC AS is the first AS inserted in the session path.

8. The SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of ICS UE A. The SCC AS correlates the CS bearer control signalling session with the service control signalling session using the SCC AS PSI and creates a SIP INVITE

ETSI


containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice or voice and video media. The INVITE request is routed from the SCC AS to the S-CSCF.


10. Completion of the Service Control Signalling Path and the CS Bearer Control Signalling Path setup procedures. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.2.1 applies.

Figure 7.3.2.2.2.1-2 provides an example flow for a session origination by an ICS UE when a SIP-URI is used to address the called party and when the ICS UE is attached to an MSC Server.

Figure 7.3.2.2.2.1-2: ICS UE Origination with CS media addressing a SIP-URI when using an MSC Server

NOTE 2: Steps 4, 5, 6, 7 and 8 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

Steps 1-5 in Figure 7.3.2.2.2.1-2 are identical to steps 1-5 in Figure 7.3.2.2.2.1-1.

At Steps 6 and 7, the MSC Server sends the IAM using the SCC AS PSI DN to an MGCF which is subsequently inter-worked to an INVITE.


7.3.2.2.2.2 Originations to a B-party number other than SIP-URI

Figure 7.3.2.2.2.2-1 provides an example flow for a session origination by an ICS UE where the I1 reference point is used to set up the session and the user dials a E.164 number, Tel-URI or SIP-URI user=phone, and when the ICS UE is attached to an MSC Server enhanced for ICS and the user is identified as an ICS user.

ETSI


Figure 7.3.2.2.2.2-1: ICS UE Origination with CS media using a E.164 number, Tel-URI or SIP-URI user=phone and an MSC Server enhanced for ICS

NOTE 1: Steps 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

1. The ICS UE A initiates a call by sending an ICS Call Initiation Request over the I1 reference point containing the UE B address. The ICS UE A also indicates in the I1 message that an SCC AS PSI DN is not needed for this session.

2. The SCC AS performs the necessary adaptation of the signalling received over the I1 reference point. The SCC AS notes the SCC AS PSI DN is not used for this session.

3. The SCC AS returns an ICS Call Initiation Result to ICS UE A over the I1 reference point.

4. The ICS UE A uses standard CS originating procedures to establish a CS Bearer Control Signalling Path with the IUA of the SCC AS by sending a SETUP message to the MSC Server containing the B-party-number. If the B party number is detected by the MSC Server as an emergency number then it will be handled as per existing MSC Server call handling procedures.

When the user dials a Non-UE detectable Emergency DN or Emergency URI but I1 has been established, or if the CS origination fails to be routed into IMS, a timer running at the SCC AS will expire as the CS Bearer Control Signalling Path was not established towards the SCC AS and an appropriate indication is returned to the UE The UE shall not release the CS bearer on receipt of this indication and the UE shall not use the Service Control Signalling Path further for the call.


6. The MSC Server sends an INVITE to the S-CSCF with the destination set to the called party number and the source to the calling party. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or public-GRUU if privacy has not been requested.

ETSI


The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

7. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS.

8. The SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of ICS UE A. The IUA correlates the CS bearer control signalling session with the service control signalling session and creates a SIP INVITE containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice or voice and video media and routes the INVITE request to the S-CSCF. If the SCC AS obtains the calling party identify from step 1, then the SCC AS shall use this identity from step 1 as the calling party identity. Otherwise, then the SCC AS shall use the calling party identity received in step 6.



Figure 7.3.2.2.2.2-2 provides an example flow for a session origination by an ICS UE where the I1 reference point is used to set up the session and the user dials a E.164 number, Tel-URI or SIP-URI user=phone and when the ICS UE is attached to an MSC Server.

Figure 7.3.2.2.2.2-2: ICS UE Origination with CS media using a E.164 number, Tel-URI or SIP-URI user=phone and an MSC Server



ETSI


In Steps 6 and 7, IN (e.g. CAMEL) origination triggers are used at the MSC Server for fetching of an IP Multimedia Routing Number (IMRN). The MSC Server sends an IAM to an MGCF using the IMRN which is subsequently inter-worked to an INVITE.

In Step 8, the S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS. This step is skipped if the I-CSCF routes the INVITE request directly to the SCC AS.


NOTE 3: The method for discovery of original called number and calling party number at the SCC AS if ISUP does not provide this information is implementation dependant. This can be realized by interactions between the SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this specification.

7.3.2.2.3 Originations with CS media when not using I1

This procedure may be used when the ICS User dials an E.164 number, a Tel URI or a SIP-URI user=phone, and the exchange of additional SIP parameters is not required. The ICS UE initiates a standard CS originating using the B-party"s E.164 number or a number derived from the Tel-URI. The call is routed to IMS via an MSC Server which is enhanced to support ICS or a standard MSC Server using IN (e.g. CAMEL) based re-direction.

Figure 7.3.2.1.2-1 provides an example flow for a session origination by an ICS UE where the I1 reference point is not required to set up the session and a MSC Server enhanced for ICS is used to set-up the CS Bearer Control Signalling Path and the user is identified as an ICS user.

For a session origination by an ICS UE where the I1 reference point is not required to set up the session and a MSC Server enhanced for ICS is not used to set-up the CS bearer control signalling, an example call flow is shown in Figure 7.3.2.1.3-1.

7.3.2.2.4 Originations with CS media using the Gm reference point

Figure 7.3.2.2.4-1 provides an example flow for a session origination by an ICS UE attached to an MSC Server enhanced for ICS where the Gm reference point is used to set up the session with the CS media bearer.

ETSI


Figure 7.3.2.2.4-1: ICS UE Origination with CS media using Gm reference point when using an MSC Server enhanced for ICS

NOTE 1: Steps 6, 7, 8 and 9 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

1. The ICS UE A sets up a Service Control Signalling Path by initiating a standard IMS origination session towards the UE B. A SIP INVITE request (indicating the use of CS media for the session) is sent to the S-CSCF serving the UE A in the home IMS network.

2. The SCC AS is inserted in the IMS session path using originating initial filter criteria at the S-CSCF. The SCC AS is the first AS inserted in the session path.

3. The SCC AS allocates a PSI DN and sends it to the ICS UE A.

4. The SCC AS returns the SCC AS PSI DN in a reliable provisional response to the S-CSCF

5. The S-CSCF forwards the provisional response (containing the SCC AS PSI DN) to ICS UE A.

6. The ICS UE uses standard CS originating procedures to establish the CS Bearer Control Signalling Path with the SCC AS by sending a CS call setup message to the MSC Server containing the SCC AS PSI DN.

NOTE 2: The UE waits for the SIP response (step 5) before the UE generates the CS call setup.


ETSI


8. The MSC Server sends an INVITE to the S-CSCF with the Request-URI set to the SCC AS PSI. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or public-GRUU if privacy has not been requested. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

9. The S-CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS.

10. The SCC AS invokes a B2BUA, terminating the Access Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of ICS UE A. The SCC AS correlates the CS bearer control signalling with the service control signalling and combines both the SDP offers into one offer towards the UE B. The SCC AS inserts the SDP received on the CS Bearer Control Signalling Path into the INVITE indicating CS media towards the B-party. The INVITE request is routed from the SCC AS to the S-CSCF.

11. The S-CSCF continues with standard IMS originated session processing and routes the request onwards to the B-party


Figure 7.3.2.2.4-2 provides an example flow for a session origination by an ICS UE attached to an MSC Server where the Gm reference point is used to set up the session with the CS media bearer.

Figure 7.3.2.2.4-2: ICS UE Origination with CS media using Gm reference point when using an MSC Server


Steps 1-7 in Figure 7.3.2.2.4-2 are identical to steps 1-7 in Figure 7.3.2.2.4-1.

ETSI


At Steps 8 and 9, the MSC server sends the IAM using the SCC AS PSI DN to an MGCF which is subsequently inter-worked to an INVITE.


7.4 Terminations

7.4.1 Terminating sessions that use PS media

7.4.1.1 Full duplex speech via PS

When the ICS UE has access to a PS network that supports the full duplex speech component of an IMS service, terminating IMS procedures (as described in clause 5.7 of TS 23.228 [2]) shall be used to terminate the session to the ICS UE. The S-CSCF shall insert the SCC AS in the IMS session path using terminating initial filter criteria. The SCC AS shall be the last AS inserted into the session path.

7.4.1.2 Void

7.4.1.3 Void

7.4.2 Terminating sessions that use CS media

7.4.2.1 Non ICS UE terminating sessions that use CS media

7.4.2.1.1 Overview

All ICS User incoming sessions are directed to IMS for delivery to the ICS User.

Non ICS UEs which have been successfully registered in IMS by the MSC Server will have a registration binding at the S-CSCF containing the MSC Server as the contact address.

The SCC AS shall be inserted in the IMS session path using the terminating iFC. The SCC AS performs T-ADS for selection of an access and returns information to assist with S-CSCF selection of a registered contact address. When the T-ADS function selects the MSC Server enhanced for ICS, the SCC AS directs the IMS terminating session towards the contact address of the MSC Server.

On receipt of the session initiation message, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.008 [6]). The MSC Server shall also control a CS-MGW using the Mc reference point to perform the necessary interworking between RTP bearers on the Mb reference point and CS access bearers and adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the response to the session initiation.

The SCC AS may select to breakout an incoming session to the CS domain in following cases:

- A non ICS UE is not registered in IMS but can be attached to the CS network at an MSC Server. In this case, terminating iFC forwards the call to the SCC AS.

- A non ICS UE is registered in IMS, the access network does not support the media type (as defined in clause 22.4 of TS 22.101 [9]), but the UE still can be attached to the CS network at an MSC Server. In this case, terminating iFC forwards the call to the SCC AS.

For both scenarios the SCC AS shall retrieve from the HSS the C-MSISDN(s) associated with all the IMPIs that are associated with the IMPU that is the target of the session. The SCC AS shall select a single C-MSISDN and shall use it to fetch a CSRN for routing the call to the CS domain. The INVITE shall be sent to the S-CSCF which then performs CS breakout according to standard IMS procedures. The INVITE may include an indication that this is an ICS session,

ETSI


which can be used by the MGCF to handle this session in a specific manner, for example to make a different cause mapping between ISUP/BICC and SIP than a normal session breakout would do. The SCC AS may also retrieve the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information from the HSS at this time or at the reception of the response, to include it into the response to the session initiation.

NOTE: The algorithm used by the SCC AS to select a C-MSISDN is implementation dependent.

For video call terminating sessions that use CS media, the MSC Server enhanced for ICS shall also, after the multimedia connection is established, perform the video codec negotiation for the non ICS UE and set up the video media bearer based upon the procedures defined in TS 29.163 [11] for 3GPP systems and based on procedures defined in 3GPP2 C.S0042 [38] for 3GPP2 systems. If the UE does not support video, or the access network is not capable of video, then the video component of the session shall not be accepted by the MSC Server enhanced for ICS.

7.4.2.1.2 Termination using I2 reference point

Figure 7.4.2.1.2-1 describes how IMS terminations are performed via CS access for non ICS UE registered in IMS. This call flow also applies for an ICS UE attached to an MSC Server enhanced for ICS where the incoming session is delivered to the ICS UE using standard CS terminating procedures, as specified in clause 7.4.2.2.5.

Figure 7.4.2.1.2-1: IMS Termination via CS Access for non ICS UE registered in IMS

1. An incoming INVITE is received at the S-CSCF of the B-party via the I-CSCF.

2. The S-CSCF performs standard service control execution procedures. Filter criteria direct the S-CSCF to send the INVITE to the SCC AS.

3. The SCC AS performs terminating access domain selection. The SCC AS chooses the CS access network and the MSC Server contact address, amongst the registered contact addresses for the UE B, for the setup of the media.

4. The SCC AS establishes a new session by sending an INVITE to the UE B via the S-CSCF.

5. The S-CSCF forwards the INVITE to the MSC Server based on the contact address stored during registration, using standard IMS procedures.

6. The MSC Server sends a Setup message to the UE B.

7. Completion of the session and bearer control setup procedures. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.4.2.1.1 applies. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information of the terminating user to the session initiation response message.

ETSI


7.4.2.1.3 Termination to non ICS UE not registered in IMS

Figure 7.4.2.1.3-1 describes how IMS terminations are performed via CS access for non ICS UE not registered in IMS. This call flow also applies for an ICS UE attached to an MSC Server where the incoming session is delivered to the ICS UE using standard CS terminating procedures, as specified in clause 7.4.2.2.5.

Figure 7.4.2.1.3-1: IMS Termination via CS Access for non ICS UE not registered in IMS

1. An incoming INVITE is received at the S-CSCF of the B-party.

2. The S-CSCF performs standard unregistered service control execution procedures. The terminating iFC direct the INVITE to the SCC AS for terminating access domain selection.

3. The T-ADS function chooses breakout to the CS domain. A CSRN is fetched for routing to the CS domain. If the SCC AS interacts with the HSS to fetch the CSRN, it may also indicate to the HSS the support of MTRR as specified in TS 23.018 [49].

NOTE 1: At this point, the SCC AS can, as an implementation option, interact with the HSS to obtain location information.

NOTE 2: Fetching the CSRN is implementation specific.

NOTE 3: If Sh is used for interaction with the HSS and SCC AS indicates support of MTRR, the SCC AS also provides its MAP address to the HSS.

4. The SCC AS establishes a new session by sending an INVITE containing the CSRN and ICS indicator towards the S-CSCF.

5. The S-CSCF then performs CS breakout according to existing IMS procedures. The call is routed to the CS domain via the BGCF/MGCF.

6. The MGCF sends an IAM to the MSC Server.

7. The MSC Server performs paging procedures and sends the CS call setup message to the UE B. If the UE does not respond to the paging request as meanwhile it has performed registration with a new MSC Server, the network may either use the MTRF or MTRR feature as specified in TS 23.018 [49] in order to re-direct the call towards the new MSC Server. If MTRR is used the SCC AS emulates GMSC behavior and may request to to re-restart call handling from step 3 onwards.

8. Completion of the session and bearer control setup procedures. To complete the session and bearer setup for a video call the specific handling as described in clause 7.4.2.1.1 applies. The MGCF may map cause codes received over the CS leg differently compared to normal CS breakout. If the SCC AS has User Location

ETSI


Information (e.g. CGI or SAI) and/or UE Time Zone Information available (e.g. from step 3, or by interacting with the HSS at this time), it adds it to the SIP response.

7.4.2.2 ICS UE Terminating sessions that use CS media

7.4.2.2.1 Overview

IMS service control is used for ICS UE terminating sessions that use CS media.

All ICS User incoming sessions are directed to IMS for delivery to the ICS User. The SCC AS is inserted in the IMS session path using the terminating iFCs. The SCC AS performs T-ADS for selection of a contact address amongst the registered contact addresses for the ICS User and subsequently selects an access network for delivery of the session to the selected contact address.

When using the Gm reference point for delivery of the incoming session to the ICS UE, the SCC AS directs the IMS terminating session toward the ICS User"s selected contact indicating use of CS bearer for the session. On receipt of the session initiating message, the ICS UE sets up a standard CS originated session addressing a PSI DN associated with the SCC AS to establish the CS bearer if a CS bearer is not available for the ICS UE. The CS bearer shall be reused if already established using the Gm reference point. The service control signalling is combined with the description of the CS bearer at the SCC AS for presentation of IMS terminating session to the S-CSCF over the Remote Leg.

When a subsequent session termination with different CS bearer requirement occurs (i.e. CS audio bearer is changed to CS video bearer, or vice versa), the CS bearer shall be updated if possible through SCUDIF or redial (refer to clause 7.9.2).

The following clauses show pairs of flows, one for an ICS UE when using an MSC Server and the other for an MSC Server enhanced for ICS. They are for the most part identical except that in the case of an MSC Server enhanced for ICS the INVITE towards the SCC AS is sent directly from the MSC Server otherwise an MSC sends an ISUP IAM and the MGCF interworks this to an INVITE towards the SCC AS.

For video call terminating sessions that use CS media, the following apply:

- When the ICS UE is attached to the MSC Server enhanced for ICS, after the multimedia connection is established, the MSC Server enhanced for ICS shall perform the video codec negotiation for the ICS UE and set up the video media bearer based upon the procedures defined in TS 29.163 [11] for 3GPP systems and based on the procedures defined in 3GPP2 C.S0042 [38] for 3GPP2 systems;

- When the ICS UE is attached to the MSC Server not enhanced for ICS, the MGCF/IMS-MGW shall perform the video codec negotiation for the ICS UE and set up the video media bearer as specified in TS 29.163 [11] for 3GPP systems and as specified in 3GPP2 C.S0042 [38] for 3GPP2 systems.

7.4.2.2.2 Terminations with CS media using the Gm reference point

Figure 7.4.2.2.2-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for ICS, where the incoming session is delivered over the Gm reference point and the media is established via the CS network.

ETSI


Figure 7.4.2.2.2-1: ICS UE Terminations with CS media information flows using Gm reference point when using an MSC Server enhanced for ICS

NOTE 1: Steps 11, 12, 13 and 14 are related to the setup of the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

1. An incoming SIP INVITE is received at the S-CSCF of the B party from UE A.

ETSI


2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS.

3. The SCC AS sends a Session Progress response to the S-CSCF.

4. The S-CSCF forwards the Session Progress response to UE A.

Steps 5a – 7a are for the case of T-ADS performed by the SCC AS.

5a. The SCC AS performs Terminating Access Domain Selection and chooses the CS domain for the setup of the media.

6a. The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to the B-party via the I/S-CSCF. This INVITE contains an indication to inform the UE to initiate the CS bearer establishment procedure. The INVITE also contains a dynamic SCC AS PSI to enable the SCC AS to later on correlate the outgoing service control signalling with the incoming CS bearer control signalling. When the T-ADS function selects the Gm reference point for service control the SCC AS prevents the S-CSCF from selecting the contact address of the MSC Server, and the S-CSCF selects the IP-CAN

7a. The I/S-CSCF sends the INVITE to B-party.

Steps 5b – 10 are for the case of UE T-ADS.

5b. Alternatively, in the case of UE T-ADS as defined in clause 5.3.1, the SCC AS performs initial T-ADS selecting IMS for the service control signalling when UE-B is registered in the IMS.

6b The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to the B-party via the I/S-CSCF. The INVITE contains options that enable UE-B to choose a CS bearer for bidirectional speech media transport if it determines that this is not supported by serving PS Access Network. The INVITE also contains a dynamic SCC AS PSI to enable the SCC AS to later on correlate the outgoing service control signalling with the incoming CS bearer control signalling. When the T-ADS function selects the Gm reference point for service control, the SCC AS prevents the S-CSCF from selecting the contact address of the MSC Server, and the S-CSCF selects the IP-CAN.

7b. The I/S-CSCF sends the INVITE to B-party.

8-10 UE-B responds with a Session Progress message. In the case that the PS access network does not support bidirectional speech media and in the event the "IMS voice over PS session supported indication" indicates voice is not supported as defined in clause 4.3.5.8 of TS 23.401 [34], UE-B shall indicate in the Session Progress message that a CS bearer is required for the bidirectional speech component of the session and that the Gm reference point is used for service control. The S-CSCF forwards the Session Progress message to the SCC AS.

11. If the establishment mechanism is for UE originated, the ICS UE sends a CS call setup message to the MSC Server using the SCC AS PSI DN to establish the CS Bearer Control Signalling Path. This will establish the circuit bearer between the UE and IMS.

12. The MSC Server responds with a call proceeding message and begins to set up the CS Bearer Control Signalling Path.

13. The MSC Server sends an INVITE towards the I/S-CSCF containing the SCC AS PSI and an SDP Offer with the media description from the MGW. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

14. The I/S-CSCF forwards the INVITE to the SCC AS.

15. The SCC AS continues the session setup towards the A-party for the original INVITE in Step 1. The response contains an SDP answer with the media description from the SDP offer received in Step 13.

16. The SCC AS completes the set-up of the CS Bearer Signalling Path towards ICS UE B which involves sending a 200 OK in response to the INVITE in Step 14. The ICS UE B, the MSC Server and the SCC AS complete the setup of the CS Bearer Control Signalling Path and the Service Control Signalling Path with UE A.

17. The ICS UE B continues with the set-up of the Service Control Signalling Path towards the UE A which includes sending a Ringing response to the SCC AS via the S-CSCF. The ICS UE B then completes the set-up of the Service Control Signalling Path towards the Remote End which includes sending a final 200 OK message in response to the INVITE received at steps 7a or 7b.

ETSI


For video call, in Steps 16 and 17, to complete the session and bearer setup, the specific handling as described in clause 7.4.2.2.1 applies.

Figure 7.4.2.2.2-2 provides an example flow for a call destined to an ICS UE attached to an MSC server, where the incoming session is delivered over the Gm reference point and the media is established via the CS network.

ETSI


I/S-CSCF

CS Domain Bearer IMS Bearer

2. INVITE (B, SDP-A)

11. CS call setup (SCC AS PSI DN)

SCC ASMGWMSC ServerICS UE B

5a. T-ADS

1. INVITE (B, SDP-A)

14. INVITE (SCC AS PSI, SDP-MGW)

7a. INVITE (B, SCC AS PSI DN)

15. INVITE (SCC AS PSI, SDP-MGW )

UE A

6a. INVITE (B, SCC AS PSI DN)

16. Continuation of the session set-up with UE-A

17. Completion of the CS bearer set-up procedures

3. Session Progress

4. Session Progress

18. Completion of the session set-up procedures

8. UE T-ADS

9. Session Progress

10. Session Progress

12. Call Proceeding

7b. INVITE (B, SCC AS PSI DN)

6b. INVITE (B, SCC AS PSI DN)

Alt 1

Alt 25b. Initial

T-ADS

MGCF

CS Domain Bearer

13. IAM (SCC AS PSI DN)

Figure 7.4.2.2.2-2: ICS UE Terminations with CS media information flows using Gm reference point when using an MSC Server

NOTE 2: Steps 11, 12,13,14 and 15 are related to the setup of the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.


ETSI


At Steps 13 and 14, the MSC server sends the IAM to an MGCF using the SCC AS PSI DN which is subsequently inter-worked to an INVITE containing the SCC AS PSI and an SDP Offer from the MGW.


7.4.2.2.3 Terminations with CS media using the I1 reference point

Figure 7.4.2.2.3-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for ICS, where the incoming session is delivered over the I1 reference point and the media is established via the CS network.

ETSI


Figure 7.4.2.2.3-1: ICS UE Terminations with CS media information flows using I1 reference point when using an MSC Server enhanced for ICS

NOTE 1: Steps 1-10, 15 and 17-22 are related to the setup of the Service Control Signalling Path. Steps 11-14 and 16 are related to the setup of the CS Bearer Control Signalling Path.

1. An incoming SIP INVITE is received at the S-CSCF of the B party from UE A.

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE to the SCC AS.

ETSI


3. The SCC AS sends a Session Progress response to the S-CSCF.

4. The S-CSCF forwards the Session Progress response to UE A.

Steps 5a – 6a are for the case of T-ADS performed by the SCC AS.

5a. The SCC AS performs Terminating Access Domain Selection and if informed of the UE capability for I1 during IMS registration, chooses the CS domain for the setup of the media.

NOTE 2: Conveyance of UE capability of support for I1 does not imply that I1 can be established (e.g. the visited network does not support I1).

6a. The SCC AS terminates the session from the A-party and establishes a new session over I1 by sending an Incoming Call Request to the B-party via the HSS and MSC Server. The Incoming Call Request contains an indication to inform the UE to initiate the CS bearer establishment procedure. The Incoming Call Request also contains a dynamic SCC AS PSI (DN) to enable the SCC AS to later on correlate the outgoing service control signalling with the incoming CS bearer control signalling.

Steps 5b – 10 are for the case of UE assisted T-ADS.

5b. Alternatively, in the case of UE assisted T-ADS the SCC AS performs initial T-ADS selecting IMS for the service control signalling when UE-B is registered in the IMS.

6b The SCC AS terminates the session from the A-party and establishes a new session by sending an INVITE to the B-party via the I/S-CSCF. The INVITE contains options that enable UE-B to choose a CS bearer for bidirectional speech media transport if it determines that this is not supported by serving PS Access Network. The INVITE also contains a dynamic SCC AS PSI (DN) to enable the SCC AS to later on correlate the outgoing service control signalling with the incoming CS bearer control signalling. When the T-ADS function selects the Gm reference point for service control, the SCC AS prevents the S-CSCF from selecting the contact address of the MSC server, and the S-CSCF selects the IP-CAN.

7b. The I/S-CSCF sends the INVITE to B-party.

8-10. In the case where the access network does not support simultaneous PS and CS, UE-B responds with a Session Progress message and in the event the "IMS voice over PS session supported indication" indicates voice is not supported as defined in TS 23.401 [34]. UE-B shall indicate in the Session Progress message that a CS bearer is required for the session and that further signalling for the session will be via I1. The S-CSCF forwards the Session Progress message to the SCC AS.

11. The ICS UE sends a CS Setup message to the MSC Server using the SCC AS PSI DN to establish the CS Bearer Control Signalling Path. This will establish the circuit bearer between the UE and IMS.

12. The MSC Server responds with a call proceeding message and begins to set up the CS Bearer Control Signalling Path.

13. The MSC Server sends an INVITE towards the I/S-CSCF containing the SCC AS PSI and an SDP Offer with the media description from the MGW. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

14. The I/S-CSCF forwards the INVITE to the SCC AS.

15. The SCC AS continues the session setup towards the A-party for the original INVITE in Step 1. The response contains an SDP answer with the media description from the SDP offer received in Step 13.

16. The SCC AS completes the set-up of the CS Bearer Signalling Path towards ICS UE B which involves sending a 200 OK in response to the INVITE in Step 14. The ICS UE B, the MSC Server and the SCC AS complete the setup of the CS Bearer Control Signalling Path and the Service Control Signalling Path with UE A.

17. UE-B sends a Ringing indication to the SCC AS via I1.

18-19. The SCC AS sends a Ringing message to the remote end.

20. UE-B sends a Connecting message to the SCC AS via I1.

ETSI


21-22. The SCC AS sends a 200 OK message to the remote end in response to the INVITE received at step 2. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.4.2.2.1 applies.

Figure 7.4.2.2.3-2 provides an example flow for a call destined to an ICS UE attached to an MSC server where the incoming session is delivered over the I1 reference point and the media is established via the CS network.

ETSI


Figure 7.4.2.2.3-2: ICS UE Terminations with CS media information flows using I1 reference point when using an MSC Server

NOTE 3: Steps 1-10, 16 and 18-23 are related to the setup of the Service Control Signalling Path. Steps 11-15 and 17 are related to the setup of the CS Bearer Control Signalling Path.


ETSI


At Steps 13 and 14, the MSC server sends the IAM to an MGCF using the SCC AS PSI DN which is subsequently inter-worked to an INVITE containing the SCC AS PSI and an SDP Offer from the MGW.


7.4.2.2.4 Terminations with CS media using CS control with I1 augmentation

Standard CS terminating procedures are used to deliver the incoming session to the ICS UE as described in Figure 7.4.2.2.3-1 when the ICS UE is attached to an MSC server enhanced for ICS, and in Figure 7.4.2.2.3-2 when the ICS UE is attached to an MSC server. Additional IMS parameters can be optionally communicated to the ICS UE using I1 after the incoming session has been delivered.

7.4.2.2.5 Terminations with CS media when not using Gm or I1

Figure 7.4.2.1.2-1 provides an example flow for a call destined to an ICS UE attached to an MSC server enhanced for ICS, where the incoming session is delivered using standard CS terminating procedures.

If an ICS UE is attached to an MSC server where the incoming session is delivered to it using standard CS terminating procedures, an example call flow is shown in Figure 7.4.2.1.3-1.

7.4.2.2.6 Void

7.4.2.2.7 Terminating access network reselection – fallback to alternate access

When using the Gm reference point for delivery of the incoming session to the ICS UE, if it fails to set up the bearer in the selected terminating access network and other access network(s) is available for the service, the UE may send a message to the SCC AS indicating the failure of bear setup with the information required for access network reselection (e.g. the information of available access network(s)), or indicate a newly selected access network. The SCC AS can then, based on the message and operator policy, update the relevant decision information for T-ADS if necessary and reselect a new access network for bearer setup to complete the terminating session establishment.

Figure 7.4.2.2.7-1 gives an example flow of terminating access reselection for ICS UE terminating session establishment using Gm reference point.

ETSI


Figure 7.4.2.2.7-1: Access reselection for ICS UE termination over Gm reference point

1. An incoming call arrives at UE B from UE A. T-ADS is executed by the SCC AS and an access network is chosen for bearer establishment (refer to Steps 1-7a in Figure 7.4.2.2.2-1).

2. Bearer setup fails in the selected access network.

3. UE B sends a message to the I/S-CSCF indicating the failure of bearer setup. Information required for the SCC AS to re-execute T-ADS and to select a new access network is provided (e.g. info of access network(s) available for the service), or a new access network selected by the UE for bearer setup is indicated.

4. The I/S-CSCF forwards the message to the SCC AS based on originating initial filter criteria.

5. The SCC AS updates the relevant decision information for T-ADS and re-executes T-ADS to select a new access network for bearer setup of the session if no new access network is selected by the UE.

6-7. The SCC AS sends an Invite message to UE B via the S-CSCF to establish the session, with the newly selected access network for bearer setup indicated or confirmed (if selected by the UE).

8. Bearer setup in the newly selected terminating access network for the session.

9. Completion of session setup procedures between UE A and UE B.

7.4.3 Terminating sessions over Gm rejected by the UE

Figure 7.4.3-1 provides an example flow for a call destined to a UE-2 and where the incoming session is delivered over the Gm reference point offering either PS speech media, CS media, or PS speech media with alternative CS media, because the SCC AS is unable to accurately determine that the CS domain should be used, e.g. when ISR according to TS 23.401 [34] is active and if the UE hasn't re-registered in the IMS. In this example call flow the UE-2 rejects the incoming session and T-ADS in the SCC AS selects CS domain for termination. The flow applies to both ICS UE and non ICS UE.

ETSI


Figure 7.4.3-1: Terminating session rejected by the UE

1. The request is received at S-CSCF following normal IMS session set up procedures.

2~3. The service logic with iFC causes the request to be forwarded to the SCC AS.

4. The SCC AS anchors the session. T-ADS is executed and the PS access is selected for termination.

5~6. The SIP INVITE is forwarded to the UE via the selected PS access. Paging is triggered if the UE is in Idle state.

7~8. The UE determines that PS access cannot be used for a session with the offered media and it returns a response to the IMS indicating the error condition. The S-CSCF forwards the message to the SCC AS.

9. On receiving the response, the SCC AS reattempts the terminating call establishment directly towards the same UE over CS domain if possible.

10~11. The SIP INVITE is forwarded to UE-2 via the MSC Server enhanced for ICS (or via MGCF and MSC if the MSC is not enhanced for ICS).

12. Terminating CS call establishment.

NOTE: If the UE determines that PS access cannot be used for the media flows it might be worth providing the caller party with a courtesy tone generated by the IMS while the termination is being re-attempted.

ETSI


7.5 Service continuity

7.5.1 Service continuity for ICS UE

7.5.1.1 Service continuity while maintaining the use of CS access for the media

7.5.1.1.1 IMS sessions established using Gm reference point

7.5.1.1.1.1 Overview

When the CS bearer is used for the media of the IMS session, the Gm reference point may be used for communication of service control signalling, contingent upon the VPLMN support of the Gm reference point. A change of access network due to handover (e.g. as described in TS 23.009 [22] and TS 25.413 [23]), may result in an inability to use the PS access for the Gm reference point while the use of CS access for the media of the IMS session is still possible; under such circumstance, the service continuity is maintained by switching the signalling transport over to the CS access, e.g. by switching the use of Gm with the I1 reference point or to not using Gm or I1.

7.5.1.1.1.2 Use of Gm reference point possible after handover

Standard Handover procedures, that are specific to different access networks (e.g. as described in TS 23.009 [22] and TS 25.413 [23]), are used for handover of the Service Control Signalling Path and the CS Bearer Control Signalling Path along with the associated circuit bearer to the target access network.

The use of Gm reference point for Service Control Signalling Path is maintained upon handover.

7.5.1.1.1.3 Use of Gm reference point not possible after Handover

Standard CS handover procedures, that are specific to different access networks (e.g. as described in TS 23.009 [22] and TS 25.413 [23]), are used to relocate the CS Bearer Control Signalling Path and the associated circuit bearer to the target access network. Upon completion of the handover of the CS Bearer Control Signalling Path and the associated circuit bearer to the target access, the UE sends a handover notification message to the SCC AS to indicate use of I1 for the Service Control Signalling Path if the I1 reference point is available in the target access network or to fallback to not using Gm or I1.

After handover, the I1 reference point is used for service control signalling in networks supporting the I1 reference point; the non ICS UE procedures apply in networks not supporting the I1 reference point.

7.5.1.1.1.3a Use of Service Control Signalling Path not possible after Handover

7.5.1.1.1.3a.1 MSC Server assisted mid-call feature not used

If the SCC AS detects that the ICS UE is not reachable over the Service Control Signalling Path and if the UE or the network does not support the MSC Server assisted mid-call feature as specified in TS 23.237 [12], the SCC AS shall:

- clear any held sessions related to the user and update the remote leg if necessary; and

- clear any active session that is a conference initiated by the user and hosted in the IMS.

NOTE 1: Detecting the loss of the Service Control Signalling Path is an implementation issue.

NOTE 2: In order to avoid an unintentional release of an ongoing ICS session, an ICS UE can re-register its Public User Identity with the IMS at a time chosen to minimize the probability of its IMS registration expiring during an ongoing ICS session when Gm is not available. To prevent the ICS UE requesting re-registration with unacceptable frequency, the Registrar in a network implementing ICS would need to set the IMS registration expiry timer to an appropriate value.

Figure 7.5.1.1.1.3a-1 is an example call flow of releasing the aforementioned session at the SCC AS when the SCC AS detects that the ICS UE is not reachable over Service Control Signalling Path and the UE or the network does not support the MSC Server assisted mid-call feature as specified in TS 23.237 [12].

ETSI


Figure 7.5.1.1.1.3a-1: release of held sessions at SCC AS when Service Control Signalling Path unavailable

1. The SCC AS detects that the ICS UE is not reachable over Service Control Signalling Path.

2. The SCC AS releases the held session between UE A and UE C and/or the active session that is a conference initiated by UE A and hosted in the IMS.

3. The SCC AS sends the UPDATE to the S-CSCF.

4. The S-CSCF forwards the UPDATE to the UE B to update the remote leg.

7.5.1.1.1.3a.2 MSC Server assisted mid-call feature used and MSC Server supports ICS

See TS 23.237 [12] IMS Service Continuity.

7.5.1.2 Service continuity when transferring the media of IMS sessions between PS and CS access

See TS 23.237 [12] IMS Service Continuity.

7.5a Addition of Gm service control to existing call

7.5a.1 Overview

A call can be established by an ICS UE that supports Gm, but without using the Gm reference point (for example, as a result of CSFB, or when in non-DTM GERAN coverage). If Gm is available after call establishment, or becomes available (for example, as a result of a change of access network due to handover), no mid-call services are applicable to the call, and the call is anchored in the SCC AS as described in clause 7.3.2.1 or 7.4.2.1, the UE may augment the ongoing CS call in order to be able to use Gm for service control signalling.

If the UE does augment the ongoing CS call with Gm service control signalling then the UE shall use Gm when establishing additional calls, or for any mid-call signalling. The UE shall continue to use Gm procedures until the existing calls end.

If the UE does not augment the ongoing CS call with Gm service control signalling then the UE shall use CS procedures when establishing additional calls, or for any mid-call signalling. The UE shall continue to use CS procedures until the existing calls end.

7.5a.2 Augmentation call flow

If configured to do so the ICS UE may invoke IMS signalling to add Gm service control to the ongoing session.

ETSI


UE

PS CS

I / S-CSCF SCC AS

3. Remote Leg Update

1. INVITE (STI, SDP speech and media

2. INVITE (STI, SDP speech and media

Figure 7.5a.2-1: Augmentation with Gm

1. When the UE determines a need to augment a CS call with Gm, the UE initiates registration with IMS via the new PS access (if not already registered). It initiates the augmentation by sending an INVITE to establish the service control signalling via the PS access. The INVITE includes the SDP for speech or speech and video and non-real-time media flow(s) and the static (provisioned) STI, as defined in TS 23.237 [12].

2. Standard procedures are used at S-CSCF for routing of the INVITE to the SCC AS.

3. The SCC AS identifies the session to be augmented using the STI. If the INVITE request contains additional PS media the SCC AS also performs the Remote Leg Update to update the combined session towards the Remote Leg.

7.6 Consistency of Supplementary Services

7.6.0 General

The applicability of Supplementary Services to the different media types that apply for ICS (as defined in clause 22.4 of TS 22.101 [9]) are specified in Annex A of TS 22.004 [41].

7.6.1 Supplementary Services for ICS UE

7.6.1.1 Overview

When the IP-CAN is used for the media of the IMS session, IMS procedures as defined in TS 24.173 [8] apply for IMS services.

When the CS bearer is used for the media of the IMS session, the Gm or the I1 reference point is used for communication of service control signalling; IMS services are provided to the ICS UE with the IUA of the SCC AS combining the service control signalling with the description of the CS bearer for execution of service control over the Remote Leg.

ETSI


7.6.1.2 IMS sessions using CS bearer

7.6.1.2.1 Overview

When the CS bearer is used for the media of the IMS Multimedia Telephony service, see TS 22.173 [4], the procedures specified in this clause apply.

7.6.1.2.2 Use of Gm reference point

7.6.1.2.2.1 Line ID Services (OIP, OIR, TIP, TIR)

IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with the service control signalling communicated over the Gm reference point as specified in clause 7.1.

7.6.1.2.2.2 Communication Diversion Services

IMS procedures as defined in TS 24.173 [8] apply with the IUA of the SCC AS combining the description of the CS bearer with the service control signalling communicated over the Gm reference point as specified in clause 7.1.

7.6.1.2.2.3 Communication Barring


7.6.1.2.2.4 Communication Hold/Resume


Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Communication Hold/Resume.

NOTE 1: Annex E describes several implementation options on how to process media using MRF.

During communication hold, if a held session is resumed with the same service type/bearer requirement (i.e. voice or video) as the existing CS bearer, the CS bearer shall be reused; otherwise, the CS bearer shall be updated if possible through SCUDIF or redial mechanism (refer to clause 7.9).

Figure 7.6.1.2.2.4-1 provides the ICS Communication Hold/Resume flow over Gm reference point for the ICS UE.

ETSI


Figure 7.6.1.2.2.4-1: ICS Communication Hold/Resume over Gm reference point

1. The ICS UE A sends a Hold request to the S-CSCF as specified in TS 23.228 [2] and TS 24.173 [8]. The hold request indicates whether the media shall continue to be sent to the remote party or not.

2. The S-CSCF forwards the Hold request to the SCC AS based upon filter criteria.

3. The SCC AS sends the Hold request to the S-CSCF indicating the remote party shall stop sending the media and, according to the hold request, continue or stop receiving media from the invoking UE.

4. The S-CSCF sends the Hold request to UE B.

5. The SCC AS sends a media update request to the S-CSCF indicating the media is held.

6. The S-CSCF forwards the media update request to the MGCF. Depending on what information is exactly contained in the request, MGCF could send call hold request towards the CS network according to TS 29.163 [11]. If the ICS UE A receives this request from MGCF, it shall ignore it.

NOTE 2: Steps 5-6 can be executed in parallel with steps 3-4.

7. Completion of communication hold between UE A and UE B based on the procedures specified in TS 23.228 [2].

8. The ICS UE A sends a Resume request to the S-CSCF as specified in TS 23.228 [2] and TS 24.173 [8].

9. The S-CSCF forwards the Resume request to the SCC AS based upon filter criteria.

10. The SCC AS sends the Resume request to the S-CSCF.

11. The S-CSCF sends the Resume request to UE B.

12. The SCC AS sends a media update request to the S-CSCF indicating the media is resumed.

13. The S-CSCF forwards the media update request to the MGCF.

NOTE 3: Steps 12-13 can be executed in parallel with steps 10-11.

14. Completion of communication resume between UE A and UE B based on the procedures specified in TS 23.228 [2].

NOTE 4: If MSC Server enhanced for ICS is deployed rather than the MSC Server and MGCF, the same flows apply and the MSC Server enhanced for ICS plays the role of MSC Server and MGCF.

ETSI


7.6.1.2.2.5 Explicit Communication Transfer

IMS procedures as defined in TS 24.173 [8] apply with the SCC AS combining the description of the CS bearer with the service control signalling communicated over the Gm reference point as specified in clause 7.1 of this document.

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Explicit Communication Transfer.

7.6.1.2.2.5.1 Consultative ECT using Gm reference point, ICS UE as transfer recipient

Figure 7.6.1.2.2.5.1-1 describes how IMS consultative ECT is performed when ICS UE B is playing the role of transfer recipient using Gm interface. The UE A has a held call with UE C and an ongoing call with ICS UE B before transfer.

Figure 7.6.1.2.2.5.1-1: IMS Consultative ECT via Gm for ICS UE (transfer recipient)

1. UE A initiates transfer of ICS UE B to UE C by sending a REFER request as specified in TS 24.173 [8].

2. The S-CSCF sends the REFER to the SCC AS as it was inserted at session establishment.

3. The SCC AS sends the REFER to the S-CSCF.

4. The S-CSCF sends the REFER to the ICS UE B.

5. The ICS UE B initiates session establishment towards UE C by initiating an INVITE message.

6. Filter criteria directs the S-CSCF to send the INVITE to the SCC AS.

7. The INVITE is sent to the S-CSCF.

8. The S-CSCF routes the request to UE C.

9.-12. UE C sends back session progress messages to the ICS UE B via S-CSCF and SCC AS.

13. SCC AS sends a backward message to MGCF to update MGW port for connecting with UE C.

ETSI


14. A session is established between the ICS UE B and UE C.

15. UE C release the session with UE A.

16. The ICS UE B provides indication that the communication transfer is complete by sending a NOTIFY message as specified in TS 24.173 [8].

17. The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment.

18. The SCC AS sends the NOTIFY to the S-CSCF.

19. The NOTIFY is sent to UE A.

20. The UE A initiates session release with ICS UE B and release the session.

NOTE: If MSC Server enhanced for ICS is deployed rather than the MSC Server and MGCF, the same flows apply and the MSC Server enhanced for ICS plays the role of MSC Server and MGCF.

7.6.1.2.2.5.2 Blind ECT using Gm reference point, ICS UE as transfer recipient

Figure 7.6.1.2.2.5.2-1 describes how IMS blind ECT is performed when ICS UE is playing the role of transfer recipient using Gm interface. The UE A has a held call with ICS UE B and no session with UE C before transfer.

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Communication ECT.

ETSI


Figure 7.6.1.2.2.5.2-1: IMS blind ECT via Gm for ICS UE (transfer recipient)

1. UE A initiates transfer of ICS UE B to UE C by sending a REFER as specified in TS 24.173 [8].


3. The SCC AS acknowledges the REFER message as a blind transfer request for ICS UE B and sends the REFER to the S-CSCF.

4. The S-CSCF sends the REFER to the ICS UE B.

5. ICS UE B accepts the transfer request.

6. The S-CSCF sends the accept message to the SCC AS as it was inserted at session establishment.

7. The SCC AS sends the accept message to the S-CSCF.

8. The S-CSCF sends the accept message to the UE A.

9. On reception of the accept message from the ICS UE B, UE A initiates the session release with the ICS UE B by initiating a BYE message to ICS UE B.

ETSI


10. The S-CSCF sends the BYE to the SCC AS as it was inserted at session establishment. On reception of the BYE, the SCC AS releases only the PS session signalling path with UE A and keeps the CS bearer between ICS UE B and the MGW.

11. The SCC AS sends the BYE to the S-CSCF.

12. The S-CSCF sends the BYE to the ICS UE B.

13. Session between UE A and ICS UE B is released. The CS bearer from ICS UE B and MGW is kept for further reuse.

14. The ICS UE B initiates session establishment towards UE C by initiating an INVITE message.


16. The INVITE with the MGW SDP received from the MSC Server/ MGCF upon UE A-UE B session establishment is sent to the S-CSCF.

17. The S-CSCF routes the request onwards to UE C.

18.-21. UE C sends back session progress messages to the ICS UE B via S-CSCF and SCC AS.

22. SCC AS sends a backward message to MGCF to update the MGW port for connecting with UE C.

23. A session is established between the ICS UE B and UE C.

24. The ICS UE B provides indication that the communication transfer is complete by sending a NOTIFY as specified in TS 24.173 [8].



27. The NOTIFY is sent to UE C as specified in TS 24.173 [8].

NOTE: If MSC Server enhanced for ICS is deployed rather than the MSC server and MGCF, the same flows apply and the MSC Server enhanced for ICS plays the role of MSC Server and MGCF.

7.6.1.2.2.6 Conferencing


Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Conferencing.

Figure 7.6.1.2.2.6-1 describes how ICS UE executes the IMS conferencing when using Gm interface. The ICS UE A has a held call with UE B and a held call with UE C before it initiates a conference.

ETSI


Figure 7.6.1.2.2.6-1: ICS UE executes the IMS Conferencing via Gm

1. The ICS UE A initiates a session with the conference AS by sending an INVITE to S-CSCF.

2. The S-CSCF sends the INVITE to the SCC AS as it was inserted at session establishment.

3. The SCC AS sends the INVITE to the S-CSCF.

4. The INVITE is sent to the conference AS.

5. A conference connection is created as specified in TS 24.173 [8].

6.-9. Conference AS sends an OK response containing the conference URI to the ICS UE A via S-CSCF and SCC AS.

10. SCC AS sends a backward message to MGCF to update the MGW port for connecting with the conference AS.

11. The ICS UE A initiates a REFER message indicating UE B transferring the current session to the conference AS using Gm interface as specified in TS 24.173 [8].



ETSI


14. The S-CSCF sends the REFER to UE B.

15. A session is established between the conference AS and UE B as specified in TS 24.173 [8].

16.-19. UE B sends a NOTIFY indicating the transfer completed back to ICS UE A via S-CSCF and SCC AS.

20. The media between the ICS UE A and UE B is released.

21. Step 11-20 are repeated for UE C.

NOTE 1: UE B and UE C can be referred to the conference in parallel.

NOTE 2: If the MSC Server enhanced for ICS is deployed rather than the MSC Server and MGCF, the same flows apply and the MSC Server enhanced for ICS plays the role of the MSC Server and the MGCF.

7.6.1.2.2.7 Communication Waiting

Figure 7.6.1.2.2.7-1 provides the ICS communication waiting flow over Gm reference point for the ICS UE.

Figure 7.6.1.2.2.7-1: ICS UE Communication Waiting over Gm Reference Point

1. An incoming INVITE message is received at the S-CSCF of the ICS UE A.

2. The S-CSCF executes terminating initial filter criteria and forwards the INVITE message to the SCC AS.

3. The SCC AS performs terminating access domain selection and chooses the CS access network for the setup of the media.

4. The SCC AS sends the INVITE message to the S-CSCF.

5. The S-CSCF sends the INVITE message to UE A.

6. The ICS UE A sends to the S-CSCF an indication that the call is waiting.

7. The S-CSCF sends the indication of call waiting to the SCC AS.

8. The SCC AS sends the indication of call waiting to the S-CSCF.

9. The S-CSCF forwards the indication of call waiting to UE C.

10. The ICS UE A sends a Hold message to the S-CSCF as specified in TS 23.228 [2].

11. The session between UE A and UE B is put on hold as described in clause 7.6.1.2.2.2 Communication Hold/Resume.

12. Completion of the session establishment between UE A and UE C. The existing CS bearer can be reused.

ETSI


7.6.1.2.2.8 Customized Alerting Tone (CAT)


The CS bearer is used for the media of the customized alerting tone, as well as the media of the regular session. And the CS bearer shall be reused if already established using the Gm reference point as specified in clause 7.3.2.2.1.

If the ICS UE originates an ICS session reusing the existing CS bearer as specified in clause 7.3.2.2.1, the SCC AS shall send the early session media info to the MSC Server/MGCF in the form of regular session media info (i.e. a SDP without early media indication). Then the SCC AS sends the regular session media info of the remote party to the MSC Server/MGCF for the session communication when receiving the 200 OK (acceptance of the session) from the remote party, if the early session or forking model is used for the CAT service.

7.6.1.2.3 Use of I1 reference point

7.6.1.2.3.1 Line ID Services (OIP, OIR, TIP, TIR)

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1 of this document. The information specific to Line ID services is communicated over the I1 reference point when the I1 reference point is used at session setup.

7.6.1.2.3.2 Communication Diversion Services

7.6.1.2.3.2.1 Communication Forwarding Unconditional (CFU)

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1.

7.6.1.2.3.2.2 Communication Forwarding on Not Logged-in (CFNL)


7.6.1.2.3.2.3 Communication Forwarding Busy (CFB)

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1. When I1 is used for session set-up, the information specific to CFB is communicated over the I1 reference point; the SCC AS performs the necessary interworking between the I1 signalling and IMS to allow execution of CFB in IMS.

Figure 7.6.1.2.3.2.3-1 provides the Communication Forwarding Busy (CFB) flow over the I1 reference point for an ICS UE.

ETSI


Figure 7.6.1.2.3.2.3-1 Communication Forwarding on Busy User flow over the I1 reference point for an ICS UE.

1 An incoming SIP INVITE is received at the S-CSCF of the B party from the A party.

2-4 The S-CSCF forwards the INVITE to the TAS and SCC AS.

5 The SCC AS sends an incoming Call Request to the UE over I1 via the MSC server.

6-7 The UE rejects the incoming call request as the user is busy and sends a User Determine User Busy (UDUB) response over I1 to the SCC AS.

8-9 The SCC AS inter-works the UDUB response over I1 into an appropriate SIP Response to indicate that the B party is busy, and sends the SIP Response to the TAS via the CSCF.

10 The TAS processes the SIP Response and executes the CFB logic.

7.6.1.2.3.2.4 Communication Forwarding No Reply (CFNR)

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1. The information specific to CFNR is communicated over the I1 reference point when the I1 reference point is used at session setup.

Figure 7.6.1.2.3.2.4-1 provides the Communication Forwarding No Reply flow over the I1 reference point for an ICS UE.

ETSI


S-CSCFTASSCC ASMSC ServerICS UE B UE A

1. INVITE

2. INVITE

6. I1: Incoming Call

3. Start Timer

9. CFNR Logic

8. No Answer from ICS UE.

Timer Expires at the TAS

4. INVITE

7. CS Bearer Setup procedures

5. INVITE

Figure 7.6.1.2.3.2.4-1: Communication Forwarding No Reply flow over the I1 reference point for an ICS UE

1. An incoming SIP INVITE is received at the S-CSCF of the B party from the A party.

2. The S-CSCF forwards the INVITE to the TAS and SCC AS.

3. The SCC AS starts a supervisory timer for the call.

4-5 The TAS forwards the INVITE to the SCC AS via the S-CSCF.

6. The SCC AS sends an incoming Call Request to the ICS UE over I1.

7. The ICS UE performs CS bearer set-up procedures.

8. The SCC AS does not receive an answer from the ICS UE and the timer at the TAS expires.

9. The TAS executes the CFNR logic.

7.6.1.2.3.2.5 Communication Forwarding on Subscriber Not Reachable (CFNRc)

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1. When I1 is used for call set-up, the SCC AS performs the necessary interworking between the I1 signalling response and SIP to allow execution of CFNRc in IMS.

Figure 7.6.1.2.3.2.5-1 provides the Communication Forwarding on Subscriber Not Reachable flow over the I1 reference point for an ICS UE.

ETSI


Figure 7.6.1.2.3.2.5-1: Communication Forwarding Not Reachable flow over the I1 reference point for an ICS UE

1. An incoming SIP INVITE is received at the S-CSCF of the B party from the A party.

2-4. The S-CSCF forwards the INVITE to the TAS and SCC AS.

5. The SCC AS, MSC Server or another node in the Service Control Signalling Path (e.g. HSS or HLR) determines that the user is not reachable, for example:

- The MSC Server pages the ICS UE B and no response to the page message is received.

- The MSC Server itself determines that the user is not reachable (e.g. IMSI detach).

- The MSC Server pages the ICS UE B and a page response is received but the CS bearer set up procedures fail.

6-7. The SCC AS sends an appropriate SIP response that indicates that the user is unreachable to the TAS via the CSCF.

8. The TAS processes the SIP response and executes the CFNRc logic.

7.6.1.2.3.2.6 Communication Deflection (CD)

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1. When I1 is used for call set-up, the information specific to CD is communicated over the I1 reference point; the SCC AS performs the necessary interworking between the I1 signalling and SIP to allow execution of CD in IMS.

Figure 7.6.1.2.3.2.6-1 provides the Communication Deflection (CD) flow over the I1 reference point for an ICS UE.

ETSI


S-CSCFTASSCC ASMSC ServerICS UE B UE A

9. SIP Response (C-party)

4. INVITE

1. INVITE

7. I1: Call Deflection Request (C-party)

8. SIP Response (C-party)

2. INVITE

3. INVITE

5. I1: Incoming Call

6. User Deflects Call

10. CD Logic

Figure 7.6.1.2.3.2.6-1 Communication Deflection flow over the I1 reference point for an ICS UE

1 An incoming SIP INVITE is received at the S-CSCF of the B party from the A party.

2-4 The S-CSCF forwards the INVITE to the TAS and SCC AS.

5 The SCC AS sends an incoming Call Request to the UE over I1 via the MSC server.

6-7 The user decides to deflect the call and the UE returns a Call Deflection Request to the SCC AS over I1 indicating the deflected-to party.

8-9 The SCC AS inter-works the Call Deflection Request received over I1 into an appropriate SIP response and sends the SIP response to the TAS via the CSCF.

10 The TAS processes the SIP response and executes the CD logic.

7.6.1.2.3.2.7 Communication Diversion Notification (CDIVN)


When I1 is used for call set-up, the SCC AS performs the necessary interworking between the I1 signalling and SIP to subscribe to the comm-div-info event package at the TAS on behalf of the UE and to receive and propagate to the UE, the notification that the call was diverted.

7.6.1.2.3.3 Communication Barring


7.6.1.2.3.4 Communication Hold/Resume

IMS procedures as defined in TS 24.173 [8] apply. The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1 of this document.

ETSI


Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Communication Hold/Resume.

NOTE: Annex E describes several implementation options on how to process media using MRF.

During communication hold, if a held session is resumed with the same service type/bearer requirement (i.e. voice or video) as the existing CS bearer, the CS bearer shall be reused; otherwise, the CS bearer shall be updated if possible through SCUDIF or redial mechanism (refer to clause 7.9).

Figure 7. 6.1.2.3.4-1 describes how IMS session hold and resume is performed via I1 interface for ICS UE.

Figure 7. 6.1.2.3.4-1: IMS communication Hold and Resume by ICS UE

1. The ICS UE A sends a Hold message to the SCC AS via I1 reference point.

2. The session between ICS UE A and UE B is held as specified in clause 7.6.1.2.2.4.

3. The ICS UE A sends a Resume message to the SCC AS via I1 reference point.

4. The session between ICS UE A and UE B is resumed as specified in clause 7.6.1.2.2.4.

7.6.1.2.3.5 Explicit Communication Transfer


Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Explicit Communication Transfer.

7.6.1.2.3.5.1 Consultative Explicit Communication Transfer

Figure 7. 6.1.2.3.5.1-1 describes how IMS consultative ECT is performed when ICS UE A is playing the role of transfer initiator using I1 interface. The ICS UE A has a held call with UE B and an ongoing call with UE C before transfer.

ETSI


S-CSCF SCC ASMGWICS UE A

1. I1: refer B to C

UE B UE C

ICS UE A has an ongoing call with UE C. ICS UE A holds the call with UE B.

3. I1: transfer complete

4. Session release between A & B

2. Refer B to C

MSC MGCF

Figure 7. 6.1.2.3.5.1-1: IMS Consultative ECT via I1 for ICS UE (transfer initiator)

1. The ICS UE A initiates transfer of UE B to UE C by sending a transfer message to SCC AS using I1 interface.

2. Completion of referring UE B to UE C as specified in TS 24.173 [8] and releasing the session between the ICS UE A and UE C.

3. The SCC AS sends the transfer complete message to ICS UE A via I1 interface.

4. The ICS UE A releases the calls between it and UE B.

Figure 7.6.1.2.3.5.1-2 describes how IMS consultative ECT is performed when ICS UE is playing the role of transfer recipient using I1 interface. The UE A has a held call with UE C and also has a held call with ICS UE B before transfer.

Figure 7.6.1.2.3.5.1-2: IMS Consultative ECT via I1 for ICS UE (transfer recipient)



3. The S-CSCF sends a transfer message to the ICS UE B via I1 interface.

4. The ICS UE B initiates a call initiation message to SCC AS via I1 interface.

5. Completion of referring the ICS UE B to UE C as specified in TS 24.173 [8] and releasing the session between the UE A and UE C.

6. The ICS UE B provides an indication that the communication transfer is complete to SCC AS via I1 interface.

ETSI


7. The SCC AS sends a NOTIFY message to the S-CSCF.


9. The UE A initiates session release with ICS UE B and release the session.

Figure 7.6.1.2.3.5.1-3 describes how IMS consultative ECT is performed when ICS UE is playing the role of transfer target using I1 interface. The UE A has a held call with UE C and also has a held call with ICS UE B before transfer.

Figure 7.6.1.2.3.5.1-3: IMS Consultative ECT via I1 for ICS UE (transfer target)

1. UE A initiates transfer of UE B to ICS UE C by sending a REFER request as specified in TS 24.173 [8].

2. An INVITE is sent by UE B upon reception of the REFER request as specified in TS 24.173 [8], and received at the S-CSCF of the ICS UE C.

3. The S-CSCF executes terminating initial filter criteria and forwards the INVITE message to the SCC AS.

4. The SCC AS sends an incoming call request to the ICS UE C over I1 reference point. The incoming call request indicates that a new session between UE C and UE B is to replace the current session between UE C and UE A.

5. Completion of referring UE B to the ICS UE C as specified in TS 24.173 [8] and releasing the session between UE A and the ICS UE C.

6. UE A initiates session release with UE B and releases the session.

7.6.1.2.3.5.2 Blind Explicit Communication Transfer

Figure 7.6.1.2.3.5.2-1 describes how IMS Blind ECT is performed when ICS UE A is playing the role of transfer initiator using I1 interface. The ICS UE A has a held call with UE B before transfer.

Figure 7.6.1.2.3.5.2-1: IMS Blind ECT via I1 for ICS UE (transfer initiator)

ETSI


1. The ICS UE A initiates transfer of UE B to UE C by sending a transfer message to SCC AS using the I1 interface.

2. Completion of referring UE B to UE C as specified in TS 24.173 [8] and releasing the session between the ICS UE A and UE B.

3. The SCC AS sends the transfer complete message to ICS UE A via the I1 interface.

Figure 7.6.1.2.3.5.2-2 describes how IMS blind ECT is performed when ICS UE A is playing the role of transfer recipient using the I1 interface. The UE A has a held call with ICS UE B before transfer.

Figure 7.6.1.2.3.5.2-2: IMS Blind ECT via I1 for ICS UE (transfer recipient)



3. The S-CSCF sends a transfer message to the ICS UE B via I1 interface.

4. Session continuation between UE A and ICS UE B as specified in clause 7.6.1.2.2.5.2, steps 5-12.

5. The ICS UE B initiates session establishment towards UE C by initiating a call initiation message to SCC AS via I1 interface.

6. Completion of session establishment between the ICS UE B and UE C as specified in clause 7.6.1.2.2.5.2, steps 15-22.

7. The ICS UE B provides indication that the communication transfer is complete to SCC AS via I1 interface.

8. The SCC AS sends a NOTIFY message to the S-CSCF.


7.6.1.2.3.6 Conferencing

IMS procedures as defined in TS 24.173 [8] apply The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1.

Additionally, the SCC AS may employ an MRF for control of media as needed for execution of the Conferencing.

Figure 7.6.1.2.3.6-1 describes how ICS UE executes the IMS conferencing when using I1 interface. The ICS UE A has a held call with UE B and a held call with UE C before it initiates a conference.

ETSI


Figure 7.6.1.2.3.6-1: ICS UE executes the IMS Conferencing via I1

1. The ICS UE A initiates a session with the conference AS by sending a conference invitation message to SCC AS via I1 interface.

2. The SCC AS continues session establishment towards the conference AS and the conference connection is created as specified in clause 7.6.1.2.2.6, steps 3 to 7.

3. On receipt of an OK message from the Conference AS, the SCC AS sends an OK message to the ICS UE via the I1 interface.

4. The SCC AS sends a backward message to the MGCF to update the MGW port for connecting with the conference AS.

5. The ICS UE A initiates a message to the SCC AS via I1 interface indicating UE B transferring the current session to the conference AS.

6. UE B is referred to the conference AS as specified in clause 7.6.1.2.2.6.

7. On receipt of a Notify message from UE B indicating transfer complete, the SCC AS sends a transfer completed message to ICS UE A via I1 interface.

8. The session between the ICS UE A and UE B is released.

9. Steps 5-8 is repeated for UE C.


NOTE 2: As specified in TS 24.147 [21], another alternative for this scenario is that ICS UE sends the Party B and Party C numbers to the conference AS via SCC AS. Consequently, the conference AS invites Party B and Party C to the conference.

7.6.1.2.3.7 Communication Waiting

IMS procedures as defined in TS 24.173 [8] apply The SCC AS combines the description of the CS bearer with the service control signalling communicated over the I1 reference point, as specified in clause 7.1.

ETSI


7.6.1.2.4 When use of Gm or I1 reference point is not possible due to VPLMN limitations

7.6.1.2.4.1 When attached to an MSC Server enhanced with ICS

Procedures specified in clause 7.6.2 Service Consistency for non ICS UE apply.

7.6.1.2.4.2 When attached to an MSC Server not enhanced with ICS

Procedures specified in clause 7.6.3 apply.

7.6.1.3 User configuration of Supplementary Services

An ICS UE supporting multimedia telephony shall manage the IMS multimedia telephony communication service settings data as specified in TS 24.173 [8]. I1 does not support configuration of supplementary services.

7.6.2 Supplementary service invocation using the MSC Server enhanced for ICS

7.6.2.1 Overview

For IMS sessions established by non ICS UEs using the MSC Server enhanced for ICS, the I2 reference point is used for communication of service control signalling. The MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling to allow the IMS to provide the IMS Multimedia Telephony Service as defined in TS 22.173 [4].

7.6.2.2 Line ID Services (OIP, OIR, TIP, TIR)

For IMS sessions established by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.081 [13]) to allow OIP, OIR, TIP and TIR as described in TS 24.173 [8] to be controlled by the IMS.

For OIP, the MSC Server may interwork any display name received in conjunction with the TEL URI or SIP URI to the CS signalling specified for the calling name presentation (CNAP) service (e.g. as described in TS 24.096 [29]).

NOTE 1: The ability to interwork identity information from the I2 reference point to CS signalling is limited to scenarios where the IMS identity is a TEL URI or its SIP URI equivalent as described in TS 23.228 [2] or to where a display name is received and the MSC Server supports the interworking described in this clause

NOTE 2: A terminating UE using CS signalling is not able to temporarily override default settings for the TIP/TIR supplementary service.

NOTE 3: Interworking of display name received in conjunction with a Tel URI or SIP URI to calling name presentation using CNAP is subject to local regulatory requirements on calling line identity and whether the originating network of the call is trusted to provide an authentic identity.

7.6.2.3 Communication Diversion Services

For IMS sessions established by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.082 [14]) to allow Communication Diversion (CDIV) services to be executed in the IMS.

7.6.2.3.1 Communication Forwarding Unconditional (CFU)

Communication Forwarding Unconditional (CFU) is provided as specified in TS 24.173 [8].

7.6.2.3.2 Communication Forwarding Busy (CFB)

Communication Forwarding network determined user Busy (CFB) is provided as specified in TS 24.173 [8].

ETSI


For Communication Forwarding user determined Busy (CFB), the MSC Server enhanced for ICS shall perform the necessary interworking between CS signalling (e.g. as described in TS 24.082 [14]) and the I2 reference point to allow the IMS to execute CFB.

7.6.2.3.3 Communication Forwarding No Reply (CFNR)

Communication Forwarding No Reply (CFNR) is provided as specified in TS 24.173 [8].

The MSC Server enhanced for ICS shall allow the IMS to control the length of time allowed for the UE to reply to the communication request prior to invoking CFNR.

7.6.2.3.4 Communication Forwarding on Not Logged-in (CFNL)

Communication Forwarding on Not Logged-in (CFNL) is provided as specified in TS 24.173 [8].

7.6.2.3.5 Communication Deflection (CD)

For Communication Deflection (CD), the MSC Server enhanced for ICS shall perform the necessary interworking between CS signalling (e.g. as described in TS 24.072 [15]) and the I2 reference point to allow the UE to deflect an incoming call back to the IMS for redirection to another user.

7.6.2.3.6 Communication Forwarding on Subscriber Not Reachable (CFNRc)

For Communication Forwarding on Subscriber Not Reachable (CFNRc), the MSC Server enhanced for ICS shall return the appropriate reply to the offered session to allow the IMS to execute CFNRc, (e.g. as specified in TS 24.604 [26]).

7.6.2.3.7 Communication Diversion Notification (CDIVN)

The support of interworking between CS signalling and the IMS for the CDIVN service is not supported at the MSC Server enhanced for ICS.

7.6.2.3.8 Diversion notifications to originating users

For IMS sessions originated by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.082 [14] and TS 24.072 [15]) to allow the UE to receive notification that an origination was diverted, for use in networks which support this subscription option. This is applicable to all CDIV services.

NOTE: Direct mapping between IMS diversion conditions and CS domain supplementary service codes might not be possible for all services (e.g. CFNL).

7.6.2.4 Communication Barring

For IMS sessions established by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.088 [16]) to provide the UE with notification that a Communications Barring (CB) service was invoked.

NOTE: Unique mappings between SIP responses defined in TS 24.611 [28] and CS domain supplementary service codes are not possible for OCB and ICB.

7.6.2.5 Communication Hold/Resume

For IMS sessions established by UEs using CS media, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.083 [18]) to allow communication hold and resume to be controlled by the IMS.

Figure 7.6.2.5-1 describes how IMS communication hold and resume is performed via the MSC Server enhanced for ICS.

ETSI


Figure 7.6.2.5-1: IMS Communication Hold and Resume via MSC Server enhanced for ICS

1. UE A sends a Hold message to the CS network (e.g. as specified in TS 24.083 [18]).

2. The MSC Server initiates interaction with the CS-MGW over the Mc reference point instructing it to stop sending the media stream toward UE B but to keep the resources for the session reserved.

3. The MSC Server sends the Hold message to the S-CSCF indicating the session is being put on hold as described in TS 24.173 [8].

NOTE 1: For point-to-point speech-only sessions, the SDP offer in the Hold message shall also include RTCP bandwidth modifiers with values greater than zero to allow the remote end to detect that the link is alive during hold, as specified in sub-clause 7.3.1 of TS 26.114 [17].

4. The S-CSCF sends the Hold message to the SCC AS as it was inserted at session establishment.

5. The SCC AS sends the Hold message to the S-CSCF.

6. The Hold message is forwarded to UE B.

7. UE A sends a Retrieve message on the CS network (e.g. as specified in TS 24.083 [18]).

8. The MSC Server initiates interaction with the CS-MGW over the Mc reference point instructing it to resume sending the media stream toward UE B.

9. The MSC Server sends a Resume message to the S-CSCF indicating the session is being resumed as described in TS 24.173 [8].

NOTE 2: For point-to-point speech-only sessions, the SDP offer in the Resume message may also include RTCP bandwidth modifiers with values equal to zero to turn off RTCP as specified in sub-clause 7.3.1 of TS 26.114 [17].

10. The S-CSCF sends the Resume message to the SCC AS.

11. The SCC AS sends the Resume message to the S-CSCF.

ETSI


12. The Resume message is forwarded to UE B.

7.6.2.6 Communication Waiting

For IMS sessions established by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.083 [18]) to allow Communication Waiting (CW) to be controlled by the IMS. A UE may reject a waiting call.

Figure 7.6.2.6-1 describes how IMS CW is performed via the MSC Server enhanced for ICS.

UE A MSC Server MGW SCC AS S -CSCF UE C UE B

Session between UE A and UE B active 1 . INVITE ( A )

2 . INVITE ( A ) with call waiting

indication 3 . INVITE ( A ) with call waiting

indication 4. INVITE ( A ) with call waiting indication

5 . Setup

11. Hold (B )

12 . Session hold between UE A and UE B 13. Connect (C )

14 . Session establishment between UE A and UE C

6. Alerting 7. Call is Waiting Indication

8 . Call is Waiting Indication

9 . Call is Waiting Indication

10. Call is Waiting Indication

TAS

1 a. INVITE (A )

9a . Call is Waiting Indication

9b. Call is waiting indication

1 b. INVITE (A ) with call waiting indication

Figure 7.6.2.6-1: IMS Communication Waiting via MSC Server enhanced for ICS

1. An incoming INVITE is received at the S-CSCF of UE A.

1a. S-CSCF forwards the INVITE to TAS.

1b. The TAS detects the CW condition and inserts Call waiting indication into the INVITE request. The TAS sends the INVITE to S-CSCF.

2. Filter criteria direct the S-CSCF to send the INVITE to the SCC AS.


4. The S-CSCF forwards the INVITE to the MSC Server based on the contact address stored during registration.

5. The MSC Server sends a Setup message to UE A to inform it of the waiting call (e.g. as specified in TS 24.083 [18]).

6. UE A sends an Alerting message for the waiting call.

ETSI


7. The MSC Server sends an indication that the call is waiting.

8. The S-CSCF forwards the indication that the call is waiting to the SCC AS.

9. The SCC AS forwards the indication that the call is waiting to the S-CSCF.

9a. The S-CSCF forwards the indication that the call is waiting to the TAS.

9b. The TAS forwards the indication that the call is waiting to the S-CSCF.

10. The S-CSCF forwards the indication that the call is waiting to UE C.

11. The ICS User accepts the call and UE A sends a Hold message to put the existing session on hold.

12. The existing session between the MSC Server and UE B is put on hold as described in clause 7.6.2.5 of this specification.

13. UE A sends a Connect message for the waiting call.

14. Completion of the IMS session setup procedures.

7.6.2.7 Explicit Communication Transfer

For IMS sessions established by UEs using CS media, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.091 [19]) to allow Explicit Communication Transfer (ECT) to be controlled by the IMS.

When the UE initiates ECT via CS access, the MSC Server enhanced for ICS shall support consultative transfer and shall play the initiator role as described in TS 23.228 [2] on behalf of the UE. The MSC Server enhanced for ICS shall also support the recipient and target roles on behalf of the UE for consultative transfer as described in TS 23.228 [2].

The MSC Server enhanced for ICS shall support the recipient and target roles on behalf of the UE for blind transfer as described in TS 23.228 [2].

The MSC Server enhanced for ICS shall support the recipient and target roles on behalf of the UE for assured transfer as described in TS 23.228 [2].

Figure 7.6.2.7-1 describes how IMS consultative ECT is performed via CS access, with the MSC Server enhanced for ICS playing the role of transfer initiator on behalf of the UE.

ETSI


Figure 7.6.2.7-1: IMS Consultative ECT via MSC Server enhanced for ICS (transfer initiator)

1. UE A initiates transfer of UE B to UE C by sending a call transfer message (e.g. as specified in TS 24.091 [19]).

2. The MSC Server sends a REFER to the S-CSCF. The REFER indicates that UE B is to be transferred to UE C and that this new session is to replace the current session between UE A and UE B.



5. The S-CSCF sends the REFER to the TAS for service execution.

6. The TAS sends the REFER to the S-CSCF.

7. The REFER is sent to UE B as the transfer recipient.

8. UE B initiates session establishment with UE C as specified in TS 24.173 [8].

9. UE C initiates session release with UE A as specified in TS 24.173 [8].

10. UE B provides indication that the communication transfer is complete as specified in TS 24.173 [8].

11. The S-CSCF sends the NOTIFY to the TAS.

12. The TAS sends the NOTIFY to the S-CSCF.



ETSI


15. The MSC Server, as transfer initiator, receives notification that communication transfer is complete.

16. The MSC Server releases the calls (A-B and A-C) toward UE A and indicates transfer success (e.g. as specified in TS 24.091 [19]).

17. The MSC Server, as transfer initiator, initiates release of the IMS session with UE B.

Figure 7.6.2.7-2 describes how IMS consultative ECT is performed via CS access, with the MSC Server enhanced for ICS playing the role of transfer recipient on behalf of the UE.

UE B MSC Server MGW SCC ASS-CSCF UE AUE C

7. INVITE (C, SDP from CS-MGW)

4. REFER (B to C)

5. REFER (B to C)

21. Notification of Call

Transfer

1. REFER (B to C)

6. REFER (B to C)




15. NOTIFY (transfer complete)




TAS

13. Session establishment between MSC Server (on behalf of UE B) and UE C

Session between UE A and UE B active, Session between UE A and UE C on hold

14. Session release

between UE A and UE C

2. REFER (B to C)

3. REFER (B to C)

22. Session release between UE A and MSC Server (on behalf of UE B)





Figure 7.6.2.7-2: IMS Consultative ECT via MSC Server enhanced for ICS (transfer recipient)

1. UE A initiates transfer of UE B to UE C by sending a REFER as specified in TS 24.173 [8].




5. The SCC AS sends the REFER to the S-CSCF within the dialog created for the session between UE A and UE B.

6. The REFER is sent to the MSC Server as the transfer recipient.

7. On behalf of UE B, the MSC Server initiates session establishment towards UE C.


ETSI



10. The S-CSCF sends the INVITE to the TAS.

11. The TAS sends the INVITE to the S-CSCF.

12. The S-CSCF continues with originated session processing as specified in TS 23.228 [2] and routes the request onwards to UE C.

13. A session is established between the MSC Server (on behalf of UE B) and UE C.

14. UE C initiates session release with UE A as specified in TS 24.173 [8].

15. The MSC Server provides indication that the communication transfer is complete by sending a NOTIFY.

16 The S-CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment.




20. The NOTIFY is sent to UE A as specified in TS 24.173 [8].

21. The MSC Servers sends a message with notification of ECT invocation to UE B (e.g. as specified in TS 24.091 [19]).

22. UE A initiates session release with the MSC Server as specified in TS 24.173 [8].

Figure 7.6.2.7-3 describes how IMS blind ECT is performed via CS access, with the MSC Server enhanced for ICS playing the role of transfer recipient on behalf of the UE.

ETSI


Figure 7.6.2.7-3: IMS Blind ECT via MSC Server enhanced for ICS (transfer recipient)

1. UE A initiates transfer of UE B to UE C by sending a REFER as specified in TS 24.173 [8].




5. The SCC AS sends the REFER to the S-CSCF within the dialog created for the session between UE A and UE B.

6. The REFER is sent to the MSC Server as the transfer recipient.

7. UE A initiates release of the existing session with the MSC Server which is acting on behalf of UE B.

8. On behalf of UE B, the MSC Server initiates session establishment towards UE C.



11. The S-CSCF sends the INVITE to the TAS.

12. The TAS sends the INVITE to the S-CSCF.

13. The S-CSCF continues with originated session processing as specified in TS 23.228 [2] and routes the request onwards to UE C.

ETSI


14. A session is established between the MSC Server (on behalf of UE B) and UE C.

15. The MSC Server sends a NOTIFY to provide indication that the communication transfer is complete.






21. The MSC Servers sends a message with notification of ECT invocation to UE B (e.g. as specified in TS 24.091 [19]).

7.6.2.8 Conferencing

For IMS sessions established by UEs using CS media, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.084 [20]) to allow Conferencing to be controlled by the IMS.

When the UE initiates three-way session creation via CS access, the MSC Server enhanced for ICS shall support the initiator role as described in TS 23.228 [2] on behalf of the UE. The MSC Server enhanced for ICS shall be able to derive a conference factory URI, e.g. using components from the subscriber"s identity (e.g. IMSI).

Once a conference is created, the MSC Server enhanced for ICS shall supporting adding parties to or removing parties from the conference on behalf of the UE.

The MSC Server enhanced for ICS shall also support joining a conference on behalf of the UE upon receiving an invitation from a remote party or conference focus.

If the conference is being managed by a UE using CS media, the MSC Server enhanced for ICS shall not allow the UE to create a private conversation with a remote party by splitting that party from the conference.

NOTE 1: Interworking is blocked due to no multiparty split service being defined for MMTel.

The MSC Server enhanced for ICS may subscribe to the conference related events in IMS. And when the MSC server receives the conference related events, it should inform the UE of the events.

Figure 7.6.2.8-1 describes how conference creation can be performed via CS access, with the MSC Server enhanced for ICS playing the role of conference initiator on behalf of the UE. This flow does not preclude the use of other mechanisms for inviting remote parties to the conference as specified in TS 24.147 [21].

ETSI


UE A MSC Server MGW SCC ASS-CSCF UE CUE B

1. Multiparty call setup

2. INVITE (Conf Fac URI)


22. Ack

Conf AS / MRFC



6. Conference creation

11. REFER (B to Conf)




15. UE B joins conference

21. UE C referred to conference





7. 200 OK (Conf URI)

Session between UE A and UE B on hold, Session between UE A and UE C active




20. Session Release between UE-B and MSC-Server

Figure 7.6.2.8-1: IMS Conferencing via MSC Server enhanced for ICS (initiator)

1. UE A initiates creation of the conference by sending a multiparty call setup message (e.g. Build MPTY message as specified in TS 24.084 [20]).

2. The MSC Server derives a conference factory URI and sends an INVITE to the S-CSCF.



5. The S-CSCF sends the INVITE to the Conferencing AS / MRFC.

6. The Conferencing AS / MRFC creates a conference connection as specified in TS 24.147 [21].

7. The Conferencing AS / MRFC returns the conference URI to the S-CSCF.

8. The S-CSCF sends the response to the SCC AS.

9. The SCC AS sends the response to the S-CSCF.

10. The S-CSCF sends the response to the MSC Server.

11. The MSC Server sends a REFER to UE B to refer that party to the conference.



14. The S-CSCF sends the REFER to UE B.

ETSI


15. UE B joins the conference as specified in TS 24.147 [21].

16. UE B sends a NOTIFY indicating transfer to the conference is complete.

17. The S-CSCF sends the NOTIFY to the SCC AS.


19. The S-CSCF sends the NOTIFY to the MSC Server.

20. UE B initiates a session release.

21. Steps 11 to 20 are repeated for UE C.


22. The MSC Server sends an acknowledgement to UE A (e.g. Build MPTY Acknowledgement as specified in TS 24.084 [20]).

7.6.2.9 User configuration of communication service settings

7.6.2.9.1 TAS procedures

The TAS shall allow an ICS User to manipulate the communication service settings using only one of the following mechanisms:

- communication service settings via the MSC Server enhanced for ICS as described in clause 7.6.2.9.3;

- communication service settings directly from the UE as described in TS 24.173 [8], with following enhancements:

- it shall be possible for a user subscription to provision only a subset of the MMTel services, e.g. corresponding to the PSTN/ISDN and CS supplementary service set;

- the subset of MMTel services that are available to the user is provided to the UE by the network.

The TAS shall reject the manipulation of the communication service settings via the prohibited mechanism.

7.6.2.9.2 UE supporting multimedia telephony

Clause 7.6.1.3 applies.

7.6.2.9.3 MSC Server enhanced for ICS

The MSC Server enhanced for ICS may implement a communication service setting conversion function between CS signalling (e.g. as described in TS 24.010 [30] for systems based on TS 24.008 [6]) and communication service setting procedures (as defined in TS 24.173 [8]).

7.6.2.10 Customized Alerting Tone (CAT)

For origination sessions established by UEs using the I2 reference point, the MSC Server enhanced for ICS shall perform early media procedures as specified in TS 29.292 [43].

7.6.2.11 Communication Completion on Busy Subscriber/No Reply/Not Logged In

7.6.2.11.1 Communication Completion Terminated at Served User

For IMS sessions established by UEs, where the I2 reference point is used, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.093 [47]) to allow Communication Completion to be controlled by the IMS.

Figure 7.6.2.11.1-1 describes how IMS CCBS is performed via the MSC Server enhanced for ICS. CCNR and CCNL follow the same principles. The following Figure assumes that UE A has an ongoing call.

ETSI


Session between UE A and UE B active 1. INVITE (A)

UE B S -CSCF MGWMSC Server UE A SCC AS TAS UE C

2. INVITE (A ) 3 . INVITE (A )

4 . INVITE (A )5 . INVITE (A )

6. INVITE (A ) 7 . Setup8 . Release Complete 9 . Busy

10. Busy 11. Busy

12 . Busy13. Busy , CC

possible 14. Busy , CC possible

15 . CC Invocation Request 16 . CC Invocation Request

17 . CC Invocation Response 18. CC Invocation Response

Session between UE A and UE B terminates

20. CC Ready 21. CC Ready

22. INVITE (A ) 23. INVITE (A ) 24. INVITE (A )


27 . INVITE (A ) 26 . Setup

19. Session between UE A and UE B terminates

28 . Setup

29 . Call set -up proceeds in accordance with normal procedures .

Figure 7.6.2.11.1-1: IMS Communication Completion to Busy Subscriber via MSC Server enhanced for ICS

There is an ongoing session between UE A and UE B.


2-6. Via Initial Filter Criteria the INVITE is forwarded to the TAS and the SCC AS, before it is forwarded to the MSC Server.

7. The MSC Server enhanced for ISC sends a Setup message to UE A to inform it of the incoming call. Depending on CW settings the MSC Server enhanced for ICS may send a Busy response immediately.

8. UE A responds with a Release Complete message with cause "user busy".

9. The MSC Server enhanced for ISC maps the Release Complete message to a SIP Busy message.

10-12. The SIP Busy message is forwarded via SCC AS and S-CSCF to the TAS.

13. The TAS adds a CC possible indicator to the Busy response.

14. The Busy response is forwarded towards UE C.

15. A CC Invocation Request is received at the S-CSCF of UE A.

16. The CC Invocation Request is forwarded to the TAS.

17. The TAS accepts the CC Invocation Request, sends a CC Invocation Response towards UE C and begins supervising UE A for becoming not busy.

18. The CC Invocation Response is forwarded by the S-CSCF towards UE C.

19. The Session between UE A and UE B terminates.

ETSI


20. After an appropriate time to allow UE A to initiate a call, the TAS sends a CC Ready notification towards UE C.

21. The CC ready notification is forwarded by the S-CSCF towards UE C.

22. An INVITE Request resulting from the CC ready notification is received by the S-CSCF.

23. The INVITE Request is received by the TAS.

24. After appropriate checking that the INVITE request is resulting from the CC ready notification the TAS forwards the INVITE request to the S-CSCF.

25-29. The call set-up proceeds in accordance with normal procedures.

7.6.2.11.2 Communication Completion Originated at Served User

For IMS sessions established by UEs, where the I2 reference point is used, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.093 [47]) to allow Communication Completion to be controlled by the IMS.

Figure 7.6.2.11.2-1 describes how IMS CCBS is performed via the MSC Server enhanced for ICS. CCNR and CCNL follow the same principles. The following Figure assumes that UE B has an ongoing call.

3 . INVITE (A )

UE B S - CSCF MGWMSC Server UE A SCC AS TAS

2 . INVITE (A )1 . Setup

16. Disconnect

13 . Busy

11. TAS invokes the CC service towards UE B and receives a confirmation of successful invocation .

6. INVITE (A )

4 . INVITE (A )

10 . TAS offers User A to invoke CC using an early announcement . User A accepts to invoke CC .

31 . Call set - up proceeds in accordance with normal procedures .

5. INVITE (A ) 7 . INVITE ( A )

12 . Busy

8 . Busy, CC possible 9. Busy , CC possible

14 . Busy 15. Busy

19 . TAS receives a CC Ready notification indicating UE B is free .

23 . REFER (AtoB )

20 . REFER (AtoB )

17. Release18 . Release Complete

24. CM Service Prompt 25 . Start CC

26 . CC establishment 27 . CC establishment

Confirmed 28 . Recall 29 . Setup 30 . INVITE (A )

21 . REFER (AtoB )22 . REFER (AtoB )

Figure 7.6.2.11.2-1: IMS Communication Completion via MSC Server enhanced for ICS


1-9. A normal call set-up results in a Busy condition at user B. The TAS serving user A receives a Communication Completion possible indication.

10. The TAS offers Communication Completion to user A who accepts. The offer is by means of an early announcement.

11. The TAS invokes the CC service towards user B. The TAS is notified that the invocation is successful.

ETSI


12-18. The Busy response without Communication Completion possible indication is sent towards UE-A. The MSC server enhanced for ICS terminates the session towards UE A without giving a the option of activating CCBS request.

19. TAS receives a CC ready notification indicating that UE B is free.

20-23. To start the recall procedure the TAS sends a REFER towards UE A.

24-28. The MSC server enhanced for ICS starts the recall following normal procedures.

29. After notification of the user and confirmation that CC call is desired UE A sends a Setup towards the MSC server enhanced for ICS.

30. The MSC server enhanced for ICS maps the Setup to an INVITE in accordance with normal procedures and forwards the request towards the S-CSCF.

31. Call set-up continues in accordance with normal procedures.

7.6.3 Service consistency for non ICS UE when attached to an MSC Server not enhanced with ICS

7.6.3.1 Line ID Services (OIP, OIR, TIP, TIR)

The service control for the Line ID services may be provided by the CS domain if they are provisioned in the CS domain.

7.6.3.2 Communication Diversion Services

7.6.3.2.1 Communication Diversion services; CFU, CFNL

Standard IMS procedures apply toward IMS on behalf of the non-ICS UE.

7.6.3.2.2 Communication Diversion services; CFNR, CFB

IMS control of the CFNR and CFB services are provided toward IMS on behalf of the non-ICS UE.

NOTE: Annex D describes several implementation options which may be used for the execution of these services.

7.6.3.2.2a Communication Diversion services; CFNRc

IMS control of the CFNRc service is provided on behalf of non-ICS UE. The MGCF may use the ICS indication as means to map cause codes received over the CS leg to appropriate IMS error code so that CFNRc can be triggered in the IMS domain.

7.6.3.2.3 Communication Diversion services; Communication Deflection

The service control for the Call Deflection service may be provided by the CS domain (if it is provisioned in the CS domain) or may be provided by IMS.

NOTE: Annex C describes an implementation option which may be used for the execution of this service in IMS.

7.6.3.3 Communication Barring


7.6.3.4 Communication Hold/Resume

The service control for the Call Hold and Retrieve services may be provided by the CS domain if they are provisioned in the CS domain.

ETSI


7.6.3.5 Explicit Communication Transfer

The service control for the Explicit Call Transfer service may be provided by the CS domain if it is provisioned in the CS domain.

7.6.3.6 Conferencing

The service control for the Multiparty service may be provided by the CS domain if it is provisioned in the CS domain.

If the access transfer from PS to CS has been performed, the MSC Server not enhanced for ICS may subscribe to the conference related events in IMS. And if the UE has a subscription for the conference event package, the MSC server should send the conference related events to UE.

7.6.3.7 User configuration of Supplementary Services

7.6.3.7.1 UE not supporting multimedia telephony

When using procedures as defined in TS 24.010 [30], and the MSC Server enhanced for ICS does not implement a communication service setting conversion function or the UE is using MSC Server not enhanced for ICS, the following apply:

- No activation or deactivation of supplementary services shall be allowed by the CS network.

- Interrogations of CFU and CNFL (clause 7.6.3.2.1), CFNR, CFNRc and CFB (clause 7.6.3.2.2) and Communication Barring (clause 7.6.3.3) shall not be allowed by the CS network.

NOTE 1: The service interrogation, activation, and deactivation are prevented for services which are not provisioned for the subscriber in CS domain.

NOTE 2: If an ICS User uses a non ICS UE not supporting multimedia telephony, a downloadable application can be used to manage IMS multimedia telephony communication service settings data as specified in TS 24.173 [8].

7.6.3.7.2 UE supporting multimedia telephony

Refer to clause 7.6.1.3.

7.6.3.8 Customized Alerting Tone (CAT)


7.6.3.9 Communication Waiting

A network provider may allow UE based CW by activating CW in the CS service profile as specified in TS 23.083 [46].

7.6.3.10 Communication Completion on Busy Subscriber/No Reply/Not Logged In

7.6.3.10.1 Communication Completion Terminated at Served User

For IMS sessions established by UEs in the IMS network, where on the terminating side the MSC Server is not enhanced for ICS and the UE is in the CS domain the CC services can be provided by the IMS network.

Figure 7.6.3.10.1-1 describes a call flow via an MSC Server not enhanced for ICS. CCNR and CCNL follow the same principles.

ETSI


Session between UE A and UE B active 1 . INVITE (A)

UE B S -CSCF MSC Server UE A SCC AS TAS UE C

2 . INVITE (A ) 3. INVITE (A )

4. INVITE ( A )5. INVITE ( A )

6. INVITE (A ) 8 . Setup9. Release Complete 11 . Busy

12. Busy 13. Busy

14. Busy 15 . Busy , CC

possible 16. Busy , CC possible

17 . CC Invocation Request18 . CC Invocation Request

19 . CC Invocation Response 20. CC Invocation Response

Session between UE A and UE B terminates 21 . CC Ready 22 . CC Ready

23 . INVITE (A)24 . INVITE (A )25 . INVITE (A )


28. INVITE (A )26. Setup

21. Session between UE A and UE B terminates

30. Setup

31 . Call set -up proceeds in accordance with normal procedures .

MG CF

7 . IAM 10 . REL

29 . IAM

Figure 7.6.3.10.1-1: IMS Communication Completion to Busy Subscriber via MSC Server not enhanced for ICS



2-6. Via Initial Filter Criteria the INVITE is forwarded to the TAS and the SCC AS, before it is forwarded to the MGCF.

7. The MGCF sends an IAM message to the MSC Server to inform it of the incoming call.

8. The MSC Server sends a Setup message to UE A to inform about the incoming call. Depending on CW settings the MSC Server may send a REL response immediately.

9. UE A responds with a Release Complete message with cause #17 "user busy".

10. The MSC Server maps the Release Complete message to a REL message.

11. The MGCF maps the REL message to a SIP Busy message.

12-14. The SIP Busy message is forwarded via SCC AS and S-CSCF to the TAS.

15. The TAS adds a CC possible indicator to the Busy response.

16. The Busy response is forwarded towards UE C.

17. A CC Invocation Request is received at the S-CSCF of UE A.

18. The CC Invocation Request is forwarded to the TAS.

19. The TAS accepts the CC Invocation Request, sends a CC Invocation Response towards UE C and begins supervising UE A for becoming not busy.

ETSI


20. The CC Invocation Response is forwarded by the S-CSCF towards UE C.

21. The Session between UE A and UE B terminates.

22. After an appropriate time to allow UE A to initiate a call, the TAS sends a CC Ready notification towards UE C.

23. The CC ready notification is forwarded by the S-CSCF towards UE C.

24. An INVITE Request resulting from the CC ready notification is received by the S-CSCF.

25. The INVITE Request is received by the TAS.

26. After appropriate checking that the INVITE request is resulting from the CC ready notification the TAS forwards the INVITE request to the S-CSCF.

27-31. The call set-up proceeds in accordance with normal procedures.

7.6.3.10.2 Communication Completion Originated at Served User

For IMS sessions established by UEs in the CS domain and the MSC Server is not enhanced for ICS the Communication Completion can be controlled by the IMS provided that the originating TAS performs a specific 3pcc procedure to initiate the CC call.

Figure 7.6.2.11.2-1 describes a call flow via an MSC Server not enhanced for ICS. CCNR and CCNL follow the same principles.

4 . INVITE (A )

UE B S -CSCF MGCF MSC Server UE A SCC AS TAS

3 . INVITE (A )1. Setup

18 . Disconnect

14. Busy

12 . TAS invokes the CC service towards UE B and receives a confirmation of successful invocation .

7 . INVITE (A )

5 . INVITE (A )

11. TAS offers User A to invoke CC using an early announcement . User A accepts to invoke CC .

34 . TAS sends SDP answer from MRFP in an ACK and begins to play an announcement towards UE A to inform that the CC call is proceeding .

6 . INVITE ( A )8. INVITE (A )

13. Busy

9. Busy, CC possible10. Busy , CC possible

15. Busy 16 . Busy

21. TAS receives a CC Ready notification indicating UE B is free . TAS reserves MRFP resources for an announcement .

25. INVITE A , no SDP

22. INVITE A , no SDP

19 . Release 20. Release Complete

28 . Connect

23 . INVITE A 24 . INVITE A

2 . IAM

26 . IAM 27. Setup 29 . ANM

30 . OK , SDP offer31 . OK 32 . OK

33. OK

35. INVITE B , no SDP 36 . INVITE A 37 . SDP offer 38. OK

39. To connect the two legs , TAS semds the SDP offer towards UE A ,.

17 . REL

Figure 7.6.2.11.2-1: IMS Communication Completion via MSC Server enhanced for ICS


1-10. UE A initiates a call towards UE B, which responds with Busy and a CC possible indication.

11. The TAS offers Communication Completion via announcement and in-band activation to user A who accepts.

ETSI


12. The TAS invokes the CC service towards user B. The TAS is notified that the invocation is successful.

13-20. The Busy response without Communication Completion possible indication is sent towards UE-A. The call terminates following normal procedures.

21. TAS receives a CC ready notification indicating that UE B is free. The TAS can reserve announcement resources now or after step 33.

22-27. To start the recall procedure the TAS sends an INVITE without SDP towards UE A.

28-33. UE A answers the call, information is sent to the TAS. The MGCF includes an SDP offer in the OK message.

35. After completion of announcement, the INVITE without SDP is sent towards B. After receipt of Ringing response, a ring tone is played towards UE A.

37. UE B answers the call and includes an SDP offer.

39. The TAS uses this SDP offer to update the SDP towards UE A. UE A and UE B are now connected, and the announcement resources can be released.

7.7 Session Release

7.7.1 Session Release for ICS UE

7.7.1.1 General Gm Procedures

If receiving a session release from the CS access leg for the ICS UE using Gm while the PS access leg is still active, the SCC AS shall release the CS access leg. The SCC AS shall further update the remote leg, and if applicable, the PS access leg, to reflect the change of media.

NOTE: Race conditions may occur where the session release of the CS access leg could arrive prior an update over Gm from the UE removing the CS media.

7.7.1.2 Session Release for Gm and I1

Figure 7.7.1.2-1 provides a call flow illustrating the session release procedures for an ICS UE attached to an MSC Server enhanced for ICS, which has an ICS session already established. This call flow applies when either Gm or I1 have been used to set up the Service Control Signalling Path.

ETSI


Figure 7.7.1.2-1: Session Release for Gm and I1 when using an MSC server enhanced for ICS

1. IMS procedures are executed for the release of the service control signalling session when using the Gm reference point as defined in clause 5.10 of TS 23.228 [2]. When using I1, the procedure for the release of the service control signalling session is documented in clause 7.7.1.3.

2. The SCC AS initiates release of the CS Bearer Control Signalling Path.

3. The MSC Server releases the CS Session with the ICS UE.

4. After confirmation of the session release from the ICS UE, the MSC Server completes the release of the CS Bearer Control Signalling Path with the SCC AS. Step 4 does not have to wait for step 3 to complete.

Alternatively the ICS UE may initiate release of the CS Bearer Control Signalling Path. The SCC AS and the ICS UE shall gracefully handle the case when both the SCC AS and ICS UE initiate the release procedure.

The call flow in Figure 7.7.1.2-1 also applies when the ICS UE is attached to an MSC server.

7.7.1.3 Release of the Service Control Signalling Session when using I1

7.7.1.3.1 ICS UE Initiated Release

Figure 7.7.1.3.1-1 provides a call flow illustrating the release of the service control signalling session by an ICS UE regardless of whether the ICS UE is attached to MSC server enhanced for ICS or not, when using I1.

ETSI


Figure 7.7.1.3.1-1: ICS UE initiated release of the service control signalling session over I1

1. The ICS UE sends a release over I1.

2 The SCC AS sends a SIP BYE to the I/S-CSCF serving the ICS UE.

3. The S-CSCF forward the SIP BYE to UE A.

4-5. UE A sends a SIP OK to the SCC AS via the S-CSCF of the UE B.

6. The SCC AS completes the session release procedure by sending a release-ack over I1.

NOTE: If this is the release of the last service control signalling session, then the CS Bearer Control Signalling Path is released as described in Clause 7.7.1.2

7.7.1.3.2 Network Initiated Release

Figure 7.7.1.3.2-1 provides a call flow illustrating the release of a service control signalling session by the home IMS network regardless of whether the ICS UE is attached to MSC server enhanced for ICS or not, when using I1.

ETSI


Figure 7.7.1.3.2-1: Network initiated release of a service control signalling session initiated using I1

1. The S-CSCF decides the session should be terminated due to administrative reasons or due to service expiration.

Steps 2-5 occur in parallel to Steps 6-7.

2. The S-CSCF sends a SIP BYE message to the SCC AS.

3. The SCC AS sends a release message over I1 to the ICS UE.

4. The ICS UE sends a release-ack to the SCC AS over I1.

5. The SCC AS sends a SIP OK to the I/S-CSCF.

6. The S-CSCF sends a SIP BYE message to UE A.

7. UE-A acknowledges receipt of the SIP BYE and sends a SIP OK back to the S-CSCF.


7.7.1.3.3 Far End Initiated Release

Figure 7.7.1.3.3-1 provides a call flow illustrating the release of a service control signalling session by the far end regardless of whether the ICS UE is attached to MSC server enhanced for ICS or not, when using I1.

ETSI


Figure 7.7.1.3.3-1: Far End release of a service control signalling session initiated using I1

1. UE A terminates the session by sending a SIP BYE (via its own S-CSCF) towards the I/S-CSCF of ICS UE B.

2. The S-CSCF sends a SIP BYE message to the SCC AS.

3. The SCC AS sends a release message over I1 to the ICS UE.

4. The ICS UE sends a release-ack to the SCC AS over I1.

5. The SCC AS sends a SIP OK to the I/S-CSCF.

6. The S-CSCF sends a SIP OK message to UE A.


7.7.2 Session Release for MSC Server enhanced for ICS

7.7.2.1 General

If receiving a CS session release from the non ICS UE the MSC Server enhanced for ICS shall release the session towards IMS. The SCC AS shall further update the remote leg, to reflect the change of media. If receiving a session release from the IMS, the MSC Server enhanced for ICS shall release the CS session with the UE.

7.7.2.2 Session Release by served UE

Figure 7.7.2.2-1 provides a call flow illustrating the session release procedures initiated by an UE attached to an MSC Server enhanced for ICS.

ETSI


Figure 7.7.2.2-1: Session Release initiated by UE A when using an MSC server enhanced for ICS

1. The UE releases CS Session.

2. The MSC Server releases the IMS Session. Step 2 does not have to wait for step 1 to complete.

3. The SCC AS updates or releases the remote leg depending on whether other media components remain in the remote leg after removal of speech media.

7.7.2.3 Session Release by far-end

Figure 7.7.2.3-1 provides a call flow illustrating the session release procedures initiated by far end for an UE attached to an MSC Server enhanced for ICS.

Figure 7.7.2.3-1: Session Release initiated by far end when using an MSC server enhanced for ICS

1. The UE B initiates session release.

2. The MSC Server releases CS session with UE A.

3. Completion of session release initiated by far end. Step 3 does not have to wait for step 2 to complete.

7.7.2.4 Network initiated Session Release

Figure 7.7.2.4-1 provides a call flow illustrating the session release procedures initiated by the home IMS network for an UE attached to an MSC Server enhanced for ICS.

ETSI


Figure 7.7.2.4-1: Network initiated Session Release when using an MSC server enhanced for ICS

1. The S-CSCF decides the session should be terminated due to administrative reasons or due to service expiration.

2. The S-CSCF initiates a session release towards UE B and MSC server.

3. The MSC Server releases CS session with UE A.

4. Completion of session release is provided from UE B and MSC Server to S-CSCF. Step 4 does not have to wait for step 3 to complete.

7.8 Loss of Gm capability The Figure 7.8-1 provides an example flow for transfer of Service Control Signalling Path from Gm to I1 when the UE discovers Gm is not available and UE supports I1.

Figure 7.8-1: Service Control Signalling Path handover from Gm to I1

ETSI


1. Upon detecting that there is a loss of Gm reference point, the ICS UE prepares to trigger the service control signalling path transfer.

2. ICS UE sends the service control signalling path transfer notification to the SCC AS over I1 requesting a switch to I1 for Service Control Signalling Path.

3. SCC AS accepts the transfer request, and returns the acknowledgement to ICS UE over I1.

After the above steps, the Service Control Signalling Path is switched from the Gm reference point to the I1 reference point.

7.9 Addition/Removal of video media flow

7.9.1 Addition/Removal of video media flow for Non ICS UE

7.9.1.1 Overview

The procedures in this clause and the following clauses are applicable only to 3GPP systems.

For IMS sessions that use CS media established by the non ICS UE, the MSC Server enhanced for ICS shall perform the necessary interworking between the I2 reference point and CS SCUDIF signalling described in TS 23.172 [37] and TS 24.008 [6] to add/remove the video media flow through SCUDIF if supported by the CS access network.

In the case that the non ICS UE is attached to the MSC Server not enhanced for ICS, the MGCF shall perform the service change procedures to add/remove the video media flow as specified in TS 29.163 [11].

The non ICS UE can also use the redial mechanism as defined in TR 23.903 [39] for switching between voice and video services.

7.9.1.2 Addition/Removal of video media flow through SCUDIF using I2 reference point

Figure 7.9.1.2-1 describes how a video media flow is added to an ongoing speech session for the non ICS UE via the MSC Server enhanced for ICS. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

non ICS UE A MSC Server MGW SCC ASS-CSCF UE B

1.Modify(MuMe)

2.Modify Bearer Characteristics

3.Re-INVITE(m=audio; m=video)




7. Completion of the session and bearer setup procedures

Video call between non ICS UE A and UE B established

Speech call between non ICS UE A and UE B active

Figure 7.9.1.2-1: Addition of video media flow for non ICS UE via the MSC Server enhanced for ICS

ETSI


1. The non ICS UE A sends a MODIFY message requesting service change from speech to multimedia (i.e. video and voice) as specified in TS 23.172 [37].

2. The MSC Server initiates interaction with the MGW instructing it to modify bearer characteristics.

3. The MSC Server sends a re-INVITE message that offers the adding of the video media to the ongoing speech session to the S-CSCF.

4. The S-CSCF sends the re-INVITE to the SCC AS which has been inserted at session establishment.

5. The SCC AS sends the re-INVITE to the S-CSCF.

6. The S-CSCF forwards the re-INVITE to UE B.

7. Completion of the session and bearer setup procedures, where upon the establishment of the multimedia connection, the MSC Server shall perform the video codec negotiation and set up the multimedia bearer based on the procedures defined in TS 29.163 [11].

7.9.1.3 Addition/Removal of video media flow through SCUDIF via the MSC Server not enhanced for ICS

Figure 7.9.1.3-1 describes how a video media flow is added to an ongoing speech session for the non ICS UE via the MSC Server which is not enhanced for ICS. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

SCC ASMGWMGCFMSC Servernon ICS UE A UE B

Speech call between non ICS UE A and UE B active


Video call between non ICS UE A and UE B established

I/S-CSCF

3.Modify Bearer Characteristics

2.Modify Codec(Selected Codec = MuMe)





1.Modify(MuMe)

Figure 7.9.1.3-1: Addition of video media flow for non ICS UE via the MSC Server not enhanced for ICS

1. The non ICS UE A sends a MODIFY message requesting service change from speech to multimedia (i.e. video and voice) as specified in TS 23.172 [37].

2. The MSC Server sends the Modify Codec message to the MGCF indicating the change from speech to multimedia (i.e. video and voice).

3. The MGCF initiates interaction with the IMS-MGW instructing it to modify bearer characteristics.

4. The MGCF sends the re-INVITE that offers the adding of the video media to the ongoing speech session to the S-CSCF.

5-7. Steps 5-7 in Figure 7.9.1.3-1 are identical to Steps 4-6 in Figure 7.9.1.2-1.

ETSI


8. Completion of the session and bearer setup procedures, where upon the establishment of the multimedia connection, the MGCF/IMS-MGW shall perform the procedures as specified in TS 29.163 [11] to set up the multimedia bearer.

7.9.2 Addition/Removal of video media flow for ICS UE

7.9.2.1 Overview

The procedures in this clause and the following clauses are applicable only to 3GPP systems.

For the IMS sessions that use CS media established by the ICS UE, adding/removing of video media flow can be made by updating the CS access leg through SCUDIF procedures as specified in TS 23.172 [37], or by using redial mechanism over the CS access leg as defined in TR 23.903 [39] if SCUDIF is not supported.

7.9.2.2 Addition/Removal of video media flow through SCUDIF using Gm Reference Point

Figure 7.9.2.2-1 describes how a video media flow is added to an ongoing speech session through SCUDIF for the ICS UE over the Gm reference point. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

ICS UE A MSC Server MGW SCC ASS-CSCF UE B

Speech call between ICS UE A and UE B active

Video call between ICS UE A and UE B established

5. Completion of service change procedures


3.200 OK

4.200 OK


Figure 7.9.2.2-1: Addition of video media flow for ICS UE through SCUDIF using Gm reference point

1. The ICS UE A sends a re-INVITE message that offers the adding of the video media to the ongoing speech session to the S-CSCF.

2. The S-CSCF sends the re-INVITE message to the SCC AS.

3. The SCC AS sends a 200 OK message to the S-CSCF.

4. The S-CSCF forwards the 200 OK to the ICS UE A.

5. Completion of service change from speech to video call as specified in clause 7.9.1.2 if the ICS UE is attached to the MSC Server enhanced for ICS, or as specified in clause 7.9.1.3 if the ICS UE is attached to the MSC Server not enhanced for ICS.

7.9.2.3 Addition/Removal of video media flow through SCUDIF using I1 Reference Point

Figure 7.9.2.3-1 describes how a video media flow is added to an ongoing speech session through SCUDIF for the ICS UE over the I1 reference point. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

ETSI


ICS UE A MSC Server MGCF SCC ASS-CSCF UE B


1. I1: ICS Call Modify(MuMe)

2. I1: ICS Call Modify Response


3. Completion of service change procedures

MGW

Figure 7.9.2.3-1: Addition of video media flow for ICS UE through SCUDIF using I1 reference point

1. The ICS UE A sends a Call MODIFY message to the SCC AS requesting service change from speech to multimedia (i.e. video and voice).

2. The SCC AS sends a Call MODIFY Response message to the ICS UE A.

3. Completion of service change from speech to video call as specified in clause 7.9.1.2 if the ICS UE is attached to the MSC Server enhanced for ICS, or as specified in clause 7.9.1.3 if the ICS UE is attached to the MSC Server not enhanced for ICS.

7.9.2.4 Addition/Removal of video media flow through redial using Gm Reference Point

Figure 7.9.2.4-1 describes how a video media flow is added to an ongoing speech session through redial for the ICS UE which is attached to the MSC Server enhanced for ICS over the Gm reference point. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

ETSI




7.BYE

5.CS call disconnect

6.BYE

10.INVITE(m=audio; m=video)




8. Completion of the CS access leg release procedures



3.200 OK

4.200 OK



9.CS call setup(MuMe)

Figure 7.9.2.4-1: Addition of video media flow for ICS UE via the MSC Server enhanced for ICS through redial using Gm reference point

1. The ICS UE A sends a re-INVITE message that offers the adding of the video media to the ongoing speech session to the S-CSCF.

2. The S-CSCF sends the re-INVITE message to the SCC AS which has been inserted at session establishment.

3-4. The SCC AS sends 200 OK to the ICS UE A via the S-CSCF.

5. The ICS UE A sends a CS call disconnect message to the MSC server to release the existing CS access leg.

6. The MSC server sends the BYE message to the S-CSCF.

7. The S-CSCF forwards the BYE message to the SCC AS.

8. Completion of the CS access leg release procedure.

9. The ICS UE A sends a CS call setup message to the MSC server to establish a new CS access leg supporting video and speech media.

10. The MSC server sends an INVITE message to the S-CSCF.

11. The S-CSCF sends the INVITE to the SCC AS.

12. The SCC AS sends a re-INVITE message to the S-CSCF that offers the adding of the video media to the ongoing speech session to update the remote leg.

13. The S-CSCF sends the re-INVITE to UE B.


ETSI


Figure 7.9.2.4-2 describes how a video media flow is added to an ongoing speech session through redial for the ICS UE which is attached to the MSC Server not enhanced for ICS over the Gm reference point. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

I / S- CSCF SCC ASMGWMGCFMSC ServerICS UE A UE B


8.BYE


7.BYE



6.REL

11.IAM(MuMe)

9. Completion of the CS access leg release procedure




3.200 OK

4.200 OK





Figure 7.9.2.4-2: Addition of video media flow for ICS UE via the MSC Server not enhanced for ICS through redial using Gm reference point


6. The MSC server sends a REL message to the MGCF.

7. The MGCF sends a BYE message to the S-CSCF.


11. The MSC server sends an IAM message to the MGCF.

12. The MGCF sends an INVITE message to the S-CSCF.



7.9.2.5 Addition/Removal of video media flow through redial using I1 Reference Point

Figure 7.9.2.5-1 describes how a video media flow is added to an ongoing speech session through redial for the ICS UE which is attached to the MSC Server enhanced for ICS over the I1 reference point. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

ETSI




5.BYE

1. I1:ICS Call Modify(MuMe)

2. I1:ICS Call Modify Response

3. CS call disconnect

4.BYE

7. CS call setup(MuMe)








Figure 7.9.2.5-1: Addition of video media flow for ICS UE via the MSC Server enhanced for ICS through redial using I1 reference point

1. The ICS UE A sends a Call MODIFY message that offers the adding of the video media to the ongoing speech session to the SCC AS.


3. The ICS UE A sends a CS call disconnect message to the MSC server to release the existing CS access leg.

4. The MSC server sends the BYE message to the S-CSCF.

5. The S-CSCF forwards the BYE message to the SCC AS.

6. Completion of the CS access leg release procedure.

7. The ICS UE A sends a CS call setup message to the MSC server to establish a new CS access leg supporting video and speech media.

8. The MSC server sends the INVITE to the S-CSCF.

9. The S-CSCF sends the INVITE to the SCC AS.

10. The SCC AS sends a re-INVITE to the S-CSCF that offers the adding of the video media to the ongoing speech session to update the remote leg.

11. The S-CSCF sends the re-INVITE to UE B.


Figure 7.9.2.5-2 describes how a video media flow is added to an ongoing speech session through redial for the ICS UE which is attached to the MSC Server not enhanced for ICS over the I1 reference point. Change from multimedia (i.e. speech and video) to speech can be achieved in a similar way.

ETSI


I / S-CSCF SCC ASMGWMGCFMSC ServerICS UE A UE B


6.BYE


5.BYE




4.REL

9.IAM(MuMe)




1. I1:ICS Call Modify(MuMe)

2. I1:ICS Call Modify Response



Figure 7.9.2.5-2: Addition of video media flow for ICS UE via the MSC Server not enhanced for ICS through redial using I1 reference point

1. The ICS UE A sends a Call MODIFY message that offers the adding of the video media to the ongoing speech session to the SCC AS.


3. The ICS UE A sends a CS call disconnect message to the MSC Server to release the existing CS access leg.

4. The MSC Server sends a REL message to the MGCF.

5. The MGCF sends a BYE message to the S-CSCF.


9. The MSC Server sends an IAM message to the MGCF.

10. The MGCF sends the INVITE to the S-CSCF.



ETSI


8 Charging

8.1 General description The charging strategy applied in ICS shall ensure complete and correct charging of the access leg that is used for an ICS call. An ICS subscriber may establish or accept a call through CS access or through an IP access network (IP-CAN). The charge that is levied against an ICS subscriber for a call shall encompass the usage of the access network (CS access or IP-CAN) as well as the usage of the IMS network, further depending on the destination of the call and other call related aspects. The access related charge for an ICS call, i.e. the CS access network related charge or IP-CAN related charge, shall be included in the charging record generated by SCC AS.

The charge of a SIP call or session may be adapted when this call or session is subject to a value added service (e.g. number translation, call diversion) or is subject to a supplementary service (e.g. call forwarding, call transfer, conference call).

Standard inter-operator reconciliation mechanisms for CS and IMS can and should be used. Additional reconciliation for I1 flows can also be applied, due to such flows being uniquely identifiable from other flows over the same bearer (see clause 5.4.1 for more information).

8.2 Offline charging Charging record generated by the SCC AS may be correlated with charging records generated in the MSC Server or with charging records in the IP-CAN, where applicable. The combination of charging records from SCC AS with charging records from MSC Server or IP-CAN is used for determining access charge for the call or multimedia session. The combination of these charging records may further be correlated with other IMS-based charging records generated by S-CSCF or other functional entities in the IMS network, for the purpose of generating an overall charge for a call or multimedia session, including access related charge.

Where PS to CS transfer has occurred, at least in roaming situations, the visited network shall correlate the charging records from MSC Server and any visited network IMS functions. The information used for correlation is described in TS 23.237 [12].

8.3 On-line charging When on-line charging is applied for an ICS subscriber, this on-line charging should be performed strictly in IMS. CS network based on-line charging service (e.g., CAMEL prepaid), for example, shall not be invoked for ICS subscribers.

NOTE: If for an ICS subscriber a call that is established in CS is not anchored in IMS network, i.e. no ICS is applied for that call, then on-line charging in CS access can be applied for that call.

9 Security Considerations

9.1 Access security ICS re-uses the CS domain security described in the detailed access specific specification.

Access using MSC Server enhanced for ICS is secured by the combination of the CS access security and the IMS Network Domain Security. The MSC Server enhanced for ICS also performs the trusted node authentication procedures according to TS 33.203 [32].

9.2 Network Domain Security Network domain security with the MSC server enhanced for ICS shall be provided by NDS/IP according to TS 33.210 [33] for the I2 reference point.

ETSI


NOTE: If the control plane interfaces are trusted (e.g. physically protected), there is no need to use protection according to TS 33.210 [33].

ETSI


Annex A (informative): Service Consistency IMS Centralized Services (ICS) provides communication services such that all services, and service control, are based on IMS mechanisms and enablers. It enables IMS services when using CS access for the media bearer.

With ICS, the user services are provided by IMS. User sessions are controlled in IMS via PS or CS access. When using CS access network, or when using PS access networks which do not support full duplex speech component of an IMS service, the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions.

Functionality is needed to provide IMS Centralized Services to devices using a circuit switched access network for media transport. Two fundamentally different approaches are enabled in this specification. One approach supports legacy UEs by placing new functional elements in the MSC Server. Another approach provides new functionality in the UE. The following figure depicts the provision of IMS Centralized Services for these approaches from the user"s perspective. This figure is intended to be illustrative in nature, and is not intended to depict a complete or definitive identification of the various IMS Centralized Services that may be provided using different access networks or solutions.

CS Voice

CS Equiv

MMTEL SS

ICS enhanced

CS MSC

Legacy UE ICS UE ICS UEICS UE

Legacy (or ICS enhanced)

CS MSC

ICS UE

IMS

Centralized Services

IMS

Centralized

Services

Provided to

User

Access

Network

Core

Network

Common Device Client provides Consistent User View

Service Capabilities Grow with Access Capabilities

WLAN

LTE/HRPD/

Wired

Access

UMTS/

HSPA

GSM +

GPRS,

EDGE

CDMA-1X

GSM +

GPRS,

EDGE

CDMA-1X

CS Voice

Partial

MMTEL SS

Data

IP Services

CS Voice

FULL

MMTEL SS

Hi Speed

Data

Rich IP

Services

IMS Video

QoS VoIP

FULL

MMTEL SS

Hi Speed

Data

Rich IP

Services

IMS Video

Real Time

Services

( Gaming )

VoIP

FULL

MMTEL SS

Hi Speed

Data

Rich IP

Services

IMS Video

Figure A-1: IMS Centralized Services

ETSI


Annex B (informative): ICS functions in different deployment scenarios The following tables provides guidance on which of the functions and functionalities are needed in the different deployment scenarios.

Scenario 1: An operator who only supports UEs that have ICS functionality for their ICS Users:

MSC Server with ICS enhancements

ICS UE Transparent control channel

SCC AS

I1 Gm CAA IUA T-ADS

Required No Yes As driven by operator policy and VPLMN support.

As driven by operator policy and VPLMN support.

Yes, only if I1 is supported

Yes Yes

ICS Users using a non-ICS UE (e.g. after SIM swap) will not make use of the transparent control channel; non ICS UE originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008 [6]) for call origination.

Scenario 2: An operator who only supports non ICS UEs for their ICS Users:



SCC AS

I1 Gm CAA IUA T-ADS

Required Yes No No No No Conditional* Yes

* Required if the operator supports IN (e.g. CAMEL) redirection of CS originated calls.

Scenario 3: An operator who supports UE"s for their ICS Users that do, and do not, have ICS functionality (to different subscribers and the same subscribers) ensuring the coexistence of UEs that have and do not have ICS functionality:



SCC AS

I1 Gm CAA IUA T-ADS

Required Yes Yes As driven by operator policy and VPLMN support.

As driven by operator policy and VPLMN support.

Yes, if I1 is supported

Yes Yes

ETSI


Scenario 4: Inbound roaming - operator supports ICS

Inbound roaming subscribers on an operator's network that supports either the same or different ICS functionality that the inbound roaming subscriber is using, ensuring the coexistence of UEs that have and do not have ICS functionality.

Sub case 4.1: Subscriber from operator supporting scenario 1 roams into network of scenario 1

Same functions and functionalities in roaming in-network as in scenario 1. No additional functions or functionalities.


Same functions and functionalities in roaming in-network as in scenario 2. No additional functions or functionalities.


Same functions and functionalities in roaming in-network as in scenario 2. No additional functions or functionalities. Roaming agreement, operator policy and access network restrictions decide on the use of the transparent control channel between ICS UE and SCC AS in the home network.



Same functions and functionalities in roaming in-network as in scenario 1: No additional functions or functionalities. Roaming agreement and operator policy decide on the fallback solution, i.e., whether or not originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008 [6]) for call origination.

Scenario 5: Inbound roaming - operator does not support ICS

Inbound roaming subscribers on an operator's network that does not support ICS.

Sub case 5.1: Subscriber from operator supporting scenario 1 roams into an operator's network that does not support ICS.

Roaming agreement, operator policy and access network restrictions decide on the use of the transparent control channel between ICS UE and SCC AS in the home network.


Sub case 5.2 Subscriber from operator supporting scenario 2 roams into an operator's network that does not support ICS.

Roaming agreement and operator policy decide on the fallback solution, i.e., whether or not originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008 [6]) for call origination.

ETSI


Annex C (informative): Communication Deflection support when call has been delivered using CS call control When a call has been delivered to a non ICS UE using CS call control, Communication Deflection service can be centralized and executed in IMS by using IN (e.g. O-CSI CAMEL) if it is supported by the network and user subscription.

ETSI


Annex D (informative): Conditional Call Forwarding support when call has been delivered using CS call control When a call has been delivered to an UE using CS call control, conditional call forwarding services can be centralized and executed in IMS by one of (or a combination of) the following implementation options.

Solution 1: Default PSIs

In this solution, Conditional CF is configured in IMS with default service configuration in the CS domain. The Conditional CF services are configured in the HLR. The different forwarded number can be set in HLR to indicate the type of CF. The VMSC redirects the call to IMS for appropriate handling of the service in IMS.

Solution 2: MAP suppression-of-announcements

In this solution, Conditional CF is configured and provisioned in IMS domain exclusively, according to IMS Centralized Service principle. It provides means to suppress the announcement in CS domain at the MSC for the conditional call forwarding services. MGCF provides the appropriate responses to TAS on behalf of the ICS user in CS domain. The MGCF can use the ICS indication if available to map cause codes received over the CS leg to appropriate IMS error codes.

For support of CFNRy, the TAS starts a supervisory no-reply timer on receipt of Alerting from the called party. If the timer expires without receipt of the Connect from the called party, the TAS invokes the CFNRy service.

Solution 3: IN

In this solution, Conditional CF is configured in IMS with default service configuration in the CS domain so that the VMSC invokes the CF service in the CS domain upon detection of CF triggers. IN (e.g. O-CSI CAMEL service) is configured in the HLR to redirect service control to IMS for processing of CF.

ETSI


Annex E (informative): Using MRF for media process After the session between ICS UE and other party ( Party B) is hold, if the SCC AS receives the new session request, it can use MRF for media process. The following three options give details on how to implement it.

Solution 1: using MRFP by SCC AS for held party

In this solution, if the SCC AS receives the new session request after the session between ICS UE and other party (Party B) is hold, it changes the MGW media path from Party B to the third party (Party C), and connects Party B to MRF for playing announcement.

Solution 2: using MRFP by SCC AS for active and Held party

In this solution, if the SCC AS receives the new session request after the session between ICS UE and other party (Party B) is hold, it changes the MGW media path to MRF, and then connects Party B to MRF for playing announcement and connects the third party (Party C) to MRF to communicate with ICS UE.

Solution 3: using MRFP by TAS for Held call

In this solution, TAS is always kept in ICS UE A's remote leg. After the TAS receives the Hold request from the ICS UE via the SCC AS, it performs communication Hold procedure as described in TS 24.147 [21]. The MRF is connected to Party B for playing announcement.

ETSI


Annex F (informative): Call diversion from CS to IMS

F.1 General An incoming call for a subscriber with a service provided by the IMS (e.g. ICS, SC, SR-VCC) can be received either through the CS domain or IMS. For such a subscriber, certain calls that are received through the CS domain need to be routed to the IMS for anchoring at the SCC AS, prior to the onward routing of the call to the subscriber. Solutions for this are discussed in clause F.2.

NOTE: Requirements and preconditions for anchoring of CS calls for a subscriber with a service provided by the IMS are documented in clause 7.4 of the present document.

When an incoming CS call is anchored at the SCC AS using certain implementation options described in clause F.2, then as a result of domain selection, the call can be routed back to the CS domain to determine the CSRN for CS termination. In this case, the call can be treated as a new incoming call from the CS network, and then be re-routed to the IMS for anchoring again, thus creating a circular loop. Solutions for this are discussed in clause F.3.

F.2 Implementation options for call diversion from CS to the IMS

Several techniques available in the current CS networks can be used to implement the call diversion from CS to IMS, as detailed below:

1 Use of CAMEL for call diversion to IMS

This option applies to configurations requiring handling of incoming calls at the GMSC function. Upon receipt of an incoming call, the GMSC queries the HSS for routing information via the Send Routing Information (SRI) query. The user profile in the HSS is configured to return T-CSI including a gsmSCF address to the GMSC in response to the SRI query. When handling calls for a subscriber with a service provided by the IMS, the subsequent processing at the gsmSCF and the GMSC results in routing of the call to the IMS using the IMRN. The call is routed to the SCC AS according to standard IMS routing procedures. In order to determine the necessary information to complete the call, the SCC AS uses the IMRN or the ISUP information mapped to SIP headers.

2 HSS directed call diversion to IMS

This option also applies to configurations requiring handling of incoming calls at the GMSC function. Upon receipt of an incoming call, the GMSC queries the HSS for routing information using the MAP Send Routing Information (SRI) procedure (as defined in TS 29.002 [45]). Based on a non-standardized mechanism, the user profile in the HSS is configured to return an IP Multimedia Routing Number (IMRN) to the GMSC in response to the SRI query, when the call is directed to a subscriber with a service provided by the IMS. The subsequent processing at the GMSC results in routing of the call to IMS using the IMRN. Two methods can then be used to ensure correlation between the IMRN and the original called party.

a. Cooperative allocation/deallocation: In this method, the IMS is made aware of the assigned IMRN and when a call is received for that number, the original number is retrieved. This method is similar to the Provide Roaming Number procedure in MAP (see TS 29.002 [45]).

b. Algorithmic: In this method, a known algorithm is used to derive the IMRN at the CS, and to deduce the original called number from the IMRN at the IMS. One method of performing such an algorithm could be use of a prefix. In such a case, care is required in the network configuration to avoid call looping for the case when the call is subsequently routed from the IMS to the CS domain for call termination (see clause F.3 for possible solutions to prevent call looping).

3 Static diversion from GMSC with dedicated trunk groups

ETSI


This option also applies to configurations requiring handling of incoming calls at the GMSC function. Dedicated trunk groups can be used at the GMSC to divert CS terminations to the MGCF.

NOTE 1: The handling of call types that an operator has not centralised the services into the IMS need to be taken into account if this solution is chosen.

4 Static diversion using Local Number Portability

This option can be used for routing of calls originating in PSTN networks to IMS. A Local Number Portability database dip can be used to reroute incoming calls to a subscriber with a service provided by the IMS with calls to the MGCF.

NOTE 2: The handling of calls other than calls needs to be taken into account if this solution is chosen.

5 Direct routing to IMS

Translations can be set up in the PSTN network to route the incoming call to a subscriber with a service provided by the IMS to the MGCF. This way the normal IMS routing technique specified in TS 23.228 [2] can be used.

NOTE 3: The handling of call types that an operator has not centralised the services into the IMS need to be taken into account if this solution is chosen.

NOTE 4: With some of the aforementioned options, care must be taken to avoid a circular loop which can occur when used in conjunction with certain techniques applied to route the call from IMS to the terminating user via CS network. Techniques for the prevention of circular looping are described in clause F.3.

F.3 Implementation options for prevention of circular looping of CS Terminations

Several implementation techniques can be used to avoid circular looping, as detailed below:

1 Use of SCC AS for retrieving the CSRN

When the SCC AS decides that the call is to be terminated in the CS domain, the SCC AS retrieves the CSRN from the MSC/MSC-Server via the HSS using the following method:

a. MAP SRI Query: This option makes use of a MAP Interface between the SCC AS and the HSS to request allocation of a CSRN from the HSS for routing of the call to the MSC/MSC-Server currently serving the subscriber.

b. Sh UDR Query: This option makes use of the Sh interface between the SCC AS and the HSS. The SCC AS sends a Sh UDR query to the HSS to request allocation of a CSRN for routing of the call to the MSC/MSC-Server currently serving the subscriber.

2 Use of a specific CSRN to indicate the anchored call

When the SCC AS decides that the call is to be terminated in the CS domain, the SCC AS allocates a specific CSRN. The specific CSRN can be an MSISDN with added prefix digits. The SCC AS uses the specific CSRN to route the call to the CS network. The following options are available to resolve the MSISDN of original called party from the CSRN.

a. MGCF resolution: In this option, the SCC AS forwards the call to the MGCF (which has a GMSC function). The specific CSRN is used by the MGCF to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The MGCF resolves the MSISDN from the CSRN and invokes GMSC functionality integrated in the MGCF for handling the CS call terminating procedure. In particular, the MGCF/GMSC includes the "Suppress T-CSI" parameter in the MAP SRI sent to the HSS.

b. GMSC resolution: In this option, the SCC AS forwards the call to the MGCF, which then forwards the call on to GSMC. The specific CSRN is used by the GSMC to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The GMSC resolves the MSISDN from the CSRN and invokes the CS call terminating procedure. In particular, the GMSC includes the "Suppress T CSI" parameter in the MAP SRI sent to the HSS.

ETSI


c HSS resolution: In this option, the SCC AS forwards the call to the GMSC. The GMSC treats the call as a normal terminating call and sends a MAP SRI request to the HSS for the specific CSRN. The specific CSRN is used by the HSS to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The HSS resolves the MSISDN from the CSRN and uses CS call terminating procedures to obtain routing information from the MSC/MSC-Server.

3 Use of a dynamically allocated CSRN to route via the GMSC

This option uses a dynamically allocated CSRN to divert the call to the appropriate GMSC as described below:

- The SCC AS allocates a CSRN that maps to an appropriate GMSC. Standard CS termination procedures are then executed at the GMSC.

- The GMSC is configured with N-CSI and criteria corresponding to the CSRN. This causes the GMSC to issue an InitialDP containing the CSRN to the gsmSCF.

- The gsmSCF performs a function on the CSRN to obtain the MSISDN of the called party number and the MSISDN is returned to the GMSC in a CONNECT operation together with the CSRN as a Re-direction ID.

- The GMSC continues the normal CS call termination procedure by issuing an SRI to the HSS using the MSISDN, which causes T-CSI to be returned back to the GMSC.

- The GMSC issues another InitialDP containing both MSISDN and CSRN to the gsmSCF. The gsmSCF recognises that it has been triggered for the second time (due to the presence of the CSRN) and therefore returns a CONTINUE for the MSISDN, thus avoiding a circular loop.

- The GMSC sends a MAP SRI query to the HSS with the "Suppress T CSI" parameter, thus allowing the HSS to obtain the MSRN through standard call terminating procedures.

ETSI


Annex G: Change history

Change history Date TSG # TSG Doc. CR Rev Cat Subject/Comment Old New

2010-03 SP-47 SP-100161 0142 1 B Support for additional media types in network based ICS 9.5.0 10.0.0 2010-06 SP-48 SP-100350 0155 3 B Incorporate CAT supplementary service 10.0.0 10.1.0 2010-09 SP-49 SP-100592 0162 - A Clarification of Gm use 10.1.0 10.2.0 2010-09 SP-49 SP-100558 0156 4 F Mid-call service continuity for ICS UE handover 10.1.0 10.2.0 2010-09 SP-49 SP-100558 0157 1 F Collocation of I1 requirements 10.1.0 10.2.0 2010-09 SP-49 SP-100558 0161 1 B Addition of annex on diverting incoming CS calls to IMS for

anchoring at SCC AS 10.1.0 10.2.0

2011-03 SP-51 SP-110076 0166 - F Correcting the Mobile Station behaviour for Communication Diversion

10.2.0 10.3.0

2011-03 SP-51 SP-110076 0169 1 F Clarification of the behaviour of the MSC Server enhanced for ICS

10.2.0 10.3.0

2011-03 SP-51 SP-110064 0172 1 A Correction to correlation of charging information collected at the MSC for SRVCC in roaming scenarios

10.2.0 10.3.0

2011-06 SP-52 SP-110343 0173 4 B Selection by the ICS UE of the origination procedure with CS media

10.3.0 11.0.0

2011-12 SP-54 SP-110738 0177 1 A Correction of roaming procedures for ICS 11.0.0 11.1.0 2011-12 SP-54 SP-110748 0178 1 F Support for Completion of Communication Services 11.0.0 11.1.0 2011-12 SP-54 SP-110738 0180 1 A Communication Waiting correction for ICS 11.0.0 11.1.0 2011-12 SP-54 SP-110738 0182 - A CR for Terminated Case of Video Call Domain Selection 11.0.0 11.1.0 2011-12 SP-54 SP-110738 0184 - A ICS and usage of Sh for CSRN fetching 11.0.0 11.1.0 2012-03 SP-55 SP-120081 0185 1 B Location information provision during ICS

origination/termination procedures 11.1.0 11.2.0

2012-03 SP-55 SP-120075 0187 - A Clarifications on supported media 11.1.0 11.2.0 2012-06 SP-56 SP-120243 0188 - F Removal of CSG ID as a network provided location

information parameter 11.2.0 11.3.0

2012-06 SP-56 SP-120251 0189 1 F Correction on CFNRc usage for ICS 11.2.0 11.3.0 2012-09 SP-57 SP-120481 0190 1 F RAVEL clarifications for MSC enhanced for ICS 11.3.0 11.4.0 2012-12 SP-58 SP-120728 0193 2 F Mobility Management Procedures via Gs Interfaces for Non-

ICS UE 11.4.0 12.0.0

2013-03 SP-59 SP-130088 0196 1 A Correction on the Call Waiting in the ICS 12.0.0 12.1.0 2013-06 SP-60 SP-130223 0198 3 A Support of MTRR feature for T-ADS 12.1.0 12.2.0 2013-06 SP-60 SP-130223 0200 - A Clarification regarding conference call participants leaving

the conference 12.1.0 12.2.0

2014-03 SP-63 SP-140100 0203 2 A ICS Indicator to support MSC not enhanced for ICS 12.2.0 12.3.0 2014-03 SP-63 SP-140100 0205 1 A IMS registration via I2 upon Combined Attach via SGs 12.2.0 12.3.0 2014-06 SP-64 SP-140249 0211 1 A Access Domain Selection when an ongoing IMS voice over

PS session 12.3.0 12.4.0

2014-06 SP-64 SP-140274 0213 2 C Synchronizing service settings data management between CS and IMS

12.4.0 13.0.0

2014-012 SP-66 SP-140686 0220 2 A Subscription for conference event package 13.0.0 13.1.0 2014-012 SP-66 SP-150239 0228 1 F Notify UE conference event package after SRVCC 13.1.0 13.2.0

ETSI


History

Document history

V13.2.0 March 2016 Publication

TS 123 292 - V13.2.0 - Digital cellular telecommunications ... · PDF file7.2 Registration ......

Documents

Transcript of TS 123 292 - V13.2.0 - Digital cellular telecommunications ... · PDF file7.2 Registration ......