A.3 Signalling flows for registration
24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS
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)
REGISTER sip: ics.mnc015.mcc234.3gppnetwork.org SIP/2.0
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)
REGISTER sip:ics.mnc015.mcc234.3gppnetwork.org SIP/2.0
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)
REGISTER sip:scc_as.home1.net SIP/2.0
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
REGISTER sip:ics.mnc015.mcc234.3gppnetwork.org SIP/2.0
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
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: 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">
<registration aor="sip:user2_public1@home1.net" id="a6" state="active">
<contact id="75" state="active" event="created">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
<allOneLine>
<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>
<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>
<allOneLine>
<gr:temp-gruu uri="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@home1.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration aor="tel:+358504821437" id="a7" state="active">
<contact id="77" state="active" event="created">
<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>
</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