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

IMS Service Features

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

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

The power of SIP

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

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

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

User-based Service Routing

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

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

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

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

User-centric Service Architecture

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

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

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

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

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

Implicit Addressing for Some Personal Services

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

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

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

Single User Identity / Multiple Services

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

Virtual Service Location

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

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

Network-based Service Authorization

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

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

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

Personalized and Shared Service Access

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

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

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

Integration of non-IMS services with IMS

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

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

Service Anthropomorphism

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

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

Christophe