A.6 Signalling flows for PS-CS access transfer

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.6.1 PS-CS access transfer: CS-PS

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN.

Figure A.6.1-1: Signalling flow for PS-CS Access Transfer: CS to PS

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

1. SC UE A has an ongoing session with remote UE B

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A.

2. SC UE A connects to a new IP-CAN:

The SC UE A decides to transfer the session over the new IP-CAN. The UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration procedure and reserves resources in the new IP-CAN.

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) – see example in table A.6.1-3

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call.

Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities)

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

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.home1.net:7531;lr >, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info: IEEE-802.11b

Privacy: none

From: <sip:user1_public1@home1.net>; tag=171828

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

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition

Require: sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

Contact: <sip:user1_public1@home1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="principal";

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

Accept: application/sdp; application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 3456 RTP/AVP 97 96

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

4. Evaluation of initial filter criteria

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request towards the SCC AS.

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

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC.

6. Remote Leg Update

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A (Step 3).

Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)

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

Via: SIP/2.0/UDP sccas.home1.net; branch=z9hG4bK332b33.3;

Max-Forwards: 67

Route: <scscf1.home1.net;lr >,<sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-237-555-1111>

P-Access-Network-Info: IEEE-802.11b

Privacy: none

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

P-Charging-Function-Addresses:

From: <sip:user1_public1@home1.net>; tag=1717777

To: <tel:+1-237-555-2222>, tag=4321

Call-ID: dc14b1t10b3teghmlk5013237

Cseq: 111 INVITE

Supported: precondition, 100rel

Contact: <sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

Accept: application/sdp

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 3456 RTP/AVP 97 96

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

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B)

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B.

9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities)

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS.

11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities)

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

13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities)

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A.

15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities)

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS

17. Media paths between UE A and UE B

The media path is using the new IP-CAN.

18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities)

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request.

20-22. CC DISCONNECT message (interworking entities to SC UE A)

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS bearer.

NOTE: Steps 20-21 are performed only if signalling over CS domain is possible after the CS-PS access transfer is completed; otherwise, the SC UE A and the network release the source access leg locally, without any signalling between the SC UE A and the network.

23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities)

A.6.2 PS-CS access transfer: PS-CS

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer without ICS capability.

Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS

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

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

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is anchored at SCC AS.

2. SC UE A attaches to the CS domain

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer.

3. CC SETUP messages

The SC UE sends the CC SETUP message with the static STN as the called party number.

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in table A.6.2-4

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

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

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

Max-Forwards: 70

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

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

P-Charging-Vector: ####

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition

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:mgcf1.home1.net;gr>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

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

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 IMRN, as obtained from CS networks signalling.

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

5. Evaluation of initial filter criteria

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request towards the SCC AS.

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS)

7. Remote Leg Update

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) –see example in table A.6.2-8

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE B via the intermediate IM CN subsystem entities.

Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 SIP/2.0

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

Max-Forwards: 67

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

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

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

P-Charging-Vector: icid-value="BzyretyU0dm+6O2IrT5tAFrbHLso=023551034"; orig-ioi="type3home1.net"

Privacy: none

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

To: <tel:+1-237-555-2222>; tag=26545

Call-ID: dd13a0s09a2sdfglkj490378

Cseq:

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow:

Content-Type: 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/AVPF 97 96

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

m=message 0 TCP/MSRP 98

a=accept-types:text/plain

9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B)

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B.

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

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.

11. 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 SIP re-INVITE request to the SCC AS in the originating network.

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities)

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.

14-15. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities)

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

16. CC CONNECT message (interworking entities to SC UE A)

17-18. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities)

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS.

19. CC CONNECT ACKNOWLEDGE message (SC UE A to interworking entities)

20. Media paths between SC UE A and UE B:

The CS bearer is setup while the PS bearer is still existing.

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities)

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

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities)

Upon receiving the SIP BYE request over the old IP-CAN, the SC 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 22-23 are performed only if SC UE A is using Gm after the PS-CS access transfer is completed; otherwise, the SC UE A and the network release the source access leg locally, without any signalling between the SC UE A and the network.

25. Media paths between SC UE A and UE B

Finally, the session is transferred from PS bearer to CS bearer.