A Bulding Block Approach to Standardization

For decades, the telecommunications industry has standardized solutions from A to Z, with little if any reuse of existing specifications when creating new ones. The progressive migration from circuit switched to IP based services did not initially change this fact much: MMS or OMA IMPS (that I take as an example in this post) are typical examples of creating telco-specific standards based on a loose reuse of IETF ones (SMTP for MMS, HTTP for OMA IMPS).

This has changed with IMS, and more especially its SIP component. 3GPP and the IETF collaborate with each other, and needed extensions to the SIP protocol due to IMS requirements are under the control of the IETF.

By importing IETF specifications into telecom standards, 3GPP implicitly accepted the building block approach to specifications that is common place in the Internet domain. In this post I will try to describe this approach and its benefits.

Building block standardization of SIP

SIP is a textbook example of a building block approach to standardization. The people and groups in charge of specifying SIP constantly try to apply the following rules:
- Do not reinvent the wheel. Reuse and adapt existing specifications if they fulfill your requirements. Only create when needed.

- Make everything as generic as possible. Even if your requirements are very precise, try to make your solution generic enough to be reused for other requirements.

Here follow some examples of how this was applied to SIP standardization:

- SIP sessions make use of the Session Description Protocol (SDP), which was specified prior to SIP. In effect, it is possible to use SDP without SIP.

- SIP SUBSCRIBE and NOTIFY methods were initially created to support a very specific requirement, actually related to the telecom domain (the support of the telephony Automatic Call Back service with SIP). However, it was decided to make the concept a generic and extensible means to distribute event notifications in a SIP network through event packages (see the first draft for SUBSCRIBE/NOTIFY here). When a part of the IETF community decided to support presence through SIP, they simply had to reuse the event package specification and create two presence-specific event packages. While the requirement was initially very specific, it gave birth to a concept that is fundamental for SIP and constantly evolving through the creation of new event packages. It is actually remarkable that this is a telephony -related requirement that led to a SIP concept which opens the door to a large variety of non-telephony related applications of the protocol.

- In the Instant Messaging (IM) area, presence was initially no more than a single state, describing if a recipient could accept an IM. The IETF decision to support presence through the inclusion of an XML document in the body of SIP methods, and allowing extensions to the basic schema, permitted the definition of presence to be gradually extended to become a large set of information about users (or services), their communication means, terminals and applications.

- SIP PUBLISH was initially created specifically for a client to remotely update presence information. The first versions of the draft were tightly linked to the presence event package and made impossible the reuse of PUBLISH in different contexts (see the very first draft here). However, the IETF community rapidly ensured the possibility to reuse PUBLISH for all existing and future event packages. PUBLISH therefore contributed to the enrichment of SIP-based presence, but at the same time a requirement initially scoped to presence contributed to the enrichment of the whole SIP protocol.

- Instant Messaging through SIP was initially supported only through the creation of a new SIP method: MESSAGE. However, it rapidly emerged that this approach was far from optimal to support all potential requirements associated to instant messaging: the concept of chat, which embeds IMs in a specific dialog context, the need to potentially exchange large documents via IM (e.g. a video file) while SIP is a control protocol and not a transport one like HTTP, or the need to support potentially high IM traffic while a SIP infrastructure might not have been implemented with this purpose in mind. It took time and several tries for the IETF community to address these requirements, and the final decision was to reuse the concept of SIP session as well as another protocol to transport an IM within the session. As a protocol like HTTP was not optimal to support the requirements for this IM transport protocol, it was decided to specify a new one called MSRP. This decision makes the comparison between Jabber/XMPP and SIP to support IM very biased. Maybe Jabber/XMPP is a better protocol than SIP for IM. However, Jabber/XMPP was initially specified and optimized for it, making its extension for, say VoIP, far from straightforward. On the other hand, in a SIP context, IM can be perceived as one communication component among others in a multimedia session.

OMA IMPS vs. IETF Presence and IM

The vertical standardization mindset that still prevailed a few years ago in the telecom community can be illustrated with OMA IMPS (initially called Wireless Village), a mobile specification to support instant messaging, chat rooms and presence.

Instead of reusing IM and presence related protocols available in the Internet, the Wireless Village group decided to specify a client to server protocol and a server to server protocol that would be specific to the mobile telecom domain, just reusing HTTP as a semantic-less transport protocol for OMA IMPS commands.

The group also decided to define IM, chat rooms and presence as tightly coupled together from a protocol and an architecture perspective, and to tightly link presence information to the mobile context.

In order to support its requirements, the Wireless Village group had to define various kinds of user lists (or groups) serving different purposes. Instead of creating a generic user group concept, they decided that each group fulfilling a specific purpose was a distinct object. Consequently, each group object led to a set of specific commands in the protocol, for creating/deleting the group, adding/removing elements to it, etc. With such an approach, if you define, say 4 types of user groups and 6 management commands, you end up with 24 distinct commands in the protocol.

In comparison, to address similar objectives, the IETF decided to decouple various concerns.

While presence is a concept originated in an IM context, the IETF decoupled one from the other, permitting each to evolve independently, thus permitting presence to apply to a much broader scope than simply IM.

By reusing the SIP session concept for session-based IM, the IETF permitted both the implementation of IM-specific systems, and multimedia systems using IM as one component among others in a SIP session.

The approach to address user groups and associated management, specified in RFCs related to XCAP, followed this approach:

- A user group is a user group, no matter what it is used for. The same user group can serve different purposes, and the set of applications for user groups is not arbitrarily bounded.

- A user group is user data, and there might be other user data that require similar access and management. No need to specialize access and management methods to user groups.

Consequently, XCAP is an HTTP-based protocol defining a few data management methods. The data itself is specified in XML, and there exist specifications for these data being user groups. As one of the requirements associated to data management was to be able to notify a user about changes made to data, the IETF decided to use a SIP event package. In effect, the IETF specifications for user data management include the joint usage of XCAP and SIP.

Building block standardization approach in IMS

The building block mindset to specifications has spread to IMS and non IMS standardization into 3GPP.

For instance, despite a terminology which is heavily related to SIP sessions (e.g. CSCF - Call Session Control Function), the IMS core network can be seen as a SIP connectivity network able to route SIP signaling, whether it is session-related or not, within an IMS domain, across IMS domains, and between IMS and non-IMS SIP domains.

In this context, IMS Presence, Messaging, and Chat Rooms are implemented as independent applications on top of the IMS core network and that make use of it. Once again, the comparison with OMA IMPS is quite interesting:

- OMA IMPS specifications lead to an implementation based on a network of IMPS servers over the mobile IP network. An IMS implementation relies on deploying application servers on top of an IMS core network. The IMS core network directly supports some of the requirements that are supported vertically in the OMA IMPS specifications (and implementations), like user authentication or routing and interfacing between various operators' OMA IMPS networks.

- OMA IMPS specifications tightly link the concepts of IM, presence and user groups. On the other hand, IMS specifications treat each of them as independent enablers which can be used together or in different contexts.

- OMA IMPS specifications were totally under the control of the Wireless Village group, and then OMA. On the other hand, by reusing IETF specifications, IMS specifications directly benefit from the evolutions performed in the IETF community, including some originating from people and companies which do not belong in the telecom or IMS domains.

A quite similar comparison can be applied to MMS and the equivalent support through IMS messaging.

Another interesting example is the 3GPP Generic User Profile specification, which permits to provide a centralized and homogeneous access to user data actually residing in various locations (e.g. HLR, HSS, AuC, application servers) and normally accessed through a variety of protocols (e.g. MAP, Diameter, LDAP). At the beginning of the erratic standardization process for GUP, 3GPP intended to standrdize a specific GUP protocol as well as a specific GUP schema to describe user data. Later on, it was decided to align on the specifications for Liberty Alliance, which define web services permitting 3rd party service providers to access user data owned by the network operator. As a consequence, GUP can be used directly as the means to access user data in network databases to support the Liberty Alliance web services exposed to 3rd parties.

The GUP specifications were also made generic enough to clearly distinguish between the methods used to access and manage user data and the data itself, that needs to be specified by instantiating and extending the generic GUP schema. On the other hand, the GUP specifications also include a SOAP-based user data modification notification mechanism, which duplicates what SIP event packages can and do support for XCAP. However, one can argue that the usage scope of GUP is broader than IMS and cannot rely on a protocol that 3GPP only uses in the context of IMS.

Some advantages associated to building block standardization

Reusing existing specifications instead of defining them from scratch permits to speed up the standardization process.

A protocol component or an application performing a generic task can be implemented once and reused several times, leading to faster development and validation.

In some cases, building blocks can be re-arranged with others to create new solutions. I gave the example of session-based messaging which, by applying the concept of SIP session to instant messaging, permits to integrate IM as one component among others in a multimedia SIP session.

Christophe

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