Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.335  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   A…   A.4…   B… 
5 User Data convergence information flows  5.1 General  5.2 Requirements  5.3 Querying data from the UDR  5.4 Creating data within the UDR  5.5 Deleting data from the UDR  5.6 Updating data within the UDR  5.7 Subscription to Notifications  5.8 Notification of data modification 
...

 

5  User Data convergence information flows  p. 12

5.1  General  p. 12

This clause documents the main procedures on the Ud reference point that are used by the different Front Ends. These procedures are described using text description as well as information flow diagrams. The procedures described in this document are meant to provide a high level description and are not intended to be exhaustive.
In the following clauses, the multiple network elements are depicted as a single entity, since the procedures are common for all applications.
These procedures assume that the existing network elements accept a request message sent by any FE, e.g. a MSC/VLR accepts a MAP Cancel Location sent by any HLR-FE, an AS accepts Sh-Notif from any HSS-FE and an S-CSCF accepts Cx-Deregister from any HSS-FE. Figure 5.1-1 shows the general UDC information flow. See Annex A for specific examples.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.1-1: General UDC Information Flow
Figure 5.1-1: General UDC Information Flow
(⇒ copy of original 3GPP image)
Up
Step 1.
The FE receives an initial request on one of the supported interfaces from UE, Core Network, Service Layer or OSS.
Step 2.
When receiving an initial request message, the FE may read user data from the UDR.
Step 3.
The FE shall store the read user data (if any) as a temporary local copy and use it when performing its application logic. There may be applications that do not need to retrieve and store user data from the UDR in order to perform the application logic.
Step 4.
The FE performs its application logic.
Step 4a.
As part of performing the application logic, the FE shall continue and complete the communication with the UE, Core Network, Service Layer or OSS. This may include sending messages to and receiving messages from entities within the UE, Core Network, Service Layer or OSS other than the entity that sent the initial request.
Step 4b.
As part of performing the application logic, the FE shall access user data in the UDR if so required by the application. This may happen more often than once. Steps 4a and 4b may be performed in any order of sequence.
Step 5.
After application logic is completed, the FE shall delete its temporary local copy of user data.
Step 6.
The UDR shall send a notification message to an appropriate FE if the data modified in step 4b are subscribed data for notification. The notification message shall include user data. More than one notification messages are sent if the modified data are subscribed more often than once.
Step 7.
The FE shall store the received user data as a temporary local copy and use it when performing its application logic.
Step 8.
The FE performs its application logic.
Step 8a.
As part of performing the application logic, the FE shall communicate with the UE, Core Network, Service Layer or OSS if so required by the application.
Step 8b.
As part of performing the application logic, the FE shall access user data in the UDR if so required by the application. This may happen more often than once. Steps 8a and 8b may be performed in any order of sequence.
Step 9.
After application logic is completed, the FE shall send a notify acknowledgement to the UDR. Depending on the application the notify acknowledgement may be sent earlier, e.g. immediately after step 6.
Step 10.
After application logic is completed, the FE shall delete its temporary local copy of user data.
Up

5.2  Requirements  p. 14

The following points are considered as requirements for the purpose of these procedures.
  1. It shall be possible for an authorized Front End to read relevant user data stored in the UDR.
  2. It shall be possible for an authorized Front End to modify (i.e. create, update, and delete) relevant user data stored in the UDR.
  3. The UDR shall support notifications to the related Front Ends about changes of user data which they have subscribed to. Specifically, the UDR shall allow applications to subscribe to specific events on specific data of specific users.
  4. The UDR shall support controlled access. Accordingly, UDR shall authenticate and authorize Application Front Ends.
    The authentication shall be based on the identity provided by the FE when accessing the UDR.
    The authorization/access control shall be based on the following criteria:
    • the requested user's network (e.g. PLMN identity)
    • identity provided by the FE
    • application type
    • the user data which are requested
    • the request type (e.g. query, modify)
  5. Access to the UDR shall be independent of the structure of the data models, i.e. the changes in the data models shall not affect these procedures.
  6. It shall be possible to present different views on the user data to the different FEs which require access.
  7. A group of Front Ends (or a single Front End) for a specific application type shall be distinguished by a unique Front End cluster identifier.
  8. The UDR may store the current Front End identifier/Front End cluster identifier(s) when certain user data (e.g. user's location, Sh AS subscription data, service data settings, etc.) is changed as part of the user data and may use this information to determine which Front Ends should be used for notifications.
Up

5.3  Querying data from the UDR  p. 15

The Query data procedure is used by an FE to retrieve data from the UDR.
The information flow for the Query data procedure is shown in Figure 5.3-1:
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.3-1: Query data procedure
Figure 5.3-1: Query data procedure
(⇒ copy of original 3GPP image)
Up
Step 1.
When an application FE - during processing of its application logic - needs to retrieve user data from the UDR it shall issue a Query data request message and send it over the Ud reference point to the UDR. The message shall contain:
  • the FE Identifier or the FE Cluster Identifier
  • the user identity
    an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity
  • the requested data
    the identification of the data of which the value is requested
Data identification and structure shall comply with the requesting FE's data view.
Step 2.
The UDR shall perform access control to check whether the FE/application type is allowed to read the requested data. If it is not, an unsuccessful response shall be returned to the FE and steps 3 and 4 shall be skipped.
Step 3.
If the access control check is successful, the UDR shall fetch the value of the requested data and format it according to the requesting FE's data view.
Step 4.
The UDR shall return a Query data answer message to the FE. The FE then shall continue processing its application logic with the retrieved data.
Up

5.4  Creating data within the UDR  p. 16

Create data procedure is used by a FE to insert a new user data record into the UDR, e.g. when a provisioning FE creates an account for a new user, or creates a new service profile for an existing user.
The information flow for create data procedure is shown in Figure 5.4-1.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.4-1: Create Data flow
Figure 5.4-1: Create Data flow
(⇒ copy of original 3GPP image)
Up
Step 1.
When an application FE - during processing of its application logic - needs to insert new user data in the UDR, e.g. open a new user account in the database, it shall issue a Create Data Request message and send it over the Ud reference point to the UDR. The message shall contain:
  • the FE Identifier or the FE Cluster Identifier
  • the user identity
    an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity
  • the identification of data to be inserted.
  • the new data value.
Step 2.
The UDR shall perform access control to check whether the FE/application type is allowed to create the requested data. If it is not, an unsuccessful response shall be returned to the FE and steps 3 and 4 shall be skipped.
Step 3.
If the access control check is successful, the UDR shall insert the user data with the new data value.
Step 4.
If the notification triggering conditions are met, the UDR shall perform notification procedure. This procedure may run before, after or in parallel of sending Create data answer (see step 5). See clause 5.8.
Step 5.
The UDR shall return a Create data answer to the FE. The FE then shall continue processing its application logic.
Up

5.5  Deleting data from the UDR  p. 17

Delete Data procedure is used by a FE to delete user data stored in the UDR, e.g. when a provisioning FE deletes a service profile for an existing user, or removes the account of a user.
The information flow for Delete Data procedure is shown in Figure 5.5-1.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.5-1: Delete Data flow
Figure 5.5-1: Delete Data flow
(⇒ copy of original 3GPP image)
Up
Step 1.
When an application FE - during processing of its application logic - needs to delete user data from the UDR, e.g. delete user service profile, it shall issue a Delete Data Request message and send it over the Ud reference point to the UDR. The message shall contain:
  • the FE Identifier or the FE Cluster Identifier
  • the user identity
    an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity
  • the identification of data to be deleted.
The message may contain:
  • the delete condition, if supported by the UDR
Step 2.
The UDR shall perform access control to check whether the FE/application type is allowed to delete the requested data. If it is not, an unsuccessful response shall be returned to the FE and steps 3-5 shall be skipped.
Step 3.
If the message contains the delete condition, the UDR shall check if the delete condition is satisfied. If it is not, an unsuccessful response shall be returned to the FE and steps 4-6 shall be skipped
Step 4.
If the access control check is successful and the delete condition is satisfied, the UDR shall delete the requested user data.
Step 5.
If the notification triggering conditions are met, the UDR shall perform notification procedure. This procedure may run before, after or in parallel of sending Delete data answer (see step 6). See clause 5.8.
Step 6.
The UDR shall return a Delete data answer to the FE. The FE then shall continue processing its application logic.
Up

5.6  Updating data within the UDR  p. 18

The Update data procedure is used by an application FE to modify user data in the UDR.
The information flow for the Update data procedure is shown in Figure 5.6-1:
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.6-1: Update data procedure
Figure 5.6-1: Update data procedure
(⇒ copy of original 3GPP image)
Up
Step 1.
When an application FE - during processing of its application logic - needs to update user data in the UDR it shall issue an Update data request message and send it over the Ud reference point to the UDR. The message shall contain:
  • the FE Identifier or the FE Cluster Identifier
  • the user identity
    an identity of the user, e.g. IMSI, MSISDN, IMS public user identity, IMS private user identity
  • the requested data
    the identification of the data of which the value is to be updated.
  • the new data value
    value of the data that is to be written in the UDR
The message may contain:
  • the update condition, if supported by the UDR
Data that is updated may have a complex structure with multiple attributes. So the data update achieved through the Update data procedure may comprise addition, modification or deletion of some attributes of this data.
Data identification and structure shall comply with the Data view associated to the application FE.
Step 2.
The UDR shall perform access control to check whether the FE/application type is allowed to update the requested data. If it is not, an unsuccessful response shall be returned to the FE and steps 3-5 shall be skipped.
Step 3.
If the message contains the update condition, the UDR shall check if the condition is satisfied. If it is not, an unsuccessful response shall be returned to the FE and steps 4-5 shall be skipped.
Step 4.
If the access control check is successful and the update condition is satisfied, the UDR shall update the requested data with the new data value. If the notification triggering conditions are met, the UDR shall perform the Notification Procedure. This procedure may run before, after or in parallel of sending Update data answer (see step 5). See clause 5.8.
Step 5.
The UDR shall return an Update data answer message to the FE. The FE then shall continue processing its application logic.
Up

5.7  Subscription to Notifications  p. 19

This procedure is used by FE to perform the subscription/un-subscription to notification to specific events which occurs on specific user data stored in the UDR. The events can be changes on existing user data, addition of user data, and so on. The information flow for the Subscription to Notifications procedure is shown in Figure 5.7-1.
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.7-1: Subscription procedure
Figure 5.7-1: Subscription procedure
(⇒ copy of original 3GPP image)
Up
Step 1.
When an FE wants to receive notifications of specific events on specific user data stored in the UDR, it shall construct a Subscription Request message and send it over the Ud reference point to the UDR. The message may consist of the following information:
  • the FE Identifier or the FE Cluster Identifier
  • User identity, e.g. IMSI, MSISDN, IMS public user identity or IMS private user identity. The User Identity may not be present indicating that the subscription is applicable to all users in the UDR.
  • Subscription Type
    The Subscription Type indicates whether this request is to subscribe or to unsubscribe.
  • Notification Type. It indicates whether this subscription request should result in a notification to any FE of the application type or cluster identifier, or in a notification to the FE requesting the notification.
  • Subscription to Notifications information, which consists of:
    • Identification of the requested data
      The Identification of the requested data indicates the data to which notifications are subscribed.
    • The notification condition(s)
      The notification condition indicates the specific events on which the notification shall be triggered. It shall consist of the addition of the requested data, the deletion of the requested data or the changes of the requested data.
    • The expiry time
      If the subscription is not permanent, the expiry time indicates the point in time when the subscription to notifications expires.
    • The original entity identity
      If the subscription request is related to a UDC external entity (e.g. AS) subscription request, this item indicates the original entity which sent the subscription request message to the FE in order to subscribe to the notification of the specific events of the requested data. The item shall contain the address or the name of the original entity.
Step 2.
When receiving a Subscription Request from a specific FE, the UDR shall perform access control to check whether the FE is allowed to perform the subscription to the UDR on the requested data. If not, an unsuccessful response shall be returned to the FE, and steps 3 and 4 are skipped.
Step 3.
The UDR shall store the subscription to notifications information.
Step 4.
The UDR shall return a successful response message to the FE.
Up

5.8  Notification of data modification  p. 20

5.8.1  Description |R10|  p. 20

The Notification procedure shall be used by the UDR to notify an FE about modification of data, when data in the UDR is added, modified or deleted, and an FE needs to be informed about this, due to a previous subscription to notifications procedure (as defined within clause 5.7) or due to local configuration policy in the UDR. No notification should be done towards the FE at the origin of a data modification or to a FE belonging to the cluster of the FE at the origin of a data modification.
The information flow for the Notification procedure is shown in Figure 5.8-1:
Copy of original 3GPP image for 3GPP TS 23.335, Fig. 5.8-1: Notification procedure
Figure 5.8-1: Notification procedure
(⇒ copy of original 3GPP image)
Up
Step 1.
The Notification procedure in the UDR is started by the Update data procedure, the Create procedure, or the Delete procedure; see clause 5.6, clause 5.4 and clause 5.5 respectively.
The UDR shall check whether the relevant notification condition(s) are met. If not met, the following steps shall be skipped and the procedure terminates.
Step 2.
If the notification condition(s) are met the UDR shall select an available FE that supports the relevant application. If the notification is the result of a Subscription to Notification procedure, the FE selection shall take into account the value of the Notification Type information element:
  • If the Notification Type indicates that the notification is to be sent to the FE requesting the subscription, the UDR shall select the FE that requested the notification.
  • If the Notification Type indicates that the notification is to be sent to any FE of the application type or cluster identifier, the UDR shall select an appropriate FE of the application type or cluster identifier as applicable.
Step 3.
The UDR shall fetch the data that are needed by the FE to perform the relevant application logic, such as the value of updated data, and may fetch other additional data based on local configuration policy in the UDR, such as the previous value of updated data, the original subscribing entity identity, etc. to construct a notification request message that includes data (in FE data view).
Step 4.
The UDR shall send the notification request message to the selected FE. The FE shall perform the relevant application logic.
Step 5.
The FE shall return a response message to the UDR to indicate success or failure. If no response is received or a failure is indicated, the UDR shall repeat the procedure starting with step 2 and selecting a different FE.
Up

5.8.2  Notifications and transactions |R10|  p. 22

An optional feature allows grouping of notifications associated to the data changes occurring within a transaction. When this optional feature is supported, the notifications of data changes associated to a transaction shall be grouped into one notification procedure to each relevant FE or cluster of FEs, taking into account the subscriptions to notifications or the local configuration policies that requested the notifications of the data changes. The grouping of notifications shall apply independently of those subscriptions to notifications or local configuration policies that requested the notifications of the data changes.
Up

Up   Top   ToC