User Application Data: Opinions

After describing a panorama of the standards and technologies that can be used for user application data management and storage, here is a more subjective post.

User Data Distribution Can Be Managed!

Our industry has been struggling for years between two extremes:
- Distributing user data in application servers in order to optimize service delivery.
- Centralizing user data in order to simplify its management and ensure its integrity.

I think that with both the IMS service architecture and the Generic User Profile (GUP), we now have the tools to permit user data to reside where it is the most useful for service delivery, i.e. in the application servers hosting services.

As I tried to illustrate with the Automatic Service Discovery & Configuration example, and this is the same for presence, discovering the XCAP location of user data can be as easy as generating a SIP SUBSCRIBE addressed either to the identity of the user the data is associated to, or the identity of the service it applies to. The SIP/XCAP combo also permits to synchronize duplicates of user data with the master copy.

GUP is the exact equivalent in the web services sphere. GUP could be used to support centralized user data / subscription management, by hiding distribution details to the BSS system. See more below on GUP.

Exploiting Presence

Presence should be considered as one of the main sources of information related to the user, its devices and its applications.

This repository of user data will store both static and dynamic user-related data. This data will be populated/modified by the user, but also automatically by client and network based applications acting on behalf of the user, as well as network entities (e.g. IMS core, location server).

Presence data may be used by many applications, as an alternative to user application data specifically managed for them.

SIP and XCAP will be the natural protocols to access presence, according to 3GPP and IETF specifications.

Centralization for Common Application Data

User data that need to be shared between multiple applications can be stored in a centralized repository. Which one?

I do not like the idea of using the HSS as a user application data repository. Besides the potential impacts on HSS characteristics, another issue with this approach is that Diameter is not an optimal protocol for application data management. Moreover, the Sh reference point is very weak in terms of data management semantic, more especially compared to available alternatives. You have to realize that 3GPP specified the possibility to store application data in the HSS before GUP, XCAP, and CPS were defined.

I would like a centralized user repository to support SIP and XCAP in order to permit a smooth integration in the IMS service architecture. This means that the repository would be a SIP application server in the IMS architecture, and not a standalone XDMS as the OMA architecture seems to suggest.

This user repository could be based on the CPS architecture, which means that LDAP could also be an interface to it, and it would support GUP as well.

Therefore, overall, the user repository would be a SIP AS, using CPS as a backend data store, and supporting the GUP interface.

Generic User Profile & Liberty

I believe that Liberty and GUP would permit a strong integration of the future telecommunications network into a Service Oriented Architecture and into Web 2.0.

GUP is the optimal architecture and set of protocols to support Liberty in the operator's network.

I also think it should be used for subscription and user data management by the operator. Do you know that 3GPP specified the whole HSS data model using a GUP-compliant XML schema? This means that GUP could be imposed on suppliers right now as an open interface for HSS provisioning.

On the other hand, SIP/XCAP is a more lightweight approach to support access and management of user application data by IMS clients and IMS application servers.

It should be noted that at the moment the plans of most Network Equipment Providers to support GUP seem to be quite fuzzy, to say the least. There is therefore a risk that GUP remains a good idea on paper. At least as long as operators do not exert more pressure on their favorite vendors.

Common Profile Store to Break Silo Databases and for Coherent Data Modeling

In terms of actual database implementation, I think that the CPS approach is rolling and nothing will stop it. Some major suppliers have already embraced the concept and are offering HLRs and HSS's implemented on it. Others still resist, but will have to surrender sooner or later.

In the mid-term, all network databases (e.g. HLR, HSS, AAA) as well as some of the application servers will be implemented according to the CPS approach. All open service platforms (whether based on J2EE or JAIN SLEE) should integrate with a CPS.

Moreover, the CPS approach provides a unique opportunity to define a coherent model for user profile data across multiple network databases and application servers, while permitting application-specific extensions as required for a dynamic and differentiated service network.

Christophe

User Application Data: a Panorama

I tend to think that IMS and all-IP will make the telecommunications industry move from an era where the typical technical challenge was to design a specific solution for every problem to a new one where the main difficulty will be to select one solution among many candidates.

An illustration of this is user profile management and storage in the future application layer.

In this post I will try to make a panorama of standards and industry trends that may impact this topic in the years to come. In another one, I will express some personal opinions about the way to go.

User Profile Data in the HSS (Diameter, unspecified data format)

The Home Subscriber Server (called UPSF for fixed networks) is the database to store all the user data required by the IMS core network to fulfill its duties.

Additionally, the IMS service architecture has an interface between the HSS and the SIP Application Server called Sh.

This interface is based on Diameter and can be used by the application server for two purposes:

- Accessing user data normally stored in the HSS (or in the HLR), such as the user registration status, the S-CSCF that serves the user, or the service profile associated to the user.

- Storing application data in the HSS. This data is transparent to the HSS, i.e. it does not understand its format and semantic.

Sh supports a Diameter-based notification mechanism, permitting to alert the application server when data has been modified.

Most suppliers support the data repository feature of the HSS. It should be noted that the HSS is a mission critical database, which tends to constitute a major portion of the cost of an IMS core network. In this context, the application data repository feature of the HSS and associated questions (e.g. how much data will be stored in it? How much traffic will it generate?) raises questions about the required characteristics for the HSS and its eventual cost for an operator.

User Profile Data in SIP Application Servers (SIP/XCAP, XML)

In the IMS service architecture, there is a reference point called Ut between IMS clients and Application Servers that is used for service customization. This interface is based on XCAP, a simple HTTP based protocol specified in the IETF, which permits to access and manage data defined as XML documents.

The IMS service architecture therefore implies that a SIP application server can own the user data corresponding to the services it supports. This is a quite straightforward and optimized approach to co-locate user service data with the services that make use of them.

In the Automatic Service Discovery & Configuration example, I showed how a SIP event package (i.e. SUBSCRIBE, NOTIFY, PULBLISH) can be used by an IMS client to easily retrieve the XCAP location of user data associated to the user (SUBSCRIBE is addressed to one of the user's Public Identities) or to a specific service associated to the user (SUBSCRIBE is addressed to Public Service Identity). The XCAP URI can then be provided to the client in a NOTIFY. The event package also permits the client to monitor changes to the data (as in the IETF, a SIP event package is used to monitor changes in data manipulated using XCAP). These mechanisms can also be used within the network for an application server to retrieve user data in another application server.

XCAP Data Management Servers (XCAP, XML)

Based on XCAP, the Open Mobile Alliance (OMA) defined an architecture for user data management which consists of XCAP Data Management Servers (XDMS). You can see figures in this page from Tech-invite.

OMA decided to define a Shared XDMS storing common data between different services/enablers, as well as a specific XDMS for each of them (e.g. push to talk, presence, resource lists). Each of these XDMS is logically separated from the SIP application server supporting the corresponding service/enabler.

In practice, this ambiguous architecture is likely to lead to two implementation options:

1) The supplier decides to implement a network database called XDMS to store all XCAP data, i.e. OMA Shared XDMS and all the service/enabler -specific XDMS. This database is accessed through the XCAP protocol. A priori, it does not support any SIP event package, which may lead to synchronization problems with clients.

2) The supplier decides to combine each service/enabler specific XDMS in the SIP application server supporting the corresponding application. This approach is more in line with the 3GPP service architecture for which Ut (XCAP) and ISC (SIP) terminate to the same entity. It also corresponds to the user-profile-data-in-SIP-AS option above. It permits to support the SIP event package for monitoring of changes in the user data. The supplier may also decide to implement the Shared XDMS as a SIP AS.

Presence (SIP/XCAP, XML)

It might seem strange to list presence, a specific IMS service/enabler, as a potential data repository.

Actually, presence has considerably evolved since the early days when it only supported instant messaging and the IETF suggested to implement it as part of the basic SIP registrar function.

Through multiple extensions to its baseline XML schema, presence can now be considered as an extensive set of static and dynamic information about the user, its devices and its applications. In this context, presence can be seen as an essential repository of user data, that can be used as an enabler by many IMS applications.

In a network in which presence is a basic enabler associated to every user, some data currently considered as user application data, that the user manages service per service, may simply be part of the user's presence. To take a trivial example, presence may eventually make the explicit definition of forwarded-to-numbers for call management services totally irrelevant.

Presence is a specific example of the user-data-in-SIP-AS approach described above.

Generic User Profile (SOAP, XML)

GUP is a 3GPP standard, which is independent from IMS but that can optimally be used with it.

To make it short, GUP permits to define a virtual centralized user database, by enabling an homogeneous and centralized access to distributed user profile components, stored in network databases (e.g. HLR, HSS) and application servers.

The GUP location server is called GUP Server. A client application asks to access user data by providing the identity of the user (e.g. an IMS public identity) and the name of user profile components it wants to access. The GUP server either provides in return the address of the GUP data repository (e.g. an application server) or accesses the data on behalf of the application).

GUP interfaces are based on SOAP and the user data is defined according to a hierarchical XML schema (GUP does not specify the data itself). As GUP aims at supporting Liberty Alliance (set of web services towards 3rd party service providers) within the 3GPP network, GUP interfaces totally align with the Liberty Alliance Project specifications.

The GUP architecture can be compared to the user-data-in-SIP-AS approach in which:

- SOAP replaces SIP/XCAP to access and monitor changes in user data

- The GUP server and its location data plays the role the S-CSCF making use of service profiles endorses with SIP

More especially, the two approaches are able to dispatch a request based on the identity of a target user.

Common Profile Store (LDAP)

Every supplier or operator has its own name for this concept, but CPS is the term under which 3GPP has been addressing it.

CPS originates from a recent telecom industry trend which aims at changing the monolithic nature of network databases (e.g. HLR, HSS, AAA, application servers) into a multi-tiered IT architecture, in which the business logic of the database (e.g. Diameter features of HSS, MAP features from HLR) is physically separated from data storage. An LDAP server supporting telco-grade requirements (e.g. availability, capacity, performance) is shared between stateless business logic frontends implementing a variety of network entities.

CPS permits to optimize and rationalize the architecture of network databases. It also permits to reduce vendor locking achieved through monolithic network databases.

While it does not impose it, CPS also favors a more coherent modeling of user data across the various network databases and application servers, which permits to decrease operating costs and to foster new synergies.

In the context of IMS, CPS would permit to remove the need for a direct interface between the HSS and the HLR (required for Sh) by permitting user data sharing through access to the common backend.

Integration with open service platforms (e.g. J2EE, JAIN SLEE) would permit to use CPS for all applications implemented on these platforms.

So many possibilities... In the next post, I will provide personal opinions on them.

Christophe