A.2 Information flows with Updating data procedure over Ud

23.3353GPPRelease 17Stage 2Technical realization and information flowsTSUser Data Convergence (UDC)

A.2.1 General

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

Figure A.2.2-1: CS location update with Ud Update from HLR-FE

1. The VLR initiates MAP Update Location message towards HLR.

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.

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.

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.

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.

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.

NOTE: Step 6 can be done immediately after step 3

7. If the front-end is allowed to modify the type of data, the UDR updates the new VLR number.

8. The HLR-FE sends MAP CANCEL LOCATION to cancel the location in the old VLR.

9. The old VLR acknowledges the request and remove all data related.

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.

NOTE: In this example, by updating the VLR-Number in the UDR after receiving MAP-Update-Location, the HLR-FE implicitly activates a pre-configured subscription to notification of relevant Subscriber Data changes. By deleting the VLR-Number in the UDR after receiving MAP-PurgeMS, a HLR-FE implicitly deactivates the pre-configured subscription to notification. The presence of a VLR-Number in the UDR is equivalent to a HLR-FE subscription over Ud for sending Notification Messages at modification of any relevant Subscriber Data.

A.2.3 IMS service data change information flow example

Figure A.2.3-1: IMS service data change information flow example with Ud Update from HSS-FE

1. UE initiates a service data configuration update (e.g. activates call waiting) via Ut interface towards the AS.

2. AS performs Sh-update to store the new service data (i.e. transparent data) in the HSS.

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.

4. If the front-end is allowed to read the type of data, the UDR responds with service data.

NOTE 1: At this step the HSS-FE can also receive the subscription information stored for data requested (i.e. list of ASs subscribed to transparent data changes)

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.

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

NOTE 2: If the HSS-FE knows from step 4 that no other AS has subscribed to be notified when transparent data change, the HSS-FE does not send Sh-PNR to any other AS. If no other AS subscribed to transparent data changes and no other notifications are required (based on local configuration policy in the UDR), no Ud Notify is sent.

NOTE 3: It is assumed that the UDR has not allowed to write the transparent data and sequence number by a HSS-FE during steps 3-6.

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.