7.6.1 Supplementary Services for ICS UE

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

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

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.

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.

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.

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

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.

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

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

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.

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.

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

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

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

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

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.

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

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

7.6.1.2.2.8 Customized Alerting Tone (CAT)

IMS procedures as defined in TS 24.182 [42] 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.

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)

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.

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.

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.

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.

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

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.

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.

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)

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

7. The SCC AS sends a NOTIFY message to the S‑CSCF.

8. The NOTIFY is sent to UE A.

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)

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)

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

9. The NOTIFY is sent to UE A.

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.

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 1: UE B and UE C can be referred to the conference in parallel.

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

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.