Course on the IMS Application Layer

Through my company Arismore, I am offering a 2-day course on the IMS application layer. It can be delivered either in French or in English (all the material is in English). There are sessions regularly organized in my company's premises in Saint-Cloud, Paris, France, which are open to individuals. The course can also be delivered on site, within or outside Europe.

What makes this course unique is that, while others usually provide a litteral description of IMS specifications and essentially concentrate on the IMS core network, largely overlooking the IMS service architecture, sometimes even delivering misleading information, this one totally concentrates on this domain in which resides the true potential of IMS for differentiation and revenue generation (both for operators and suppliers). You can take this course after a regular IMS one, but my experience shows that even IMS novices can follow it without missing any core network background.

The course does not only describe IMS application-related specifications that span multiple standardization organizations (3GPP, the IETF, OMA, ETSI TISPAN). It also helps understanding what lies behind them, by providing revealing insights on how they were produced (e.g. historical timeline, assumptions, mistakes, conflicts between companies, need to address specific issues), shows in details how they effectively work, explains how they can optimally be exploited to deliver innovative services or innovatively deliver existing ones, and finally addresses the main opportunities and challenges that IMS brings to the industry. After this course, the student can understand what IMS can deliver, why there exist so many conflicting perceptions of IMS, and why IMS is as much a challenge as a promise.

Several on site sessions have been given or are planned in the near future, and the response has been so positive that these sessions usually lead to discussions about further collaboration between the customer company and Arismore.

Contact me at cgourraud@yahoo.ca if you are interested in either an on site session or in a session organized in our offices in Paris (planned dates can be found in the side bar of the blog).

Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.

Part 1: The IMS Service Architecture

This is the most comprehensive part of the course. It addresses several objectives: understanding how the IMS service architecture works (dynamic view), getting an overview of the specifications (static view), understanding the drivers behind standardization decisions (motivations, design by accident, pending issues), understanding how the architecture can be used (application layer architecture, service patterns).

Standardized topics include:
- Overview of the architecture
- IMPUs & PSIs
- ISC usage scenarios & examples
- Details of ISC
- Service profiles and initial filter criterias (iFCs)
- OSA SCS / IM SSF / SIP AS
- MRFC/MRFP
- SCIM & Service Broker
- IMS Communication Services
- User Data Management (Sh, OMA XDM, GUP)

The service features of SIP are treated as a specific topic. It highlights the potential of the protocol when used in IMS or in other networks:
- Multimedia sessions
- Event packages
- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)
- Support of Group Services
- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)
- Interoperability aspects (between SIP profiles, between SIP and other protocols)

Service oriented features specific to the IMS service architecture, and complementing the intrinsic SIP ones are also detailed. This part permits to understand the value IMS adds on other SIP-based networks:
- Service composition
- Logic mutualization
- Personalization / Differentiation of user experience
- Simple access to services
- Service flexibility / agility
- Authorization to services
- Unlimited service scalability
- Multi-vendorship / Differentiation for each service
- Service anthropomorphism
- Usage of a single identity for multiple services

Part 2: IMS standardized services and enablers

This part covers IMS services and enablers standardized or under standardization in 3GPP, OMA and ETSI TISPAN. As for Part 1, background information about the standardization process is given.

User data services & enablers:
- Presence (IETF, 3GPP, OMA specifications)
- Group Management / Group Services

Voice oriented services & enablers:
OMA Push To Talk Over Cellular (Poc) V1 and V2
3GPP Combining circuit-switched and IMS services (CSI)
3GPP Voice Call Continuity (VCC)
3GPP/TISPAN Multimedia Telephony (MMTel)
3GPP IMS Centralized Services (ICS)
3GPP Conferencing

Messaging services & enablers:
OMA SIP Push
Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)
3GPP SMS over generic IP access
OMA Converged IP Messaging (CPM) - Messaging part

Multimedia services & enablers:
OMA Converged IP Messaging (CPM) - Multimedia part
TISPAN IPTV

This part ends with a description of the Rich Communication Suite (RCS) initiative

Part 3: Opportunities & Challenges

This final part addresses essential topics which go beyond IMS specifications.

It is structured around the following topics:
- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)
- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)
- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)
- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)
- IMS as a service integration framework (different types of IMS services, how to integrate non-IMS services into IMS, relationship to 3rd party service providers)

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