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