IMS Service Routing: Service Profile

In the previous post, I showed that, in a typical end-to-end SIP interaction between two IMS clients, there is a succession of routing phases. Two of them (phases 2 and 5) make use of an IMS-specific mechanism, which does not exist as a standard in any other SIP network: service profile -based SIP routing.

In this post I will describe what an IMS service profile is. In the next one, I will detail how a service profile is used in the interactions between the IMS core network and the IMS application layer.

Service Profiles in Short

IMS service profiles can be seen as SIP routing information stored in a network database called the Home Subscriber Server (HSS).

This SIP routing information can be associated to the two types of public identities that exist in the IMS: IMPUs (for users) and PSIs (for services and service-related resources). An IMS service profile therefore influences the routing of SIP requests that are either originated or addressed to a particular IMPU or PSI.

The IMS core network entity that utilizes service profiles for SIP routing is the S-CSCF, which retrieves them from the HSS over the Cx (Diameter-based) reference point. A service profile is transferred over Cx in a standardized XML format.

A service profile is composed of a list of initial filter criterias (iFC), which are processed one after the other by the S-CSCF. An iFC essentially consists of a condition to be met by the SIP request and the address of an application server the SIP request should be routed in that case.

The processing of a service profile by the S-CSCF may lead to the routing of a SIP request to several application servers over the IMS Service Control (ISC) reference point. If no application server decides to serve as an endpoint to the SIP request, the S-CSCF then proceeds with normal SIP routing procedures (i.e. phase 3 or phase 6).

Service Profile in 3GPP Specifications

While this post provides a description of IMS service profiles, nothing can replace a direct access to the sources.

Section 5.2 in TS 23.218 provides a quick overview of the service profile, as well as the associated procedures for the S-CSCF.

However, the best information can be found in the annexes of TS 29.228, which specifies the Cx reference point:

Annex B provides a UML model for the HSS user profile, which essentially consists of the service profile. The figures in this post are taken from this annex.

Annex C describes the conjunctive and disjunctive normal forms that can be used to define initial filter criterias. This is also the place where you can find an XML sample of a service profile.

Annex D provides the specification of the XML schema used to transfer the service profile over Cx.

Service Profiles in More Details

The figure at the top of this post (click to enlarge) shows that a service profile is associated to possibly several IMPUs or PSIs. In the case of IMPUs, they are part of the same IMS subscription (i.e. they correspond to the same subscriber, typically a user in a mobile context).

Core Network Service Authorization identifies a policy (through an integer) which is supposed to be used by the S-CSCF to decide which types of media are authorized inside a SIP session associated to the IMPU or PSI. In the latest version of the specification, Core Network Service Authorization also includes a list of communication service identifiers that are authorized for the IMPU/PSI. However, the recent decision to let the IETF specify the support of communication services in IMS may possibly lead to future changes to this part. As of now, most IMS implementations I know do not support Core Network Service Authorization yet.

The most important part of the service profile is the set of initial filter criterias that constitute it.

In order to optimize the provisioning and storage of service profiles, the concept of Shared iFC sets was introduced. These are sets of initial filter criterias that are shared among multiple subscribers. Instead of being integrally defined in the service profile, they are referenced through an integer. According to the specification, this integer points at iFC sets that are locally stored in the S-CSCF.

Initial Filter Criterias (iFCs)

An iFC is composed of the following elements.

A Priority, which is defined as an integer. The term might be misleading, as each iFC in a service profile must have a different priority, permitting the S-CSCF to process the iFCs in a deterministic order.

A Trigger Point, which consists of a set of criterias to be met by the SIP request to be routed to an AS. These criterias are defined as a set of Service Point Triggers (SPT) that are linked through logical boolean operators (AND, OR, NOT).

The SIP URI of an Application Server, to which the request should be routed if the Trigger Point is true.

A Default Handling element, which indicates what the S-CSCF should do in case the AS does not respond (continue with processing or reject the SIP request).

An optional Service Information element, which is a string provisionned in the service profile, that the S-CSCF should place in the body of the SIP request before it is sent to the AS (the AS is supposed to know what to do with it). Originally, it was assumed that a Service Information element could be added in every SIP request that the S-CSCF would forward (proxy) to an AS. This could have been interesting, for instance, to provide a kind of identification of the iFC that led to the forwarding (based on this ID, the AS could determine what services need to be executed). However, it soon appeared that tempering with the body of a SIP request is incompatible with the behavior of a SIP proxy. The possibility to use Service Information is therefore limited to the only SIP request issued to an AS that does not result from a proxy behavior: REGISTER (see next post). Consequently, the usage of Service Information should remain very limited in the future.

Trigger Point & Service Point Trigger

A Trigger Point consists of a set of Service Point Triggers, that are linked through boolean operators: AND, OR, NOT.

The characteristics of a SIP request that SPTs permit to check are as follows.

The Session Case permits to define if the request was originated by the public identity while it was registered, if it was originated by the public identity while it was not registered, if it terminated to the public identity while it was registered, or if it terminated to the public identity while it was not registered.

Originating cases correspond to the phase 2 described in the previous post, while terminating cases correspond to the phase 5.

The terminating unregistered case corresponds to the situation where a request is addressed to a public identity while no IMS client is currently reachable with this identity. The request may then be routed to an application server that supports service logic that handles this situation (e.g. call forwarding, message store). Alternatively, though addressed to an IMPU, the request may not be targeted at an IMS client, but to an IMS application server hosting logic for this IMPU, and which should always be reachable. This is for instance the case for presence (presence requests are addressed to an IMPU but should reach a presence server) or for the automatic service discovery and configuration example I gave in a past post.

The originating unregistered case corresponds to the situation where an application server issues a request on behalf of an IMPU that is not currently registered with IMS. For instance, the service logic sends an instant message on behalf of a user, even if this user is not currently registered. This case is also required for Voice Call Continuity (VCC).

The SIP Method element permits to check if the SIP request is an INVITE, a SUBSCRIBE, a MESSAGE, a PUBLISH or... any method that may be created in the future (the type is a string, not an enumeration).

The Request-URI element permits to check the URI the SIP request is addressed to. This is typically used for iFCs that relate to private or restricted access to a PSI (the request-URI is the PSI).

The SIP Header element permits to check if a particular header exists in the SIP request, as well as the content of this header. It is possible to use a wildcard in the value of the content. Note that once again, there is no pre-conception about the header, which can be any standard, non-standard or future standard header.

Finally, the Session Description element permits to check the Session Description Prototocol (SDP) body that may be attached to the SIP request it it is an INVITE. The SDP permits to describe the details of the content of a session (e.g. media, application, codec).

With these elements, it is possible to determine the routing to an IMS application server of any existing and future SIP message, based on any combination of criteria met by this SIP request.

In addition, a specific element, Registration Type, permits to inform the S-CSCF that it should notify an AS of one or several IMS registration events associated to an IMPU: initial registration, de-registration and re-registration (renewal of a registration before the registration timer expires).

An Example

John has a service profile associated to the sip:John@operator IMPU whose translation in plain English is:

(Priority 10): every registered originating INVITE for a voice session should be routed to sip:vcc_server@operator

(Priority 20): every registered originating INVITE should be routed to sip:multimedia_session_control_orig@operator

(Priority 25): every terminating INVITE should be routed to sip:multimedia_session_control_term@operator

(Priority 30): every terminating INVITE for voice should be routed to sip:vcc_server@operator

(Priority 32): every originating MESSAGE to request-URI sip:My_Family@operator should be routed to sip:message_exploder@operator

(Priority 40): every originating INVITE to request-URI sip:My_Family@operator should be routed to sip:multimedia_conference_server@operator

(Priority 50): every terminating SUBSCRIBE with a header called "event" whose value is "presence" should be routed to sip:presence_server@operator

(Priority 60): every originating PUBLISH or SUBSCRIBE to Request-URI sip:John@operator with a header called "event" whose value is "presence" should be routed to sip:presence_server@operator

The overall sequencing permits to prioritize the processing of some requests (e.g. session set up) over others (e.g. presence requests).

There are cases where the iFCs are mutually exclusive (e.g. 10 and 25, 30 and 32). It does not really matter if one is processed before the other.

There are cases where several iFCs may be true for the same SIP request. It is very important to define a coherent sequencing between them. For instance, if John issues an INVITE for a voice session addressed to a user group representing his family, it is important that the following order is respected: voice call continuity server (in case there is the need to switch the call between IMS and circuit-switched), multimedia call features server for originating calls (e.g. call blocking), and then a conferencing server that will start a multiparty call between John and all the members of the family group. In a typical case, the INVITE will chain the VCC server, the multimedia call features server and the conferencing server together. It will terminate at the conferencing server which serves as a bridge between all the participants in the conference, including John.

iFCs 10 and 20 hint at the possibility to indicate the direction of the request (originating, terminating) in the SIP URI identifying the IMS application server (an alternative would be to add a parameter in the URI). The two SIP URIs may point at the same AS, but permit the AS to determine the direction of the request and may help it determine which services should be invoked.

iFCs 32 and 40 show that a service profile may combine a Request-URI (the usual information used to route a SIP request) with othercharacteristics of the SIP message to decide on its routing.

iFCs 50 and 60 could be combined into a single iFC.

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