1. Introduction:
In the IP Multimedia Subsystem, data pertaining to the subscriber is managed by different network entities. Network entities maintain role-specific data. This means that the data maintained at the network element satisfies the use cases of that network element only and helps in its proper functioning.
These network entities belong to different telecom planes in the context of network deployment. Some of these entities belong to the signaling plane, some belong to the OSS/BSS plane, others may belong to the services plane and some may be part of the policy/QoS plane.
Therefore, the nature of the data maintained at each telecom tier is specific to the functions it has to perform. There may or may not be a logical/functional linkage between the data fragments belonging to these diverse planes.
However, there are instances where this diverse data has cohesions with respect to each other and there is room for optimized data storage.
Sometimes, it becomes necessary to synchronize the data maintained at different planes. This is usually observed during certain provisioning scenarios.
In order to meet these challenges, and to improve data management and promote optimized storage of data, 3GPP has proposed two central concepts of data management:
1. The 3GPP Generic User Profile (GuP), which represents a uniform and generic data representation paradigm for the IMS subscriber’s data.
2. User Data Convergence (UDC), which presents an alternative architecture for optimized data storage for IMS network elements keeping in mind the challenges of scalability and redundancy.
This post aims to harmonize these two central concepts to present a unified strategy for IMS data management exploiting the benefits of both these concepts (GuP and UDC).
In addition to subscriber-specific data management, this post also explores possible solutions for maintaining IMS network element specific data by using the concepts of GuP and UDC.
2. Types of User Data in a (telecom) IMS network
The nature of data stored in an IMS network, or in any telecom network can be broadly divided in the following categories:
a. Subscriber specific user profile data
b. Device specific data
c. Service specific data
d. QoS and Policy specific data
e. Charging specific data
f. Provisioning and OSS specific data
g. Access-network specific data
h. IMS network element specific data.
There may me more categories and sub-categories in addition to those defined above. However, these are the “major” data types that are encountered during practical deployment.
The first six categories (a-f) pertain to the data maintained for the customer.
The last two categories (g-h) are maintained at the individual IMS network elements. This type of data may be regarded as internal configuration data that enables the proper functioning of the network element. This data may also be stored in north-bound management entities (EMS and NMS systems).
Conceptually speaking, the figure shown below summarizes the scope for this post and demarcates the nature of the IMS data that needs to be maintained in a real network:
3. Current Data management situation across telco planes:
Data management in the IP Multimedia Subsystem (IMS) is distributed amongst network elements.
– When the subscriber is provisioned in an IMS network for the first time, a subscriber user profile is created in the HSS. This data is maintained in the HSS for as long as the subscriber is part of the IMS network.
– If the subscriber opts for certain value added services, data pertaining to such services is maintained in the individual application servers that host the VASs. Some IMS networks also have a Service Delivery Platform (SDP) deployment that is a logical aggregate of SIP application servers. Hence, the data relating to services opted by the subscriber is maintained at the services tier.
– Each subscriber has to be charged and billed for his services based on the tariff plans opted by the subscriber. Charging specific data and the tariff plan related information is maintained at the charging system. The charging system caters to both post-paid (CDF) customers and pre-paid (OCS) customers. This charging profile is used for creating Charging Detail Records (CDRs) when the subscriber consumes his/her services in the IMS network. These CDRs are fed to the billing system (BSS) for the generation of itemized bills.
– As the IMS core network is access independent, an IMS subscriber may own multiple devices that use different access networks to connect to the core network and its services. A subscriber may use Mobile WiMAX to access his data services and video share services. The subscriber may use a mobile handset (HSPA enabled) to access his Presence and presence-enabled services. A set top box may be used for accessing IPTV and triple play services and so on.
Access network based information is stored at the PCRF, HSS and Session Border Controllers (SBCs).
The IMS core network has to store certain information pertaining to these diverse access networks for the following reasons:
a. For providing proper Quality of Service based on the access network being used. Eg: HSPA and Fixed broadband customers shall enjoy GOLD class QoS. However, GPRS and WLAN based customers will be entitled to SILVER class QoS due to the inherent limitations of these networks.
b. For applying access network based policies at the network elements. Eg: If the access network of the customer is Fixed broadband, then the S-CSCF needs to forward all requests unconditionally to an IPTV Application Server.
c. For applying the appropriate charging strategy based on the access network in use. Eg: IPTV based Video on Demand can be charged based on the volume of data downloaded. However, Presence based services may be charged on a monthly basis.
– Device profiles of IMS User Equipment can be stored in an OMA compliant Device Management server. This server can also be used for OTA updates and provisioning actions. Specialized device information such as the contact book, buddy lists and personal network management information can be stored in their respective application servers over the Ut interface.
– OSS information pertaining to the subscriber has to be maintained at provisioning platforms, such as those defined by the NGoSS body. A subscriber may have logged many active requests and queries to the OSS system. These requests are executed by business processes modelled by using BPM (Business Process Management) tools and they frequently require offline action by the carrier. In the meanwhile, the business process related data has to be maintained at the OSS platform until the requests are closed by the operator and the requests are resolved.
In addition to this data, there are special data types that are consumed by the IMS core network for its internal functioning. Some examples of this data are given below:
a. CSCF internal configuration data (static and runtime)
b. CDRs (at the CDF to be pushed to the BSS)
c. FCAPS data (at the SNMP agent of the NE)
d. Persistent storage data of the CSCFs/HSS (for IMS restoration and HA)
e. Media files of the MRF (announcements, tones etc)
f. EMS/NMS configuration data. (topology graphs, NE information)
g. OSS Data (customer care requests, eTOM module related data)
The following table provides a bird eye’s view on which network entity maintains which data type:
4. The concept of the UDC architecture
4.1 Concepts:
User Data Convergence (UDC) aims to address the siloed approach of data management across telco planes and network entities. In the current data management scenario, data is managed individually by network elements in their own closed repositories. This approach of data management gives rise to rigid data silos.
When scaling the network, the number of network elements also increase. This leads to further fragmentation of user data amongst multiple instances of the same logical application.
Eg: For supporting 3 million BHCA, if we deploy 3 HSS instances in the same domain, then effectively user data of that domain is being maintained at three separate locations, even though the data access function (HSS) is the same logical application.
This siloed approach is logically represented as shown in the figure below:
With the advent of IMS and IMS based services, data management at several places poses a major operational and maintenance issue. Introduction of new user data becomes an issue, as any new user data attribute needs to be reflected at multiple locations. Moreover, data synchronization across multiple locations becomes a major challenge.
4.2 UDC Deliverables:
Therefore, UDC aims to provide the following deliverables:
a. To simplify overall network topology and interfaces
b. To overcome the data capacity bottleneck of a single entry point
c. Avoid data duplication and inconsistency
d. Avoid data fragmentation
e. Reduce CAPEX and OPEX for the carrier.
Therefore, UDC aims to provide convergence of user data in order to enable smoother management and deployment of new services and networks.
A logical view of UDC deliverables can be represented as shown in the figure below:
4.3 UDC Architecture:
This section will provide an introduction to the UDC architectural model and its major interfaces.
The architecture consists of the following major components:
a. Client applications.
Client applications may be IMS clients, XDM clients, SIP based application servers or PC browsers.
b. Application Front ends.
The application front ends are 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, application front ends 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.
There is a special Application front end for the UDR which is used as a provisioning application for it. It is called a Provisioning Front End. The Provisioning Front End is defined as an Application Front End for the purpose of provisioning the UDR. The Provisioning Front End provides means to create, delete, modify and retrieve user data.
c. 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.
Applications that are 3rd party or are outside the trusted domain of the IMS network can access the UDR after proper authentication and authorization procedures have been applied.
The diagram below shows this architecture:
The Ud reference allows different FEs to create, read, modify and delete user data stored in the UDR.
The Ud reference point also supports 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 etc. All these operations are ACID compliant (Atomicity, Consistency, Isolation, and Durability).
5. The concept of the GUP architecture:
Conceptually speaking, the GUP is a 3 tier architecture. It consists of client applications, the GUP server and the data repositories.
The key objective of having this architecture is to have a harmonized means of data access for a particular user. A user may have data relating to his services, charging policies, QoS metrics and HSS profile data, all of which is maintained separately by these entities. Each entity would also have its own unique semantics of data storage.
The GUP provides a common mechanism of data addressal, reference, access and modification to all applications that may need this data for their functioning. GUP data may be stored at one place, or it may be stored with different entities. However, the data access and manipulation semantics shall comply to the GUP architecture. This will allow uniformity with regard to the management of the subscriber’s data.
The suppliers and consumers of the data can be divided into the following groups of applications:
- Applications in the home network.
- 3rd Party Applications.
- OAM and subscription management applications.
The Generic User Profile architecture is composed of the following major components and interfaces:
a. GUP Server:
The GUP Server acts as a single point of access of subscriber data. The physical location of the GUP server is implementation dependant and the standard does not impose any special requirements. The GUP server acts as a single interface which is exposed to the client applications who wish to manipulate the subscriber data.
The GUP server can act in two modes, namely proxy mode and redirect mode. While operating in proxy mode, all requests made to the GUP server are proxied to the appropriate data repositories. The results of those queries are returned back to the application by the GUP Server.
While operating in redirect mode, the GUP server redirects the client application to the actual GUP repositories that contain the data which was requested initially by the client.
The interface between the client applications and the GUP server is the Rg reference point.
b. Repository Access Function (RAF):
The RAF behaves as an abstraction between the GUP server and the GUP data repositories. It hides the actual implementation of the data repository from the server. The interface between the GUP server and RAF is the Rp reference point.
c. GUP Data Repositories:
The data repositories store the master copy of one or more GUP data components.
d. Rg and Rp reference points:
These are the two major reference points in the GUP architecture. The clients share the Rg reference point with the GUP server. The protocol on this interface is SOAP (Simple Object Access Protocol) which is exposed as a web service to the clients.
The GUP server has the Rp reference point towards the RAF. This reference point is implementation dependant. However the standard shows a SOAP interface on this interface
The Rp reference point shall allow the GUP Server or applications, excluding external applications (e.g. located in a third party application or in the IMS UE), to create, read, modify and delete user profile data. Rp is an intra-operator reference point.
e. Client Applications:
These are the application servers and applications that need access to GUP data components. They may host some GUP data components themselves and may act as RAFs.
The physical architecture of the GUP arrangement is shown below:
6. Harmonizing UDC with the GUP architecture:
These two architectural options provided by 3GPP can be harmonized and used together to achieve a cohesive strategy for data management and access.
While UDC provides a common data management and access architecture, GUP provides a means of locating and addressing that data using a common strategy.
This section will provide a unified architecture that leverages upon the concepts of UDC and GUP to provide a unified data management strategy in an IMS network.
6.1 Unified architectural view (GuP+UDC):
A unified view of the integrated Generic User Profile architecture with the User Data convergence paradigm is shown below:
The unified architecture will consist of the following concepts:
a. The client applications
These are the applications which act as consumers of the data. The data being referred to in the unified architecture is the GUP data fragments. The GUP data is being stored in GUP repositories that form parts of the User Data repository (UDR).
b. The Rg reference point re-use for UDC:
For applications that wish to access the UDR over a proprietary interface (labelled as “other ref points” in the UDC standard) shall use the standardized Rg reference point that follows the SOAP/WSDL standard semantics over HTTP. Client applications such as Web 2.0 applications, OSS entities and self care portals can use the Rg reference point to access the UDR.
c. Partial standardization of the Rp reference point for intra operator entities:
The Rp reference point allows entities belong to the same home network to directly access the user data from the RAF. Therefore, SIP application servers will access the user data over the Sh interface from the HSS belonging in the same network. However, if it needs to modify data that is outside the scope of the Sh XML schema, it will need to send the request to the GUP server over SOAP giving instructions to execute one of the standard procedures over the Rg reference point (Create,Modify, Delete etc). These procedures will be mapped to their appropriate counterparts over the Rp reference point.
d. RAFs integrated with Application Front Ends (FEs):
Application front ends of the UDC architecture will behave as RAFs for their respective GUP components. These RAFs will support both standard interfaces (as described in point c) and SOAP based Rp interfaces.
e. GUP data repositories integrated with the UDR:
The UDR will now be composed of GUP data repositories. However, there may be instances where the data model of certain GUP components require a separate data repository. In such a case, the GUP repository will be outside the UDR. The location of this distributed GUP component will be resolved by the GUP server by locating the appropriate RAF component.
f. Ud interface between integrated RAF+FEs and UDR:
The Ud reference point will be re-used as an interface between the integrated RAF+FEs and the actual UDR (or independent GUP repository).
6.2 Case Study: HSS IMS GuP Components:
The following figure gives an outline of the UML model of the logical view of the HSS IMS GUP Components. The main Component is called HSSIMSData.
Each element in that figure represents a part of the XML Schema structure, either a GUP Component or a lower level block of data contained in a GUP Component. Elements marked with the same background colour make up an independently manageable GUP Component, whose root is marked with ‘<<GUP Component>>’.
All HSS IMS GUP Components can be managed with the procedures provided by GUP.
(Click on the image for a larger view)
7. User Data access scenarios:
Please refer to the unified architecture described in Section-6 for realizing these use cases.
7.1 Typical IMS use case:
In this use case, the S-CSCF requests data over DIAMETER protocol from the HSS to execute its duties during IMS registration. Here the Rp interface is nothing but the standard Cx interface.
7.2 OSS entity use case:
In this use case, the service activation eTOM of the OSS system activates the service of a particular subscriber by invoking an operation in the IMS HSS. Here the interface under use is the Rg interface over SOAP protocol.
7.3 SIP-Application server use case
In this use case, a SIP application server retrieves data from the HSS regarding the barring status of an IMS public user identity before executing its service logic along with the repository data stored in the HSS. The repository data is retrieved over the Rp interface, which is nothing but the Sh interface. However, the barring indication information is taken over the Rg interface.
7.4 IMS enablers use case:
A Click-to-Call application fetches the buddy list of a subscriber who has just logged into the server over the standard Rp interface that uses XCAP protocol towards the XDM server. The same application then subscribes to the presence status of each buddy present in the list over SIP protocol.
7.5 Web 2.0 use case:
A Web 2.0 application requests the subscriber’s presence information from the Presence Server and his/her photograph from a Flickr application repository. After the presence data has been fetched, this application retrieves the implicit IMPU set from the HSS. Then this application fetches the location of each of the registered public user identities.
All this information is then rendered on a Google Map application complete with presence status and a photograph thumbnail.
7.6 Self help portal use case:
The subscriber requests to subscribe to the voicemail service over a self help portal. On accepting the agreement, the Self help portal sends a trigger to the charging platform to deduct the amount suitable for this service and executes a create procedure towards the HSS to create an iFC component (The ServiceProfile <<GUPComponent>> defined in the standards). This operation takes place over the Rg interface.
8. Conclusion:
It is feasible to integrate and leverage upon the strengths of the User Data Convergence (UDC) architecture in cohesion with the Generic User Profile (GUP) semantics to derive a hybrid data management strategy.
However, the final reference architecture can be derived only when the concrete use cases to be supported are known.
A unified architecture will make data management and data access more intuitive and re-use the standardization principles wherever possible as demonstrated in Section-6.
