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

Conflicting Views on the IMS Service Architecture

The two figures above both depict the IMS Service Architecture.

The first one is taken from the 3GPP specifications and is therefore the primary basis for anyone to understand the IMS Service Architecture.

The second one is my own representation of the IMS service architecture, based on the exact same specifications, and is therefore only accessible by the readers of this blog. As I have not seen so far a similar representation anywhere else, you can assume that this is not at the moment the mainstream perception of the IMS service architecture in the telco community.

IMS as a New Intelligent Network (IN)

The 3GPP representation of the IMS service architecture is network centric. It represents the IMS application layer solely according to its interface to the IMS core network, placed at the center of the figure with the S-CSCF.

This representation is potentially misleading as technicians with a classical telecom background can perceive the IMS service architecture as an IP replica of the Intelligent Networks that can be found in all existing fixed and mobile circuit-switched networks. Actually, I have seen this view supported numerous times, both by these people who know everything about telecommunications and by alleged IMS experts.

This IN perception of the IMS service architecture is re-inforced by the fact that two of the IMS application server types represented in the figure are tightly linked to IN: the IM SSF is a gateway between IMS and an IN application server, and the OSA gateway is usually (and rightly) perceived as being essentially an API on top of IN. Adding to the confusion, the terminology used for the IMS service architecture (e.g. trigger points) heavily borrows from IN (to be frank, some companies participating to IMS standardization did see this architecture as an IN one).

In an IN network, the (fixed or mobile) switch interfaces with the application server through a dedicated control interface (e.g. INAP, CAP, an IS.41 subset), which permits the application server to control the switch by issuing instructions to it. These instructions essentially serve the purpose to control voice calls, as the circuit-switched network is voice centric.

In such an architecture, the basic voice services are supported by the core network, which is complemented by application servers for the delivery of "supplementary" or "value-added" services.

With this kind of background, it is easy to perceive ISC as the IMS equivalent to INAP/CAP and the IMS application servers as an extension to the core network. Some might even argue that the IMS application layer is not needed, if you can implement all the required supplementary services within the S-CSCF.

IMS as a Totally New Service Architecture

However, the IN-oriented interpretation of the IMS service architecture does not resist a thorough analysis of the specifications that I tried to describe in past posts (here, there, there and there).

First, with the exception of the user registration part of the ISC reference point (which permits the S-CSCF to notify application servers about registration events, but does not permit the AS to block registrations), ISC cannot be seen as a logical interface between the S-CSCF and the application server.

On the contrary, ISC is only one branch in an end-to-end SIP interaction between the application server and other application-related entities. In such an interaction, the S-CSCF and the whole IMS core network only act as intermediaries and service-related routing functions between application-related entities. This is why I tend to represent the whole IMS core network as a SIP-oriented service bus supporting the IMS application layer (I will come back on this in a future post). This bus is essential for the IMS application layer, but its significance is close to zero from a service perspective. Suffice to say that it duly supports its service bus role, and that the best additional value it can offer to applications is to be totally transparent to them.

The second essential characteristic of IMS that dismisses the claims of an IN replica is that SIP is not the equivalent of SS7 over IP:
- SIP sessions are not voice calls. They are much more generic service sessions, which may even not include any voice or person-to-person communication component.
- SIP is not only about SIP sessions. Other SIP methods make SIP a very generic service control protocol.

With such a knowledge in mind, it is irrelevant to represent the IMS service architecture without representing what is on the other side of ISC (and other SIP-relate reference points supported in the IMS core network). My figure tries to represent all the possibilities.

However, this figure is still incomplete, as it focuses on the SIP dimension of the IMS service architecture. For a more complete view, look at this previous post.

The End-To-End IMS Service Architecture (SIP Dimension)

Many possibilities exist, that I already described in the past (here, there and there), but I will summarize below (note that the examples are very basic).

An IMS endpoint (terminal, endpoint application server) in the operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.

An IMS endpoint (terminal, endpoint application server) in another operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.

An endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. enterprise network, the Internet) initiates a service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence. Note that the non-IMS endpoint may either use SIP or another protocol to initiate the interaction. In the latter case, a protocol converter (e.g. Jabber to SIP) will translate the initial request into SIP.
Specific case: the non-IMS endpoint is an application server (e.g. Internet application requiring user's presence).

The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in the same operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user.

The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in another operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user of another operator.

The application server initiates a SIP service interaction with an endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. in an enterprise network or in the Internet). ISC is the first branch used in this interaction. Example: application server sends instant message to user in the Internet. Note that the non-IMS endpoint may either accept SIP requests or not. In the latter case, a protocol converter (e.g. SIP to Jabber) will translate the initial request to the required protocol.
Specific case: the non-IMS endpoint is an application server (e.g. presence server).

The application server initiates a SIP service interaction with another IMS application server in the same operator's domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.

The application server initiates a SIP service interaction with another IMS application server in another operator's IMS domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.

An IMS application server acts as an intermediary in any of the interactions listed above, plus the essential case where none of the service interaction endpoint is an IMS application server (e.g. two IMS devices, an IMS device and a non-IMS device, an IMS device and a non-IMS endpoint application server). The idea is for the intermediary AS to either control or add-value to the end-to-end interaction. ISC is a branch somewhere in the middle of the SIP signalling path. Note that several IMS ASs can be inserted as intermediaries in the signalling path, forming a chain of combined services. Examples: IMS AS authorizes and/or charges for access to service, IMS application server inserts media plane intermediary to improve user experience (e.g. media mixing, media transcoding).

User Oriented Service Routing

The SIP dimension of the IMS service architecture relies on two SIP routing mechanims:
1) Standard SIP routing (labelled in the figure as IETF SIP routing) based on the resolution of the target SIP address towards an endpoint.
2) IMS User Oriented and Service Profile based routing (labelled in the figure as user profile based routing), which permits to dynamically alter SIP routing on a user-per-user basis towards IMS application servers. The service profiles stored in the HSS can be seen as service routing routing under the control of the operator and modifiable over time. This permits to incrementally modify SIP routing as applications are added or removed from the network, and this without impacting endpoints.

This draws a service architecture which is very flexible in terms of service logic location (in service entities like application servers in the network, endpoint application servers, devices), very flexible in terms of location of service entities in different domains (the operator's domain, another operator's domain, an enterprise domain, the Internet) and very agile in its possibility to dynamically modify service logic at work in the network.

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

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

Here is my SCIM

I am far from convinced that the SCIM, as it is usually promoted by suppliers, or as it is currently being standardized by 3GPP under the name of Service Broker, is an essential feature for an IMS that does not limit itself to the reimplementation of legacy telephony over IP.

It can be argued that what I am going to describe in this post is not a SCIM. I would prefer to give it another less ambiguous name, such as Service Dispatcher (Service Broker is already taken). The concept was already discussed with a big IT supplier, and may eventually be implemented as part of their service platform.

Personalized Service Chaining

For me, one of the great features of the IMS service architecture is the possibility to chain services on the SIP signalling path and to have this chaining personalized for each user.

IMS service chaining is based on service profiles, stored in the HSS, and associated to IMS Public User Identities (IMPUs). In practice the same service request originated by or addressed to two different IMPUs can be chained totally differently for each of these IMPUs. The two IMPUs may either be associated to different users, or may implement different personas for the same user.

Service chaining can be very interesting for composing IMS services. There might be several cases (see also this post):
- Two chained services may exert control on the same end-to-end SIP transaction or dialogue, without having to be aware of each other. This is for instance the case when a voice call continuity service (VCC) is composed with other session management services. As long as VCC and the other session management features are chained in the right order, end-to-end behavior will remain consistent. In practice, many typical service interaction management use cases can be solved through a proper chaining of services on SIP signalling.
- A service may impact end-to-end signalling with the knowledge of how service logic further down the chain will react to the change.
- A service may initiate new SIP interactions as a consequence of being in the SIP signalling path (e.g. send an IM to a user)
- A service may monitor SIP signalling without any intention to impact it (e.g. a messaging archive).

It is important to note that service chaining on SIP signalling is very interesting, but is not the panacea to address all service composition use cases. More especially, it may need to be complemented with more classical web service orchestration higher up in the service logic.

Need to Complement S-CSCF Service Chaining

I do not support the opinion that the current specification for service profiles (initial filter criterias) and for service chainiing by the S-CSCFare too limited and should be extended to handle more criteria such as time or presence information. I find that the current mechanism is both efficient and reasonably simple. If more advanced mechanisms are necessary, they should be implemented in the IT-centric application layer, possibly in the SCIM.

On the other hand, taken in isolation, S-CSCF -based service chaining is not enough, and it has the following issues:
1) It may lead to a heavy processing by the S-CSCF of SIP interactions with application servers, in addition to the other tasks it already has, i.e. virtually doing everything in the IMS core network (e.g. user registration & authentication, end-to-end SIP routing, generation of charging information, etc).
2) Multiple SIP based interactions between the S-CSCF and application servers may lead to bad end-to-end latency for service delivery. These latency issues may potentially lead the operator to limit service chaining for the sake of service usability.
3) Chaining actually concerns application servers, and not individual services hosted by each of these application servers.

Issues #1 and #2 should be addressed via service co-location. It should be possible for an operator to co-locate on the same server, for a given user, services that are likely to be chained together or that generate other SIP interactions (e.g. presence based service accesses presence).

This requires a change of mindset for service topology from a service centric to a user centric approach. Instead of having a server = service(s) approach in which, for instance, presence is implemented a dedicated server aiming at serving all users, personal services should be deployed as much as possible according to a server = users approach. In this context, presence, which is the prototype personal service, could be implemented as an application co-located with other applications using it as an enabler, on application server instances each serving a subset of the users.

Such a service co-location approach reinforces the need for the adoption of standard and open IT-centric service platforms that I already mentioned.

#3 requires the possibility to chain services together at a finer granularity than the S-CSCF, and to do it inside the application server itself. Service co-location makes this need even more essential.

Main Features of the SCIM

In this context, the SCIM performs in the application server, and at service level, what the S-CSCF does in the network and at application server level. Its role is therefore to select and chain the services that need to be executed when a SIP standalone or initial request reaches the application server.

The SCIM exploits and complements the IMS capability to have a personalized chaining (composition) of services on the signalling path associated to a SIP request. Of course, SIP requests may relate to a large variety of services, and are not limited to telephony or even to session control.

The SIP chaining mechanism of the SCIM is very similar to the one supported by the S-CSCF. The user "service profile" used by the SCIM might have similarities and differences with the initial filter criteria of the service profile used by the S-CSCF. All potential enrichments desired for chaining decisions can be implemented at the SCIM level.

The SCIM is one of the orchestration mechanisms supported by an IMS application server, which is SIP centric. Web Services oriented service orchestration is to be supported by a complementary component of the platform.

The platform is typically implemented as a JAIN SLEE or Java EE (J2EE) server supporting SIP servlets. In the latter case, the SCIM can be implemented as an application router in JSR 289.

Such a SCIM aims at enriching the user oriented nature of the IMS service architecture and at providing a highly customizable and differentiated service experience between IMS users. At the same time, it can fulfill many typical service interaction management use cases that are targeted by service broker standardization.

Other Potential Features for the SCIM

I like the idea of keeping a SCIM well focused and simple enough to be managed. However, the core functionality described above can be extended directly in the SCIM, or through some complementary components added to it.

Here follow some examples.

An IMS application server needs to follow some rules when interacting with the IMS core network. For instance, when a service initiates a SIP request out of the blue, it needs to include relevant information such as a an original ID for the SIP dialogue/transaction or a charging vector, and it may be mandated to route the request to a specific S-CSCF when this request is initiated on behalf of a user. This task may be handled by the SCIM, if it is not by another component or by the application itself.

As part of its service selection and chaining task, the SCIM may forward a SIP message to remote application servers. By doing so it partly takes over the responsibility of the S-CSCF and permits to offload the IMS core network from a part of application layer related SIP interactions.

A remote application server may not comply with IMS extensions to SIP, and may therefore not be able to exploit them (for instance, a non IMS application server may not be able to extract the asserted identity of the request initiator from the 3GPP specific P-Asserted-Identity header). In this case the SCIM may adapt SIP messages between between IMS and the non-IMS application server.

A remote application server may belong to a 3rd party service provider. The SCIM or a complementary component may support policies for interactions with this 3rd party.

The SCIM may possibly translate SIP requests into web service requests or other application-related interfaces.

July 6th 2007 update: I made another post on this subject, with figures.

Christophe

IMS Service Logic Distribution

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

In this post I will explore different distribution possibilities.

Intelligence in Endpoints or in the Network?

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

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

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

IMS is therefore an intelligent network for intelligent endpoints.

Personal and Shared Services

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

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

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

End-to-end Service Chaining

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

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

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

SIP and non-SIP Service Logic

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

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

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

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

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

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

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

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

Future posts will further investigate these possibilities.

Christophe

IMS Service Interaction Use Cases: Part 3

The last two posts presented service interaction use cases which applied end-to-end, between service entities consisting of clients and application servers. They distinguished between cases where the initiator of the service interaction was a client and others where it was an application server.

These simple use cases can be made more interesting by the addition of application servers between the endpoints, in order to add value to end-to-end service interactions. All these application servers make use of the IMS service architecture and sit on the IMS Service Control (ISC) reference point. This said, there can still be multiple variants for the way the services on the application servers behave, leading to a vast array of service possibilities.

In this post I will try to introduce these service variants, at least those I can think of.

The service may either act as a SIP proxy (a) or as a back-to-back user agent (B2BUA) (b). Without going into details, the proxy behavior permits little control on the end-to-end SIP interaction and generally applies to services that simply monitor SIP traffic or perform actions which do not directly impact the end-to-end service interaction (e.g. the service initiates a new service interaction as a consequence of the one it is proxying). On the other hand, acting as a B2BUA is more adequate for services which intend to control the end-to-end service interactions (e.g. changing a leg, modifying session description).

The service either inserts itself in a service interaction initiated by a peer (i.e. a client or application server use case from previous posts) (c), or the service is itself the initiator of the service interaction between the peers (d). For instance, the service initiates a session between John and Mary.

The service may be tranparent to the peers involved in the service interaction (e). This is the case when the service only adds value to an otherwise peer-to-peer service interaction. Alternatively the service may be visible, i.e. it appears in SIP signalling as the recipient or initator of SIP messages via its Public Service Identity (PSI) (f). In this case the service is offered as such to the peer, and its implementation happens to be a facade (or a frontend), which makes use of other services or connect to other peers to deliver its features. For instance, a multimedia content service identified via a PSI actually aggregates individual media components accessible via SIP as part of its delivery session. Note that SIP is only one of the protocols that the facade service can use towards backend services.

The service may either apply to one peer of the end-to-end service interaction (e.g. John) (g) or be shared by all participants in the peer-to-peer relationship (h). In the former case the service is personal to a user and may be customized specifically for him/her, while in the latter case the service is shared between two or more users. A typical example of a shared service is one that supports the multi-party nature of a SIP service interaction, e.g. a multimedia conference server, or a chat room for IMS.

The service may either be the single intermediary between the peers (i), or may be chained with other services (j). An example of chained services on a service interaction path of type messaging (SIP MESSAGE) could be: an anti-spam service, an anti-virus service and an archive service. Another example applied to VoIP would be the chaining of a voice call continuity (VCC) server responsible for switching between WiFi/IMS and cellular/circuit-switched during the voice call, with a voice application server supporting typical telephony features for the user.

In the case where a service is part of a chain, there might be two variants: either the service is independent of the other services further down in the chain (k), or it has been developed with the knowledge of the intended/possible signalling path and with the intention to have an impact on services further down in the chain (l). The examples given for (j) belong to the first category, as each service is independent from the others. An example of a service of the second category would be one that forwards an intended SIP interaction to one PSI or to another, thus impacting the service chain. Another example would be a service that adds or removes a parameter in the SIP message in order to trigger or inhibit a service or feature somewhere down the path.

Finally, a service may systematically act as an intermediary in the peer-to-peer service interaction (m) or may sometimes decides to take over the role of the peer for the service interaction (n). In the VoIP example given for (j), the VCC server will always act as an intermediary, while the voice application server may sometimes act as an intermediary when it decides to let call setup happen, or as a peer if it decides to reject the call attempt on behalf of the user it serves.

Maybe with a little bit more thinking I could find more variants in order to go up to the letter "z". The point I am trying to make is that there are too many variants for involving application servers in the middle of peer-to-peer SIP service interactions for me to even try coming up with a complete list of use cases.

However, in future posts where I will try to give examples of potential IMS services, I will certainly refer to the framework defined in this post and the previous two.

Christophe