7.6.2 Supplementary service invocation using the MSC Server enhanced for ICS

23.2923GPPIP Multimedia Subsystem (IMS) centralized servicesRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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].

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.

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 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 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.

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.

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.

3. The SCC AS sends the INVITE to the S‑CSCF.

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.

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.

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.

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

4. The SCC AS sends the REFER to the S‑CSCF.

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.

13. The S‑CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment.

14. The SCC AS sends the NOTIFY to the S‑CSCF.

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.

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].

2. The S‑CSCF sends the REFER to the TAS for service execution.

3. The TAS sends the REFER to the S‑CSCF.

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

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.

8. Filter criteria directs the S‑CSCF to send the INVITE to the SCC AS.

9. The SCC AS sends the INVITE to the S‑CSCF.

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.

17. The SCC AS sends the NOTIFY to the S‑CSCF.

18. The S‑CSCF sends the NOTIFY to the TAS.

19. The TAS sends the NOTIFY to the S‑CSCF.

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.

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].

2. The S‑CSCF sends the REFER to the TAS for service execution.

3. The TAS sends the REFER to the S‑CSCF.

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

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.

9. Filter criteria directs the S‑CSCF to send the INVITE to the SCC AS.

10. The SCC AS sends the INVITE to the S‑CSCF.

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.

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.

16. The S‑CSCF sends the NOTIFY to the SCC AS as it was inserted at session establishment.

17. The SCC AS sends the NOTIFY to the S‑CSCF.

18. The S‑CSCF sends the NOTIFY to the TAS.

19. The TAS sends the NOTIFY to the S‑CSCF.

20. The NOTIFY is sent to UE A.

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].

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.

3. Filter criteria directs the S‑CSCF to send the INVITE to the SCC AS.

4. The SCC AS sends the 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.

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

13. The SCC AS sends the REFER to the S‑CSCF.

14. The S‑CSCF sends the REFER to UE B.

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.

18. The SCC AS sends the NOTIFY to the S‑CSCF.

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.

NOTE 2: UE B and UE C can be referred to the conference in parallel.

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.

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.

1. An incoming INVITE is received at the S‑CSCF of UE A.

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.

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

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.

Figure 7.6.2.11.2-1: IMS Communication Completion via MSC Server enhanced for ICS

There is an ongoing session between UE A and UE B.

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.

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.