A.16 Signalling flows for PS to CS SRVCC session transfer for IMS emergency session

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

The signalling flows for PS to CS SRVCC session transfer for IMS emergency session demonstrate how an IMS emergency session is transferred from PS network to CS network using PS to CS SRVCC procedure. The following signalling flow is included:

– subclause A.16.2 shows an example when a UE initiating an emergency session in IMS for the case that the UE is not in limited service mode ;and

– subclause A.16.3 shows an example when the emergency session need to transfer from PS to CS using PS to CS SRVCC procedure for the case that the UE is not in limited service mode.

A.16.2 UE initiating an emergency session in IMS

The signalling flows shown in figure A.16.2-1 describes the UE initiating an IMS emergency session procedure for the case that the UE is not in limited service mode. The flow illustrates the anchoring of the session at the EATF.

Figure A.16.2-1: Signalling flow for UE initiating an emergency session in IMS

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

NOTE 2: For clarity, the SIP 180 (Ringing) response is not shown in the signalling flow.

NOTE 3: For clarity, the precondition mechanism is not shown in the signalling flow.

1. SIP INVITE request (UE A to P-CSCF) see example in table A.16.2-2

Table A.16.2-2: SIP INVITE request

INVITE urn:service:sos.fire SIP/2.0

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

Max-Forwards: 70

Route: <sip:pcscf.visit1.net:7531;lr;comp=sigcomp>

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

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

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

To: <urn:service:sos.fire>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, 199, gruu

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

Require: sec-agree

Proxy-Require: sec-agree

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

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+sip.instance="<urn:gsma:imei:90420156-025763-0>"

Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>;inserted-by="sip:user1_public1@home1.net";routing-allowed="yes"

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:ddd

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

t=0 0

m=audio 3400 RTP/AVP 98

a=curr: qos local none

a=curr: qos remote none

a=des: qos mandatory local sendrcv

a=des: qos mandatory remote sendrcv

a=inactive

Contact: contains the "sip.instance" media feature tag as specified in IETF RFC 5626 [22] with a value formed from an IMEI as defined in 3GPP TS 23.003 [12].

2. SIP INVITE request (P-CSCF to E-CSCF) see example in table A.16.2-3

Table A.16.2-3: SIP INVITE request

INVITE urn:service:sos.fire SIP/2.0

Via: SIP/2.0/UDP pcscf.visit1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

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

Record-Route: <sip:pcscf.visit1.net;lr>

P-Preferred-Identity:

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Accept:

Require:

Proxy-Require:

Accept-Contact:

P-Preferred-Service:

Security-Verify:

Contact:

Geolocation:

Allow:

Content-Type:

Content-Length: (…)

a=curr:

a=des:

3. SIP INVITE request (E-CSCF to EATF) see example in table A.16.2-4

Table A.16.2-4: SIP INVITE request

INVITE urn:service:sos.fire SIP/2.0

Via: SIP/2.0/UDP ecscf.visit1.net;branch=z9hG4bK87ly12.1, SIP/2.0/UDP pcscf.visit1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

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

Record-Route: <sip:ecscf.visit1.net;lr>,<sip:pcscf.visit1.net;lr>

P-Preferred-Identity:

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Accept:

Require:

Proxy-Require:

Accept-Contact:

P-Preferred-Service:

Security-Verify:

Contact:

Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>;inserted-by="sip:user1_public1@home1.net";routing-allowed="yes";used-for-routing

Allow:

Content-Type:

Content-Length: (…)

4. EATF anchors the emergency session

The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the signalling path which invokes a 3pcc for enablement of Access Transfers

5. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-5

The EATF 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 PSAP via the intermediate IM CN subsystem entities.

Table A.16.2-5: SIP INVITE request

INVITE urn:service:sos.fire SIP/2.0

Via: SIP/2.0/UDP eatf1.visit1.net;branch=z9hG4bKnas34r5

Max-Forwards: 67

Route: <sip:ecscf.visit1.net:7531;lr;comp=sigcomp>

Record-Route: <sip:eatf1.visit1.net;lr>,<sip:ecscf.visit1.net;lr>,<sip:pcscf.visit1.net;lr>

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

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

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

To: <urn:service:sos.fire >

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, 199, gruu

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

Require: sec-agree

Proxy-Require: sec-agree

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

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+sip.instance="<urn:gsma:imei:90420156-025763-0>"

Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>; inserted-by=" sip:user1_public1@home1.net"；routing-allowed="yes";used-for-routing

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:ddd

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

t=0 0

m=audio 3400 RTP/AVP 98

a=curr: qos local none

a=curr: qos remote none

a=des: qos mandatory local sendrcv

a=des: qos mandatory remote sendrcv

a=inactive

6. SIP INVITE request (E-CSCF to PSAP)

E-CSCF routes the SIP INVITE request to the PSAP.

7. SIP 200 (OK) response (PSAP to E-CSCF) see example in table A.16.2-6

Table A.16.2-6: SIP 200 (OK) response

SIP/2.0 200 OK

Via: SIP/2.0/UDP ecscf.visit1.net;branch=z9hG4bKnas34r5

Max-Forwards: 67

Record-Route: <sip:eatf1.visit1.net;lr>;<sip:ecscf.visit1.net;lr>,<sip:pcscf.visit1.net;lr>

Privacy: none

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

To: < urn:service:sos.fire >;tag=232456

Call-ID:

Cseq:

Require: 100rel, precondition, 199, gruu

Contact: <sip:mgcf.visit1.net>.

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:ddd

c= IN IP6 5555::fff:eee:ccc:ddd

t=0 0

m=audio 3400 RTP/AVP 98

a=curr: qos local none

a=curr: qos remote none

a=des: qos mandatory local sendrcv

a=des: qos mandatory remote sendrcv

a=inactive

8-9. SIP 200 (OK) response (E-CSCF to EATF and to E-CSCF)

E-CSCF forwards the SIP 200 (OK) response.

10-11. SIP 200 (OK) response (E-CSCF to UE A) see example in table A.16.2-7

Table A.16.2-7: SIP 200 (OK) response

SIP/2.0 200 OK

Via:

Max-Forwards: 65

Record-Route:

Privacy:

From:

To:

P-Asserted-Identity: tel:911;context="+1"

Call-ID:

Cseq:

Require:

Contact:

Allow:

Content-Type:

Content-Length:

12. SIP ACK request

UE A responds to the SIP 200 (OK) response with a SIP ACK request.

A.16.3 Session transfer for emergency session using PS to CS SRVCC procedure: PS-CS

In the example in figure A.16.3-1, UE A (which has a valid subscription, is authenticated and authorized for PS service and is normal attached to the network) has an ongoing emergency session with a PSAP using a PS bearer which is anchored at EATF. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a PS to CS SRVCC handover to CS access.

Figure A.16.3-1 Signalling flow for emergency session transfer using PS to CS SRVCC procedure

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

1. UE A is on an active emergency session with a PSAP

There is an ongoing IP bearer between the UE A and the remote end PSAP. The call is achored at EATF.

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 E-STN-SR, refer to 3GPP TS 23.237 [9].

3. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in table A.16.3-2

Table A.16.3-2: 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 msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

Route: <sip:icscf1.visit1.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: 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.home1.net>;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+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 E-STN-SR, as routed to the EATF

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

Contact: contains the "sip.instance" media feature tag as specified in IETF RFC 5626 [22] with a value formed from an IMEI as defined in 3GPP TS 23.003 [12].

4. SIP INVITE request

The I-CSCF routes the SIP INVITE request directly to the EATF by using the procedure defined in 3GPP TS 23.228 [15] for PSI based application Server termination.

NOTE 2: The use of indirect routing for PSI based Application Server Termination as described in 3GPP TS 23.228 [15] in subclause 5.7.6 cannot be used for routing the SIP INVITE request to the EATF.

5. Remote Leg Update

The EATF based on the content of the "gr" parameter in the Contact header field 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 EATF performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg.

6. SIP re–INVITE request (EATF to intermediate IM CN subsystem entities) –see example in table A.16.3-3

TheEATF 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 PSAP via the intermediate IM CN subsystem entities.

Table A.16.3-3: SIP re-INVITE request (EATF to intermediate IM CN subsystem entities)

INVITE #### SIP/2.0

Via: SIP/2.0/UDP eatf1.visit1.net;branch=z9hG4bKnas34r5

Max-Forwards: 68

Route: <sip:ecscf.visit1.net:lr>

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

P-Charging-Function-Addresses: ####

P-Charging-Vector:####

Privacy: none

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

To: <urn:service:sos.fire>;tag=232456

Call-ID: cb03a0s09a2sdfglkj490333

Cseq:

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+sip.instance="<urn:gsma:imei:90420156-025763-0>"

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

7. SIP re–INVITE request (E-CSCF to PSAP)

E-CSCF forward the SIP re-INVITE request to the PSAP.

8. SIP 200 (OK) response (PSAP to E-CSCF)

Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP 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.

9. SIP 200 (OK) response (E-CSCF to EATF)

E-CSCF forward the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating network.

10-11. SIP ACK request (EATF to PSAP via IM CN subsystem entities)

The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the PSAP.

12-13. SIP 200 (OK) response (EATF to interworking entities via IM CN subsystem entities)

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

14-15. SIP ACK request (interworking entities to EATF via IM CN subsystem entities)

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

16-18: SIP BYE request (EATF to UE A via intermediate IM CN subsystem entities)

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

19-21. SIP 200 (OK) response (UE A to E- SCC AS via intermediate IM CN subsystem entities)

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 EATF. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN.

NOTE: Steps 18-19 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.

22a. CS bearer establishment (interworking entities to UE A)

22b. IP bearer establishment (interworking entities to PSAP)