7 Application management
32.1813GPPFramework for Model Handling and ManagementRelease 17Telecommunication managementTSUser Data Convergence (UDC)
7.1 Application Access Control Data
Specification 23.335 [8] in Chapter 5.2 defines the requirements for application access to the UDR including authentication and authorisation.
To be able to authenticate an application and to provide it access data in the UDR the following have to be stored:
– identity of the application including additional access protocol dependent authentication information (e.g. password)
– type of the application with associated Data Model
To be able to authorise an application for access to data in the UDR the following have to be stored:
– allowed PLMN-Id(s)
– allowed operations with the associated Data Model
– restrictions on operations possibly at information element level.
7.2 Application Data Model and Mapping to Consolidated Data Model
7.2.1 Application Data Views
Different applications have different needs when accessing the data. Consider a piece of data: some applications may need to read and write that data; other applications will only need to read the same data; and a third group of applications should not be able to access that data at all. Since the UDR implements the CDM, there must exist a mechanism to control the access of data per application, so that only the authorised subset of the CDM is exposed to that application with the correct access permissions, details on primary access control are to be found in Chapter 7.1 of this specification.
Access only to the authorised subset of the CDM is achieved by implementing Application Data Views in the UDR connected to the different application types. The concept is illustrated in Figure 7.2.1-1 in a simplified way. A detailed figure is given in Figure 7.2.1-2, and a more developed concept (considering different vendors) is provided in Figure 7.2.1-3.
According to Figure 7.2.1-1 , the UDR implements the CDM. Application Data Views are implemented for each application type accessing its specific user data within CDM in the UDR. The Application Data View is responsible for enabling and limiting applications access to data within the UDR.
FE 1
FE 2
FE 3
Figure 7.2.1-1: Application Data Views in the UDR (simplified)
Specialized IM (SpIM)
Appl IM (AIM)
App Data View
Capabilities for Apps
App Data Model
App Data Model Mapping
Figure 7.2.1-2: Correlation of IM and Application Data View for a single Application type in the UDR
In a multi-vendor scenario, for a given application type, each Front End vendor and application version may implement their own data model. Therefore, data models for the same application need not be equal across different vendors or release of the software. This scenario conceptually requires a different application data model mapping for each application and vendor. The concept is illustrated in Figure 7.2.1-3. For each application type, there can be a number of Application Data Views, each one handling the mapping to the particular data model of the vendor of the Front End. For example, for Application type #1, there can be three Front End vendors, named FE11, FE12, FE13, respectively. Each of these front ends implements its own data model. A different Application Data View handles the correct mapping to each data model. In Figure 7.2.1-3, Application Data View 11 manages FE11, Application Data View 12 manages FE12, Application Data View 13 manages FE13, and so on.
FE 11
FE 22
FE 32
FE 13
FE 21
FE 23
FE 33
FE 31
App 13
App 12
App 11
App 21
App 22
App 23
App 31
App32
App 33
FE 11
FE 11
FE 21
FE 21
FE 22
FE 22
FE 23
FE 23
FE 33
FE 33
FE 32
FE 32
FE 31
FE 31
FE 13
FE 13
FE 12
FE 12
FE 12
Figure 7.2.1-3: Application Data Views in the UDR
7.3 Subscription and Notification Related Data
Specification 23.335 [8] in Chapter 5.7 and 5.8 defines the procedure of subscription and notification. Specification 29.335[9] in Chapter 6.6, 6.7 and Annex A defines the content and format of the subscription and notification messages.
Subscription can be done by subscription message (dynamic) or configuration of the UDR (permanent). To support both kinds of subscription and to allow authorised unsubscribe operations, the following information should be stored in the UDR:
– type of subscription, dynamic or permanent
– user identifier, e.g. IMSI, MSISDN, IMS public user identity or IMS private user identity, if not specified the subscription is applicable to all users’ data of the application in the UDR.
– information on the data requested to be observed
– identity of the original (originating) subscribing entity identity, 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 data requested to be observed
– notification condition(s), this item indicates the specific events on which the notification shall be triggered. The triggering events shall consist of one or more of the following: the addition of the observed data, the deletion of the observed data or the changes of the observed data.
– type of notification, this item indicates whether this subscription request should lead to a notification to any FE of the application type or cluster identifier, or to a notification to the FE requesting the notification.to originating entity or to an FE/application based on actual selection
To support dynamic subscriptions the following information has to be stored in the UDR:
– the subscription expiry time
– the identifier of the FE or the FE Cluster which sent the subscription message (conditional, if the notification type indicates that the notification is to be sent to the FE requesting the subscription, this item is needed.)
To support the notification of data modification, the following information should be stored in the UDR:
– additional data to be sent to the application in the notification when the notification condition is met
– the FE selection algorithm (conditional, if the notification type indicates that the notification is to be sent to any FE of the application type or cluster identifier, this item is needed. This is only the identifier of the selection algorithm, not the algorithm itself.)
If the Notification Type indicates that the notification is to be sent to any FE, when the notification condition is met, the UDR should use the FE select algorithm to select a proper FE to notify. For example, the UDR may select to notify the application actually serving the user.