User Data Convergence (UDC) is currently is being developed by the Third Generation Partnership Project (3GPP). The technical specification 3GPP TS 23.335 describes the technical realization of UDC, which separates the user data from the application logic of different network elements. A User Data Repository (UDR) provides a centralized database, which is accessed by different Application FEs.
FIG. 1 is a simplified block diagram of a generic UDC architecture 10. The user data is stored in the UDR 11. Application Front Ends (FEs) 12a-12c are data-less functional entities. The Application FEs retain the application logic of functional network entities such as a Home Location Register (HLR), Home Subscriber Server (HSS), Authentication Center (AUC), Application Server (AS), Provisioning system, and the like, but do not locally store user data permanently. The Application FEs may handle one or several applications simultaneously. The UDC architecture interfaces with a Core Network, Service Layer, and Operation and Support System (OSS) 13 via protocols 14 such as Diameter, Mobile Application Protocol (MAP), Session Initiation Protocol (SIP), or other suitable protocols. A requirement of the UDC implementation is to minimize the impact on the existing network.
FIG. 2 is a simplified block diagram of a UDC architecture in which the UDR 11 provides user data for a plurality of Application FEs implemented as HLR-FEs 21a-21c. The HRL-FEs, in turn, support a plurality of MSC/VLRs 22a-22e. As it is apparent, each Application FE is configured with an individual identifier usually known as “FrontEnd Identifier”, which is used to establish communications with other entities of the architecture. The interface 23 between the UDR and the HLR-FEs supports notifications functionality which allows the UDR to notify a relevant HLR-FE about specific events which may occur to specific user data in the UDR. The events may be changes to existing user data, addition of user data, and so on. The core network and service layer applications may explicitly subscribe to these notifications. For example, an AS (as an example of Application FE) may subscribe to receive changes to specific user data. Alternatively, the core network and service layer applications may implicitly subscribe to notifications according to the UDC concept. For example, a notification that a user is located and his location may be administratively cancelled.
It is assumed that any Application FE of a specific application type such as “HLR” is suitable for handling notifications towards any of the elements in the Core Network/Service Layer/OSS associated with that application type. Thus, in FIG. 2 it is assumed that the UDR 11 can notify any HLR-FE 21a-21c of a user data change, and the notified HLR-FE can notify any of the MSC/VLRs 22a-22e regardless of the conditions (e.g., the user's geographical location). Therefore, the UDR is not concerned about sending the notification to a specific HLR-FE.
Some operators with large networks, however, may utilize a routing hierarchy in which their overall network is divided into a number of area networks connected, for example, by Signaling Transfer Points (STPs). In this network configuration, an HLR-FE in a first area network might not have a “direct” signaling connection to an MSC/VLR in a second area network, but an “indirect” connection wherein the signaling is routed through one or more STPs. Also, given that meshing all-with-all the nodes in a communications network usually requires complex and expensive developments, it might happen than an HLR-FE might not have signaling connections with e.g. all the MSC/VLRs in other geographical location areas. Thus, for a data change affecting a particular MSC/VLR, the UDR must manage its HLR-FE selection so that the UDR does not select an HLR-FE that is not capable of reaching the affected MSC/VLR.
USPTO Backgrounds
USPTO Backgrounds