What is an IMS Service?

Considering the current fuzziness around IMS, it is a remarkable fact that there is not even a common understanding of what an IMS service is. For anybody who can't provide such a definition or is giving a wrong one, promoting IMS as the next big thing or dismissing it as the next big telco failure are equally blind statements.

In this post I will try to clarify this issue and provide my own definition.

In the following, I will often distinguish between SIP, the Internet protocol, and IMS, a specific architecture making use of SIP.

Often Heard

For many, an IMS service is a service that is developed specifically for IMS, and which uses SIP as its main, if not unique control protocol. Push to Talk over Cellular (PoC) or VoIP based on SIP and IMS are typical such services.

Another common statement is that IMS will not be used to develop new services, but to re-implement existing services with a new architecture and a new control protocol.

From these statements can be derived many interesting questions, including the following.

Aren't web services a better approach and isn't SOA a more adequate architecture to deliver services?

Isn't Jabber/XMPP a better protocol than SIP to support Instant Messaging?

Isn't the fate of SIP (and IMS) already sealed, considering that many of the most important companies delivering communication services to very large communities over the Internet have decided to go for alternative (standard or proprietary) protocols?

Is there any viable future for a network and a protocol that are inherently incapable to foster service innovation?

I will come back on these questions in the following, either directly or indirectly.

There will be be a huge (global) IMS and (global) SIP community, covering both telco networks and the Internet

First, while this is true that major communication applications running on the Internet do not all make use of SIP, it should be acknowledged that this is not the rule. The popular communication application provided by the company founded by the wealthiest man on earth is based on SIP, even if some "optimizations" brought to the protocol do not make it directly interoperable with other SIP-based clients. Th Gizmo project pushes forward the fact that SIP is a standard, and therefore permits interoperability. A famous Internet company uses both Jabber/XMPP and SIP for its communication services.

IMS is an architecture and a standard supported by standardization forums like 3GPP, 3GPP2, ETSI TISPAN, CableLabs, and the WiMax Forum. As a consequence, every operator in the world supporting a single or a combination of access technologies (ex. fixed broadband, cable, licensed or unlicensed radio access) should to at least consider IMS as a candidate in its roadmap. It is very likely that a significant number of operators will opt for IMS, thus creating a huge community of SIP and IMS users across the world.

The intrinsic capabilities of SIP as a control protocol (see Index for several posts on this subject), and the integration of SIP servlets support in all J2EE platforms, even in the versions that are not aimed at the telecommunications market, make that it is possible to eventually see SIP used in other domains that those which directly relate to telecommunications, and for applications which do not focus on person-to-person communication.

All in all, there is a high probability that the SIP community eventually exceeds in dramatic proportions all communities relying on other protocols for communication.

Note that as long as interoperability is ensured, there is no need for all parties in this community to rely on the same architecture or on the exact same SIP profile.

A very valid question is whether a non-IMS SIP community can supersede and eventually kill an IMS SIP community. The temptation of certain telecommunications actors to artificially create an IMS SIP walled garden by adding barriers in IMS standards between IMS SIP and non-IMS SIP clients and applications is an implicit invitation to a war, which may eventually damage the whole SIP ecosystem (however, it is important to note that many telco actors do not want such a fight and may find ways to eliminate these barriers - this may be stating the obvious, but the telco domain is not only standard-driven: business concerns are more fundamental). Otherwise, I guess that this is essentially a question of service offering and business model. If a user can benefit from similar or better services from an alternative service provider, and for a lower cost, it may be tempted to bypass the IMS-based offer.

SIP does not have to be the only communication protocol to be successful

Once again I am stating the obvious, but there is such a thing as protocol gateways, enabling interoperability between communication and control protocols, even if this conversion has to be adapted to semantical differences between protocols and may only address the common functionality between them. In the case where the protocols that need to interoperate are both standard, the conversion may itself be standard, as this is the case between SIP and XMPP (last time I checked the standardization of this particular gateway was work in progress).

An existing service can become an IMS one through integration

The thought that a service has to be specifically implemented in order to run on IMS and to be SIP-centric is wrong.

Access to a service can be preceded by a SIP interaction. The binding between SIP and the service specific protocol(s) usage can be supported by such SIP mechanisms as content indirection or the use of the SIP method REFER. I wrote a post on this subject, giving examples of this type of integration and describing some of the advantages associated to it.

Another way to integrate a non-IMS service with IMS is to encapsulate the delivery of the service within a SIP session: SIP is used to manage a session between the IMS client and the server supporting the non-IMS service (or an IMS application server acting on its behalf), while the service specific protocol(s) is (are) used to deliver the service within the session. I also described this approach here.

Integrating a service with IMS does not necessarily require that the existing implementation of the service be modified to incorporate components addressing the SIP specific logic. This SIP logic can be isolated and deployed on a SIP application server that is remote from the server supporting the legacy non-IMS logic, keeping the overall integration process simple from a service delivery perspective.

Yet another integration approach can be limited to IMS being used for service discovery, subscription and configuration, while service delivery is integrally supported outside of the IMS domain. I wrote a specific post on this subject.

This integration subject is a central topic of the article I wrote for the IEEE Vehicular Technology Magazine.

This means that a lot of future IMS services might already be out there. As an example, an existing Video on Demand (VoD) service might be integrated with IMS using the service discovery, subscription and configuration approach, and/or service delivery through content indirection, REFER, or within a SIP session. The service-specific protocol is RTSP and the binding between the service and IMS for content indirection or REFER is supported through the usage of the RTSP URI within SIP methods.

IMS can be used to combine multiple services

A non-IMS service delivered within a SIP session can be combined with other non-IMS services delivered within the same session, either simultaneously or sequentially. In order to optimize this combination from a user perspective, the IMS-based SIP logic might insert an intermediary on the media plane in order to mix/combine the different services at the media level. For instance, the media intermediary might mix the soundtrack of the video with another audio source, or insert textual messages in the video. See this post for an example.

Through an adequate conferencing support, the service can be shared between several users, and combined with person-to person communication components. For instance, the video of a VoD service can be viewed by different users in remote locations, who can exchange their comments through a messaging, a video or a voice communication component.

If there is the need to find a single reason to integrate a non-IMS service with IMS, then the possibility to combine it with person-to-person communication is this one, considering that communication is the core business of telecom operators. However, I hope I have illustrated in past posts that there could be other important motivations for such a combination.

Existing services can be enriched through SIP and IMS

IMS can support a large number of enablers implemented through application residing in SIP application servers or directly supported by terminals or endpoint servers connected to the IMS.

This permits existing services to be enriched with logic making use of IMS-based application like presence (providing information about the user, its communication means, its terminals, its applications) and group management (defining a standard way to access and manage groups of users, to which the service can be delivered simultaneously or which define who is authorized to access the service).

Enablers supported directly by terminals may enable real time communication between the service and the user, provide real time and accurate information about the user, its terminal(s) and its applications, or use SIP as a transport protocol to exchange service control semantic with a remote application server. SIP event packages may typically be used for this. For instance, existing event packages may permit the service to know if a user is currently involved in a SIP session or typing on its keyboard. New event packages can be defined permitting the service to access information or being notified about events related to the user, a terminal, or a specific application. A straightforward example is one where the service would retrieve the location of a GPS-enabled terminal.

Enrichment of an existing service through the usage of IMS-supported enabler(s) requires a modification of the existing service logic to make use of these enablers, even if the SIP/IMS specific part of it can be encapsulated through the usage of appropriate APIs.

Services can be delivered through complementary usage of SIP and other protocols and architectures

It would be a fundamental misunderstanding to believe that an IMS service has to uniquely or even essentially use SIP to be delivered.

The IETF applies a building block approach to specification, with a continuous concern to make every concept as generic as possible, and to always look at what has already been specified, even in adjacent application areas, prior to reinventing the wheel. SIP is a remarkable example of this, and as a result. The IETF community systematically tries to ensure that every SIP extension avoids to betray the spirit that governed the initial creation of the protocol, that every extension is made generic enough to be used beyond its initial purpose, and that mechanisms exist to combine SIP with other protocols that are optimized for fulfilling specific needs. SIP sessions, content indirection and SIP REFER are examples of mechanisms created to enable such a combination see here or in the Index). The building block approach to SIP specification is an interesting topic in itself, that I will address in the next post.

Another fundamental misunderstanding would be to believe that the IMS service architecture is incompatible with other service architectures and their associated protocols. It was specified from a SIP-centric perspective, focusing on the relationship between the IMS application layer and the IMS core network. However, 3GPP did not want to address the details of how the the IMS application layer would be implemented, leaving room for integration with other appropriate architectures and protocols.

As an example, SOA (Service oriented Architecture) and web services are not alternatives to IMS and its service architecture, but powerful complements to them and the usage of SIP as a service control protocol. I already wrote several times on this particular topic (just look at the IMS Lantern Index).

An important question is how the integration of IMS and SOA should be performed. At the moment, the prevailing understanding is that it should take place uniquely through the definition of web services, permitting to integrate a SIP-centric IMS with a web services and SOA -centric application layer. I believe that this view is incomplete and that the optimal integration between IMS and SOA should be more intimate, considering that IMS service logic should combine the direct usage of SIP and web services for service delivery, instead of only developing SIP-centric logic and web services -centric logic connected through a loose web services adaptation layer, similar to the one that connects the pre-IMS networks with SOA. I gave a name to this more intimate integration architecture, which extends both OSA and the standardized IMS service architecture: the User Oriented Architecture (UOA).

This distinction between a future service architecture integrating IMS and SOA solely through a web services adaptation layer (which makes that IMS is simply integrated in a SOA-centric service architecture) or through both a web services layer and direct usage of SIP by applications, might look artificial, but it provides alternatives considerations to the following issues:

- How to share a service context between IMS-centric logic and web services -centric logic? In the SOA-centric architecture, contextual information needs to be exchanged through web services defined between the IMS domain and the SOA domain, and may be limited to what is feasible or what has been done there. In a UOA architecture, this context can be naturally internal to the logic making use of both SIP and web services.

- Which IMS service enablers are provided to services in the application layer? In a SOA-centric application layer, this set of services enablers is limited to the set of web services exposing IMS capabilities to applications, while in a UOA architecture it can be extended to whathever the SIP protocol permits at any time. In a SOA-centric architecture, if no web service has been defined to expose a particular capability to applications, then no application will try to use this capability and the potential for innovative services will be limited. Typically, web services defined by people and organizations viewing IMS as a network and a set of standardized enablers like presence and group management are likely to miss most of the capabilities that are terminal and endpoint -related, as terminals and IMS endpoints tend to be considered more as consumers of network-based services than intrinsic parts of the service architecture. Will the set of web services exposing IMS capabilities to applications ever permit applications to access information generated by another application residing in an IMS terminal, like a game, if the service architecture assumes that IMS capabilities are only those that are accessible through web services defined by network people?

- How can IMS service enablers be used by applications? The synchronous nature of web service is likely to limit these enablers to those that can easily be rendered in a synchronous manner. In some cases, mapping the asynchronous capabilities of SIP to a synchronous interface might limit the usability of these capabilities or make them complex and unattractive to use. Directly using an asynchronous protocol like SIP to access asynchronous capabilities is likely to be simpler.

- Can all services be efficiently delivered to users? A complex architecture clearly discriminating between IMS/SIP -centric entities on the one hand, SOA/web services on the other hand, and forcing a web services -centric mapping between the two is likely to induce delays in the end-to-end delivery of services, as service delivery needs to cross several technical domains, while these delays could be largely reduced in a more integrated architecture.

- What is the cost for IMS services? The previous point hints at a more complex architecture induced by the definition of IMS and SOA -centric servers, and a gateway functionality between them. To this you can add the systematic duplication between web services and SIP interfaces induced by the SOA-centric architecture.

- How fast can new services be created and deployed? If you need to specify and implement a web service for each and every IMS capability, service creation is likely to be slower than if direct usage of SIP by applications is possible.

In addition to combining SIP with other IP and Internet service control and delivery protocols, like HTTP or RTSP, and integrating SOA and IMS, web services and SIP in a new service architecture called UOA, another important aspect that is not described in IMS specifications is to permit IMS applications to access capabilities available in pre-IMS telco networks, like user location (access to location servers), user registration status in the circuit-switched network, call control in the circuit-switched network, SMS, MMS or email as messaging enablers. Some of these enablers that are IP-based can be used in a straightforward manner. Others may require gateways between the IP and circuit-switched worlds, which may be based, on the usage of OSA/Parlay gateways but also on more specific protocol converters.

Therefore, the IMS service architecture can go well beyond the support of SIP and access to access to IMS-based enablers. Here is an overview of this scope.

Conclusions

An IMS service is a service that makes use of SIP and the IMS either centrally or marginally.

SIP itself and even more the combination of SIP with other protocols can give birth to a flurry of new services, some of them implemented on IMS.

The ability of SIP to combine various existing services of different types (communication, data, content, applications) can give birth to a new user experience, which is by itself a new service. This is an important matter to consider when comparing SIP with more purpose-centric protocols.

These new services can reach a huge community covering all the continents, all types of access technologies and spreading between telco domains, other business domains, and the Internet, possibly redefining the definitions of these domains.

IMS and SOA are not alternative architectures to deliver new services. They should rather be seen as building blocks permitting to create a new and more powerful service architecture called UOA.

This draws a potential future world, in which there might be a little bit of SIP everywhere, and consequently a a good potential for IMS to fit as a particular SIP service architecture deployed by telco operators.

However, history shows that the best technologies do not always prevail. In a possible future, the potential of SIP as a service control protocol used in different architectures including IMS, and/or IMS as a service architecture augmenting the intrinsic capabilities of SIP, might eventually fail. Conversely, would SIP and/or IMS be only used at a fraction of their potential (e.g. for VoIP and a limited set of additional services), they could still be a success.

Christophe

An IMS Application Server in Context

The figure above (click to enlarge) shows how an IMS application server can fit in a service delivery context that includes a legacy telecommunications environment, the Internet, the IT environment of the users it provides services to, and (of course) the IMS.

This picture might not be perfect (though I like the shades of blue), but let me know if you can find much better in the current IMS literature.

A specific instance of an IMS application server may only implement a subset of the features shown in this figure, depending on the capabilities of the platform supporting it, and its potential specialization based on the logic it supports.

It is not the purpose of this post to discuss the technologies that can be used to support such an IMS application server. However, if you look for platforms able to support most of what is implied here, J2EE and JAIN SLEE are certainly the best candidates, and a combination of both might be the winning ticket right now.

Pre-IMS Context (white boxes, black arrows)

The white boxes and black arrows represent the typical pre-IMS context of an application server, that applies to most current Service Delivery Platforms (SDPs).

Applications implemented on the application server can make use of a set of network capabilities such as call control, location, SMS, MMS.

Each set of capabilities is supported by a dedicated network server (e.g. switch, location server) and through a specific network to network interface (e.g. INAP, MLP).

On top of these protocols, the typical SDP provides for the service logic it hosts such features as horizontalization (e.g. hiding of the underlying stove pipes), homogenization (e.g. via a set of similar APIs), simplification (e.g. hiding details of ugly telecom protocols), and abstraction (e.g. permitting to manipulate a call at a high level).

It also exposes the capabilities to 3rd party service providers, through CORBA APIs (e.g. Parlay Classic) or web services (e.g. Parlay X).

The set of capabilities available to service logic in the SDP and to 3rd party service providers is limited and static. It followed a very slow standardization and implementation process, starting with the standardization of the network enabler (e.g. IN), and finishing with the implementation of (standardized) web services (e.g. call control). This means several years.

IMS, and more generally the move to all-IP can change all this and make the picture more colorful.

Where is the IMS Core Network? (lower part)

You might have noticed that the figure does not show any IMS core network entity (e.g. CSCFs, HSS, gateways).

This is not because they are not there or they are not important to the IMS service architecture. Actually, without them, the IMS service architecture would not exist at all!

The point is that the IMS core network itself is of limited relevance from an application perspective, compared to the sophisticated SIP routing mechanisms it provides. This is an aspect that is usually overlooked, as the IMS core network is often the tree that hides the forest to those who try to understand the IMS service architecture.

For instance, I believe that ISC (IMS Service Control) should not be considered as an interface between the S-CSCF and the IMS application server, like INAP is an interface between a switch and an Intelligent Network server. ISC is just the SIP road that permits to connect the IMS application server to the IMS/SIP motorway that connects all the blue entities in the lower half of the picture.

One of my core beliefs is that, among all the benefits the IMS core network can provide to its application layer, one of the most important should be its transparency. An application should only care about what the IMS architecture can provide to it, not about the sophisticated details of how this is done. The application should only know that by issuing this SIP message to this user identity, it will be able to magically access this enabler (e.g. the presence information of this user), and that is all. This is unfair for the hundreds of pages that specify the IMS core network, and the thousands of workers that implement or will operate it, but life is unfair.

SOA and UOA (upper vs. lower parts)

As I wrote in an earlier post, the IMS service architecture as it is depicted in 3GPP specifications is like a picture of a person which would only show its lower half. The reason for this is that 3GPP IMS specifications are core network centric, and only address the relationship between the IMS application server and the core network.

Whereas the pre-IMS application server only exposes a few web services to (hypothetical) 3rd party applications, the future application server should be an integral part of a service oriented architecture, in which applications deployed in the operator's domain could as much be consumers of 3rd party services as they expose some, and could as well integrate with the user's IT environment (e.g. calendar, applications running at home or in the office).

This Internet and IT -centric dimension of the application layer is complemented with its IMS and SIP counterpart (SIP is not the only service protocol that will be used in the IMS, and IMS is not the only network making use of SIP), which adds user orientation to the global service architecture.

To over-simplify, the service oriented architecture routes service requests according to the identity of services, while the user oriented architecture enabled by IMS and SIP can route service requests according to user identities, service identities, or a combination of both. As a consequence, the identity of a user placed in a SIP message (as originator or recipient) may impact service routing and direct the SIP service request to network-based applications serving the user, client or endpoint applications serving the user, or the user itself.

In terms of semantic, it is time for the large part of the telecom industry that still ignores it to understand that the concept of SIP session is much broader than its legacy "call" counterpart, and that SIP is not limited to session control. There are other SIP methods and mechanisms which could be of great interest in the future application layer (e.g. SIP event packages), and which sometimes overlap with the semantic usually associated to web services (e.g. will you use a web service or a SIP SUBSCRIBE to access user information?).

IMS Capabilities: Numerous, Dynamic and Everywhere (lower part left)

The semantic power of SIP, as well as its extreme extensibility and versatility compared to telecom protocols (just look at the rate new SIP drafts pop up in the IETF) make that capabilities usable by applications can be varied, dynamic and multiple.

These capabilities will seldomly be located in standardized network servers like today.

Some will be located in IMS application servers. Every new IMS application exhibiting a SIP interface to end users might be usable as an enabler by other applications using the same SIP interface. Some of these applications could themselves be used as enablers, and so on,

Other capabilities will be located in endpoint servers and devices connected to the IMS, including those associated to end users in a fixed mobile converged environment (e.g. mobile phone, PC at home, home gateway, set top box, fixed phone). Every new application deployed in these endpoints and devices may give birth to new enabling capabilities usable by the IMS application layer. Just to take an example, there exists today a SIP event package that can be used to monitor the activity of a user on a keyboard.

Access to these enablers located in network application servers, IMS devices and enpoint servers, can cross network boundaries. This is, an application located in operator X's network can access an enabler located in or registered with operator Y's network or in the Internet. For instance, an application associated to John, subscriber of operator X, can access the presence of Alice, subscriber of operator Y, and the presence of Bob, located in the Internet.

Web Services, SOA: Much More Possibilities (upper part center)

The multiplicity and dynamicity of IMS service capabilities permits the operator to offer a much richer and differentiated set of IMS services to 3rd party service providers.

Besides the usual communication-related suspects, a large portion of these services are likely to be informational: information about the user, its preferences, its data, its applications, its devices, its activity, etc. It will be the responsibility of the operator to preserve the intimacy and privacy of the users.

The dynamic approach implies that operators will have to rely less on standards and more on differentiation in order to attract third party service providers. This is one example, among others, about the need for the telecom industry to find a new balance between standardization and differentiation.

Web services are not the only way to integrate 3rd party services in the operator's offer. This integration can also be performed on a more horizontal axis.

3rd Party Services Integrated Through End-to-End SIP (bottom part right)

3rd party applications located in the IMS (e.g. in a different operator's network) or in a non-IMS network (e.g. the Internet) can have an end-to-end SIP interaction with the IMS clients of the operator's subscribers. These rd party applications may either be network-based (e.g. implemented in an IMS application server) or device/endpoint server based.

This end-to-end service interaction can be placed under the control of the IMS application server, as soon as the service profile of the user is provisioned with an initial filter criteria that identifies end-to-end SIP signaling between the user and the 3rd party application.

For instance, routing of SIP signaling to the IMS application server may be determined by the fact that the SIP request is addressed to a specific SIP URI (e.g. sip:this_service@3P_SP.com), a specific SIP URI domain (e.g. 3P_SP.com), or because the SIP request explicitly identifies a 3rd party application in a SIP header or in an SDP (session description protocol) body. For instance, the name of a game could appear in the session description of a SIP INVITE aiming at starting a gaming session.

Service logic inserted in the signaling path between the user and the 3rd party service can serve various purposes: control, charging, monitoring, adding value. Do not overlook the latest item: telecommunications should not be only about control and charging.

3rd Party Services Through SIP Indirection or Inclusion in SIP Session (same)

This is just a variant of the previous one.

This case differs from the one above because SIP interaction only takes place between the user and the service logic hosted in the IMS application server.

The 3rd party logic or content is accessed/controlled through other protocol(s) than SIP (e.g. HTTP, RTSP, web services).

I already gave an example of such an integration through SIP indirection. In the future, I will post another one showing inclusion of 3rd party content in a SIP session controlled by the operator.

The Ut Reference Point (lower part left)

The picture shows the support of the Ut interface which, in the IMS service architecture, permits an IMS client to interface with the IMS Application Server using XCAP (HTTP-based protocol that manipulates XML documents) for service data management.

I extended this interface to HTTP in general, as it is very important to permit that IMS clients interact with service logic through advanced web-based user interfaces. Other relevant protocols may be added as needed.

Conversion Between SIP and Non-IMS Protocols (upper part right)

It can be rightfully argued that this should not be part of the SOA layer, but please bear with it.

The IMS service architecture makes it very convenient to detect and divert SIP signaling which needs to be converted into another protocol (e.g. Jabber/XMPP, OMA IMPS CSP) to an IMS application server serving as gateway towards this other protocol. Conversely, the IMS Application Server can receive non-IMS messages and convert them towards SIP for interaction with IMS clients.

This approach is currently used in 3GPP for the support of SMS over generic IP access (which encapsulates legacy SMS's into SIP IMS Messaging).

Note that the IMS core network only supports protocol conversion from/to legacy circuit-switched networks for voice calls. The rest is up to the application layer.

Christophe

The Beatles & The Stones

The summary of a new report by Light Reading titled Telco Web 2.0 Mashups: A New Blueprint for Service Creation makes me think of the Beatles v. Stones battle.

Obviously, in the 60's the Beatles and the Rolling Stones were foes to death, and history can tell that only one of these two bands was great. Which one?

The report apparently highlights the need for operators to rapidly embrace a web services and service mashups approach. Fine, I totally agree with this.

My problem is when IMS and SIP are presented as an alternative to this approach. In this report this is clearly the bad one, as everybody knows that you cannot implement both web services and SIP/IMS and combine the two for an optimal usage.

When will the industry stop looking for the silver bullet? The unique technical solution, the unique business model that will answer all problems?

A core thesis I am trying to develop in this blog is that SOA/web services and IMS/SIP can be combined together to form a new paradigm (User Oriented Architecture) which, like the bands cited above would be more than the sum of its parts.

Another summary of the report cites JAIN SLEE as the service creation/execution environment in the context of IMS. I like JAIN SLEE and I think it can play an interesting role in IMS and across IMS and other networks.

However, it would be more interesting if the summary mentioned Java EE (J2EE) as well, as it could show that the Web Services / SIP picture is not that black and white. J2EE platforms fit very well in a web services world and I know at least three of the main J2EE platform suppliers which include SIP servlet support at the core of their platform. This means that there exist on the market platforms that can be used to implement services that are both web services and SIP/IMS centric. Unless of course this is strictly forbidden by both IMS and Web Services purists (I already had the opportunity to write about the artificial separation between IMS and Web Services chapels).

Why should the telecom industry just follow the steps of Internet companies and not try to bring its own contribution to the future, by integrating and enriching what exists today?

Christophe

SOA & IMS: Same Fight?

Here is an excellent article about the difficulties for the Service Oriented Architecture (SOA) to be adopted in the IT community: Finding the Real Barrier to SOA Adoption.

I defend the idea that SIP and IMS can integrate with and extend SOA by adding user orientation to an approach which is service centric. I already started to describe some architectural aspects of IMS, and the possibility to implement service logic as a distributed set of individual services reusable by others.

This is therefore not a surprise that I can identify within the telecom industry the same types of problem with regards to IMS and SIP, that the author of this article does with SOA and the IT industry.

He states that IT organizations are the first barrier to SOA adoption. I also think that existing telco organizations play such a role for IMS.

SOA permits to solve some complexity issues that IT organizations want to maintain, for the sake of keeping their job. I would liken this to the subdued but real ongoing fight between some of the telco vendors, who want to maintain complexity in the IMS, and IT suppliers, who can help make IMS much simpler for service developers.

SOA forces to think differently, in terms of reusability, architecture, and distribution. This is the same for IMS, which could support a new service architecture, much more distributed and powerful than the legacy ones.

The reference to silos is explicitly linking to the application silos we know in our networks, and that start to be implemented as well on IMS.

The fear of the unknown is also a very common problem in our industry, as people just want to work on topics they have already been addressing for years. Just look at how current SCIM/Service Broker standardization is just a way to keep on working on the old IN service interaction management problem and not to think of what could be beyond voice.

I would add an IMS-specific problem related to SOA: many people in the telecom industry that defend SOA concepts do not want to accept the idea that IMS is more than just another telco network, and that it supports SOA-related concepts as well.

Christophe

Three Axes for IMS: #3 User Oriented Architecture

The Service Oriented Architecture (SOA) is an IT architecture that enables the creation of applications via the combination of loosely coupled and interoperable services. While there may be different implementations, typical SOA makes use of WSDL, BPEL and web services. Web 2.0 and Mashups are also linked to SOA.

SOA concepts and ideas are spreading very fast in the Telco industry. However, at the moment, few see a relationship between IMS and SOA, other than the fact that IMS (like the pre-IMS network(s)) can exhibit web services to an application layer implemented around SOA. In this vision, there are two clearly separated worlds: an IMS/SIP core network and a SOA/WS service network, the former integrating with the latter according to the latter's terms, i.e. by exposing its capabilities through web services.

My belief is that such a vision is very partial and totally ignores the capabilities of SIP and IMS for the delivery of services. SIP as a protocol, and IMS as a service architecture, can optimally integrate with and complement a SOA, by bringing a dimension that is currently missing to it and is fundamental: user orientation.

To understand how SIP and IMS can support a User Oriented Architecture (UOA), it is first important to realize that SIP is not only a very generic session control protocol, that can support application-level sessions (see previous entry). SIP also features an important set of non session-related extensions, which make it a very generic service control protocol. The most important of these extensions is certainly the concept of "event package", which is based on the methods SUBSCRIBE, NOTIFY, and PUBLISH. SIP-based Presence relies on event packages, which permit a user (or application) to access, monitor or modify presence information. However, presence is only the tip of the event package iceberg. There already exist numerous event packages, which permit, e.g. to monitor the activity of a user on a keyboard or the changes made to a user profile, or for a server to receive and interpret stimuli from a graphical user interface (e.g. the user touched this area, then entered this and that key). Event packages permit to create, update and distribute any type of event, data, and commands into a SIP network.

The user orientation of IMS is based on characteristics that are specific to the SIP protocol, and on others that belong specifically to the IMS service architecture.

In short, SIP addresses can relate to services, but are more usually associated to users. The IMS service architecture permits to route SIP requests to devices and to application servers based on the identity of the user. The routing of SIP requests to devices associated to the user is based on normal SIP routing procedures, while the routing of SIP requests to specific application servers is based on "service profiles" associated to each user and stored in the IMS user database, the HSS.

In practice, while SOA would permit an application to access the presence of user X by using a presence service with the identity of a user as parameter, SIP and IMS permit to access the presence of a user via the generation of a SUBSCRIBE which is addressed to the user identity. Instead of being routed to a unique presence service applicable to all users, the SIP request can be routed to an instance of the presence service which is specific to this particular user.

Such a reversal of the addressing and routing approach (service for SOA, user for SIP) is very important, as a request addressed to a SIP user address in IMS can reach a user, but also the devices associated to this user, and applications or application instances associated to this user, whether these applications reside in the network (e.g. presence) or in the device(s) of the user (e.g. a game).

Imagine a health monitoring device installed on the body of the user. A very convenient way for a centralized entity to access health indicators of the user and to monitor their changes over time would be to issue a SUBSCRIBE for a specific event package, and to address this SUBSCRIBE to the user itself. The same SUBSCRIBE addressed to different users will reach the health monitoring devices associated to each of them.

Now, think of all the potential applications of SIP event packages, add to it all the potential applications of the generic session control mechanisms of SIP. Think that there exist other SIP extensions of interest to add to the pack. Then, imagine the potential of a service architecture that combines both SOA and SIP/IMS principles...

Christophe