A.18 Signalling flows for PS to CS Access Transfer: PS to CS SRVCC enhancements using ATCF

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

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

A.18.1 Introduction

The signalling flows in the subclause demonstrate the PS to CS SRVCC enhancements using ATCF. The following signalling flows are included:

– subclause A.18.2 shows an example of PS to CS SRVCC enhancements using ATCF and without media anchored.

– subclause A.18.3 shows an example of PS to CS SRVCC enhancements using ATCF and media anchored.

A.18.2 Signalling flows for PS to CS Access Transfer: PS to CS SRVCC enhancements using ATCF and without media anchored

The signalling flow shown in figure A.18.2-1 gives an example for PS to CS access transfer when using ATCF enhancements and without media anchored. In this case, the ATCF has been included in the path for subsequent transactions created at registration, but media has not been anchored in ATGW.

Figure A.18.2-1 Signalling flows for PS to CS access transfer: PS to CS SRVCC enhancements using ATCF and without media anchored

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

1. UE A is on an active session with UE B

There is an ongoing PS bearer between the UE A and the remote end UE B. The media is not anchored at ATGW.

2. SC UE A attaches to the CS domain

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 3GPP TS 23.216 [49].

3. SIP INVITE request (MSC server to ATCF)-see example in table A.18.2-3

Table A.18.2-3: SIP INVITE request (MSC server to ATCF)

INVITE tel: +1-237-555-3333 SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel: +1-237-555-3333>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the STN-SR, as routed to the ATCF.

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

P-Asserted-Identity: the C-MSISDN of the served UE.

4-5. SIP INVITE request (ATCF to SCC AS via I-CSCF)- see example in table A.18.2-4

Since the media has not been anchored at the ATGW, the ATCF forwards the SIP INVITE request to the SCC AS by replacing the request URI to the stored ATU-STI for PS to CS SRVCC.

Table A.18.2-4: SIP INVITE request (ATCF to I-CSCF)

INVITE sip:AUT-STI1@sccas.home1.net SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel: +1-237-555-4444>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

6-7. SIP re-INVITE request (SCC AS to UE B via S-CSCF)

The SCC AS based on the content of the C-MSISDN correlates the SIP INVITE request to the local and remote call legs of the existing session between the UE A and the remote end. The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg.

8-9. SIP 200 (OK) response (UE B to SCC AS via S-CSCF)

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available.

10-11. SIP ACK request (SCC AS to UE B via S-CSCF)

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the remote UE B.

12-13. SIP 200 (OK) response (SCC AS to ATCF via I-CSCF)

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) response towards the ATCF.

14. SIP 200 (OK) response (ATCF to MSC server)

The ATCF generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) response towards the MSC server.

15. SIP ACK request (MSC server to ATCF)

The MSC server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the ATCF.

16-17. SIP ACK request (ATCF to SCC AS via I-CSCF)

The ATCF generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS.

18-21. SIP BYE request (SCC AS to UE via I-CSCF, ATCF and P-CSCF)

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request to the UE A.

22-24. SIP 200 (OK) response (UE A to SCC AS via P-CSCF, ATCF and I-CSCF)

Upon receiving the SIP BYE request over the old IP-CAN, the UE A sends a SIP 200 (OK) response over the old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN.

NOTE: Steps 21-22 are performed only if the UE A uses Gm after the PS-CS access transfer is completed; otherwise, the UE A and the network release the source access leg locally, without any signalling between the UE A and the network

A.18.3 Signalling flows for PS to CS Access Transfer: PS to CS SRVCC enhancements using ATCF and media anchored

The signalling flow shown in figure A.18.3-1 gives an example for PS to CS access transfer for PS to CS SRVCC enhancements using ATCF and media anchored. In this case, the media is anchored in ATGW and ATCF has been included in the path for subsequent transactions created at registration.

Figure A.18.3-1 Signalling flows for PS to CS access transfer: PS to CS SRVCC enhancements using ATCF and media anchored

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

1. UE A is on an active session with UE B

There is an ongoing IP bearer between the UE A and the remote end UE B. The media is anchored at ATGW.

2. SC UE A attaches to the CS domain

3. SIP INVITE request (MSC server to ATCF)-see example in table A.18.3-3

Table A.18.3-3: SIP INVITE request (MSC server to ATCF)

INVITE tel: +1-237-555-3333 SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel: +1-237-555-3333>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the STN-SR, as routed to the ATCF.

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

P-Asserted-Identity: the C-MSISDN of the served UE.

4. Configure ATGW (ATCF to ATGW)

Upon receiving the access transfer message, the ATCF correlates the transferred session using C-MSISDN. The ATCF updates the ATGW by replacing the existing PS access leg media path information with the new CS access leg media path information, by sending a Configure ATGW message to ATGW.

5. Configure ATGW ACK (ATGW to ATCF)

The ATGW sends Configure ATGW Acknowledgment message back to ATCF.

6. SIP 200 (OK) response (ATCF to MSC server)

The ATCF sends the SIP 200 (OK) response to the MSC server with the media information allocated by the ATGW during session establish procedure. In the SIP 200 (OK) response, the ATCF includes the Record-Route header field containing its SIP URI that indicate where the ATCF expect to receive the indialog request sent by the MSC. In the Contact header field, the ATCF inserts the saved URI of the UE B that the UE A received from the UE B when the IP bearer between the UE A and the UE B was established.

7. SIP ACK request (MSC server to ATCF)

8. SIP INVITE request (ATCF to I-CSCFs)-see example in table A.18.3-8

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a new SIP INVITE request to the SCC AS using the stored ATU-STI for PS to CS SRVCC. When resolving the ATU-STI for PS to CS SRVCC (e.g. via DNS access), the ATCF obtains the IP address of the I-CSCF. The ATCF updates the SCC AS via the new dialog indicating that the transfer has taken place. As there is no update in the SDP information, no remote end update will be performed.

Table A.18.3-8: SIP INVITE request (ATCF to I-CSCF)

INVITE sip:AUT-STI1@sccas.home1.net SIP/2.0

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-3333>;tag=1888828

To: <tel: +1-237-555-4444>

Call-ID: cb03a0s09a2sdfglkj490444

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Require: tdialog,

Record-Route:<sip:atcf.visited2.net:5060;lr>

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ggg

c=IN IP6 5555::aaa:bbb:ccc:ggg

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the ATU-STI for PS to CS SRVCC, that resolves (e.g. via DNS access) to the IP address of the I-CSCF.

Target-Dialog: specifies that the existing dialog is related with this request.

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request from the SCC AS.

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required.

P-Asserted-Identity: the C-MSISDN of the served UE.

SDP: the media information at ATGW.

9. SIP INVITE request (I-CSCF to SCC AS)

The I-CSCF forwards the SIP INVITE request to the SCC AS.

10. SIP 200 (OK) response (SCC AS to I-CSCF)

Since there is no update in the session description, no remote end update will be performed. The SCC AS sends confirmation response to the ATCF which contain the SDP answer that the SCC AS stored during the original session establishment procedure. The SIP 200 (OK) response also includes the Record-Route header field(s) that was constructed by the SCC AS adding its SIP URI to the Record-Route header field(s) that was received in the initial SIP INVITE request in step 9. The SIP URI of the SCC AS specifies where the SCC AS expects to receive the in-dialog request from the ATCF.

11. SIP 200 (OK) response (I-CSCF to ATCF)

12-13. SIP ACK request (ATCF to SCC AS via I-CSCF)

14-17. SIP BYE request (SCC AS to UE A via I-CSCF, ATCF and P-CSCF)

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request to the UE A.

18-21. SIP 200 (OK) response (UE A to SCC AS via P-CSCF, ATCF and I-CSCF)

Upon receiving the SIP BYE request, the UE A sends a SIP 200 (OK) response to the SCC AS. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN.

NOTE: Steps 17-18 are performed only if UE A uses Gm after the PS-CS access transfer is completed; otherwise, the UE A and the network release the source access leg locally, without any signalling between the UE A and the network

A.18.4 Session transfer for originating call is in alerting phase using PS to CS SRVCC procedure with ATCF: PS to CS

In the example flow at the figure A.18.4-1, SC UE A has invited for an originating session with speech media component which is anchored at ATCF. The session is in alerting phase. Specifically, this flow illustrates that after successful transfer procedure, a direct media path is established between MSC server and the remote UE and thus any resources in the ATCF and ATGW allocated when the original session was initiated are released.

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

Figure A.18.4-1: PS-CS SRVCC, originating call in alerting phase

1. SC UE A has setup an outgoing call

The media of the outgoing call has been anchored at the ATGW. Both ends have reserved the resources and SC UE A has received a SIP 180 (Ringing) response.

2. SC UE A attaches to the CS domain

3. SIP INVITE request (MSC server to ATCF) – see example in table A.18.4-3

The MSC server sends an initial SIP INVITE request transferring the session with the recived STN-SR.

Table A.18.4-3: SIP INVITE request (MSC server to ATCF)

INVITE tel: +1-237-555-3333 SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-1111>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel:+1-237-555-3333>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; g.3gpp.srvcc-alerting

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Recv-Info: g.3gpp.state-and-event

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the STN-SR.

SDP: The SDP contains set of codecs supported by the MGW.

4. SIP INVITE request (ATCF to intermediate IM CN subsystem entities) – see example in table A.18.4-4

The ATCF sends the initial SIP INVITE request replacing the STN-SR with an ATU-STI for PS to CS SRVCC associated with a session in the transferable session set to the intermediate IM CN subsystem entities.

Table A.18.4-4: SIP INVITE request (ATCF to intermediate IM CN subsystem entities)

INVITE sip:sccas1-atu-sti.home1.net SIP/2.0

Via: SIP/2.0/UDP atcf.visited1.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 69

Route: <sip:icscf1.visit1.net;lr>

P-Asserted-Identity: <tel:+1-237-555-1111>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel:+1-237-555-3333>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; g.3gpp.srvcc-alerting

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Recv-Info: g.3gpp.state-and-event

Record-Route: <atcf.visited1.net;lr>

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the ATU-STI for PS to CS SRVCC.

Record-Route: contains ATCF URI.

SDP: The SDP contains set of codecs supported by the MGW.

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)

The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF.

5a. Remote Leg Update

The SCC AS correlates the initial SIP INVITE request to the local and remote call legs of the existing session between the UE A and the remote end. The SCC AS performs the Remote Leg update by sending SIP UPDATE request towards the Remote Leg.

6. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities)

The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received initial SIP INVITE request and the information previously stored against this session.

7. SIP UPDATE request (Intermediate IM CN subsystem entities to remote UE B)

The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B.

8. SIP 200 (OK) response (Remote UE B to Intermediate IM CN subsystem entities)

Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE B sends a SIP 200 (OK) response.

9. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.

10. SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities)

The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the remote UE B. The SDP answer indicates that resources are available

11. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to ATCF)

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the ATCF.

12. SIP 183 (Session Progress) response (ATCF to MSC server)

The ATCF forwards the 183 (Session Progress) response to the MSC server.

13. SIP PRACK request (MSC server to ATCF)

The MSC acknowledges the receipt of the 183 (Session Progress) response.

14. SIP PRACK request (ATCF to intermediate IM CN subsystem)

The ATCF forwards the SIP PRACK request to intermediate IM CN subsystem entities.

15. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS.

16. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities)

The SCC AS acknowledges the SIP PRACK request.

17. SIP 200 (OK) response (Intermediate IM CN subsystem entities to ATCF)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the ATCF.

18. SIP 200 (OK) response (ATCF to MSC server)

The ATCF forwards the SIP 200 (OK) response to the MSC server.

19. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.18.4-19

The SCC AS sends a SIP INFO request that indicates that the call is an early dialog and that the SC UE was the initiator.

Table A.18.4-19: INFO request (SCC AS to intermediate IM CN subsystem entities)

INFO sip: msc1.visit1.net:1357 SIP/2.0

Via SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 70

Route: <sip:scscf1.home1.net;lr> <atcf.visited1.net;lr>

From: <tel: +1-237-555-3333>;tag=314159

To: <tel:+1-237-555-1111>;tag=171828

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 129 INFO

Info-Package: g.3gpp.state-and-event

Content-Disposition: Info-Package

Content-Type: application/vnd.3gpp.state-and-event-info+xml

Content-Length:

<?xml version="1.0" encoding="UTF-8"?>

<state-and-event-info>

<state-info>early</state-info>

<direction>initiator</direction>

</state-and-event-info>

20. SIP INFO request (Intermediate IM CN subsystem entities to ATCF)

The intermediate IM CN subsystem entities forward the SIP INFO request to the ATCF.

21. SIP INFO request (ATCF to MSC server)

The intermediate IM CN subsystem entities forward the SIP INFO request to the ATCF. The MSC server is now aware that the call that is transferred is in originating alerting phase.

22. SIP 200 (OK) response (MSC server to ATCF)

The ATCF forwards the SIP 200 (OK) response to intermediate IM CN subsystem entities.

23. SIP 200 (OK) response (ATCF to intermediate IM CN subsystem entities)

The ATCF forwards the SIP 200 (OK) response to the intermediate IM CN subsystem entities.

24. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.

25. MSC goes in Call delivered state

The MSC enters Call delivered (N4) state as defined in 3GPP TS 24.008 [8] due to the information received in the SIP INFO request.

26. SIP 200 (OK) response (Remote UE B to intermediate IM CN subsystem entities)

The remote UE B accepts the call and sends a SIP 200 (OK) response.

27. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to SCC AS.

28. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)

The SCC AS sends the SIP 200 (OK) response to indicate that the remote UE B has accepted the call.

29. SIP 200 (OK) response (Intermediate IM CN subsystem entities to ATCF)

The SIP 200 (OK) response is forwarded to the ATCF.

30. SIP 200 (OK) response (ATCF to MSC server)

The SIP 200 (OK) response is forwarded to the ATCF.

31. CC CONNECT (MSC server to SC UE A)

The MSC server indicates to the SC UA A that the remote UE B has accepted the call in accordance with 3GPP TS 24.008 [8].

32. SIP ACK request (MSC server to ATCF)

The MSC server acknowledges the SIP 200 (OK) response received from SCC AS

33. SIP ACK request (ATCF to intermediate IM CN subsystem entities)

ATCF forwards the SIP ACK request to the intermediate IM CN subsystem entities.

34. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. The SCC AS starts a operator specific timer supervising the release of the original source leg.

35. SIP ACK request (SCC AS to intermediate IM CN subsystem entities)

The SCC AS acknowledges the SIP 200 (OK) response received towards the remote UE B.

36. SIP ACK request (Intermediate IM CN subsystem entities to remote UE B)

The SIP ACK request is forwarded towards the remote UE B.

37. CC CONNECT ACK (MSC server to SC UE A)

SC UE A acknowledges the CC CONNECT in accordance with 3GPP TS 24.008 [8].

38. SIP 404 (Not Found) response (SCC AS to intermediate IM CN subsystem entities)

The SCC AS releases the original source leg towards the SC UE A after the operator specific timer has expired by means of a SIP 404 (Not Found) response.

39. SIP ACK (Intermediate IM CN subsystem entities to SCC AS)

The SIP ACK request is sent to SCC AS.

40. SIP 404 (Not Found) response (Intermediate IM CN subsystem entities to ATCF)

Intermediate IM CN subsystem entities send a SIP 404 (Not Found) response in order to release to original source dialog towards the SC UE A.

41. SIP ACK (ATCF to intermediate IM CN subsystem entities)

The SIP ACK request is sent to the intermediate IM CN subsystem entities.

42-43.Media recources reserved in ATGW is released by ATCF.

The ATCF orders the ATGW to release all media terminations (including termination created due to forking on remote end) of the used for media anchoring during call setup in. The ATGW acknowledges the release.

44-47.SIP 404 (Not Found) response (ATCF towards SC UE A)

The ATCF sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC UE A via P-CSCF.

NOTE : The SC UE A can only receive the SIP 404 (Not Found) response and send the SIP ACK request if the signalling bearer is not suspended.

A.18.5 Signalling flows for PS to CS Access Transfer: SRVCC enhancements using ATCF with MSC server assisted mid-call feature and ATCF anchored

The flow shown in Figure A.18.5-1 applies if the CS to PS SRVCC is supported when the PS to CS SRVCC access transfer takes place.

Figure A.18.5-1: Signalling flows for PS to CS Access Transfer: SRVCC enhancements using ATCF with MSC server assisted mid-call feature and ATCF anchored

1. UE A is on an active session X with UE B and a held session Y with UE C

UE A is on an active session X with UE B and on another held session Y with UE C. Both Sessions through PS network are anchored at ATCF, and medias are anchored at ATGW.

2-21. PS to CS access transfer between UE A and UE B

The PS to CS access transfer between UE A and UE B is specified in subclause A.18.3: SRVCC enhancements using ATCF and media anchored.

22. SIP REFER request (SCC AS to I/S-CSCF) – see example in table A.18.5-22

The SCC AS sends a SIP REFER request to the I/S-CSCF inside the dialog created by the message 10.

Table A.18.5-22: SIP REFER request (SCC AS to I/S-CSCF)

REFER sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via: SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bk731b8a

Max-Forwards: 70

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net

To: <tel:+1-237-555-1111>;tag=171828

From: <tel:+1-237-555-3333>;tag=sdfsdf

Call-ID: cb03a0s09a2sdfglkj490444

Cseq: 55998 REFER

Content-Length: 125

Route: <sip:scscf1.home1.net;lr>

Refer-Sub: false

Supported: norefersub, gruu

Contact: sip:sccas1.home1.net

Refer-To: <sip:additional.session.xfer.pscssrvcc@sccas.home1.net?Target-Dialog=ksdjfhwrklf%3Bremote-tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel:+1-237-555-1111&To=tel:+1-987-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D-%202987933623%202987933623%20IN%20IP6%205555::ggg:fff:aaa:bbb%0D%0As%3D-%0D%0Ac%3DIN%20IP6%205555::ggg:fff:aaa:bbb%0D%0At%3D0%200%0D%0Am%3Dvideo%200%20RTP%2FAVP%2098%0D%0Am%3Daudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%20AMR%0D%0Aa%3Dfmtp:97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A>

Content-Type: multipart/mixed;boundary="boundary"

–boundary1

Content-Type: application/vnd.3gpp.mid-call+xml

<?xml version="1.0" encoding="UTF-8"?>

<mid-call/>

–boundary1

Content-Type: application/vnd.3gpp.srvcc-ext+xml

<?xml version="1.0"?>

<srvcc-ext>

<PS-reg-info>

<ATCF-Management-URI>sip:atcf.visited2.net</ATCF-Management-URI>

<C-MSISDN>tel:+1-237-555-1111</C-MSISDN>

</PS-reg-info>

</srvcc-ext>

–boundary1–

Refer-To: contains the additional transferred session SCC AS URI for PS to CS SRVCC and the following URI header fields:

Target-Dialog: the dialog identifier of the source access leg.

Require: containing "tdialog" option tag

From: contains the public user identity of the UE A

To: contains the public user identity of the UE C

Content-Type: containing "application/sdp" MIME type of the "body" URI header field

body: SDP describing the media used in the session

application/vnd.3gpp.mid-call+xml MIME body: indicates that REFER is related to MSC server assisted mid-call feature.

application/vnd.3gpp.srvcc-ext+xml MIME body: provides ATCF management URI and C-MSISDN.

23. SIP REFER request (I/S-CSCF to ATCF)

The I/S-CSCF forwards the SIP REFER request to the ATCF.

24. SIP REFER request (ATCF to MSC server) – see example in table A.18.5-24

The ATCF forwards the SIP REFER within the dialog.

Table A.18.5-24: SIP REFER request (ATCF to MSC server)

REFER sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via: SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bk731b8a

Via: SIP/2.0/UDP sip:scscf1.home1.net;branch=z9hG4bk869d11e

Via: SIP/2.0/UDP sip:atcf1.home1.net;branch=z9hG4bk9251re3

Max-Forwards: 70

P-Charging-Vector:

To:

From:

Call-ID:

Cseq:

Content-Length:

Route: <sip:mscserver1.home1.net;lr>

Refer-Sub:

Supported:

Contact:

Refer-To: <sip:additional.session.xfer@sccas.home1.net?Target-Dialog=ksdjfhwrklf%3Bremote-tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel:+1-237-555-1111&To=tel:+1-987-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D-%202987933623%202987933623%20IN%20IP6%205555::ggg:fff:aaa:bbb%0D%0As%3D-%0D%0Ac%3DIN%20IP6%205555::ggg:fff:aaa:bbb%0D%0At%3D0%200%0D%0Am%3Dvideo%200%20RTP%2FAVP%2098%0D%0Am%3Daudio%203456%20RTP%2FAVP%2097%2096%0D%0Ab%3DAS:25.4%0D%0Aa%3Drtpmap:97%20AMR%0D%0Aa%3Dfmtp:97%20mode-set%3D0%2C2%2C5%2C7%3B%20mode-change-period%3D2%0D%0Aa%3Dmaxptime:20%0D%0A>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/vnd.3gpp.mid-call+xml

<?xml version="1.0" encoding="UTF-8"?>

<mid-call/>

–boundary1

Content-Type: application/vnd.3gpp.srvcc-ext+xml

<?xml version="1.0"?>

<srvcc-ext>

<PS-reg-info>

<ATCF-Management-URI>sip:atcf2.visited2.net</ATCF-Management-URI>

<C-MSISDN>tel:+1-237-555-1111</C-MSISDN>

</PS-reg-info>

</srvcc-ext>

–boundary1–

25-27. SIP 200 OK response

Upon receiving the SIP REFER request, the MSC Server sends a SIP 200 (OK) response to ATCF, ATCF forwards it to the SCC AS.

28. SIP INVITE request (MSC Server to ATCF) -see example in table A.18.5-28

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request to the ATCF according to the Refer-To header field in the SIP REFER request. MSC server also includes Route header field with the ATCF management URI received in the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP REFER request.

Table A.18.5-28: SIP INVITE request (MSC Server to ATCF)

INVITE sip:additional.session.xfer@sccas.home1.net SIP/2.0

Via: SIP/2.0/UDP msc1.home1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-1111>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel:+1-987-654-3210>

Call-ID: asdfgqwerq

Cseq: 1275 INVITE

Supported: 100rel, precondition, 199, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE

Target-Dialog: ksdjfhwrklf;remote-tag=676723565;local-tag=45418454

Require: tdialog

Content-Length: (…)

Content-Type: multipart/mixed;boundary="boundary1"

Route: <sip:atcf2.visited2.net;lr>

–boundary1

Content-Type: application/sdp

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=video 0 RTP/AVP 98

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

a=sendonly

–boundary1

Content-Type: application/vnd.3gpp.srvcc-ext+xml

<?xml version="1.0"?>

<srvcc-ext>

<Setup-info>

<C-MSISDN>tel:+1-212-555-1111</C-MSISDN>

<direction>initiator</direction>

</Setup-info>

</srvcc-ext>

–boundary1–

Request-URI: contains the additional transferred session SCC AS URI for PS to CS SRVCC as received in the Refer-To header field in the SIP REFER request.

Route: contains the ATCF URI as received in the application/vnd.3gpp.srvcc-ext+xml MIME body in the SIP REFER request and with "lr" parameter.

P-Asserted-Identity: the C-MSISDN of the served UE.

application/vnd.3gpp.srvcc-ext+xml: Contains the direction of call and the C-MSISDN of the UE.

29. ATCF configures the ATGW

Upon receiving the SIP INVITE request to it, the ATCF decides to anchor the ATGW, and configures the ATGW. Then the ATGW return the ACK to complete the configuration.

30-31. SIP INVITE request (ATCF to SCC AS via I/S-CSCF) -see example in table A.18.5-33

The ATCF sends the SIP INVITE request to the I/S-CSCF. The I/S-CSCF forwards the SIP INVITE request to the SCC AS.

NOTE: ATCF uses the same procedure as in subclause A.4.3.

Table A.18.5-33: SIP INVITE request (ATCF to SCC AS via I/S-CSCF)

INVITE sip:additional.session.xfer.pscssrvcc@sccas.home1.net SIP/2.0

Via: SIP/2.0/UDP atcf1.home1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity:

P-Charging-Vector:

Privacy: none

From:

To:

Call-ID: asdfgqwerq2

Cseq:

Supported:

Accept-Contact:

P-Asserted-Service:

Contact:

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE

Content-Type:

Target-Dialog:

Require: tdialog

Content-Length: (…)

32. SIP re-INVITE request (SCC AS towards UE C)

33. SIP 200 (OK) response to the SIP re-INVITE request (UE C towards SCC AS)

32. SIP ACK request (SCC AS towards UE C)

35-36. SIP 200 (OK) response (SCC AS to ATCF via I/S-CSCF)

The SCC AS sends the SIP 200 (OK) response to the SIP INVITE to the I/S-CSCF, and the I/S-CSCF forwards it to the ATCF.

37. SIP 200 (OK) response to the SIP INVITE request (ATCF to MSC server)

38-40. SIP ACK request (MSC server to SCC AS via I/S-CSCF)

The MSC server generates the SIP ACK request to the SIP 200 (OK) response, and sends the SIP ACK request to the I/S-CSCF. Then the I/S-CSCF forwards it to the SCC AS.

41-43. SIP BYE request (SCC AS towards SC UE A via I/S-CSCF, ATCF and P-CSCF)

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a SIP BYE request towards the UE A which received by P-CSCF.

44-46. SIP 200 (OK) response (P-CSCF to SCC AS via ATCF and I/S-CSCF)

Upon receiving the SIP BYE request over the old IP-CAN, the P-CSCF sends a SIP 200 (OK) response over the old IP-CAN to the SCC AS.

A.18.6 Signalling flows for PS to CS Access Transfer: PS to CS SRVCC enhancements using ATCF and session traverses IBCF

The signalling flow shown in figure A.18.6-1 gives an example for PS to CS access transfer when using PS to CS SRVCC. The call is established, contains active speech media component and has been anchored in ATGW, and traverses IBCF during the establishment of the call. There are IBCFs between ATCF and SCC AS, e.g. UE A is roaming in another network. When PS to CS SRVCC enhancements using ATCF is triggered, the session trasfer notification message initiated by ATCF using ATU-STI may traverse different IBCF(s) comparing to previous signaling path duing the initial session set up between ATCF and SCC AS.

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

Figure A.18.6-1 Signalling flows for CS to PS Access Transfer: CS to PS SRVCC occurs during a call.

1. The UE A has a session with active speech media component with UE B

UE A has an active session with remote UE B, media is anchored in ATGW and the session traverses IBCF1.

2. SIP INVITE request (MSC server to ATCF)-see example in table A.18.5-2

Table A.18.6-2: SIP INVITE request (MSC server to ATCF)

INVITE tel: +1-237-555-3333 SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-1111>;tag=171828

To: <tel: +1-237-555-3333>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the STN-SR, as routed to the ATCF.

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

P-Asserted-Identity: the C-MSISDN of the served UE.

3. SIP 200 (OK) response (ATCF to MSC server)

4. SIP ACK request (MSC server to ATCF)

5. The new CS media between UA and MSC Server/MGW is established, and the PS media between MSC Server/MGW and ATCF/ATGW is established.

6-7. SIP INVITE request (ATCF to SCC AS)-see example in table A.18.6-6

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a new SIP INVITE request to the SCC AS using the stored ATU-STI. And the new dialog traverses IBCF2. The ATCF updates the SCC AS via the new dialog indicating that the transfer has taken place.

Table A.18.6-6: SIP INVITE request (ATCF to SCC AS)

INVITE sip:AUT-STI1@sccas.home1.net SIP/2.0

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

From: <tel:+1-237-555-3333>;tag=1888828

To: <tel: +1-237-555-4444>

Call-ID: cb03a0s09a2sdfglkj490444

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu

Require: tdialog,

Record-Route:<sip: atcf.visited2.net:5060;lr>

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ggg

c=IN IP6 5555::aaa:bbb:ccc:ggg

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the ATU-STI, that resolves (e.g. via DNS access) to the IP address of the I-CSCF.

Target-Dialog: specifies that the existing dialog is related with this request.

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request from the SCC AS.

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required.

P-Asserted-Identity: the C-MSISDN of the served UE.

SDP: the media information at ATGW.

8. SIP re-INVITE request (SCC AS to UE-B)

When the SCC AS receives the SIP INVITE from ATCF, since the SDP is different with the one in old session, the SCC AS performs the remote leg update with sending a SIP re-INVITE request to remote UE B.

9. SIP 200 (OK) response (UE B to SCC AS)

10. SIP ACK request (SCC AS to UE B)

11-12. SIP 200 (OK) response (SCC AS to ATCF)

13-14. SIP ACK request (ATCF to SCC AS)

15. There are old PS media and new PS media between ATCF and remote UE B at the same time. Therefore there is no session break due to remote leg update.

16-18. SIP BYE request (SCC AS to UE A)

The SCC AS terminates the source access leg, which was using the old IP-CAN, by sending a SIP BYE request to the UE A. In this case, it’s assumed that the SIP BYE request go to UE A.

19-21. SIP 200 (OK) response (UE A to SCC AS)

Upon receiving the SIP BYE request, the UE A sends a SIP 200 (OK) response to the SCC AS. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN.

22. After the PS to CS session transfer is completed, a new CS media between UA and MSC Server/MGW is established, and the PS media between MSC Server/MGW and ATCF/ATGW is established, and a new PS media between ATCF/ATGW and UE B is established.