Content for TS 23.335 Word version: 17.0.0
A Information flows
A.0 Introduction
A.1 Information flows with Query data procedure over Ud
A.2 Information flows with Updating data procedure over Ud
A.3 Example Information flows for subscriptions to notifications
...
...
A Information flows p. 22
A.0 Introduction p. 22
The following information flows examples show the possible use of Ud procedures by application front-ends such as HLR, HSS front-ends when executing some of their own procedures with the network
A.1 Information flows with Query data procedure over Ud p. 22
A.1.1 General p. 22
When user data (temporary or permanent) has to be fetched, the application front-end shall perform a query towards the UDR.
The following flows show an example of a terminating call in CS network and an example of a re-registration procedure in an IMS network. These scenarios do not address the mechanisms for access authorisation in the UDR. These scenarios only address the specific actions of traffic events that are currently in effect.
A.1.2 CS terminating call information flow example p. 22
Figure A.1.2-1: CS terminating call example with Ud Query from HLR-FE
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The GMSC initiates MAP Send Routing Info towards the HLR
Step 2.
Upon reception of SRI, the application specific front-end (HLR-FE) fetches all the user data it needs to perform its application logic (e.g. VLR number, barring indicators, call forwarding data) from the UDR through a Ud Query procedure.
Step 3.
After applying the proper access control (i.e. the front-end is allowed to read that type of data), the UDR responds with the requested user data.
Step 4.
The HLR-FE sends MAP Provide Roaming Number to get a MSRN from the VLR.
Step 5.
If the user is reachable, the VLR provides a MSRN in the response. This MSRN is not stored in the UDR, since it is temporarily reserved and consumed in the VLR,
Step 6.
The HLR-FE responds to GMSC with the provided roaming number. No user data is kept in the front-end after the procedure is ended.
A.1.3 IMS re-registration information flow example p. 23
Figure A.1.3-1: IMS re-registration flow example with Ud Query from HSS-FE
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
I-CSCF receives an incoming REGISTER request.
Step 2.
The I CSCF sends the Cx-Query/Cx-Select-Pull to the HSS with the Public User Identity.
Step 3.
Upon reception of Cx-Query, the application specific front-end (HSS-FE) fetches all the user data it needs to perform its application logic (e.g. capabilities associated to the user subscription, list of visited networks allowed, S-CSCF name, etc.) in the UDR through a Ud Query procedure.
Step 4.
After applying the proper access control (i.e. the front-end is allowed to read the type of data), the UDR responds with data requested (user location, required capabilities, etc.).
Step 5.
The HSS-FE includes the S-CSCF name in the response. No user data is kept in the HSS FE.
Step 6.
The I-CSCF sends the REGISTER request to the received S-CSCF.
Step 7.
The S-CSCF sends to HSS Cx-Put/Pull. This request, in this example, is received by a different HSS-FE.
Step 8.
Upon reception of Cx-Put/Pull, the HSS-FE fetches the user profile, S-CSCF name, etc. from the UDR through a Ud Query procedure .
Step 9.
After applying the proper access control, the UDR responds with data requested (e.g. user profile).
Step 10.
The HSS- FE detects that this is a re-registration, so it sends Cx-Put/Pull Resp to S-CSCF. No user data is kept in the front-end after the procedure is ended.
Step 11.
The S-CSCF returns 200 OK to I-CSCF
Step 12.
The I-CSCF forwards the response to P-CSCF.
A.2 Information flows with Updating data procedure over Ud p. 24
A.2.1 General p. 24
When user data (temporary or permanent) has to be modified, the application front-end shall perform an update procedure towards the UDR.
The following flows show an example of a location update in CS network and an example of a service data update in an IMS network. These scenarios do not address the mechanisms for access authorisation in the UDR. These scenarios only address the specific actions of traffic events that are currently in effect.
A.2.2 CS location update information flow example p. 25
Step 1.
The VLR initiates MAP Update Location message towards HLR.
Step 2.
Upon reception of UL, the application specific front-end (HLR-FE) fetches all the user data it needs to perform its application logic (e.g. barrings, VLR number, etc.) from the UDR through a Ud query procedure.
Step 3.
After applying the proper access control (i.e. the front-end is allowed to read that type of data), the UDR responds with the user data requested.
Step 4.
If the request is allowed (e.g. no barring is to be applied), the HLR-FE sends MAP Insert Subscriber Data to provide the user data to VLR.
Step 5.
The VLR acknowledges the request. HLR-FE receives the information about services supported by the new VLR. This can lead to certain additional modifications on user data.
Step 6.
If the previous and new VLR are not the same, the HLR-FE updates the new user data (e.g. VLR number) in the UDR through a Ud Update procedure.
Step 7.
If the front-end is allowed to modify the type of data, the UDR updates the new VLR number.
Step 8.
The HLR-FE sends MAP CANCEL LOCATION to cancel the location in the old VLR.
Step 9.
The old VLR acknowledges the request and remove all data related.
Step 10.
The HLR-FE informs the new VLR about the result of the Update Location procedure. No user data is kept in the front-end after the procedure is ended.
A.2.3 IMS service data change information flow example p. 26
Figure A.2.3-1: IMS service data change information flow example with Ud Update from HSS-FE
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
UE initiates a service data configuration update (e.g. activates call waiting) via Ut interface towards the AS.
Step 2.
AS performs Sh-update to store the new service data (i.e. transparent data) in the HSS.
Step 3.
Upon reception of Sh-Update, the application specific front-end (HSS-FE) checks the AS permission list. If AS is allowed, the HSS-FE fetches the service data for the user from the UDR through a Ud Query procedure. These data include the sequence number to synchronize the writing of data among different ASs.
Step 4.
If the front-end is allowed to read the type of data, the UDR responds with service data.
Step 5.
If sequence number is correct, the application specific front-end (HSS-FE) updates the service data for the user in the UDR through a Ud Update procedure. The update data request message contains an update condition to ensure that the data is to be updated if the sequence number was not updated by other FEs.
Step 6.
If the front-end is allowed to update the type of data and the update condition is satisfied, the UDR stores the new service data configuration and the new sequence number
Step 7.
The HSS-FE sends the response to Sh-Update to AS. No user data is kept in the front-end after the procedure is ended.
A.3 Example Information flows for subscriptions to notifications p. 27
A.3.1 General p. 27
When an UDC-external entity subscribes/un-subscribes to notifications of specific events which occurs on specific user data stored in the UDR, the application front-end should perform a subscription procedure towards the UDR.
The following flows show examples of an application server subscription to notification and un-subscription to notification in IMS network. These scenarios do not address the mechanisms for access authorisation in the UDR.
A.3.2 Application Server Subscription information flow example p. 27
Figure A.3.2-1: Subscription over Sh with Ud subscription from HSS-FE
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
AS sends the Sh-Subs-Notif request to the HSS-FE to subscribe or un-subscribe to the notifications of changes on the Repository Data with the related Public User Identity, the Service Indication, the Application Server Identity, the Expiry Time (not for un-subscribing) and other information.
Step 2.
Upon reception of the Sh-Subs-Notif request, the HSS-FE checks the AS-permission list to see whether the AS is allowed to contact the HSS. If so, the HSS-FE sends the Query Request to the UDR to fetch the user data needed to process the Sh-Subs-Notify request from the UDR.
Step 3.
After applying the access control, the UDR responds to the HSS-FE with the requested data.
Step 4.
The FE sends a Subscription Request to the UDR.
The Subscription Request message includes:
Step 5.
- The Application type of the FE
- Application FE identity
- Public User Identity
- Subscription Type: indicates whether this request is to subscribe or to un-subscribe.
- Notification Type
-
the following Subscription-to-Notifications information:
- Identification of the requested data: Repository Data with Service Indication.
- The notification condition: change on user data.
- The original entity identity: Application Server Identity which issues the Sh-Subs-Notif request.
- The expiry time: the Expiry Time in the Sh-Subs-Notif Request, if any (possibly modified by the HSS-FE); expiry time is not applicable for un-subscriptions.
The UDR checks whether the subscription/un-subscription is allowed. If it is permitted, the UDR shall store/delete the Subscription-to-Notification information. The UDR responds with the Success Indication.
Step 6.
Upon reception the Subscription Response, the HSS-FE sends the Sh-Subs-Notif Resp to the AS with the value of the requested data and with the result code set to DIAMETER_SUCCESS.
