8 Information flows

23.2793GPPCombining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) servicesRelease 17Stage 2TS

8.1 Exchange of capability information at CS call setup

It shall be possible for the UE to perform end-to-end information exchange about the current radio environment during CS call setup. The current radio environment information exchange procedure shall include the information as outlined in clause 7.2.1.

NOTE: There will exist UEs, which do not support the radio environment exchange procedure, but do support parallel CS calls and IMS sessions, e.g. Rel-5 IMS-capable UMTS UEs. Thus lack of an answer in the radio capability exchange procedure does not mean that the remote UE cannot handle a parallel IMS session or the SIP based capability exchange.

The sequence diagram in figure 8-1 outlines the exchange of information about the current radio environment, at CS call setup. The diagram the messages that should be used to transport the information of the current radio environment: the full message sequences for UUS-1 are specified in TS 23.087 [15]. For this procedure to be successful, the network must handle the radio capability information transparently.

Figure 8-1: Exchange of current radio environment information "at" CS call setup

1) The UE-A initiates a CS call by sending a SETUP message towards UE-B, including the current radio environment information encoded in the User-User Signalling IE.

2) The CS domain of the originating network sends an IAM message including the current radio environment information of UE-A to the CS domain of the terminating network. Whether the MSC performs the procedures for UUS-1 (refer to TS 23.087 [15]), or, whether the MSC merely copies the User-User Signalling IE from the SETUP message into the IAM is implementation dependent. Additional MSC based policing of the UUS information content is also implementation dependent.

3) The CS domain of the terminating network sends a SETUP message IAM including the current radio environment information of UE-A to the UE-B. Whether the GMSC and/or the VMSC performs the procedures for UUS-1, or, whether they merely copy the information into the User-User Signalling IE of the SETUP message from the IAM is implementation dependent.

4) The UE-B stores the current radio environment information of UE-A and sends the current radio environment information of UE-B in the final response to the SETUP message, i.e. the CONNECT message. UE-B takes the current radio environment information of UE-A into account when deciding what service options to present to the user and/or whether to initiate a UE capability information exchange, see clause 8.2.

If UE-B find that UE-A and UE-A’s current radio environment supports simultaneous CS and PS services and the IM Status indicates that an IMS communication is likely to be successful, then UE B should attempt an IMS registration (in case IMS registration had not previously been performed) based on preconfigured user’s preference.

NOTE: The radio environment information is only sent in the CONNECT message to avoid sending non-relevant information to the originating side, e.g. in case Call Forwarding on No Reply is active.

5) The CS domain of the terminating network sends an ANM or CON message including the current radio environment information of UE-B to the CS domain of the originating network.

6) The CS domain of the originating network sends a CONNECT message including the current radio environment information of UE-B to the UE-A.

7) The UE-A takes the current radio environment information of UE-B received into account when deciding what service options to present to the user and/or whether to initiate a UE capability information exchange, see clause 8.2.

If UE-A find that UE-B and UE-B’s current radio environment supports simultaneous CS and PS services and the IM Status indicates that an IMS communication is likely to be successful, then UE‑A should attempt an IMS registration (in case IMS registration had not previously been performed) based on preconfigured user’s preference.

8.2 Exchange of UE capability information

This clause outlines the exchange of UE related capability information using the SIP OPTIONS procedure to minimize the amount of network signalling and resource usage as well as the number of failed SIP INVITE requests. It also allows an up-to-date indication to the user which capabilities he could add to the ongoing call. Note that UE capability information exchange at IMS session initiation is specified in clause 8.4.

It shall be possible for a UE to request the SIP OPTIONS request to be sent to any other registered UE. In case of existing IMS session between UE-A and UE-B, to guarantee that SIP OPTIONS request is routed to UE-B, the SIP OPTIONS request should be sent as part of the existing IMS session. In case there is an ongoing CS call between UE-A and UE-B, it should be possible to provide a higher probability that the UE capability exchange is routed to the UE-B.

As the SIP OPTIONS request include both the IMS Public User Identity in the form of an SIP URI and the MSISDN the procedure enables both UE-A and UE-B to correlate the IMS session with the CS call and within one context inform the user what capabilities the user is able to use.

NOTE: If the UICC is not provisioned with the MSISDN the UE may get it during the IMS registration as an associated identity.

The execution of this SIP OPTIONS request procedure is recommended when UE-A has not stored capability information for UE‑B, or when UE-A has become aware that UE-B has changed its capabilities by comparing the stored and received UE capability version.

A SIP OPTIONS may also be sent by UE-A to UE-B in case UE-A’s capabilities have been updated. This request triggers UE‑B to initiate SIP OPTIONS request towards UE-A to retrieve the updated capabilities.

Figure 8-2: Exchange of UE capability information

1) UE-A sends an SIP OPTIONS request towards UE-B preferably using a SIP URI of UE-B, or a TEL URI, if no valid SIP URI is available. In case of an existing IMS session, the OPTIONS request should be sent as part of the existing session. Subject to privacy controls, in UE-A the SIP OPTIONS request shall contain MSISDN of UE-A, if available.

2) The IMS Core (A) performs the normal security procedures and forwards the SIP OPTIONS request towards IMS Core (B). If the destination address is in the format of a TEL URI, IMS Core (A) performs MSISDN to SIP URI translation as per clause 4.3.5 in TS 23.228 [2], before forwarding the SIP OPTIONS request to IMS Core (B).

The IMS Core (A) should add the MSISDN of UE-A to the SIP OPTIONS request, if not included by UE-A.

3) If the SIP OPTIONS request is not sent as part of an existing dialog, the IMS Core (B) makes a routing decision based on information in the caller preferences, as defined in RFC 3841 [19], in the SIP OPTIONS request and any registered caller capabilities, as defined in RFC 3840 [18], (e.g. CS-Voice or CS-Video).

4) The IMS Core (B) then forwards the SIP OPTIONS request to UE-B. If privacy is requested, IMS Core (B) shall remove the MSISDN of UE-A.

5) The UE-B stores the address information of UE-A.

6) The UE-B sends a 200 OK that, subject to UE-B’s privacy settings contain the information outlined in clause 7.2.2.

7) The IMS Core (B) forwards the 200 OK to IMS Core (A).

The IMS Core (B) should add the MSISDN of UE-B to the 200 OK, if not included by UE-B.

8) The IMS Core (A) forwards the 200 OK to UEA-A. If privacy is requested, IMS Core (A) shall remove the MSISDN of UE-B.

9) The UE-A stores or updates the UE capability information received and if not already available stores the address information of UE-B.

For the capability exchange procedure to work properly UE-B should send an SIP OPTIONS request towards UE-A, in the following situations, provided that the associated conditions are met:

1. An SIP INVITE request is received from UE-A, and

– The SIP INVITE request received from UE-A did not include any UE’s capabilities capability information, and

– UE-B has not stored capability information for UE‑A’s capabilities, or UE-B’s capabilities have been updated e.g. UE-B has been upgraded with video capability or supports a new service, or;

– The UE capability version included in the SIP INVITE request received from UE-A is different from the previously stored UE-A’s capability version.

2. UE-B is in a CS call with UE-A, and

– UE-B has not stored capability information for UE‑A or has received a UE capability version different from previously stored UE-A’s capability version from UE-A during CS call setup, and

– If received, the current radio environment information indicates that UE-A is capable of supporting CS and PS simultaneously.

3. A SIP OPTIONS request is received from UE-A, and

– There is no ongoing (or recently finished) UE-B initiated capability exchange with UE-A.

NOTE: The received SIP OPTIONS is not a result of a recent UE-B capability version sent from UE-B.

In the situations 1 and 2 above, a SIP OPTIONS request may also be sent by UE-B to UE-A in case UE-B’s capabilities have been updated. This request triggers UE-A to initiate SIP OPTIONS request towards UE-B to retrieve the updated capabilities.

8.3 User adds an IMS service to an ongoing CS call

8.3.1 IMS session set up without media requiring resource reservation

The following sequence diagram shows an IMS service being added to an ongoing CS call when the CSI capabilities of UE-B have not previously been stored by UE-A and are therefore exchanged after CS call setup.

NOTE 1: The SIP session may setup any service based on IMS and normal requirements as per TS 23.228 [2] apply.

Figure 8.3-1: User adds an IMS session to an ongoing CS call

1) A CS call is setup as per clause 8.1.

2) The UE-A should initiate an IMS capability exchange as described in clause 8.2.

NOTE 2: This step is only needed when UE-A does not have the UE-B IMS capabilities stored and vice versa.

NOTE 3: The IMS Capability exchange will also include the correlation between the MSISDN and the SIP URI.

3) The UE-A shall send the SIP INVITE request to the IMS Core along the signalling path established during registration.

4) The IMS Core (A) forwards the INVITE request to IMS Core (B).

5) The IMS Core (B) forwards the INVITE request to UE-B.

6) The UE-B shall associate the INVITE request with the ongoing CS call by using the MSISDN and SIP URI, obtained through the IMS Capability exchange procedure and/or included in the INVITE request

7) The UE-B invokes the correct application, which associates the SIP session with the ongoing call by matching the identities used in the CS call and the SIP session. The UE-B then sends a 200 OK.

8) The IMS Core (B) forwards the 200 OK to IMS Core (A).

9) The IMS Core (A) forwards the 200 OK to UE-A.

10) The UE-A acknowledges the 200 OK.

11) The IMS Core (A) forwards the acknowledgement to IMS Core (B).

12) The IMS Core (B) forwards the acknowledgement to UE-B.

13) Media as per the session setup is sent between the two UEs.

8.3.2 IMS session set- up with media requiring resource reservation

For an IMS session setup in the context of CSI it shall be possible to require media resource reservation as per procedures in TS 23.228 [2], illustrated in the use case below.

The following sequence diagram shows an IMS service being added to an ongoing CS call when the CSI capabilities of UE-B have not previously been stored by UE-A and are therefore exchanged after CS call setup. Only media resource reservation based on the "inactive" mechanism is shown.

Figure 8.3-2: User adds an IMS session to an ongoing CS call

1) A CS call is setup as per clause 8.1.

2) The UE-A should initiate an IMS capability exchange as described in clause 8.2. If UE-B does not receive any IMS capability exchange from UE-A within a certain time limit the UE-B should initiate the IMS capability exchange, if required.

NOTE 1: This step is only needed when UE-A does not have the UE-B IMS capabilities stored and vice versa.

NOTE 2: The IMS Capability exchange will also include the correlation between the MSISDN and the SIP URI.

3) The UE-A shall send the SIP INVITE request with the media components marked "inactive" to the IMS Core along the signalling path established during registration.

4) The IMS Core (A) forwards the INVITE request to IMS Core (B).

5) The IMS Core (B) forwards the INVITE request to UE-B.

6) The UE-B shall associate the INVITE request with the ongoing CS call by using the MSISDN and SIP URI, obtained through the IMS Capability exchange procedure and/or included in the INVITE request. If required, UE-B immediately initiates IP-CAN bearer setup. No alerting of user B needs to be carried out.

7) The UE-B directly sends a 200 OK with the media components marked ‘inactive’.

8) The IMS Core (B) forwards the 200 OK to IMS Core (A).

9) The IMS Core (A) forwards the 200 OK to UE-A.

10) The UE-A initiates IP-CAN bearer setup for the media and acknowledges the 200 OK.

11) The IMS Core (A) forwards the acknowledgement to IMS Core (B).

12) The IMS Core (B) forwards the acknowledgement to UE-B.

13) The UE-A shall send the SIP INVITE request with the media components marked "active" to the IMS core when the IP-CAN bearer is established on UE-A access.

14) The IMS Core (A) forwards the INVITE request to IMS Core (B).

15) The IMS Core (B) forwards the INVITE request to UE-B.

16) The UE-B shall perform necessary service action to receive/send user plane media.

17) The UE-B shall send 200 OK with the media components marked ‘active’ when the IP-CAN bearer is setup and the UE is ready to receive media.

18) The IMS Core (B) forwards the 200 OK to IMS Core (A).

19) The IMS Core (A) forwards the 200 OK to UE-A.

20) The UE-A acknowledges the 200 OK.

21) The IMS Core (A) forwards the acknowledgement to IMS Core (B).

22) The IMS Core (B) forwards the acknowledgement to UE-B.

23) User plane connection is established.

8.4 User adds a CS call to an ongoing IMS session

Figure 8.4-1: User adds a CS call to an ongoing IMS Session

1) The UE-A sends the SIP INVITE request to the IMS Core (A) using the address obtained during registration.

The SIP INVITE may contain CSI specific information including MSISDN and current CSI capabilities in addition to the standard information for the desired IMS service.

2) The IMS-Core (A) forwards the SIP INVITE request to the IMS Core (B)

3) The IMS-Core (B) forwards the SIP INVITE request to UE-B.

4) The UE-B should send a provisional response i.e. 18x (or a final response) and include the MSISDN of UE-B. If the session includes media requiring resource reservation then same principles apply as described in clause 8.3.2, except that the UE-B should reply with a provisional response to allow the user to answer from other UEs.

5) The IMS Core (B) forwards the provisional or final response to IMS Core (A).

6) The IMS Core (A) forwards the provisional or final response to UE-A

7) The IMS flow continues as standard.

8) The UE-A initiates a CS call by sending a SETUP message towards UE-B.

9) The CS domain of the originating network sends an IAM message to the CS domain of the terminating network.

10) The CS domain of the terminating network sends a SETUP message IAM of UE-A to the UE-B.

UE-B recognises the calling party number as negotiated in SIP session setup.

NOTE: Without exchanging radio capabilities in IMS, the PS connection could be suspended. From the user experience perspective this is considered as acceptable.

11) The UE-B sends ALERTING message to UE-A.

12) The CS domain of the terminating network sends an ACM message to the CS domain of the originating network.

13) The CS domain of the originating network sends an ALERTING message to the UE-A.

14) The UE-B sends CONNECT message to UE-A.

15) The CS domain of the terminating network sends an ANM message to the CS domain of the originating network.

16) The CS domain of the originating network sends an CONNECT message to the UE-A.

8.5 Release of CSI

The UE shall release the CS call and the IMS session independently of each other.

8.6 Terminating a Multimedia IMS session to a CSI UE

Figure 8.6-1 describes the call flow for a multimedia session (e.g. with both voice and messaging components of IMS origination and CSI termination. The assumption is that UE 1 is both CS attached and IMS domain registered. Also, the MSRP protocol is used for transporting the messaging component. Note that the procedure below is simplified for clarity, e.g. some entities are omitted, but the normal IMS procedure for IMS/CS interworking procedure shall be applied.

Figure 8.6-1: Call flow for terminating a multimedia IMS session to a CSI UE

The procedure is as follows:

1. UE 2 initiates the multimedia session for voice and MSRP by sending an INVITE message towards UE 1.

2. The S-CSCF 2 of the originating network sends the INVITE message for the voice and MSRP to the S-CSCF1 of the terminating network.

3. Triggered by the applicable iFC, the S-CSCF1 of terminating network sends the INVITE message for the voice and MSRP to the CSI AS.

4. The CSI AS invokes the Termination Logic (see clause 6.2) that decides to split the original IMS session into two sessions: One with the voice media component that will be terminated via the CS domain 1 of the terminating network and another with the messaging component that will be terminated via the PS domain. The CSI AS acts as a 3rd party call control entity for initiating and controlling these two sessions.

5. The CSI AS initiates the first session with the voice component by sending an INVITE message to S-CSCF 1 containing a Tel URI corresponding to UE 1 and any additional information to terminate the session in the CS domain.

6-8. and 11-14. Normal IMS/CS interworking functionality is invoked and a CS voice call is established toward UE 1 via CS domain 1 of the terminating network.

9. The CSI AS initiates the second session with the messaging component by sending an INVITE message to S-CSCF 1 containing a SIP URI corresponding to UE 1. CSI AS uses any information available to ensure to send the second session to the same terminating UE as the destination of the voice call.

10. and 15-16. UE 1 accepts the messaging session by sending a 200 OK message to CSI AS.

17-19. The CSI AS accepts the original INVITE message from UE 2 by sending to UE 2 a 200 OK response.

20. Finally, the CS voice bearer, the PS VoIP bearer, and the PS MSRP bearer are created.

NOTE: The MSRP media could go through the CSI AS.