A.3 Procedures
23.2793GPPCombining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) servicesRelease 17Stage 2TS
A.3.1 General Architecture
Figures A.1 and A.2 show an architecture for the general architecture for CSI interworking when CSI origination and IMS termination is used for the CSI interworking with the support of interworking in the network. Figure A.1 shows the case where the CSI interworking is performed in the originating network, and figure A.2 shows the case where the CSI interworking is performed in the terminating network.
NOTE: When to support interworking in the originating network is a matter of policy in the home operator originating network. Such policy could take into account the destination network.
Figure A.1: General architecture and signalling flow in case of CSI origination and IMS termination with CSI interworking in originating network
Figure A.2: General architecture and signalling flow in case of CSI origination and IMS termination with CSI level interworking in terminating network
The solid lines present the signalling flow between UE 1 and UE 2. The voice call (yellow line) which is initiated by UE 1 is routed to the CSI‑AS, while the IMS session for other services is also routed to the CSI‑AS. The CSI‑AS continues the communication towards UE 2 with a single session using normal IMS routing procedure. The above examples illustrate the interworking in both originating and the terminating networks and further consideration is required in order to determine whether the CSI‑AS is in the originating network, terminating network or both.
NOTE: This is for the case when the UE in CSI origination is not subscribing the VCC service.
A.3.3 Call flows for setting up the voice session for CSI origination and IMS termination with CSI interworking
Figure A.3 shows the flows for establishing the voice session for CSI origination and IMS termination with the interworking performed in the originating network. The flow is simplified and omits elements such as I‑CSCF and HSS from IMS Core B.
Figure A.3: CSI interworking on originating side for CSI origination
NOTE: The functionality of the CAMEL Svc and CSAF are the same as described in TS 23.206 [17].
1. The CSI user originates a voice call in the CS domain using a CSI UE to party‑B.
2. Origination triggers at the VMSC are detected; VMSC sends an Initial DP message towards the gsmSCF.
3. The gsmSCF invokes the CSI interworking Application’s CAMEL Service that determines that the call needs to be interworked to IMS for CSI; thus, the CAMEL Service interworks the call to the IMS by allocating an IMRN and returning it to the gsmSCF; otherwise it responds with a CAP Continue.
NOTE: How the information available to the CAMEL Service is used to decide whether the call should be routed through the IMS is implementation specific.
4. The gsmSCF responds with a CAP Connect message containing the Original Called party ID and Destination Routing Address. Destination Routing Address contains the IMRN to route the call to the CSAF. Handling of Destination Routing Address and Original Called party ID is as defined in TS 23.078 [16].
5. The VMSC routes the call towards the user’s home IMS network using the IMRN via an MGCF in the home network.
6. The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating CSI user. The calling party number and/or original called number are included in the INVITE if they are received from the PSTN call setup signalling (e.g. ISUP).
7. 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].
7a. The I‑CSCF forwards the INVITE to the CSAF via the S‑CSCF that is assigned to the IMRN.
7b. The I‑CSCF forwards the INVITE directly to the CSAF.
8. If, when the INVITE arrives at the CSI Interworking Application, it is processed by the CSAF of the CSI Interworking Application that may use the IMRN to retrieve the original called party number and the calling party number from the CAMEL Service. The CSAF uses the original called number and the calling party number 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].
9. The CSAF sends the INVITE back to the S‑CSCF for completion of the call toward the remote end.
10. The S‑CSCF forwards the INVITE to the CSI‑AS
11. The CSI‑AS forwards the INVITE to the S‑CSCF.
12. The CSI‑AS forwards the INVITE to the IMS Core B.
The rest of the call is established as per normal SIP signalling with interworking towards the CS domain. The voice call is considered to be established.
Figure A.4 shows the flows for establishing the voice session for CSI origination and IMS termination with the interworking performed in the terminating network. The flow is simplified and omits elements such as I‑CSCF and HSS.
Figure A.4: CSI interworking on terminating side for CSI origination
1. UE1 initiates a voice call on the CS side by sending a SETUP message to the CS domain (MSC).
2. The originating network generates an IAM which is forwarded to the visiting network. The IAM is routed to a MGCF.
3. The MGCF generates an INVITE and forwards the INVITE the call to S‑CSCF2.
4. S‑CSCF2, based upon iFC, forwards the INVITE to CSI‑AS2.
5. CSI‑AS2 terminates the INVITE from the MGCF and generates a new INVITE towards UE2. It also performs the service logic required for originating CSI interworking (e.g. 3rd party call control).
6. CSI‑AS2 sends the INVITE back towards S‑CSCF2.
7. S‑CSCF2 forwards the INVITE to UE2.
8. UE2 accepts the session by responding to S‑CSCF2 with a 200OK.
9. S‑CSCF2 forwards the 200 OK to CSI‑AS2.
10. CSI‑AS2 forwards the 200OK back to S‑CSCF2.
11. S‑CSCF2 forwards the200OK to the MGCF.
12. The MGCF generates a CON messages which is sent to the originating CS domain.
13. The MSC in the CS domain accepts the call by sending a CONNECT to UE1.
The voice bearer is considered to be established.
A.3.4 Call flows for adding IMS sessions to existing voice calls for CSI origination with CSI interworking
In addition to the call flows described above, the following call flows describe some of the cases where CSI interworking can occur within the network on the terminating side.
Figure A.5 below shows a call flow for adding an IMS session (e.g. MSRP session) to an existing voice call. In this case the voice call was established with IMS origination, and the interworking is performed in the network. The addition of the IMS session is from the terminal that performed the IMS origination.
NOTE: 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 A.5: Call flow for adding IMS session to existing voice call using a the existing dialog
1. The UE 2 initiates a request for adding the MSRP by sending the RE‑INVITE message within the existing dialogue.
2. The S‑CSCF 2 of the originating network sends the RE‑INVITE message for the MSRP to the S‑CSCF 1 of the terminating network, in accordance with the already established sessions.
3. The S‑CSCF 1 sends the INVITE message for the MSRP to the CSI‑AS
4. The CSI‑AS generates an INVITE that is targeted towards the user of UE1 and sends this to S‑CSCF1
5. The S‑CSCF1 sends the INVITE towards UE1
6. The UE 1 responds to the INVITE message with the 200OK message.
7. The S‑CSCF1 sends the 200OK message to the CSI‑AS1.
8. The CSI‑AS1 generates a 200OK and sends it to S‑CSCF1.
9. S‑CSCF1 sends the 200OK message to S‑CSCF 2 of the originating network.
10. The S‑CSCF 2 of the originating network sends the 200OK message to the UE 2.
11. Finally, the user plane for the MSRP is created.
NOTE: The MSRP media could go through the CSI AS.
Figure A.6 shows a call flow for adding an IMS session (e.g. MSRP session) to an existing voice call. In this case the voice call was established with CSI origination, and the interworking is performed in the network. The addition of the IMS session is from the terminal that performed the CSI origination.
NOTE: 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.
The flow below assumes that the CSI interworking was performed in the originating network.
Figure A.6: Call flow for adding IMS session to existing voice call using a the existing dialog
1. The UE1 initiates a request for adding the MSRP by sending an INVITE message within the destination towards UE2.
2. The S‑CSCF 1 of the originating network sends the INVITE message for the MSRP to CSI‑AS1 based upon the filter criteria.
3. The CSI‑AS1 generates a RE‑INVITE message within the existing dialogue towards UE2. This is returned to the S‑CSCF1. The RE‑INVITE contains the SDP for the original media (e.g. the audio) and the added media (e.g. MSRP).
4. S‑CSCF1 forwards the RE‑INVITE message towards S‑CSCF2 within the existing dialogue.
5. S‑CSCF2 forwards the RE‑INVITE towards UE2.
6. The UE 2 responds to the INVITE message with the 200OK message.
7. The S‑CSCF12sends the 200OK message to S‑CSCF2.
8. S‑CSCF1 forwards the 200OK message CSI‑AS1.
9. CS‑AS1 generates a 200OK messages and forwards the message to S‑CSCF1.
10. S‑CSCF1 of the originating network sends the 200OK message to the UE1.
11. Finally, the user plane for the MSRP is created. Note that the MSRP media could go through the CSI AS.
Figure A.7 shows a call flow for adding a voice call to an existing IMS session (e.g. MSRP session). In this case the original IMS session was established with CSI origination, and the interworking is performed in the network. The addition of the IMS session is from the terminal that performed the CSI origination.
NOTE: 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.
The flow below assumes that the CSI interworking is performed in the originating network.
NOTE: The functionality of the CAMEL Svc and CSAF are the same as described in TS 23.206 [17].
Figure A.7: Call flow for adding a voice call to an existing IMS session
1. The CSI user originates a voice call in the CS domain using a CSI UE to party‑B.
2. Origination triggers at the VMSC are detected; VMSC sends an Initial DP message towards the gsmSCF.
3. The gsmSCF invokes the CSI interworking Application’s CAMEL Service that determines that the call needs to be interworked to IMS for CSI; thus, the CAMEL Service interworks the call to the IMS by allocating an IMRN and returning it to the gsmSCF; otherwise it responds with a CAP Continue.
NOTE: How the information available to the CAMEL Service is used to decide whether the call should be routed through the IMS is implementation specific.
4. The gsmSCF responds with a CAP Connect message containing the Original Called party ID and Destination Routing Address. Destination Routing Address contains the IMRN to route the call to the CSAF. Handling of Destination Routing Address and Original Called party ID is as defined in TS 23.078 [16].
5. The VMSC routes the call towards the user’s home IMS network using the IMRN via an MGCF in the home network.
6. The MGCF initiates an INVITE towards the I‑CSCF in the home IMS of the originating CSI user. The calling party number and/or original called number are included in the INVITE if they are received from the PSTN call setup signalling (e.g. ISUP).
7. 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].
7a. The I‑CSCF forwards the INVITE to the CSAF via the S‑CSCF that is assigned to the IMRN.
7b. The I‑CSCF forwards the INVITE directly to the CSAF.
8. If, when the INVITE arrives at the CSI Interworking Application, it is processed by the CSAF of the CSI Interworking Application that may use the IMRN to retrieve the original called party number and the calling party number from the CAMEL Service. The CSAF uses the original called number and the calling party number 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].
9. The CSAF sends the INVITE back to the S‑CSCF for completion of the call toward the remote end.
10. The S‑CSCF forwards the INVITE to the CSI‑AS.
11. The CSI‑AS forwards the RE‑INVITE to the S‑CSCF. The RE‑INVITE contains the SDP for the original media (e.g. MSRP) and the added media (e.g. audio).
13. The CSI‑AS forwards the RE‑INVITE to the IMS Core B. The CS part of the CSI session is now interworked to IMS Core B.
The rest of the call is established as per normal SIP signalling with interworking towards the CS domain. The voice call is considered to be established.
Annex B (informative):
Change history
|
Change history |
||||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
Old |
New |
|
2007-06 |
SA#36 |
SP-070398 |
0036 |
– |
B |
Supporting CSI capability exchange for CSI Interworking |
7.6.0 |
8.0.0 |
|
2007-09 |
SA#37 |
SP-070534 |
0038 |
2 |
A |
CSI phase 1 alignment with stage 3 |
8.0.0 |
8.1.0 |
|
2009-12 |
SA#46 |
– |
– |
– |
– |
Update to Rel-9 version (MCC) |
8.1.0 |
9.0.0 |
|
2011-03 |
SA#51 |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.0.0 |
10.0.0 |
|
2012-09 |
– |
– |
– |
– |
– |
Update to Rel-11 version (MCC) |
10.0.0 |
11.0.0 |
|
2014-09 |
SA#65 |
– |
– |
– |
– |
Update to Rel-12 version (MCC) |
11.0.0 |
12.0.0 |
|
2015-12 |
– |
– |
– |
– |
– |
Update to Rel-13 version (MCC) |
12.0.0 |
13.0.0 |
|
2017-03 |
– |
– |
– |
– |
– |
Update to Rel-14 version (MCC) |
13.0.0 |
14.0.0 |
|
2018-06 |
SP-80 |
– |
– |
– |
– |
Update to Rel-15 version (MCC) |
14.0.0 |
15.0.0 |
|
2020-07 |
SP-88E |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
15.0.0 |
16.0.0 |
|
2022-03 |
SP-95E |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
16.0.0 |
17.0.0 |