Content for TS 23.335 Word version: 17.0.0
A.4 Information flows with notification procedure over Ud
A.4.1 General
A.4.2 IMS user capability change with notification information flow example
A.4.3 Application Server Notification information flow example without Ud-Notify
A.4.4 Application Server Notification information flow example with Ud-Notify
A.4.5 Application Server Notification information flow example without Ud-Notify - Subscription expired
A.4.6 Application Server Notification information flow example with Ud-Notify - Subscription expired
A.4 Information flows with notification procedure over Ud p. 28
A.4.1 General p. 28
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 p. 29
Figure A.4.2-1: IMS service data change information flow example with Ud notification towards HSS-FE
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 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).
Step 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.)
Step 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.)
Step 4.
HSS-FE acknowledges the notification.
Step 5.
The user is de-registered from S-CSCF1 by HSS-FE.
Step 6.
S-CSCF1 acknowledges the Cx command.
A.4.3 Application Server Notification information flow example without Ud-Notify p. 30
Step 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.
Step 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.
Step 3.
After applying the access control, the UDR responds to the HSS-FE with the requested data.
Step 4.
The HSS-FE sends an Update Data Request to the UDR.
Step 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.
Step 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.
Step 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.
Step 8.
AS2 sends Sh-Notif Resp to the HSS FE.
A.4.4 Application Server Notification information flow example with Ud-Notify p. 31
Step 1.
OSS sends the Update request to the Provisioning-FE to update the Charging Information with the related Public User Identity.
Step 2.
Upon reception of the Update request, the Provisioning-FE sends the Query Request to the UDR to fetch user data from the UDR.
Step 3.
After applying the access control, the UDR responds to the Provisioning-FE with the requested data.
Step 4.
The Provisioning-FE sends Update Data Request to the UDR to update the Charging Information.
Step 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.
Step 6.
Upon reception the Update Data Response, the Provisioning-FE sends the Update Resp to the OSS.
Step 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:
Step 8.
- 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.
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.
Step 9.
AS sends Sh-Notif Resp to the HSS FE.
Step 10.
HSS-FE sends Notify Resp to the UDR.
A.4.5 Application Server Notification information flow example without Ud-Notify - Subscription expired p. 32
Figure A.4.5-1: Notification over Sh without Ud notification - Subscription expired
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1-6.
See clause A.4.3.
Step 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.
Step 8.
UDR sends Un-Subscribe Resp to the HSS FE.
A.4.6 Application Server Notification information flow example with Ud-Notify - Subscription expired p. 33
Step 1-7.
See clause A.4.4
Step 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.
Step 9.
UDR sends Un-Subscribe Resp to the HSS FE.
Step 10.
HSS-FE sends Notify Resp to the UDR.
