IMS Service Anthropomorphism

Anthropomorphism is the attribution of uniquely human characteristics and qualities to nonhuman beings, inanimate objects, or natural or supernatural phenomena (wikipedia).

The pictures taken from various cartoons by Tex Avery that you can see at the top of this post illustrate an anthropomorphic behavior associated to animals.

Service anthropomorphism is therefore the possibility for an IMS service to behave and be treated as a human user of the IMS network. This post describes how IMS supports service anthropomorphism and what an anthropomorphic service can do and benefit from.

Symetric usage of SIP between IMS users and IMS services

The IMS service architecture ensures that every SIP request that is generated or processed by an IMS client can also be generated or processed by an IMS application server.

For instance, if an IMS client can generate a SIP instant message, set up a SIP session, or subscribe to the presence of another user, an IMS application server can do it as well.

Conversely, if an IMS client can receive a SIP instant message, process a SIP session set up request or process a SUBSCRIBE to any SIP event package (e.g. presence), an IMS application server can also do as well.

An interesting consequence of this feature is that the concept of enabler (the possibility for a service to use a remote feature) is simple to implement in an IMS network, and can be extremely powerful.

In a traditional telecommunications architecture, some services offered to an end-user can also be used as an enabler by an application server. This is the case for network-based user location in a mobile network, which can accessed in a location server from both a device and an application server hosting location-based services. However, in most cases, the user to service interface and the service to service interface are different, and both need to be specified and implemented for the application to be used as both an end-user service and an enabler by other services. In IMS, as soon as a service is deployed in the network, for which a SIP based interface has been defined for access by IMS clients, the exact same interface can immediately be used by other IMS application servers to access the service as an enabler for their own services. In theory and when it makes sense from a service perspective, every new IMS service can become an enabler for other services, which themselves can become enablers for other services. There is therefore a high potential for an explosion of service opportunities each time a new IMS service is deployed in the network.

Another difference with a traditional telecommunications network is that, in such a network, a service enabler is always network-based. As devices are more or less stupid, every added-value logic that can serve other services is located on a server in the network. On the other hand, with IMS, every logic processing SIP requests can theoratically be located both in IMS clients and in IMS application servers. While complex logic (e.g. full-featured presence) will tend to be located in powerful IMS ASs, simpler logic can be located in the IMS client and be accessed by an AS through SIP. For instance, IMS clients can support SIP event packages (using SUBSCRIBE, NOTIFY, PUBLISH) that are able to inform and notify ASs about what is located or is happening in the IMS client: session states, information located in device, information or status about a specific device-based application like a game. This implies that, with IMS, the concept of enabler is extended from the network to the endpoints, and this offers potentially huge service opportunities.

Finally, in a traditional network a service and the enabler it accesses are most of the time located in the same operator's domain, as addressing, request routing and security issues are important barriers to overcome for inter-operator interfaces. In an IMS network, SIP routing procedures cross boundaries between networks with secured interfaces, and the addressing of SIP enablers is based on public identities like IMS Public User Identities (IMPUs) and Public Service Identities (PSIs). This implies that, technically, a presence based service from one operator can access the presence of a user subscribed with a different operator (or located in the Internet, but then with security risks).

In an IMS network, all SIP requests originate from a public identity (IMPU, PSI) and are addressed to a public identity (IMPU, PSI). How do IMS application servers fit in this picture?

Service impersonating a user

An IMS AS can process requests addressed to an IMPU of a user it serves, and can generate a SIP request on behalf of a user, by placing an IMPU as the originator of the request it (the AS) actually generates.

For instance, an AS hosting session control logic for a user can receive the INVITEs addressed to an IMPU of this user and serve it on its behalf (e.g. accept or reject the session). In another example, IMS presence requests are always addressed to an IMPU of the user from which the presence is sought. In theory, this request could and should be routed to one or several IMS clients associated to the user, but in practice they are all routed to a network-based AS serving presence requests on its behalf.

In yet another example, consider a service that decides on the best way to route messages issued by user A. Possible alternatives include IMS messaging to the same IMPU, IMS messaging to another IMPU, SMS, MMS, email, or an Internet IM service. When user A issues an IMS message to user B, this message is routed to the AS supporting the advanced routing function. This AS can then extract the IMPU of user B from the IM, and generate a presence request originated from user A and addressed to user B. This request will reach the presence server of user B, possibly in another network, which will apply authorization rules associated to user A and generate an appropriate response. This response may provide information to the service about the messaging alternatives available for user B, as well as the associated addresses, preferences, and reachability. It can therefore select the most appropriate approach to deliver the message to user B. In this use case, it is very important for the advanced routing service to endorse the identity of user A, because it acts on its behalf and must benefit from the exact same information as user A would.

This means that an IMS service can act as a network-based agent or proxy of a user (and here I do not mean "SIP User Agent" and "SIP Proxy").

Service acting as itself

A service can also receive requests addressed to a PSI that identifies itself, or generate a request using its own PSI as the originator.

This may permit a service to communicate with a user ("Hey, I am your voicemail") or to benefit from privileges associated to a service (e.g. when the service generates a presence request to a presence server located in the same domain, it has full access rights and top priority toward all users' presence information).

Group Management

Group management permits a user (or an operator) to regroup a set of URIs (SIP or others) into a set which is identified and addressable via a PSI. Such a group PSI can then be used in SIP requests, which then automatically become group requests through appropriate support in IMS application servers. For instance, an IM addressed to a group will be exploded to individual IMs sent to each member of the group, a presence request to a group will be decomposed into individual presence requests, and an INVITE to a group will automatically start a conference. Groups can also be utilized within application servers to define, e.g. black or white lists.

An IMPU and a PSI have the exact same formats (either a SIP URI or a TEL URI).

This means that groups of services identified by a PSI can be defined, as well as groups mixing IMPUs and PSIs. Consequently, everything that can be made towards user groups can also be made towards service groups and service/user groups. For instance, conference session setup can relate to groups including both human beings and automatons like a media server.

Associating services to services

There exist several approaches to route a SIP request addressed to a PSI to an AS serving this PSI. Most approaches rely on a direct mapping between the PSI (SIP or TEL URI) and the address of a server. They differ by where the mapping is defined (DNS, HSS), constraints on how the PSI URI is constructed, and where the routing is performed (originating S-CSCF, I-CSCF).

One approach is different, and while the IMS specifications never describe what it permits, its potential is much more significant from a service perspective. It lies in the association of a service profile to the PSI in the HSS, the same way service profiles are associated to IMPUs, which permit the routing of SIP requests associated to the IMPU to IMS application servers. With this approach a PSI is provisioned in the HSS like an IMPU, except that not all information need to be provisioned (e.g. no need for authentication information).

A first interest of this approach is that not all requests addressed to a PSI have to be routed to the same server. Some requests might be routed to one and others to another, based on initial filter criteria in the PSI service profile.

A very interesting feature of this approach, which is not related to service anthropomorphism, is that if an IMS user decides to make a user group consisting of the members of its family, identified by a PSI like sip:MyFamily@operator.com, an INVITE addressed to the PSI might be routed to a conferencing server, a MESSAGE addressed to the same PSI to an IM exploder, and a SUBSCRIBE to the PSI to a resource list server (in order to explode the request toward each member and compile the results in a single NOTIFY). Compare to the other approaches, which will route requests addressed to sip:MyFamily@operator.com to a single server, actually forcing the user to define a different PSI for each service it would like to apply to its family if it wants different services to apply (e.g. sip:MyFamily@conferencing.operator.com). This need to define a specific SIP URI for a combination group/service is also the way you will have to proceed in a non-IMS SIP network. This is an interesting example of how IMS can add value over non-IMS SIP networks and make the life of a user easier.

To come back to the subject of this post, let us consider a streaming service for a live event like a concert. An IMS user will typically start viewing the event by generating a SIP INVITE to a PSI identifying the live event. With service profile based SIP routing, the operator could define that a SUBSCRIBE to the presence event package would be routed to a presence server instead of the streaming media server (to which INVITEs will be routed). This would permit to associate presence information to the live event, like a description of the live event, information on how to subscribe to it, and status information (delayed, not started, starting, started). A user subscribing to the live event's presence could then be automatically be notified about when it can start viewing it.

In effect, associating a presence to the live event is associating a service to it, the same way presence can be a service associated to a user.

But there are other ways to associate a service to a service. Service profile -based routing permits to chain different services in the SIP signalling path. Consider an anti-spam application the operator proposes to its IMS customers. Every message addressed to the user can be routed to this application to be analyzed and possibly blocked. Now consider a discussion forum based on IMS messaging. The name of the forum is identified by a PSI (e.g. sip:TheIMSLantern@operator.com) so that each IM addressed to the forum is distributed to all the users currently registered with it. Service-profile based PSI routing would permit the operator to route a SIP request addressed to the forum first to the anti-spam application, then to the forum server. This is as if the discussion forum was treated as an IMS user subscribed to the anti-spam service. Now extend this example with an anti-virus application and an archive server, or think of other examples.

To conclude...

An IMS service can be anthropomorphic because it can act like a user, it can act as a network-based agent of the user, it can interact with other services like a user, it can communicate with "other" users, and it can be associated to other IMS services just like a user.

Note that "IMS service anthropomorphism" is not a standard or a commonly used term. I created it. You might therefore want to be careful and cite your source if if decide to use the term in discussions or in documents.

Christophe

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

IMS Service Routing: ISC for S-CSCF

This is the third (but not last) post in a series that tries to describe the service-related and IMS-specific mechanisms used to route SIP requests in an IMS network.

After a first post that set the scene, and positioned IMS service routing into a bigger end-to-end context (big picture), after a second post that described the concept of IMS service profile, this post will describe how the IMS core network entity called S-CSCF makes use of the service profile to route SIP requests to application servers over the ISC reference point in the phases 2 and 5 of the big picture.

However, it takes two to tango. While this post concentrates on ISC from an S-CSCF perspective, the next one will address it from the point of view of an IMS application server.

Where to Look in 3GPP Specifications

The ISC procedures at the S-CSCF are not described in a dedicated document or in a dedicated chapter of a 3GPP specification. They are embedded in the detailed description of the S-CSCF procedures in TS 24.229.

Though it definitely makes sense to read other parts of the specification in order to fully understand the procedures, the following sections are the most important:

- Section 5.4.3.2 describes the procedures at the S-CSCF when it receives a request initiated by the user it serves. This corresponds to the phase 2 in the big picture diagram.

- Section 5.4.3.3 describes the procedures at the S-CSCF when it receives a request that is terminated at the user it serves. This corresponds to phase 5.

- Subsections in 5.4.1 address IMS registration procedures, which imply a specific ISC behavior.

As always, I recommend to read the specifications, while on my side I will try to provide a different description of the procedures, that can help the reader to more easily decrypt the occasionally obscure wording and the untold stories from the specifications.

Overview of the Procedure

When it receives an initial or standalone SIP request that is originated by or terminated to a "user" (IMPU, PSI) it serves, the S-CSCF processes the initial filter criterias in the service profile associated to the IMPU or PSI, according to their priority. If the trigger point in a filter criteria is true, the S-CSCF forwards the SIP request to the corresponding application server.

If the application server sends a related SIP request back to the S-CSCF, it proceeds with the next iFC, and so on until a terminating condition is met.

This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).

When a terminating condition is met and there is still a SIP request to be processed, the S-CSCF then proceeds with normal SIP routing procedures in the IMS (phase 3 or 6).

iFCs Are Only Applied on Standalone or Initial Requests

A SIP standalone request is an isolated transaction requiring a single final reponse. An example of standalone request is MESSAGE.

A SIP initial request starts a dialogue, which will include a set of related transactions. a SIP session started with an INVITE is an example of SIP dialogue, but there are others, like dialogues initiated by SUBSCRIBE or REFER.

The S-CSCF applies service profile based routing only on standalone or initial requests. If an AS is contacted and decides to act as a SIP proxy or Back-to-Back User Agent (B2BUA), for an initial request starting a dialogue, it determines if it wants to remain in the signalling path for the subsequent requests of the same dialogue. This decision is recorded in a specific header called Record-Route.

The S-CSCF then processes the subsequent requests in the same dialogue according to normal SIP routing procedures. These subsequent requests may either be routed to the AS or not, depending on its initial decision.

The Original Dialogue Identifier

The original dialogue identifier is described in section 5.4.3.4 of TS 24.229.

You can read the technical details by yourself, but this token inserted by the S-CSCF in the SIP request before it is forwarded to an AS is a kind of secret word, that the S-CSCF will recover from the SIP request (or a derived one) when it comes back.

This secret word, both created and consumed by the S-CSCF serves two purposes.

This is first a convenient way for the S-CSCF to discriminate between the SIP requests it receives from the core network and those that are coming back from the application layer. When the SIP request includes an original dialogue identifier, it can be associated to an ongoing ISC procedure (i.e. ongoing processing of iFCs).

However, the original dialogue identifier was introduced for another reason.

When an application server receives a request originated from A and addressed to B, as it is shown in the big picture, it may decide to insert itself in the signalling path between the two endpoints. One way to do it is to just proxy the initial request back to the S-CSCF. However, a proxy behavior is very constraining, and does not permit the AS to have much control on the future SIP dialogue. For instance, the AS cannot change the SIP request as it wants, or temper with its body (e.g. change a codec in the SDP). Moreover, in the case of a SIP session, if the AS acts as a SIP proxy, it cannot decide during the session to e.g. play an announcement or transfer the session to another user.

In order to do this, the AS has to act as a Routeing Back-to-Back User Agent (B2BUA), which makes it act as an endpoint towards A and as another endpoint towards B. In the process, it may decide to make itself visible (i.e. place a PSI in the SIP requests towards A and B) or transparent (i.e. A and B cannot see there is a B2BUA, i.e. a service, inserted between them).

The problem is that when it acts as a routeing B2BUA, the AS creates a brand new SIP dialogue on the B-side and the S-CSCF has no standard SIP way to relate this new dialogue to the one on the A-side. The original dialogue identifier serves this purpose.

The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).

When it matches the original dialogue identifier from an incoming request with one it inserted in an outgoing request to the AS, the S-CSCF knows that the two requests relate to the same logical dialogue. This is important for charging, but also for being able to proceed with the evaluation of iFCs and associated service routing until the end.

iFC Processing Termination Condition

When does the S-CSCF stop processing iFCs?

There can be three conditions for the S-CSCF to stop its processing of iFCs:

1) An application server has decided to serve as an endpoint for the SIP request (not a routeing B2BUA, a real endpoint). The AS provides the responses to the request and does not proxy it further. Routing of the SIP request in the IMS stops there (phase 2 or 5).

2) This is a terminating case (phase 5) and an application server has modified the request-uri (i.e. intended destination) of the SIP request. The S-CSCF then processes the request according to this new request-uri, without any attempt to apply other iFCs that related to the previous request-uri.

3) All the iFCs in the service profile have been processed, and there is still a SIP request to be routed further (phase 3 or 6).

Requests Initiated by an Application Server

An AS can decide at any time to initiate a new SIP request towards the IMS core network. This SIP request may be generated totally out of the blue, or be the side effect of an interaction with a user or a 3rd party through e.g. a web page or web services. It may also be the side effect of an incoming SIP request. For instance, when receiving an INVITE from A to B, the AS may decide to send an instant message to A, B, or C.

In some cases the request is initiated on behalf of a user. In that case, the AS inserts the IMPU of the user (e.g. A) as the initiator of the request. As it acts on behalf of a user, its request must be processed as if it was really originated by the user. It must therefore be routed to an S-CSCF serving the user so that it applies originating procedures (phase 2), which include the processing of the service profile associated to the IMPU.

Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.

An S-CSCF uses different ports to process incoming and terminating SIP requests. However, in the standards, an AS has no means to know which port an S-CSCF uses for originating requests, it only knows the port for terminating requests. This is the reason why the specifications mandate that when an AS issues a SIP request on behalf of an IMPU (PSI) towards an S-CSCF serving this IMPU (PSI), it includes a specific parameter called "orig", which permits the S-CSCF to detect that the request that is coming on the terminating port should actually be processed as if it was coming on the originating one (see section 5.4.3.1 in TS 24.229).

Support of IMS Registration Notification

For an application server, knowing when an IMPU registers and de-registers from the IMS core network might be an essential information. For instance, a message store might want to be notified when a user registers, and is therefore able to receive a message that is anxiously waiting for her.

However, SIP REGISTER is the only SIP request that cannot be forwarded by the S-CSCF for the simple reason that the S-CSCF, acting as a SIP registrar, is itself the endpoint for it.

Consequently, in order to notify application servers about registration events as requested in the service profile (i.e. registration, re-registration, de-registration) , the S-CSCF issues a 3rd party REGISTER towards them. This is, the S-CSCF registers the IMPU of the user in the application server on behalf of the user.

The information in this 3rd party register is more limited than the in the original REGISTER issued by the IMS client towards the S-CSCF. For instance, 3rd party registration does not permit the application server to discover the capabilities of the IMS client (which can be very important for some services), and it only provides information about a single IMPU being registered, while the user might register several IMPUs at once.

For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.

Note that, if 3rd party registration (a standard IETF mechanism) is specific to the ISC reference point in the IMS architecture, the usage of the registration event package is not: the I-CSCF and standard IMS clients are supposed to subscribe to this event package in order to be notified about de-registration when it has been decided by the IMS core network (e.g. the operator has decided to de-register the IMPU).

Details of SIP on ISC

SIP messages over ISC include IMS-specific headers, some of which I already listed in a previous post.

However, it is important to note that none of these headers is specific to ISC. These are IMS SIP headers that are also used on other reference points.

Therefore, there is no such a thing as a specific SIP that would be used only on the ISC reference point. What makes ISC special from a core network perspective is essentially the usage of a service profile by the S-CSCF for deciding on how to route an incoming SIP request to possibly multiple IMS application servers.

Christophe

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

IMS Service Routing: Big Picture

This post is the first in a series that will describe how the routing of SIP service-related requests is performed in the IMS.

Before going into the details of service profiles, initial filter criteria and the ISC (IMS Service Control) interface, I will start with an attempt at placing IMS service routing in the larger context of end-to-end SIP routing within IMS.

I think this is something missing in most representations of the IMS service architecture, which tend to fragment the overall perception of this architecture, and make it more difficult to comprehend for the novice.

The figure you can see at the top (click to enlarge) shows the end-to-end interaction between two IMS users. However, there exist variants related to which entity initiates the SIP interaction (IMS client or IMS AS), which entity terminates the SIP interaction (IMS client or IMS AS), and whether the end-to-end SIP interaction fully takes place between IMS entities or involves entities in an external network like the circuit-switched network or the Internet. I will address these variants below using specific colors.

Before describing what IMS SIP routing permits to achieve, let's start with one of its apparent limitations compared with how SIP can be used in a non-IMS network.

Restriction to IETF SIP Routing

The routing of a SIP request to its destination is based on the resolution of the request-uri address (IMPU or PSI in IMS) to one or several targets. However, before reaching its destination, the SIP request may traverse several servers, and the originator of the request may itself define in a specific Route header (part of) the path to be followed .

This may permit the client to decide the routing of the SIP request through a set of servers that will deliver added-value services.

This is not possible in the IMS. More precisely, whatever SIP route an IMS client may define in a SIP request it originates will be discarded by the IMS core network (the P-CSCF for that matter) and replaced by another route which ensures the phase 1 of IMS SIP routing described below.

Is this a limitation to the power of IMS, compared to what is possible in, say, the Internet? I don't think so.

I do not think that relying on a SIP client to determine a set of application servers supposed to add value to the end-to-end SIP interaction is a very pragmatic and agile approach to service delivery. The mechanism is limited by the knowledge and sophistication available in the SIP client, which may be put under pressure as soon as more than one application server needs to be inserted in the signalling route (which application servers? In which order?).

Then, you have to compare what is lost (the possibility for an IMS client to define a service route) with what is gained with the IMS architecture: service profile based routing.

The IMS routing of SIP requests based on service profiles (phases 2 and 5 below), is sophisticated, very agile and permits to keep IMS clients very simple, as they do not have to care about service-related routing. It also accurately reflects the business relationship between an IMS user paying an operator, and the operator providing value for money in return.

While some may look at the IMS architecture as a way to deprive users from their freedom to access the services they want to access (note anyway that the limitation is only in the route to access a destination, not the destination itself), others can see the same architecture as a way to simplify the life of users (and their devices) and to concentrate service-related complexity in the hands of those who are asking money for value.

Service Routing for Each Party (See Figure)

An important feature of the IMS service architecture, which is not apparent in figures taken from IMS specifications, is the fact that each party in a two-party or multiparty SIP interaction benefits from its own service routing, and therefore its own services.

As shown in the figure above, an end-to-end SIP interaction between John and Mary will first lead to the invocation of services associated to John (phase 2), and then to services associated to Mary (phase 5).

This feature is very natural for a telecommunications service architecture (it is similar to IN), but it is not to most of the non-IMS SIP implementations, more especially those supporting enterprise VoIP services. Typically, these non-IMS implementations will combine the execution of features that apply to all parties of a call. This difference is usually the most important one to overcome when porting a non-IMS application server on the IMS.

In the IMS architecture, a specific party in an end-to-end SIP interaction is either identified by an IMPU or a PSI. While the figure shows an example of IMPU to IMPU interaction, the following alternatives could also exist:

- IMPU to PSI: an IMS client or an AS-based application acting on behalf of a user interacts with an AS-based application identified by a PSI.

- PSI to IMPU: an AS-based application interacts with an IMS client.

- PSI to PSI: an AS-based application interacts with another AS-based application.

Here is a practical advice for when you define or analyze an IMS message flow: S-CSCFs do not hang just like that in the architecture; they always serve someone or something, and it certainly helps to make it explicit (see for instance the figures in this or the previous post).

Preliminary to the Description of End-To-End IMS Signalling

Here follows the decomposition of an end-to-end SIP interaction into 6 distinct phases.

But first a couple of things...

There is of course a pre-requisite: John is registered with IMS. This implies that his client discovered the P-CSCF it will be associated to (according to 3GPP or TISPAN procedures), and performed the IMS registration procedure leading to John's authentication, the association of an S-CSCF to him, and the setting up of a security association between its client and the P-CSCF.

The figure shows direct interfaces between different operators' networks. However, the GSM Association (GSMA) defined the possibility for 3rd party transit networks to be used in-between, in order to reduce the need for bilateral operator agreements.

Phase 1: routing of the SIP request to the S-CSCF serving the originating party

As described above, the P-CSCF removes any potential route defined by the IMS client and replaces it with a route to the S-CSCF serving the user in its home network. This route was defined during the IMS registration of the user, and may traverse an I-CSCF in case the home network wants to hide its network topology to the potential visited network (note that in practice a border gateway might be used instead).

Phase 2: service profile -based routing for originating user

The S-CSCF serving the originating party applies the service profile for the originating IMPU. This service profile consists of a list of initial filter criteria. It corresponds to the set of services the originating party is associated to. In practice, this means that the service route for the SIP request originated by John is defined by the operator and implemented by the S-CSCF.

In this phase, the S-CSCF may route the SIP request to 0, 1 or several application servers (one after the other in a signalling chain or pipe).

It is possible that one of the application servers terminates the SIP request (i.e. acts as a SIP User Agent). This may happen in three cases:

1) The request was addressed to a PSI hosted by the application server (e.g. user tries to access content)

2) The originating party issued a request addressed to itself, which was actually targeted at one of its services in the network. For instance, SIP requests that update the presence information of a user (PUBLISH for presence event package) are addressed to the user's own IMPU. Another example can be seen in the automatic service discovery and configuration example I described in an earlier post.

3) The application server terminates the request on behalf of the B-party. This may happen, for instance, with services that block traffic to unauthorized destinations. Another example could be the case where a service, potentially after having accessed the presence of the B-party, decides to transform an IMS instant message (SIP MESSAGE) into an email, an SMS, or an Internet IM. In this case, IMS SIP routing is terminated to be superseded by an alternative protocol outside of IMS.

Signalling path termination: the SIP interaction may terminate at phase 2 if one of the application servers decides to act as an endpoint for the SIP request.

IMS exit point: the SIP interaction may exit IMS at phase 2 if an application server serves as a gateway towards a different protocol/domain (e.g. email, SMS, MMS, Internet IM protocol). Note that phase 2 takes place before the IMS core network tries to route the SIP request based on the request-uri. This means that the request-uri might not be an IMS routable URI: it could be a URI specific to the protocol and/or domain to which the SIP request is actually targeted.

In case no application server terminates the SIP request, the S-CSCF proceeds with the next phase.

Phase 3: routing of the SIP request to the destination network
The S-CSCF routes the SIP request according to its request-uri.

In case the request-uri is a TEL URI, the S-CSCF may route the request to the circuit-switched network (see previous post - the request will be routed to the circuit-switched network when the TEL URI does not resolve into a SIP URI through ENUM).

Through DNS, the S-CSCF may also determine that the domain of the request-uri is resolved into a non-IMS network like the Internet.

IMS exit point: the SIP request is routed outside of IMS by the IMS core network if it is a TEL URI that does not resolve into a SIP URI, or if it is a SIP URI whose domain is outside of the IMS (e.g. in the Internet).

Side comment: to come back to the possibility for an IETF SIP client to define by itself a route towards application servers... If it is not possible for an IMS client to define such a route, it is possible for an IMS application server to do it on behalf of the client. This route could binclude application servers in the Internet and could be provided by the IMS client to the IMS AS through signalling or self-provisioning.

In case the B-party is an IMS user (same or different operator), DNS resolves the request-uri to an I-CSCF of the target operator, that acts as an entry point to its network. The request may traverse an I-CSCF of the originating network, in order to hide the network topology to the destination network (note that in practice a border gateway might be used instead).

Phase 4: routing of the SIP request to the S-CSCF serving the destination user

Either the B-party is registered with IMS or not.

If it is, the I-CSCF retrieves the location from the HSS and routes the request to the S-CSCF serving it.

If it is not, there is a procedure to dynamically allocate an S-CSCF to the B-party and to route the request to this S-CSCF. The rationale is that the B-party's IMS services in the network might need to be reachable even when the B-party is not available (e.g. presence, a voice call continuity server that will route the call to the circuit-switched network, a call forwarding service).

Alternative entry points to phase 4: instead of originating from the IMS and having followed phases 1 to 3, the request received by the I-CSCF may originate from the circuit-switched network (request is received from MGCF, i.e. signalling gateway with CS), or from a non-IMS network like the Internet.

IMS entry point: instead of an S-CSCF in the originating network, the request may come from the circuit-switched network (through an MGCF), or from a non-IMS SIP network (e.g. the Internet).

Phase 5: service profile -based routing for the terminating user

The S-CSCF serving the terminating party applies the service profile associated to the IMPU (or PSI) corresponding to the request-uri. This service profile consists of a list of initial filter criteria. It corresponds to a set of services associated to the terminating party.

In this phase, the S-CSCF may route the SIP request to 0, 1 or several application servers (one after the other).

It is possible that one of the application servers terminates the SIP request (i.e. acts as a SIP User Agent). This may happen in two cases:

1) The request was addressed to a PSI hosted by the application server (e.g. user tries to access content, user posts message in chat room). This is the case where an operator offers services to the world. Note that there exist alternative mechanisms to route a request to a PSI.

2) The application server terminates the request on behalf of the B-party. This might be the case for presence (the request was addressed to the B-party but was actually aimed at its presence server) and any other service acting on behalf of the terminating party (e.g. voice call continuity, call or message blocking or forwarding services).

Signalling path termination: the SIP interaction may terminate at phase 5 if one of the application servers decides to act as an endpoint for the SIP request.

IMS exit point: the SIP interaction may exit IMS at phase 5 if an application server serves as a gateway towards a different protocol/domain (e.g. email, SMS, MMS, Internet IM protocol).

Phase 6: delivery to the terminating party

In case there is still a SIP request to be delivered to a B-party, the S-CSCF routes the request to the P-CSCF(s) serving the B-party (there might be several in case several endpoints are registered with the same IMPU), which in turn contacts the device of the B-party.

SIP requests issued by application servers

This post essentially addressed the situation where the SIP request is initiated by an IMS client corresponding to an IMPU. However, to be complete, you also have to consider that IMS application servers are able to generate SIP requests, using either an IMPU or PSI as the originating party, and an IMPU or PSI as the request-uri.

When an AS issues a request with an IMPU as originating address, it is supposed to route it to an S-CSCF serving the IMPU. Starting with 3GPP R7, it is possible to allocate an S-CSCF to the IMPU even if it is not registered with IMS (i.e. the IMS AS issues a request on behalf of an IMPU which is not registered with IMS). IMS routing then proceeds with phase 2.

When an AS issues a request using a PSI as the originating party, it may either reach a S-CSCF serving the PSI, or route the request directly to an I-CSCF for the terminating party. Depending on the case, IMS routing then proceeds with phase 2 (the service profile is associated to the PSI) or directly with phase 4.

A specific case for having an IMS AS issuing a SIP request to the IMS is when it acts as a gateway towards another protocol and/or domain. This is the symetric case to what was described in purple for phases 2 and 5 above.

Christophe

There is no direct relationship to this post, but I just added the initial architecture proposed in 3GPP for the SCIM in the first post I wrote about it in May.

IMS Public Service Identities (PSIs)

After IMS Public User Identities (IMPUs), here is a first post on the second type of identity specified in 3GPP IMS specifications. I will start with the basics.

The concept of IMS Public Service Identity (PSI) was introduced in 3GPP R6. Like an IMPU, a PSI might be defined as a SIP URI (e.g. sip:service@operator) or a TEL URI (e.g. tel:1-234-567890).

To read about PSIs as defined in 3GPP, check chapters 4.3.6 and 5.4.12 of TS 23.228.

Definition (Sort of)

According to TS 23.228, PSIs identify "services which are hosted by application servers". The specification then states that PSIs are used to identify user groups (i.e. sets of users). Is a "user group" a "service"? I do not think so, and this makes the definition of a PSI in 3GPP specifications a little bit ambiguous or short to say the least.

For me, a PSI identifies an IMS service related resource. This might be the service itself (e.g. PSI to change session from 2-party to multiparty, PSI used to retrieve service configuration information), a service feature (e.g. PSI used for starting an ad-hoc push to talk session), a service instance (e.g. PSI identifying a pre-defined conference, PSI identifying a specific content, PSI identifying a specific chat room), a user group (e.g. request to PSI should be exploded to every user in the group identified by the PSI). A PSI could also identify a specific service parameter, a bundling of individual services...

My terminology might not be very accurate, and my own definition is certainly not complete, but basically a PSI identifies anything you might want to identify as the initiator or recipient of a SIP request, which is not an IMS user (for which an IMPU will be used instead). The definition for PSI is therefore directly linked to how SIP and IMS will be used for the delivery of future services. The more IMS and SIP are used to deliver innovative services in an innovative manner, the more the definition for a PSI might be extended.

Prior to its introduction in 3GPP specifications, the concept was not formalized but already existed in practice. For instance, 3GPP already mentioned in R5 the possibility to name a conference through a specific SIP or TEL URI. Similarly, pre-OMA specifications of Push To Talk Over Cellular also made use of a specific SIP URI to start an ad-hoc push to talk session. Concerning the IETF, though it has not been conceptualized as in 3GPP, the possibility to use a SIP URI for something else than a user is common practice (as I once read in an IETF SIP-related RFC: "In the Internet nobody knows you're a dog").

"Private" or "Restricted Access" PSIs

The terms "Private PSI" and "Restricted Access PSI" do not exist in 3GPP specifications, so do not look for them elsewhere than on this blog! Note that the association of the term "private" to an acronym whose first letter means "public" might be a hint for one of two things 1) the author of this blog writes nonsense, 2) 3GPP might not have selected the best name for the concept. You chose.

Private and Restricted Access PSIs are only usable by subscribers of the operator that owns the PSIs. As you will see below (*spoiler*) this is because their routing is based on service profiles associated to the users initiating SIP requests to them.

A Restricted Access PSI can be used by users who are explicitly authorized to access the resource identified by the PSI, i.e. their subscription permits access to the resource. For instance, a specific video streaming content is accessible to a set of users who have paid for it.

A Private PSI has a specific meaning to a limited set of users, possibly a single one. For instance, a user group consisting of John's family members and identified by a PSI like sip:MyFamily@operator, may be accessible by John alone, or John and the members of his family. Other IMS users (e.g. Mary) might have a user group with the same name, but for them this name will point at another group definition (e.g. another family).

Routing of SIP requests addressed to a Private or Restricted Access PSI is determined by the service profiles associated to the users who are authorized to use this PSI. More precisely, their service profile stored in the HSS includes one or several initial filter criteria(s) which determine(s) how a SIP request originating from this user and addressed to this PSI must be routed.

"Really Public" PSIs

"Really Public" PSIs are usable by anybody, including subscribers of other operators than the one that owns the PSI.

As they must be globally routable across various IMS domains (e.g. the request addressed to the PSI may originate from another IMS nettork or from the Internet), 3GPP had to define specific means to route SIP requests addressed to these PSIs. This is actually the reason why the concept was introduced in 3GPP specifications, and the reason for the name of the "public" in PSI.

3GPP was very generous with Really Public PSIs, as it standardized no less than 3 alternative ways to route them (4 if you count 2 sub-variants for subdomain based routing). Considering the complexity and cost induced by the standardization of options and alternative solutions (that need to be implemented and operated afterwards), I never understood why 3GPP (more especially operators) permitted this to happen. But who am I to complain?

Two of these alternatives lead to a very similar result as they route all SIP requests addressed to one PSI to a single application server (i.e. the PSI is the only criterion used to route the SIP request).

The first alternative is subdomain based routing. The PSI will look like sip:anything@service.operator. The "service.operator" subdomain will be resolved through DNS to the application server serving all the PSIs constructed with this subdomain. Sub-variants include the case where the subdomain is resolved to the AS in the network originating the request, and the one where this is the network serving the PSI that resolves the subdomain into the AS address.

The second alternative relies on an address stored in the HSS. When the request addressed to the PSI reaches a signalling entry point to the network serving the PSI (which is an I-CSCF), this I-CSCF matches the PSI with the address of an AS retrieved from the HSS.

The third mechanism is for me by far the most powerful from a service perspective. It consists in treating the PSI as an IMPU (IMS Public User Identity). This is, a service profile is associated to the "PSI user" (this term is used in the specifications) as it would be to an IMPU.

When a request addressed to the PSI is received by the I-CSCF, this one routes the request as if it was addressed to an IMPU (i.e. the HSS provides the I-CSCF with the address of an S-CSCF serving the PSI user). Routing of the PSI by the S-CSCF is then based on a set of initial filter criteria forming the service profile of the PSI.

This approach is interesting as it permits to make PSIs benefit from the service architecture defined for IMS users. More especially, it permits:
- To discriminate service routing of requests addressed to the PSI according to details of the SIP request. For instance, an INVITE for a voice session and an INVITE for a video session addressed to the same PSI may be routed to different specialized media servers. As another example, a subscription to presence (SUBSCRIBE for presence event package) and an instant message (MESSAGE) addressed to the same PSI could be routed either to a presence server or a messaging server.
- To chain several ASs on the signalling path of the SIP request, instead of routing it to a unique AS. For instance, a SIP MESSAGE addressed to the sip:The_IMS_Lantern_ChatRoom@operator PSI, a chat forum for this blog, could be routed through an archiving server, an anti-virus server, and an anti-spam server, prior to reaching its final destination: the chat room server that will dispatch it to all the users currently in the chat room.

Distinct vs. Wildcarded PSIs

Distinct PSIs are PSIs that are fully defined by the operator and provisionned as such in the HSS (e.g. sip:This_Service@operator, provisionned in the HSS with a matching application server address or a service profile).

Wildcarded PSIs permit an operator to provision PSI routing information in the HSS according to a naming pattern. All the PSIs sharing the same naming pattern will be routed the same way. For instance, sip:*_ChatRoom@operator is a wildcarded PSI that corresponds to the IMS Lantern chat room PSI introduced above.

Wildcarded PSIs permit to factorize service routing information between multiple PSIs. They also permit PSIs to be (partly) created by end users, and to be managed fully by an application server without involvement of the operator's provisioning system. For instance, I could create myself the name of the IMS Lantern chat room in the chat room server. No need to change any routing information in the HSS. Every request to the IMS Lantern chat room would be routed to the chat room server according to the wilcarded PSI it is based on.

Activation / De-activation of PSIs

An application server may activate or de-activate a PSI in the HSS through the Sh reference point (interface between an AS and the HSS based on Diameter).

This permits to have a greater application control on PSI routing information. You could imagine the case where a service is available only during certain hours of the day, or days of the week. A PSI could also be usable during a limited period (e.g. a sports event). There are certainly many other usages for the dynamic activation/de-activation of PSIs.

SIP Requests May Originate From a PSI

The IMS service architecture permits application servers to generate SIP requests towards users or other application servers.

It is possible for an AS to use a PSI as the originating address of a SIP request. This permits a service to identify itself as the originator of a service interaction towards a user or another application.

Future post(s) will show potential service patterns making use of PSIs (i.e. ideas on how to use the PSI ingredient to cook some IMS services).

Christophe

IMS Public User Identities (IMPUs)

There might be a few interesting things to say about IMS user identities.

As you certainly know, there can be two sorts of IMS Public User Identities (also known as IMPUs): tel URIs (e.g. tel:+1-234-456789) and sip URIs (e.g. sip:user@operator).

(Note that a SIP URI with an E.164 number in the user part and a parameter "user=phone" is the equivalent to a tel URI and will be treated as such by the IMS core network)

Tel URIs: Smooth Migration From Legacy Telephony

In IMS, tel URIs may be used to address an IMS user or a user in the legacy circuit-switched network.

When the tel URI corresponds to an IMS user, the core network entity called S-CSCF (Serving Call Session Control Function) will be able to resolve it into a SIP URI, thanks to a DNS extension called ENUM,. It will then proceed with the routing of the SIP request within the IMS.

When the tel URI corresponds to a circuit-switched user, the S-CSCF's query to ENUM will fail to resolve the tel URI into a SIP URI. The S-CSCF will then route the call to the circuit-switched network through an appropriate gateway.

Consequently, using a tel URI an IMS user can set up a call with another IMS user or with a legacy telephony user.

Tel URIs also permit IMS users to be called from the circuit-switched network. The CS network routes the call to a voice gateway, which sets up a voice session in the IMS using the original B-party number to form a tel URI. The IMS core then resolves the tel URI into a SIP URI of the IMS user.

In order to support interoperability with the circuit-switched network, IMS users will need to keep legacy phone numbers for years, even if they use SIP URIs in parallel.

SIP URIs: The Future of User Addressing

SIP URIs should eventually dominate and replace phone numbers as the way to address other users in some years from now.

This steady migration from telephone numbers to alphanumerical SIP addresses will be a fundamental element for different types of convergence:

- Convergence between fixed and mobile communication, as mobile and fixed -segregated phone numbers will be replaced by access-agnostic SIP URIs.

- Convergence between telecom and Internet communication, as both can use SIP and SIP URIs.

- Convergence between SIP-based communication (e.g. multimedia sessions, voice, instant messaging) and email through the possibility to use the same address between SIP and the email protocol (e.g. sip:John@service_provider vs. smtp:John@service_provider).

IMPUs Identify Users, Not a Specific Line or Device!

There is a major difference between IMS and pre-IMS addresses. While pre-IMS phone numbers are usually associated to a unique line or device, IMS IMPUs relate to end-users.

In a pre-IMS world, mapping a legacy phone number to multiple devices is an added-value feature requiring a specific implementation in existing fixed and mobile networks.

In contrast, the possibility to concurrently assign an IMPU to multiple devices is a basic IMS feature, supported by the IMS core network (i.e. S-CSCF), without the need for a specific support in the application layer. The dynamic allocation of an IMPU to one or several devices is performed through the IMS registration procedure.

In addition, the possibility for IMS to support multiple access technologies (e.g. cable, xDSL, cellular wireless, non-cellular wireless) makes that an IMPU can concurrently be shared between multiple fixed and mobile devices (e.g. fixed phone, PC, set top box, mp3 player, mobile phone). This is fixed mobile convergence at the user and network level.

Multiple IMPUs for One User

IMS specifications permit a user to have several IMPUs. It is up to the operator to decide how many IMPUs a user will be allowed to have.

Different IMPUs may serve as aliases. These IMPUs are totally inter-changeable, as they are associated to the same set of services and are transparently associated to the same devices. The user may use them to differentiate between different groups of contacts (e.g. friends vs. strangers). A user will typically have a tel URI as alias to a SIP URI (see above).

Different IMPUs may also permit the user to endorse several persona (e.g. member of an association, owner of a private business). In this case, the IMPUs may be associated to different service profiles, and possibly to different devices (but they can also be associated to the same).

One IMPU for All Services, Across All Devices

A feature that may seem to conflict with the previous, and might actually be more essential, is the possibility to associate a single IMPU to virtually all the services of a user.

IMS and SIP can unify all real time 2-party and multi-party person to person communication (e.g. voice, video, instant messaging, deferred messaging), blend communication, content and data together, and support access to user data and information (e.g. presence, user profile, various event packages permitting to access and monitor user-related data and events).

All these communication/content/data services can be accessed through a single user IMPU, which is independent from the devices and access technologies being used. Moreover, if this IMPU corresponds to the user's email address, you can then finally have a unique address on your visit or business cards, and this address may provides access to more services than all the old ones put together.

More Enablers for Services

The possibility to access a plethora of services through a single IMPU can also be extremely beneficial to services themselves.

Consider the following example (which may not be that interesting from a service perspective, but this is not the point).

John sends an electronic birthday card to Mary through IMS deferred messaging (i.e. the message will be delivered to Mary as soon as she is able to receive it). A service associated to John intercepts the SIP service request, extracts Mary's IMPU from it and generates a presence request on behalf of John and addressed to Mary's IMPU. Mary's presence server answers with a set of information related to Mary, according to John's authorization to access it. This information may be very rich about Mary, the means and addresses to communicate with her, her devices, the applications she uses, and various availability and preference information about them. John's service may use this information to suggest additional or alternative ways to deliver the electronic birthday card (e.g. email). It may also suggest to store elements of this information in various repositories, such as John's address book.

This example shows that even if a an IMS subscriber still makes use multiple identities and addresses (for instance addresses related to Internet services), one of them may be used as the key to dynamically discover all others.

It also shows that a service which had never heard about a user can discover a whole lot of information about this user and use it for the delivery of sophisticated services. In the example, I used presence, which by itself can be a very rich set of information, but this could be extended to much more than this.

Christophe