A.1 Information flows with Query data procedure over Ud
23.3353GPPRelease 17Stage 2Technical realization and information flowsTSUser Data Convergence (UDC)
A.1.1 General
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
Figure A.1.2-1: CS terminating call example with Ud Query from HLR-FE
1. The GMSC initiates MAP Send Routing Info towards the HLR
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.
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.
4. The HLR-FE sends MAP Provide Roaming Number to get a MSRN from the VLR.
NOTE: For simplicity, this example does not show any other procedures that the HLR-FE can possibly do
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,
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
Figure A.1.3-1: IMS re-registration flow example with Ud Query from HSS-FE
1. I-CSCF receives an incoming REGISTER request.
2. The I‑CSCF sends the Cx-Query/Cx-Select-Pull to the HSS with the Public User Identity.
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.
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.).
5. The HSS-FE includes the S-CSCF name in the response. No user data is kept in the HSS FE.
6. The I-CSCF sends the REGISTER request to the received S-CSCF.
7. The S-CSCF sends to HSS Cx-Put/Pull. This request, in this example, is received by a different HSS-FE.
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 .
9. After applying the proper access control, the UDR responds with data requested (e.g. user profile).
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.
11. The S-CSCF returns 200 OK to I-CSCF
12. The I-CSCF forwards the response to P-CSCF.