A.3 Signalling flows for registration

24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS

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

A.3.1 Signalling flows for CS UE IMS registration when using an MSC Server enhanced for ICS

Figure A.3.1-1 shows the registration in the IM CN subsystem performed by the MSC Server enhanced for ICS, on behalf of a UE. The registration is triggered upon a CS attach of the UE. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the UE to SIP and vice versa. In this example an IBCF is not used.

Figure A.3.1-1 MSC Server enhanced for ICS performs registraton on behalf of the UE

The details of the signalling flows are as follows:

1. CS attach (UE A to MSC)

As a result of some stimulus, UE A performs CS attachment procedure as specified in 3GPP TS 24.008 [7].

2. Authentication and Update Location (MSC/VLR to HLR/HSS)

MSC/VLR retrieves authentication vectors for the received IMSI as specified in 3GPP TS 29.002 [20] and challenges UE A as specified in 3GPP TS 24.008 [7]. After successful authentication, the MSC/VLR sends update location to the HSS/HLR as specified in 3GPP TS 29.002 [20]. HSS/HLR returns subscriber data for the IMSI that was sent by the MSC/VLR.

3. CS attach accept (MSC to UE A)

The CS attach request is accepted by the network, an accept message is sent to the MS.

4. IMS Registration evaluation

The MSC Server enhanced for ICS evaluates whether it needs to perform registration with the IM CN subsystem. This can be based on subscriber data received from the HSS/HLR.

5. IMS address discovery

The MSC Server enhanced for ICS derives a home network domain name as described in 3GPP TS 23.003 [4]. The home network domain is used to perform DNS queries to locate the I-CSCF in the home network.

6. REGISTER request (MSC Server enhanced for ICS to I-CSCF) – see example in table A.3.1-6

The purpose of this request is to register a private user identity and a temporary public user identity derived from the subscriber’s IMSI on behalf of the user with an S-CSCF in the home network. This request is routed to the I-CSCF in the home network. In this example no IBCF is employed.

Table A.3.1-6: REGISTER request (MSC Server enhanced for ICS to I-CSCF)

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

Max-Forwards: 70

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

P-Visited-Network-ID: "Visited Network Number 1 for MSC Server"

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

Path: <sip:term@msc.visited1.net;lr>

From: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>;tag=4fa3

To: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>

Contact: <sip:[5555::aaa:bbb:ccc:ddd]>;expires=600000;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"

Call-ID: apb03a0s09dkjdfglkj49111

Authorization: Digest username=" 234150999999999@ics.mnc015.mcc234.3gppnetwork.org ", realm=" ics.mnc015.mcc234.3gppnetwork.org ", nonce="", integrity-protected=auth-done, uri="sip: ics.mnc015.mcc234.3gppnetwork.org ", response=""

CSeq: 1 REGISTER

Supported: gruu

Require: path

Content-Length: 0

R-URI: Contains the home network domain name that was derived from the subscribers IMSI as described in 3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999.

From: the temporary public user identity that was derived form the subscribers IMSI as described in 3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999.

To: the temporary public user identity that was derived form the subcribers IMSI as described in 3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999.

Contact: The point-of-presence representing UE A, i.e. an IP address at the MSC Server enhanced for ICS allocated for UE a. The Contact header field contains an instance ID and a feature tag indicating that the MSC Server is acting as an MSC Server enhanced for ICS services.

NOTE: In all signalling procedures, the MSC server is assuming trusted node authentication (see 3GPP TS 24.229 [11], subclause 4.2B.1.

7. Cx: User registration status query procedure

The I-CSCF employs network domain security mechanisms to ensure that the REGISTER request was received from a trusted node. The I-CSCF makes a request for information related to the Subscriber registration status by sending the private user identity, public user identity and visited domain name to the HSS as specified in see 3GPP TS 29.228 [23]. The HSS returns the S-CSCF required capabilities and the I-CSCF uses this information to select a suitable S-CSCF.

8. REGISTER request (I-CSCF to S-CSCF) – see example in table A.3.1-8

I-CSCF forwards the REGISTER request to the selected S-CSCF.

Table A.3.1-8: REGISTER request (I-CSCF server to S-CSCF)

Via: SIP/2.0/UDP icscf.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]

Max-Forwards: 69

P-Access-Network-Info:

P-Visited-Network-ID:

P-Charging-Vector:

Path:

From:

To:

Contact:

Call-ID:

Authorization:

CSeq:

Supported:

Require

Content-Length:

9. Cx: S-CSCF Registration Notification

Based on configuration data, the S-CSCF knows that the subscriber has already been authenticated by the MSC Server enhanced for ICS. The S-CSCF informs the HSS that the user has been registered. Upon being requested by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF. For detailed message flows see 3GPP TS 29.228 [23].

10. 200 (OK) response (S-CSCF to I-CSCF) – see example in table A.3.1-10

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful.

Table A.3.1-10: 200 (OK) response (S-CSCF to I-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357; branch=z9hG4bKnashds7

Path: <sip:term@msc.visited1.net;lr>

Service-Route: <sip:orig@scscf1.home1.net;lr>

From:

To:

Call-ID:

Contact: <sip:[5555::aaa:bbb:ccc:ddd] >; pub-gruu="sip: user2_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr";+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server; expires=600000

CSeq:

P-Associated-URI: <user2_public1@home1.net>, <tel:+358504821437>

Content-Length:

11. 200 (OK) response (I-CSCF to MSC Server enhanced for ICS) – see example in table A.3.1-11

The I-CSCF forwards the 200 (OK) response to the MSC Server enhanced for ICS indicating that Registration was successful.

Table A.3.1-11: 200 (OK) response (I-CSCF to MSC Server enhanced for ICS)

SIP/2.0 200 OK

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

Path:

Service-Route:

From:

To:

Call-ID:

Contact:

CSeq:

P-Associated-URI:

Content-Length:

12. iFC evaluation

Select the filter criteria for originating session case and check the REGISTER request for the temporary public user identity against the initial filter criterion with the highest priority. In this example there is a match for the SCC AS and therefore the S-CSCF will send a third party REGISTER request to the SCC AS. In this example the filter criteria contains an Include Register Request XML element and an Include Register Response XML element.

13. REGISTER request (S-CSCF to SCC AS) – see example in table A.3.1-13

The S-CSCF sends a third party REGISTER request containing in the body the incoming REGISTER request from the PN UE and the 200 (OK) response to the incoming REGISTER request to the SCC AS.

Table A.3.1-13: REGISTER request (S-CSCF to SCC AS)

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]

Max-Forwards: 70

From: <sip:scscf1.home1.net>;tag=21235

To: <sip:user2_public1@home1.net>

Contact: <sip: scscf1.home1.net>

Call-ID:

Expires: 600000

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

P-Charging-Function-Address: ccf=192.1.1.1; ecf=192.1.1.2

CSeq:

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

Content-Length: (…)

–boundary1

Content-Type: message/sip

Via: SIP/2.0/UDP icscf.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]

Max-Forwards: 69

P-Visited-Network-ID: "Visited Network Number 1 for MSC Server"

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

From: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>;tag=4fa3

To: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>

Contact: <sip:[5555::aaa:bbb:ccc:ddd]>;expires=600000;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"

Call-ID: apb03a0s09dkjdfglkj49111

Authorization: Digest username="234150999999999@ics.mnc015.mcc234.3gppnetwork.org ", realm=" ics.mnc015.mcc234.3gppnetwork.org ", nonce="", integrity-protected=auth-done, uri="sip: ics.mnc015.mcc234.3gppnetwork.org ", response=""

CSeq: 1 REGISTER

Supported: path, gruu

Content-Length: 0

–boundary1

Content-Type: message/sip

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357; branch=z9hG4bKnashds7

Path: <sip:term@msc.visited1.net;lr>

Service-Route: <sip:orig@scscf1.home1.net;lr>

From: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>;tag=4fa3

To: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>

Call-ID: apb03a0s09dkjdfglkj49111

CSeq: 1 REGISTER

P-Associated-URI: <user2_public1@home1.net>, <tel:+358504821437>

Content-Length: 0

–boundary1–

14. 200 (OK) response (SCC AS to S-CSCF)

The SCC AS sends a 200 (OK) response to the S-CSCF indicating the third party REGISTER was successful.

15. SCC AS can subscribe to reg-event

The SCC AS can subscribe to the reg event package for the public user identity registered at the S-CSCF. Contents of the flows for subscription to reg-event from the SCC AS to the S-CSCF are similar as shown in messages 15) to 20).

16. SUBSCRIBE request (MSC Server enhanced for ICS to S-CSCF) – see example in table A.3.1-16

The MSC Server enhanced for ICS subscribes to the reg-event package.

Table A.3.1-16: SUBSCRIBE request (MSC Server enhanced to I-CSCF)

SUBSCRIBE sip:user2_public1@home1.net SIP/2.0

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

Max-Forwards: 70

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

Privacy: none

From: <sip:user2_public1@home1.net>;tag=31415

To: <sip:user2_public1@home1.net>

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

Call-ID: dre36d2v32gnlgiiomm72445

CSeq: 61 SUBSCRIBE

Event: reg

Expires: 600000

Accept: application/reginfo+xml

Contact:

Content-Length: 0

17. 200 (OK) response (S-CSCF to MSC Server enhanced for ICS) – see example in table A.3.1-17

The S-CSCF sends a 200 (OK) response to the MSC Server enhanced for ICS indicating that the subscription is established.

Table A.3.1-17: 200 (OK) response (S-CSCF to MSC Server enhanced for ICS)

SIP/2.0 200 OK

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

Max-Forwards: 70

P-Asserted-Identity: <sip:scscf1.home1.net>

Privacy:

From:

To: <sip:user2_public1@home1.net>;tag=151170

Call-ID:

CSeq:

Contact: <sip:scscf1.home1.net>

Expires:

Content-Length:

18. NOTIFY request (S-CSCF to MSC Server enhanced for ICS) – see example in table A.3.1-18

The S-CSCF sends a first NOTIFY request towards the MSC Server enhanced for ICS in order to inform about the registration status of the monitored user.

Table A.3.1-18: NOTIFY request (S-CSCF to MSC Server enhanced for ICS)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

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

Max-Forwards: 70

From: <sip:user2_public1@home1.net>;tag=31415

To: <sip:user2_public1@home1.net>;tag=151170

Call-ID:

CSeq: 42 NOTIFY

Subscription-State: active;expires=600000

Event: reg

Content-Type: application/reginfo+xml

Contact: <sip:scscf1.home1.net>

P-Charging-Info: icid=ee36d84688fe;orig-ioi=home1.net

Content-Length: (…)

<?xml version="1.0"?>

<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"

xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"

version="1" state="full">

<unknown-param name="+sip.instance">

"<urn: gsma:imei:90420156-025763-0>"

</unknown-param>

<unknown-param name=”+g.3gpp.icsi-ref”><urn:urn-7:3gpp-service.ims.icsi.mmtel>” </unknown-param>

<unknown-param name=”+g.3gpp.ics”><server>” </unknown-param>

</allOneLine>

<gr:pub-gruu uri="sip:user2_public1@home1.net

;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"/>

</allOneLine>

<gr:temp-gruu uri="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@home1.net

;gr" first-cseq="54301"/>

</allOneLine>

</contact>

</registration>

</contact>

</registration>

</reginfo>

The message body in the NOTIFY request that carries the subscriber’s registration state is formed as indicated in 3GPP TS 24.229 [11].

19. 200 (OK) response (MSC Server enhanced for ICS to S-CSCF) – see example in table A.3.1-19

Table A.3.1-19: 200 (OK) response (MSC Server enhanced for ICS to S-CSCF)

SIP/2.0 200 OK

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

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0