The present document is addressing a number of topics regarding User Data Convergence evolution. Some of these topics were identified in the Rel9 work but have been delayed, others are new.
These topics are largely independent of each other and are studied separately in this document.
They will be normally addressed through the following steps:
a description of the topic to be addressed with its interest, the associated requirements to cover or issues to be solved
a description of the alternative solutions including their impact on 3GPP specifications
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
sets of permanent data where the values are common to a large number of users.
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
In TS 23.335, it is written: "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". This statement may be interpreted as there is no more than one UDR in a given PLMN.
The present TR topic tries to address the assumption of multiple UDRs in a PLMN, to identify consequences and the possible impacts on existing UDC specifications.
From a practical point of view, even if the aim is to have one single logical repository, a certain number of considerations may drive to have more than one UDR in a PLMN.
It should be assessed if such considerations are of interest for operators and if so, what would be the possible impacts on standardization.
For very large networks with a very large amount of users, although an UDR may be implemented in a distributed architecture and multiple database servers with geographical distribution and geographical redundancy, an operator may consider to deploy several UDRs between which it will distribute the users.
Various reasons may drive an operator to deploy multiple UDRs, such as distribution of users in different administrative areas, progressive deployment of the UDC architecture starting with separate UDRs, UDRs from multiple vendors, scalability considerations, introduction of Ud reference points considered as a good way to go forward UDC without applying the complete UDC architecture. So it appears relevant to not only consider the target UDC architecture with one unique UDR, but to analyse how the UDC concept may also apply when multiple UDRs.
It is assumed that the user data of a given user is stored on only one UDR.
With regard to application FEs, we may distinguish two cases:
for clusters of HLR or HSS FEs (or application FEs behaving the same way) that are linked to only one UDR, with multiple UDRs, there would be several clusters of HLR or HSS FEs, one cluster being linked to only one UDR. It is to the interfaces between the FEs and the other core network entities to ensure the right routing of requests for a given user to the right FE cluster. Such routing is ensured by MAP or Diameter (e.g. Diameter proxies).
for some other application FEs, it may be somewhat different. In the example of the ANDSF covered by TS 23.335, a given ANDSF server may be contacted for any user of the network (to be checked), in that case according to the user, the ANDSF server should send a Ud request to the right UDR. Two sub-cases may be considered about the ANDSF-FEs:
the ANDSF supports several functional ANDSF-FEs each being connected by a Ud interface (e.g. a LDAP TCP-IP connection) to a given UDR. Then, the ANDSF has to find how to select the right Ud interface.
the FE concept is extended (extended FE) to support several Ud interfaces towards different UDRs. There is the same routing question on how to find the right UDR.
For full multivendor interoperability between FEs and UDR either a standardized Reference Data Model (common to all FEs and UDR) is required (see TR 29.935), or the UDR needs to support multiple proprietary data models (all data models that are used by the different FEs). As long as these options are not available, networks that deploy FEs from different vendors (using different vendor specific proprietary data models) may want to deploy multiple UDRs, one from each of the vendors. Vendor x FEs are connected to the vendor x UDR, vendor y FEs are connected to the vendor y UDR. The resulting architecture is the same as the one described in 5.1.2, but it is justified due to missing of a common data model rather than due to the very large amount of users.
In this case, where there are many different applications each with their user data, the UDC logic would be to group all these user data into only one logical repository (UDR). An operator may want to avoid to group all these user data in a unique database, but nevertheless to use the UDC concept and to have one UDR grouping the user data of a set of applications and another one grouping user data of another set of applications etc.
Various reasons may drive an operator to deploy multiple UDRs, an UDR addressing a certain set of user data for a certain set of applications. Currently each application is storing its user data in a dedicated database (the "silo" view); the integration of all these user data into one UDR is a target and will probably be progressive. Intermediate steps may appear where there may still be separate logical repositories, each with its own Ud accesses, so appearing as multiple functional UDRs. Some pragmatism may be observed in the transition towards the UDC architecture. So it appears relevant to not only consider the target UDC architecture with one unique UDR storing all user data, but to analyse how the UDC architecture with Ud reference points may also apply when multiple UDRs, each storing the user data for a certain set of applications, are introduced.
In principle, for a given application FE, it would only see the UDR supporting its user data, so it complies to TS 23.335 statement that "UDR is unique from Application Front End's perspective".
What can appear is that a given application has its own user data stored in a UDR and may need to access user data associated to another application (eg some HSS user data).
In this context, should such an application present two application FEs, one with a Ud interface to the first UDR, the other connected to the other UDR? The choice to use one of the functional FEs is based on the requested data, so it should not be an issue.
On the UDR side, the same user will have user data in one UDR attached to a first set of applications and other user data in other UDR(s) for other set(s) of applications. It clearly has an impact on the provisioning side as two or more UDRs may have to be provisioned for the same user.
The other point is about data that would be common to applications in the first UDR and applications in another UDR. This situation should be avoided, as it implies a synchronized management of this data.
In this solution, a network element having to access multiple UDRs through the Ud interface have a local way to define to which UDR belongs a user (e.g. through ranges numbering).
This solution can apply if this network element supports several application FEs each connected to a UDR, or with an extended FE supporting several Ud interfaces.
This solution requires to configure all network elements in the network acting according to the case 2). It is a solution less powerful than the one classically achieved with MAP or Diameter routing.
A second solution is based on a central server (a bit similar to a SLF) that is able to return the UDR identity that is storing user data of a given user to the requesting network element. Then the requesting network element will use the relevant Ud interface towards the selected UDR.
The Ud interfaces towards the different UDRs may be already established and permanently maintained, so to optimise the performances.
This solution introduces a new functional entity in the UDC architecture.
A candidate interface to this central server could be a Ud interface.
This solution would be based on a proxy approach (somewhat like with a Diameter proxy). Here the network element through its Application FE always uses the same Ud interface towards an entity that will support a proxy function able to route the requests towards the right UDR.
This entity having this proxy function will appear as a UDR ("a functional entity that acts as a single logical repository" as defined in TS 23.335) for the Application FE. Then 2 approaches are identified:
the multiple UDRs of the 5.1.2 sub-clause are grouped into a "super UDR" that itself complies to the functional content of a UDR. And as UDC architecture does not address the internal functional structure of a UDR for which many possibilities may exist, this aggregation of UDRs into one UDR is out of the scope of the UDC architecture.
UDC architecture evolves to consider such several UDRs driving to specify the proxy function and the interface between the proxy function and the various UDRs, keeping in mind that for the application FE, the Ud interface should keep its functional content. The introduction of a proxy may also alter the access performances to user data.
The hereafter analysis also applies to the case of multiple UDRs with no common data model.
In the subclause 5.1.2, it was indicated the option to extend the FE concept to support several Ud interfaces towards different UDRs. No strong arguments have been delivered for this new FE concept compared to several FEs, each handling a Ud interface towards a given UDR. The solution with several FEs is compliant with the existing definition of a FE and does not require additional standardization, whereas the concept of a FE accessing multiple UDRs requires additional standardization.
So it is currently recommended to build solutions with multiple UDRs for very large networks on the basis of the current FE definition in TS 23.335.
Regarding routing and the 3 solutions described in subclause 5.2.1, solution 1 presents a disadvantage as it requires to populate (and update over time) the routing information to find the right UDR according to the fetched user in each network element accessing multiple UDRs. So solution 2or 3 are preferred. Further investigation on the comparison of solutions 2 and 3 should be made.
Both solution 2 and 3 may rely on the standardized Ud interface, so not strictly requiring additional standardization.
Although it is not recommended to build solutions where user data of a single user are spread over multiple UDRs since this contravenes the general concept of user data convergence, intermediate steps may appear where there are separate logical repositories, each with its own Ud accesses and each storing the user data for a different set of applications, so appearing as multiple functional UDRs. For such cases, it is possible to built solutions with multiple UDRs, when many applications, on the basis of the current FE definition in TS 23.335, so avoiding to introduce the concept of an extended FE connected to several UDRs.
The main use case for bulk data operations is the provisioning from the OSS. TS 32.181 states: "The Provisioning Gateway provides a single logical point for consistent provisioning of user data for all services in the UDR. The mechanism used by the Provisioning Gateway to access UDR data using the CDM is outside the scope of the present document". So Ud is not retained as an interface to handle provisioning from the OSS. 3GPP TS 32.61x series specifies bulk operations in OAM environment. So, it should be to SA5 to assess the use of bulk operations with OSS when related to UDR.
In TS 23.335, provisioning FEs are described in subclause 4.2.2 and address the following use cases:
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 Ut interface) and that will control the validity of user requests before storing the data in the UDC.
In these use cases, provisioning actions that provisioning FEs have to execute are not correlated and are triggered on a per user basis. They are not justifying to use bulk data operations.