4 User Data Convergence architecture

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

4.1 UDC System architecture

Figure 4.1-1 presents the reference UDC architecture. UDC is the logical representation of the layered architecture that separates the user data from the application logic, so that user data is stored in a logically unique repository allowing access from entities handling an application logic, hereby named Application Front Ends.

In the architecture, the User Data Repository (UDR) is a functional entity that acts as a single logical repository of user data and is unique from Application Front End’s perspective. Entities which do not store user data and that need to access user data stored in the UDR are collectively known as application front ends.

NOTE: Depending on the different network deployment, there may be more than one UDC in an operator’s network.

Application Front Ends connect to the UDR through the reference point named Ud to access user data.

Reference points towards network elements are marked in discontinuous lines in Figure 4.1-1, and are just shown for information purposes only. Details of the roles of these functional entities are described in clauses 4.2.1, 4.2.2, 4.2.3 and 4.2. 4.

Figure 4.1-1: UDC reference architecture

Figure 4.1-2 shows how the UDC reference architecture is related to the overall network architecture by comparing a Non-UDC Network with an UDC Network. In the non-UDC Network, the figure shows NEs with their own database storing persistent user data and a NE accessing an external database; in both cases, when UDC architecture is applied,  the persistent user data are moved to the UDR and  concerned NEs are becoming Application-FEs (NE-FEs) according to the UDC architecture. This figure also shows that network interfaces between NEs are not impacted .A Network Element (NE), which in its original form represents application logic with persistent data storage, when the UDC architecture is applied, may become a NE Front End, since the related persistent data storage is moved to the UDR.

Figure 4.1-2: Comparison Non-UDC Network to UDC Network

4.2 Functional Entities

4.2.1 Application Front Ends

Functional entities, such as the HLR/HSS/AUC, Application Servers, Access Network Discovery and Selection Function in Home Network (H-ANDSF), any other Core Network nodes, Provisioning system, etc., when the UDC architecture is applied, keep the application logic, but they do not locally store user data permanently. These data-less functional entities are collectively known in the UDC architecture as Application Front Ends. The application that is handled by an FE determines the type of FE. A HSS Front End may implement a full or a part of the HSS functionalities as listed in 3GPP TS 23.002 [5], this choice being implementation dependant. The reference points between the different Front Ends and the core and service layers are not affected by the UDC architecture.

4.2.2 Provisioning Front Ends

A Provisioning Front End is an Application Front End for the purpose of provisioning the UDR. A Provisioning Front End provides means to create, delete, modify and retrieve user data. However, the provisioning should not be allowed to manipulate on the common baseline information model.

Provisioning may be associated to an application/implementation and may comprise semantic control specific to this application. It may correspond to different types of provisioning FEs corresponding to different applications logics.

The UDC may support the following provisioning possibilities of user data via Provisioning Front Ends:

– Provisioning from self care systems interfacing subscribers or users that should be allowed to initiate provisioning actions with a good response time.

– Provisioning via Applications servers that often offer user service configurations facilities (e.g. via the Ut interface) and that will control the validity of user requests before storing the data in the UDC.

The interoperation between UDC and the provisioning system is out of the scope of this specification.

4.2.3 User Data Repository

The User Data Repository (UDR) is a functional entity that acts as a single logical repository that stores converged user data. The user-related data that traditionally has been stored into the HSS /HLR/AuC, Application Servers, etc., is now stored in the UDR according to a UDC information model. UDR facilitates the share and the provisioning of user-related data throughout services of 3GPP system.

UDR provides a unique reference point to one or more Applications Front Ends, such as: one or more HSS/HLR/AuC-FEs, and one or more AS- FEs. The reference point is named Ud. UDR shall provide support for multiple applications simultaneously.

Application FEs should only be able to access the user data after proper authentication and authorization taking into account security and privacy requirements, i.e. it shall be possible to present different views on the data to the parties which require access, dependent on the authorization. The UDR shall take care of the authorization of the access to the user data. The authorization shall be based on the requestor information, the requested data, and the performed operation.

Ud reference point shall make use of Network Domain Security (3GPP TS 33.210 [7]) where applicable. For applications requiring sensitive data to be transferred over Ud (e.g. permanent authentication keys), encryption shall be required when storing these data in the UDR and transferring it over Ud.

The Application FEs managing these data shall support common algorithm(s) and key(s) for encryption/decryption.

NOTE: Given that different FEs (e.g. HLR/AuC) belonging to the same cluster can serve the same user, the encryption algorithm and key must be known by all FEs serving a given user. The key is not subscriber-specific.

The UDR functional entity may be distributed over different locations or be centralized; it may support replication mechanisms, back up functions and geographical redundancy to secure the storage of data. These functions are out of the scope of the present specification. They do not impact the functional content of the reference point Ud.

The UDR shall be able to store the following types of data:

– Permanent subscriber data: this is subscription data and relates to the necessary information the system ought to know to perform the service. User identities (e.g. MSISDN, IMSI, IMPU, IMPI), service data (e.g. service profile in IMS) and authentication data are examples of the subscription data. This kind of user data has a lifetime as long as the user is permitted to use the service and may be modified by administration means.

– Temporary subscriber data: this is data which may be changed as a result of normal operation of the system or traffic conditions (e.g. transparent data stored by Application Servers for service execution, SGSN number, user status, etc.).

There are certain types of data, as specified in 3GPP TR 22.985 [2] that in principle are not required to be stored in the UDR. However, it might be beneficial to converge these data to the UDR due to, e.g., sharing of the data within a cluster of Application Front Ends. It shall not be required that the UDR stores the following types of data:

– User-content data: content defined by the user and that may be quite large in size (e.g. Photos, videos, SMS, voice mail).

– User data that concerns event data records that can be generated on various events in the usage of services by a user and that can be used not only for charging or billing purposes but e.g. for user profiling regarding user behavior and habits, and that can be valuable for marketing purposes.

– User traffic data: this kind of user data contains call-related or session-related dynamic data (e.g. MSRN, P-TMSI), which are typically stored in VLR, SGSN or S-CSCF. These dynamic data are only used by their owner transitorily and proprietarily, and hardly shared by other services in the short term.

The UDR shall offer a Provisioning Interface to the OSS which serves as a single logical point for consistent provisioning of user data from the operator’s OSS system. This interface is out of scope of this specification.

4.2.4 Other Network Elements

Other Network Elements, which in their original form represent pure application logic with no persistent data storage functionality but with user data access towards an external database, when the UDC architecture is applied, may be assumed to perform the functionality of an Application Front End, i.e. access the user data via the Ud interface from the UDR.

For example, for Mission Critical Services (see 3GPP TS 23.280 [10]), the MC Service Server, and Configuration Management Server may be considered as Application Front Ends accessing MC Service User Profile Data via the Ud interface from the UDR.

4.3 Reference point Ud

This reference point shall allow the different FEs to create, read, modify and delete user data stored in the UDR using the harmonized access interface.

This reference point shall support subscriptions/notifications functionality which allows a relevant FE to be notified about specific events which may occur on specific user data in the UDR. The events can be changes on existing user data, addition of user data, and so on.

Through the reference point, an Application Front End shall only interface with the UDR for the data relevant to its function, and not be impacted by other data that UDR stores for other applications.

The user data that an Application Front End accesses in the UDR through the reference point Ud shall comply with an agreed data structure between the Application Front End and the UDR. Such data structure shall comply with the Application Specific Data Model, specified in 3GPP TS 32.182 [6] and in 3GPP TS 32.181 [8].

Reference point Ud shall support transactions. Operations and transactions carried out over Ud shall support the ACID (Atomicity, Consistency, Isolation, and Durability) characteristics.

4.4 Front-End Session

The application logic in a Front End is performed during an FE-Session. An FE-Session starts either with the receipt of a request message on one of the supported interfaces from the UE, Core Network, service Layer or OSS, or with receipt of a notification message on the Ud interface from the UDR.

Before an FE-Session starts, the FE does not have any user data stored.

During an FE-Session the FE

– may (depending on the application logic) read user data from the UDR and store them temporarily locally;

– may (depending on the application logic) write user data to the UDR;

– may (depending on the application logic) communicate with entities of the Network or Service Layer or OSS on supported interfaces;

– shall delete all temporarily locally stored user data when the FE-Session is completed.

After completion of an FE-Session, the FE does not have any user data stored and the FE does not maintain any state information. A subsequent FE-Session for the same user triggered by a new request message on one of the supported interfaces from the UE, Core Network, service Layer or OSS, or a new notification message on the Ud interface from the UDR may be performed by a different FE.

It must be noted that the FE-Session concept may have the following side effects on the core network and service layer:

– While in networks that do not support UDC, means are needed to route messages destined for an HSS to the correct HSS (i.e. the HSS that serves the user in question), networks that support UDC may deploy several HSS-FEs all of which have access to the UDR and hence can serve any user. Instead of routing towards the correct HSS, routing towards one of the available HSS-FE is needed. HSS-FE selection may allow load sharing or failover; details of the selection algorithm are operator specific and out of scope of this specification.

– While the FE session duration may vary (depending on the application logic), means should be provided by the different FEs (e.g. storing temporary data in the UDR to be shared by other FEs) so that any request may be handled by any FE at any given time.

4.5 UDR Session

The UDR needs to process read accesses and write accesses received via the Ud reference point.

When receiving a read-request the UDR shall check whether the requesting FE is allowed to read the requested data. If it is not, the request shall be rejected, otherwise the requested data value shall be returned to the FE respecting the FEs data view.

When receiving a write-request the UDR shall check whether the requesting FE is allowed to write the requested data. If it is not, the request shall be rejected, otherwise the UDR shall

– check whether a notification message needs to be sent via the Ud reference point to a suitable and available FE. If so, the UDR shall send the notification message;

– perform the write-request and return a successful response to the FE.