A.4 Information flows with notification procedure over Ud

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

A.4.1 General

When user data (temporary or permanent) has been modified, the application front-end may require a notification.

When an UDC-external entity modifies subscribable data in the UDR via an application FE, this application FE shall send notifications to other UDC-external entities on supported UDC-external interfaces as part of its application logic (if so required). Notifications to other UDC-external entities to which this FE is not connected, or to other AS which subscribed to notifications, require notification on the Ud-Interface.

The following flows show examples of IMS capability change for a user, 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. These scenarios only address the specific actions of traffic events that are currently in effect.

A.4.2 IMS user capability change with notification information flow example

Figure A.4.2-1: IMS service data change information flow example with Ud notification towards HSS-FE

1. The operator changes the capabilities to move the user to a new S-CSCF, the user is administratively de-registered and S-CSCF is cleared (via Provisioning FE).

2. After applying the proper access control (i.e. the front-end is allowed to write that type of data), the UDR updates the requested data (e.g. registration status, user capabilities, etc.)

3. The UDR checks if a FE is required to be notified upon these modified data. If so, it selects a FE supporting the HSS application and sends a notification which contains the user data needed by the FE to perform its application logic (old/new user status, S-CSCF name, etc.)

NOTE 1: The conditions to trigger the notification can be common for all users and can be based on local configuration policy in the UDR, e.g. a Provisioning FE modifies user data that is relevant for another application type (HSS) and other related user data is present (S-CSCF name).

NOTE 2: The FE selection mechanism performed by the UDR (e.g. FE cluster identity if it was stored at user’s registration, application supported, load balancing, etc.) is out of scope of this specification.

4. HSS-FE acknowledges the notification.

5. The user is de-registered from S-CSCF1 by HSS-FE.

6. S-CSCF1 acknowledges the Cx command.

A.4.3 Application Server Notification information flow example without Ud-Notify

Figure A.4.3-1 Notification over Sh without Ud notification

1. AS1 sends the Sh-Update request to the HSS-FE to update the Repository Data with the related Public User Identity, the Service Indication, the Application Server Identity, and other information.

2. Upon reception of the Sh-Update 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-Update request from the UDR.

3. After applying the access control, the UDR responds to the HSS-FE with the requested data.

4. The HSS-FE sends an Update Data Request to the UDR.

5. The UDR checks whether the update is allowed. If it is permitted, the UDR shall update the repository data. The UDR responds with the Success Indication. Since the update data request was sent by an FE which can contact AS2 and there is no other AS which subscribed to changes in repository data, the UDR does not send Ud-notify.

NOTE: The UDR knows that the FE can contact AS2 based on local configuration policy

6. Upon reception the Update Data Response, the HSS-FE sends the Sh-Update Resp to the AS with the result code set to DIAMETER_SUCCESS.

7. The HSS-FE checks data received in step 3 to see whether an AS has subscribed to notifications (i.e. whether a HSS-FE has previously added/stored an AS in the Application Server Identity List for the Repository Data of the user upon receiving a previous Sh-Subs-Notif). If so the HSS-FE checks the notification conditions. In this example the conditions are met (i.e. AS expiry time stored in the Application Server Identity list has not elapsed) and the HSS-FE sends Sh-Notif to AS2.

8. AS2 sends Sh-Notif Resp to the HSS FE.

A.4.4 Application Server Notification information flow example with Ud-Notify

Figure A.4.4-1 Notification over Sh with Ud notification

1. OSS sends the Update request to the Provisioning-FE to update the Charging Information with the related Public User Identity.

2. Upon reception of the Update request, the Provisioning-FE sends the Query Request to the UDR to fetch user data from the UDR.

3. After applying the access control, the UDR responds to the Provisioning-FE with the requested data.

4. The Provisioning-FE sends Update Data Request to the UDR to update the Charging Information.

5. The UDR checks whether the update is allowed. If it is permitted, the UDR shall update the charging information. The UDR responds with the Success Indication.

6. Upon reception the Update Data Response, the Provisioning-FE sends the Update Resp to the OSS.

7. Since an AS has subscribed to notification of update of Charging Information (i.e. a HSS-FE has previously added/stored an AS in the Application Server Identity List for the Charging Information of the user upon receiving Sh-Subs-Notif) and the update data request was sent by an non HSS-FE (that is, a FE which cannot contact the AS), the UDR selects an HSS-FE and sends Notify Request to the selected FE.

The Notify Request includes the following items:

– Public User Identity.

– Identification of the requested data:  Charging Information.

– Original data: Original value of the Charging Information before update.

– Updated data: updated value of the Charging Information.

– Additional data: the additional information needed by the FE to perform the Notification procedure in addition to the requested data.

– The original entity identity: the identity of the Application Server which issues the Sh-Subs-Notif request.

NOTE: In this example, it is assumed that a pre-configured subscription exists in the UDR and that a modification to the Charging Information is done by a non HSS-FE, which results in a notification to an HSS-FE.

8. The HSS-FE checks data received in step 7 to see whether an AS has subscribed to notifications on modification on charging information (i.e. whether a HSS-FE has previously added/stored an AS in the Application Server Identity List for the Charging Information of the user upon receiving a previous Sh-Subs-Notif). If so the HSS-FE checks the detailed notification conditions. In this example the conditions are met (i.e. AS expiry time stored in the Application Server Identity list has not elapsed) and the HSS-FE sends Sh-Notif to the AS.

9. AS sends Sh-Notif Resp to the HSS FE.

10. HSS-FE sends Notify Resp to the UDR.

A.4.5 Application Server Notification information flow example without Ud-Notify – Subscription expired

Figure A.4.5-1 Notification over Sh without Ud notification – Subscription expired

1-6. See A.4.3.

7. The HSS-FE checks data received in step 3 to see whether an AS has subscribed to notifications (i.e. whether a HSS-FE has previously added/stored an AS in the Application Server Identity List for the Repository Data of the user upon receiving a previous Sh-Subs-Notif). If so the HSS-FE checks the notification conditions. In this example the conditions are not met (i.e. AS expiry time stored in the Application Server Identity list has elapsed). The HSS-FE un-subscribes the expired AS subscription in the UDR by removing the AS from Application Server Identity List for the Repository Data for the user.

8. UDR sends Un-Subscribe Resp to the HSS FE.

A.4.6 Application Server Notification information flow example with Ud-Notify – Subscription expired

Figure A.4.6-1 Notification over Sh with Ud notification

1-7. See A.4.4

8. The HSS-FE checks data received in step 7 to see whether an AS has subscribed to notifications on modification on charging information (i.e. whether a HSS-FE has previously added/stored an AS in the Application Server Identity List for the Charging Information of the user upon receiving Sh-Subs-Notif). If so the HSS-FE checks the notification conditions. In this example the conditions are not met (i.e. AS expiry time stored in the Application Server Identity list has elapsed). The HSS-FE un-subscribes the expired AS subscription in the UDR by removing the AS from Application Server Identity List for the Charging Information for the user.

9. UDR sends Un-Subscribe Resp to the HSS FE.

10. HSS-FE sends Notify Resp to the UDR.

Annex B (informative): Applicability of the UDC concept to network nodes