IMS Service Routing: ISC for IMS Application Server

After a long summer break, here is a fourth post on the details of the IMS service architecture related to the handling of SIP signalling. While the previous post described ISC from the perspective of the IMS core network (S-CSCF), this one concentrates on the other side of the interface: the IMS Application Server.

The details of the procedures to be supported by an IMS application server for ISC can be found in chapter 5.7 of TS 24.229. This post does not intend to describe all the details of the IMS AS procedures (for instance I will not address such specific issues as the handling of GRUUs, local numbering or carrier selection - the reader is invited to read the specification for this). I will only provide my own description of the basics, sometimes summarizing the specification, sometimes going beyond them or placing them in a larger context.

In the following, I decided to distinguish between two cases.

In the first one, the IMS application server receives a SIP request that was originated by another SIP entity. This entity could be an IMS client (e.g. phone, TV set, home PC) or an IMS application server (e.g. a messaging server, a multimedia content server). It could be located in the same operator domain as the IMS application server, or in a different one (e.g. an IMS client or an IMS application server of operator X issues a SIP request received by an IMS application server of operator Y).

This entity could also be a client or application server located in a non-IMS network, like an enterprise network or the Internet. A SIP request originated from outside the IMS and routed to it can be discriminated from an IMS-issued request, and the IMS application server can adapt its behavior to this origination. For instance, a request originated from the Internet was not authenticated by the IMS, and has to be processed accordingly.

In the second case, the IMS application server issues a SIP request to another SIP entity. This SIP request may be the consequence of the initial reception of a SIP request (first case), but it is not directly related to it. For instance, upon the reception of a call set up request for user A, the IMS application server issues an instant message to user A (or B). It may also be generated out of the blue, or through an initial interaction based on, e.g. web services or the access of a user to a web page. The SIP request may be addressed to an IMS client or IMS application server located in the same or a different operator domain (e.g. a service from operator X accesses the presence of an IMS user located in operator Y's domain). Alternatively, it may be addressed to a client or a server located in a non-IMS network, like an enterprise network or the Internet.

Note that, through the usage of appropriate gateways, the IMS application server may use SIP to interact with entities which do not reside in the IMS and do not support the SIP protocol.

IMS Application Server Receiving SIP Requests from the Network

SIP Roles

When an IMS application server receives a SIP request from the core network - request which may have been initiated by an IMS client, a non-IMS client or an entity in a non-IMS network - it may support one of four different roles.

Acting as a SIP User Agent, the IMS application behaves as an endpoint for the SIP request. The request may have been addressed to a service or service feature supported by the IMS application Server (typically when the request-uri is a Public Service Identity or PSI), or it may have been addressed to an IMS user (the request-uri is an IMS Public User Identity, also known as IMPU). In this latter case, the service logic hosted by the IMS application server decides to terminate the request on behalf of the user it is addressed to. This is typically the case for presence requests terminated at a presence server (the presence request is addressed to the user whose presence is sought). Other examples include a call termination service or an IMS messaging store that decide that the destination user cannot accept the call or the message right now.

Acting as a SIP redirect, the IMS application server will redirect the initiating party to another destination. I do not expect an IMS application server to extensively support this (feature-poor) role.

The IMS application may also decide to act as an intermediary in the end-to-end SIP interaction that takes place between two SIP entities (e.g. client to client, client to other AS, other AS to other AS, other AS to client).

Acting as a SIP proxy server, the IMS application server has very little opportunity to impact the end-to-end interaction. This behavior is adequate in cases where the AS hosts service logic that has to apply only prior to enabling the end-to-end interaction (e.g. authorization, target selection): the AS performs its logic, then lets end-to-end SIP signalling go on without any interference. It can also be used when the AS hosts service logic that monitors end-to-end SIP signalling without any intention to interfere.

When the AS hosts service logic that requires greater control on the end-to-end SIP interaction, it has to support the so-called routeing back-to-back user agent (routeing B2BUA) behavior. As a B2BUA, the AS acts as an endpoint to both parties in the SIP interaction. Doing so, it may decide to explicitly appear as an endpoint to them (by inserting a PSI as recipient / originator of the SIP interaction) or to remain transparent to the endpoints. Here are examples of situations where service logic needs to rely on a Routeing B2BUA role: need to modify the body of a SIP request (e.g. change a codec in session description), potential need to transfer a session during its course (e.g. to another party, to an announcement), need to insert a media plane intermediary in a multimedia session (e.g. to mix/adapt/control content, to insert advertizement).

I expect the latter example of the insertion of a media plane intermediary in an end-to-end multimedia session to be a fundamental IMS service use case in the future.

Direction of Requests

This is possibly the most important feature of the IMS service architecture when you want to integrate a non-IMS SIP application server with an IMS network, more especially in the context of VoIP services: the ISC interface (more especially the initial filter criteria that govern the forwarding of SIP requests over ISC) distinguishes between requests that originate from a certain IMS identity (IMPU or PSI) and those that terminate to this IMS identity. Moreover, it permits to distinguish between the case where the IMS identity is currently registered with IMS or not (only from 3GPP R7 for requests originating from a non-registered identity, i.e. requests initiated on behalf of a non-registered user by an IMS application server).

This architectural feature (shared with IN) permits to execute different service logic depending on the direction of a request. For instance, taking classical call control services, it permits to execute an outgoing call screening service only for originating call requests, and call forwarding services only for terminating call requests. It also permits to forward an IMS instant message to a store and forward messaging AS only in the case where the recipient of the message is currently not registered with IMS, and therefore unreachable through IMS connectivity.

A clear distinction between originating and terminating parties (and their respective services) is mandatory in a multi-operator environment, in which the parties might be subscribed to different operators. However, most of VoIP application servers that exist on the market today were implemented for a closed, single service provider, environment like the enterprise. They therefore tend to execute both originating and terminating services at once. Such a behavior is incompatible with the IMS service architecture, and must be corrected when the AS is ported on IMS. On the other hand, the direction of SIP requests is not a issue when porting a presence server on IMS (the presence logic depends on the SIP requests more than their direction).

Note that, while the direction of a request (originating, originating unregistered, terminating, terminating unregistered) is an information used to determine how SIP requests should be forwarded to IMS application servers, it is not specified how to convey this information in the SIP request that is to be forwarded. A typical approach to make the AS aware of the direction is to define a distinct AS SIP URI for each direction in the initial filter criterias (IFCs), or to add a specific parameter in the AS address. In both case, the information about the direction is made explicit when provisioning AS addresses for iFCs in the HSS.

Authentication

Authentication aspects are clearly described in section 5.7.1.4 of TS 24.229.

In short, a SIP request may originate from an authenticated identity that required privacy (it will be considered as "anonymous"), from an authenticated identity whose identity can be found in a 3GPP-specific header called P-Asserted-Identity, or from a non-authenticated identity (typically originating from a non-IMS network) that either set itself as "anonymous" or to a certain value. The IMS application server is then supposed to act according to the case it handles. For instance, if a non-authenticated identity was provided in the request, it may challenge it for authentication, typically in an Internet manner (e.g. using SIP digest). In another example, the AS may host service logic that applies to anonymous users or not.

Is is an important IMS feature, that SIP requests initiated from IMS entities are authenticated by the IMS core network, and that the authenticated identity is transported across IMS entities and IMS networks sharing a security trust relationship. This implies that a SIP request issued by a subscriber of operator X can reach an IMS application server from operator Y, without the need for the AS to authenticate the user, as it was already authenticated by operator X and the fact that it was authenticated as well as the authenticated identity are transported in the SIP request. This can be seen as a cross-network single sign on feature of the IMS network, that benefits all IMS services reached through SIP.

P-Headers

As already described in a previous post, a SIP request reaching an IMS application server includes a set of IMS-specific headers ("P-" headers) which are either important for the proper behavior of the IMS application server (e.g. the already mentioned P-Asserted-Identity header, the two headers related to charging) or which can benefit the logic it supports (e.g. information about the access technology currently used by the IMS client).

With the direction of the request, this is the other part of ISC which may require an evolution of a SIP application server to be ported on IMS.

What is Possible, What is Not

In the case where a SIP request initiates a dialogue (e.g. a session, subscription to events), the initial filter criterias and associated procedures at the S-CSCF may make that this request is forwarded to an IMS application server (or several). The IMS application server may either decide that it will only process this initial request (including the responses to it) or that it will process the whole dialogue initiated by this request until the end.

This means that the following cases are not possible:

- An AS cannot get involved in the middle of an ongoing dialogue: it has to be involved from the start.

- An AS cannot cherry pick the SIP signalling it wants. Either it handles the initial request and its responses, or it handles the whole signalling in the dialogue.

- Once it has decided to be involved in a dialogue past the initial request, an AS cannot drop an ongoing dialogue it is involved in before the end.

Any deviation from this approach would be a betrayal of core SIP routing procedures. This implies that what would be gained (an alleged flexibility in the relationship between the IMS core network and the IMS application layer) would be at the expense of the integrity of the SIP protocol, and everything it can bring to the delivery of next generation services.

This feature of the IMS service architecture is sometimes regarded as one of its "limitations". My belief it that those who think this is a limitation of the IMS service architecture are only projecting their own thinking limitations upon the IMS. They would like to engineer an IMS application layer exactly the same way they would engineer a circuit-switched application layer, instead of creating an application layer optimized around and making use of the unique features of IMS and the SIP protocol.

This feature also implies that the concept of "subsequent filter criteria", initially introduced in IMS specifications and never defined afterwards will never come to a reality, as they would violate the basic SIP routing procedures used over ISC. Subsequent filter criteria were introduced to mimic dynamic triggers in the Intelligent Network, which permit an application server to dynamically inform the switch about the events it is interested in.

Registration Case

The IMS application server may reeive 3rd party registration requests from the S-CSCF, indicating that an IMPU has registered/re-registered/de-registered with the IMS core network. this implies that in that case the AS acts as a SIP registrar.

As the 3rd party registration provides little details about the registration (for instance the capabilities of the IMS client are not provided), the IMS AS may need to automatically SUBSCRIBE to the registration event package asociated to the IMPU as soon as it has received the 3rd party REGISTER indicating it has registered.

IMS Application Server Initiating SIP Requests to the Network

An IMS application server can issue SIP requests on its own, without this request being tightly related to a request the AS previously received. The generated request might be a side effect of one or several SIP requests previously received by the AS, of interactions with an end-user performed through a non-SIP interface (e.g. web page, SMS), of interactions with a 3rd party service (e.g. web services), but these are only examples: anything can do, and the more intelligent the service is, the more spontaneous the generation of SIP requests can be.

SIP Roles

The IMS application server can act as a SIP User Agent. It is the initiator of the request and it will support the end-to-end SIP interaction with its SIP peer, whether this is an IMS client, an IMS application server, or another SIP entity outside of the IMS.

The IMS application server can also act as the 3rd party initiator of a dialogue between two other SIP endpoints, like two IMS clients or an IMS client and an IMS application server. In this case, the AS acts as an initiating back-to-back user agent (initiating B2BUA). This role can be used for example by a service to automatically set up a call between two users or implement a click-to-dial-back feature supported by a web page (the user clicks on a link to get called back by an operator. the service logic selects the operator and establishes the call between the two).

Note that an alternative way to implement 3rd party control is for the application server to use SIP REFER towards one of the SIP entities it wants to involve in the dialogue (e.g. the AS asks user A to set up a session with user B). This approach is simpler to implement from an application server perspective, as it does not require the usage of an initiating B2BUA, but it also requires the support of the REFER method by the SIP client, which is not a given in current SIP networks. The approach may also have an impact on how charging will be performed.

Originating IMS Identity

When it initiates a SIP request towards another IMS or non-IMS entity, the IMS application server (more precisely the service logic it hosts) has the choice between two possibilities.

The AS may act on behalf of an IMS user, and use an IMPU of this user as the identity initiating the request. Doing so, the AS can impersonate a user it serves, and for instance send an instant message or subscribe to the presence of a 3rd party just like the user would.

Note that this ability of an AS to issue a SIP request on behalf of a user (which may not be registered with the network at the time the request is initiated) is the reason why 3GPP had to introduce the initiating unregistered session case in the R7 specifications of initial filter criterias.

The AS may alternatively populate the P-Asserted-Identity header with a PSI, thus endorsing an identity associated with the service logic that initiates the request. For instance, an application server may initiate a request as a specific conference, voice mail account, or chat room.

Because it has a secure connection with the IMS core network and it is part of the IMS trust domain, the AS can directly set up the P-Asserted-Identity header with the IMPU of the user whose behalf it acts on or a PSI, ensuring that the IMS request was duly authenticated by the IMS network.

Routing of the Request

3GPP initially tended to be very restrictive about how the routing towards the IMS core network of a SIP request initiated by an AS could be performed. Fortunately, the latest specifications permit room for variants.

When the request is sent on behalf of a user, the AS may have to route the request to an S-CSCF serving the IMPU of the user, in order for originating services associated to the user to be executed (in this case the AS has to insert the "orig" parameter to indicate this is an originating request). The routing of the request to this S-CSCF might be direct, which implies that the AS knows the address of an S-CSCF serving the IMPU (possibly through a previously received request, or by retrieving it from the HSS via Sh), or through an entry point to the network serving the IMPU (which is less efficient but requires less knowledge from the AS).

Alternatively, and if the operator policy allows it, the AS may directly route the request to the network serving the destination address, thus bypassing potential originating services and charging procedures associated to the IMPU. This flexibility was not part of initial 3GPP ideas, but I always supported it as a simpler approach placing fewer constraints on the AS, and which is certainly adequate for some services.

The procedure for the case where the request is initiated by a PSI is similar, except that when the request is routed to an S-CSCF serving the PSI in order to apply originating procedures and execute originating services, the address of this S-CSCF is a priori static and can be configured in the AS (but it can also be retrieved from the HSS as well).

Note that the case where the AS has to route the request to a S-CSCF serving the IMPU or PSI requires an IMS-specific behavior that will impact non-IMS SIP application servers when they are ported on IMS.

P-Headers

This is another constraint associated to an IMS application server, and which needs to be considered when porting a non-IMS AS on IMS: the IMS AS is responsible for generating and inserting 3GPP-specific headers in the SIP request prior to forwarding it to the IMS core network.

Beside the already mentioned P-Asserted-Identity header, the AS has to insert a P-Charging-Vector header including a unique id for the transaction/dialogue (called icid) as well as an identifier for the network the request originates from (called orig-ioi). It will also have to process 3GPP-specific information coming from responses, like the identity of the terminating network (term-ioi).

Non-SIP Interfaces

Just a reminder: SIP is only one of the protocols that may be used by an IMS client to access an IMS application server. Therefore, this post is focusing on just one part of the inclusion of the IMS application server in its environment.

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

More on the SCIM!

Today is a "lazy post" day. I think I might do it from time to time.

In April, I made a series of three posts on the infamous IMS Service Capability Interaction Manager (SCIM).

In the first one, I described the history of the concept in 3GPP. In the second one, I reviewed the features usually associated to the SCIM, mainly to say that I do not like them. Finally, I presented some of my ideas on what a SCIM could be, would it try to add value on top of the intrinsic capabilities of IMS.

As the SCIM is a topic that seems to interest a lot of people, I decided to add a little bit more meat on this subject.

You can find below three sides I made two years ago, when I first tried to formulate my vision of the SCIM. I think I still stand behind most of what is written there, and normally (hopefully) this should be consistant with my previous post on the topic.





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.

Public Service Identity Service Patterns

In this post, I will try to present some potential usage of Public Service Identities (PSIs) for the delivery of IMS services.

Services to the World

PSIs were standardized for this, but it might be useful to highlight it: PSIs permit an operator to provide services that are accessible from any SIP network.

This means that the IMS Lantern chat room from the previous post, or any content identified through a PSI, is potentially accessible to all IMS subscribers of the world, whether their subscription is a fixed, mobile, cable, or converged one.

This also means that the same service is accessible from non-IMS networks with SIP connectivity like the Internet.

Combination of Private/Restricted and Public Access to a PSI

The previous post might have given the impression that a PSI can either be accessed by a happy few or by everybody.

Actually, this does not have to be. A PSI can be accessed in one way by a happy few, and in another way by all the others, and the way a PSI is accessed can determine the logic that is executed to process the corresponding SIP request in the IMS application layer.

Private/Restricted access to a PSI is determined by the service profile associated to the originator of the SIP request addressed to the PSI (i.e. the service profile of the user includes one or several initial filter criteria that relate to the PSI and permit to route the request to an application server).

What happens for users who initiate a SIP request to the PSI and do not have a PSI-aware service profile?

The IMS core network will try to route the SIP request anyway, and then there are two cases:

1) There is no way to match the PSI to a physical address, i.e. there is no service profile associated to the PSI, and it is not defined in any DNS (or ENUM) server or in the HSS. In that case, the PSI is really accessible by a happy few.

2) There is a "public" PSI routing mechanism, i.e. one of the three mechanisms described in the previous post. In that case, the PSI is also accessible to everybody. The public access mechanism may route the request to another application server or to the same one as the private/restricted access procedure. In any case, it is possible for an application server to determine how the SIP request was routed to the application server (i.e. either as an originating or a terminating request), and consequently to apply a different logic for each case.

Automatic Service Discovery and Configuration

I already gave an example of this mechanism with the automatic service discovery and configuration service pattern. In this example, John is subscribed to Service X, and consequently benefits from the restricted access configuration information associated to the service. His girlfriend Mary is not subscribed to Service X. If she issues a request addressed to sip:ServiceX@operator.com in order to retrieve service X's configuration information, the request will be routed to an alternative service logic, which will deny access to the information.

Restricted Access for Management of Public User Groups

Another example would correspond to a user group identified by the PSI sip:Friends_of_IMS@operator.

Anybody can use this PSI to send an instant message to members of the group, access their presence information, or start a multimedia session with them (public access to the PSI). All these services are accessed through the initiation of an adequate SIP request addressed to the PSI (i.e. MESSAGE, SUBSCRIBE for presence event package, INVITE). Routing to the relevant application server is based on the service profile associated the PSI (i.e. MESSAGEs go to messaging server, SUBSCRIBEs for presence event package go to the resource list server, INVITEs go to the multimedia conferencing server).

On the other hand, only a few users can manage the user group, i.e. add/remove users to it. This implies that SIP requests that permit to access and modify the definition of the user group (SUBSCRIBE, PUBLISH for a group management event package) are restricted to a limited set of people. These people will have their service profile defined in such a way that their management requests to the sip:Friends_of_IMS@operator PSI will be routed to the application server managing the user group. The same management requests issued by a non authorized user will not be routed to any application server and will be rejected by the IMS core network (the service profile associated to the PSI does not define any routing for PUBLISH and SUBSCRIBE requests related to the group management event package).

Differentiated Access to Content (see figure, click to enlarge)

The third example is illustrated by the picture at the top. The PSI sip:This_Content@operator identifies a specific content (e.g. a video) that can be accessed through a SIP session initiated by the user.

Four application servers serve the same PSI.

A and B serve the subscribers of the operator who are authorized to access the content. Access to these application servers is based on the service profiles associated to each subscriber. The service profiles associated to subscribers in the partition #1 route the service request to A, while service profiles associated to subscribers in the partition #2 route the service request to B. Service logic on A and B delivers the content.

C serves the subscribers of the operator who are not authorized to access the content. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is the one of the operator shall be routed to C. The service logic on C may show a preview of the content and propose the user to subscribe to the content.

D serves subscribers of other operators and users from the Internet. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is not the one of the operator shall be routed to D. The service logic on D may propose the user to pay for viewing the content.

It would be possible to further discriminate between users trying to access the content. For instance, the service profile associated to the PSI could determine that SIP requests which do not include a P-Asserted-Identity header (i.e. requests originated from a non-IMS network) should be routed to an application server E.

Christophe

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