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

IMS Service Features

The Automatic Service Discovery and Configuration example permits to highlight some of the key features of an IMS-based application layer.

Many of these features directly relate to what I consider to be the fundamental trait of the IMS service architecture: its user orientation.

The power of SIP

The example permitted to exhibit two important features of the SIP protocol, that I have already presented:

- SIP event packages can be used to distribute information and event notifications in a SIP network.

- Content Indirection is a privileged way to combine SIP and other protocols for e.g., redirecting a user to a web page (a service portal in the example), or retrieving large volume data (e.g. the content of the service registry).

User-based Service Routing

The SIP request that permits John to retrieve information from his service registry is routed to the right destination thanks to the following criteria: the request originated from John, it is addressed to John, and it happens to be a SIP SUBSCRIBE for a specific event package. Would one of these criteria be missing, the request would be routed elsewhere.

Similarly, the request that permits John to retrieve configuration information for service X is routed to the right server because it was originated from John, it is addressed to service X, and this is a SIP SUBSCRIBE for a specific event package.

Concerning Mary's request to access John's service profile, the routing is based on the fact that the request is addressed to John and does not originate from him. The fact that it originates from Mary, and that Mary is a special being for John may also impact the routing and make the request reach the right destination.

Finally, Mary is unable to access service X in spite of generating an adequate request addressed to the service. This is because the request originates from her, and her service profile does not include the right service routing information.

User-centric Service Architecture

Because John and Mary have a different service profile, the same SIP request issued by each of them can be routed to a different server. For instance, the SIP SUBSCRIBE permitting John to access Service X is routed according to John's service profile, while the same SIP SUBSCRIBE permitting Mary to access Service X (in case she is also subscribed to it) can be routed to a different server because it depends on Mary's service profile.

This mechanism, which permits the same service to be located in different application servers for different users permits:

- Service scalability to infinity. If you reach the vertical scalability of an application server, just deploy another one and populate service profiles for new subscribers with the address of the new server.

- The support of service variants for different market segments. For instance, simple or more sophisticated presence depending on the subscription.

- Multi-vendorship for a given service implementation, which is difficult to achieve in pre-IMS telco networks (e.g. MMS).

Implicit Addressing for Some Personal Services

In the example, the service registry is a personal service to John. The way for John to access the service registry is to issue a SIP request that is addressed to himself, and not to a specific location. The IMS service architecture, and more especially service routing based on John's service profile stored in the HSS does the trick.

A consequence of this approach is that John's client does not need to be provisioned with the location of the service registry to access its content. John's client can simply use one of John's Public Identities the client has been registered to IMS with.

Similarly, the application server hosting service X benefits from this implicit addressing, as it just has to generate a SIP request addressed to a user identity that has just been provisioned in order to publicize its availability to John.

Single User Identity / Multiple Services

The example shows that Mary can try to access John's service registry through the usage of one of his Public Identities. The same identity could be used to start a voice call with John, to initiate a gaming session, to send an IM to him, or to retrieve his presence.

Virtual Service Location

In the example, John, Mary or service X either use John's Public Identity or a Public Service Identity to access a specific service located on a specific server. The mapping between the identity and the actual location of the service is based on a service profile stored in an HSS.

Any change to the service profile may change the location, without any impact on the underlying addressing mechanism. It is therefore possible to change the location of a service over time, without impacting the way to access it. An example is when you want to switch to a new service implementation.

Network-based Service Authorization

In the example, routing of a service request to John's service registry and to Service X requires the existence of specific service routing information (Initial Filter Criteria) in the service profile associated to John.

This permits to directly link service authorization to SIP routing mechanisms in the IMS service architecture.

The example also showed that a service request that is not routed to the application server where the service is hosted can still be routed to alternative destinations, which may provide an appropriate response to the unauthorized service request. For instance, the alternate server can explain why the request was rejected, provide a limited trial version of the service, a pay per usage option, or simply propose the user to subscribe to the service and redirect it to a subscription web page.

Personalized and Shared Service Access

When John accesses Service X through his service profile, this access is personalized for John and points at an instance of Service X that can be highly customized according to John's preferences.

When Mary tries to access the same service using the same SIP request, this request is routed to a server according to service routing mechanisms associated to the service itself and not to Mary (as she is not subscribed to Service X). This access to Service X is shared with all other users that are not subscribed to Service X...

...Or at least a subset of them. The operator may actually route shared service requests to different application servers depending on the originator of the request. For instance, by checking the domain of the originator, the operator may define in Service X's service profile different service routing mechanisms for non-subscribed users that 1) are subscribers of this operator and may add this service to their service registry, 2) foreign users who are IMS subscribers of another operator, 3) service requests coming from the open Internet.

Integration of non-IMS services with IMS

In the example, the IMS-based automatic service discovery and configuration framework is applicable to both IMS and non-IMS services. This is, SIP and the IMS service architecture are used to get information about services, but the services themselves do not need to be accessed through SIP and the IMS service architecture.

This shows that IMS should be seen as a service framework, which does not necessarily require services to be implemented specifically for it. Non-IMS services can be integrated in this framework and benefit from its capabilities, without any impact on their implementation. Other examples of such integration will be presented in the future.

Service Anthropomorphism

Anthropomorphism: Attribution of human motivation, characteristics, or behavior to inanimate objects, animals, or natural phenomena

IMS service anthropomorphism is the ability for a service to act or be treated as an IMS user. I will come back on this concept, but here it can be seen that Service X publishes its availability by issuing a SIP request which could also be generated by one of John's client. Service X can either use its own public identity or impersonate John for this. Service X therefore has its own motivation and acts as if it was another IMS user.

Christophe

IMS Service Logic Distribution

The IMS service architecture can support an extreme distribution of service logic, which generates very interesting opportunities, but also new service design challenges.

In this post I will explore different distribution possibilities.

Intelligence in Endpoints or in the Network?

I think the long-standing debate whether it is better to locate intelligence in endpoints or in the network is a sterile one. My opinion is that it depends on the services, and I see no harm in locating intelligence everywhere it is possible.

The IETF initially defined SIP as a protocol permitting to implement intelligent endpoints (devices or servers) making use of a relatively simple network. Over time, SIP extensions related to, e.g. presence, resource list management and usage, or instant messaging, tended to add more and more intelligence in the SIP network in order to better support the endpoints. IMS defines a service architecture which permits to optimally add intelligence in the network, without removing it from endpoints.

Consequently, IMS services may either be essentially or totally implemented in (IMS and Internet) endpoints, essentially or totally implemented in the network, or have their logic more or less evenly distributed between endpoints and the network.

IMS is therefore an intelligent network for intelligent endpoints.

Personal and Shared Services

Though this distinction might sometimes be arbitrary, one can say that IMS supports two types of services:
- Personal services, which serve a specific user, and may be strongly cutomized, e.g. presence, session management services, personal messaging archives;
- Shared services, which serve multiple users at the same time, e.g. chat rooms, conferencing.

When John accesses a shared service, both John's personal services and the shared service may be executed. For instance, if John issues a post to a chat room dedicated to IMS, John's personal services may archive the message, and may check if the IMS chat room has not been put in one of John's blacklists. The IMS chat room itself may have its own "personal" services, like anti-spam, anti-virus and an archive for the chat room.

In this use case, John's client and the IMS chat room are the peers for the service interaction (see use case #2 in previous post). Additionally, John's and the IMS chat room's personal services are of the types a or b, c, e, g, i or j, k or l, and m or n in the classification described in this post.

End-to-end Service Chaining

This past post described that it was possible to chain several network-based services on top of the IMS Service Control (ISC) interface.

In a bigger picture, several service chaining can succeed one to another in the process of an end-to-end service interaction, which can lead to a very rich and versatile user experience. Consider a multimedia conference between John, Paul and Mary. The end-to-end service experience may involve:
1) Service logic implemented in each of John, Paul and Mary's devices.
2) A chain of personal services for each user: John, Paul, and Mary.
3) The shared conference service.
4) A chain of "personal" services associated to the conference itself, like a logging service.

3) and 4) will define the part of the service experience that is common to the three participants, while 1) and 2) will permit each user to experience the service in a more personal and customized way.

SIP and non-SIP Service Logic

SIP permits a clear separation between SIP-related logic and logic related to other protocols used for the delivery of the service.

This is quite obvious for Content Indirection and SIP REFER, as the URI provided to the recipient of the SIP message for accessing a non-SIP logic can point at virtually any location.

More interesting, this is also the case for SIP sessions, both from a client and from a network server perspective.

In the network, this is already visible in the IMS standard architecture:
- CSCFs are pure SIP entities
- For media servers, there is a clear distinction between the MRFC (Media Resource Function Control), which deals with SIP, and the MRFP (Media Resource Function Processing), which supports the specific media in the session (e.g. voice).
- For voice gateways to the circuit-switched network, the same distinction applies between the MGCF (Media Gateway Control Function) and the MGCP (Media Gateway Control Processing).

This is also the case for SIP application servers, which can host SIP-related logic while complementary logic related to specific media or specific applications delivered in the session can be located elsewhere.

What is applicable to network entities is also applicable to SIP/IMS clients. Though not explicitly shown in 3GPP or TISPAN specifications, the client supporting SIP session control and the corresponding client(s) supporting media or application components do not have to be co-located. In theory, a SIP session established on a mobile handset could control a video content received on a PC.

However, this is not that simple. The condition for SIP logic and non-SIP logic to be remote one from the other is that the former can control the latter through an appropriate interface so that, e.g. a session content is delivered/consumed only when the corresponding SIP session is active. IMS specifications use the H.248 protocol for an MRFC to control an MRFP and an MGCF to control an MGCP, but other appropriate protocols may be used as well, such as web services or...SIP.

The possibility to clearly separate between SIP logic and non-SIP logic offers very interesting service opportunities. For instance, it may permit a non-SIP service to be integrated into IMS by adding SIP components to it, that may have no impact on the existing non-SIP logic. The approach may also allow a SIP component to be shared between multiple non-SIP components (e.g. a generic control logic implemented as SIP logic applies to an array of non-SIP logic).

Future posts will further investigate these possibilities.

Christophe