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.
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 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).
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
Stumble It!
