This basic point aside, the strategies between operators might diverge, and their differences may essentially lie into the level of control they want IMS to support. This level of control can be illustrated by the following questions, which purposedly address extreme attitudes (it should be understood that intermediate opinions also exist).
Should IMS be fully open to other IP networks, and permit communication and service interoperability with devices and service providers located outside of the traditional telecommunications domain, more especially the Internet? Or should IMS, on the contrary, help operators establishing a new "walled garden", forcing or strongly encouraging the customer to use the services provided by telecommunications operator, and preventing or strongly discouraging them to use services provided in the Internet?
Should IMS foster service innovation, permitting telecommunications operators to differentiate between themselves and compete on value for money to improve their market share? Or should IMS, on the contrary, be used to maintain the old, slow and standardization driven telecommunications model, in which most operators provide the same mass market services and only differentiate at the margin?
Operators in a challenger position, or which are confident in their ability to cope with the new challenges they are facing with the rapid evolution of technologies and customers' habits, are keen on adopting an open IMS and a new approach to service creation. In addition to developing their own services, they are likely to seek other ways to maximize revenues, acting as a channel provider or intelligent pipe provider towards 3rd party service providers, by partnering with them and/or adding values to their services (see here an example of how IMS can be used by an operator to add value to 3rd party services).
Operators with a control freak approach are more in a defensive attitude, having to preserve a market position or facing internal uncertainties about the future world.
These diverging strategies do not only concern operators, as they will directly impact the supplier ecosystem the operators will rely on in the years to come.
Operators favoring service innovation, short development cycles, high service customization, or niche market services, will have to adopt technologies and practices that come from more dynamic business sectors, where state-of-the-art IT and methods are common place. To develop their services, they are likely to rely on open service platforms (e.g. J2EE), enterprise architecture practices, and to primarily view services as applications, developed in-house, purchased off the shelf, or contracted to IT-centric application providers.
On the other hand, operators opting for mass market standardized services, with little differentiation, are likely to maintain the existing ecosystem of traditional equipment and service box suppliers. The more a traditional telecommunications equipment supplier has difficulties to move from telco IT (e.g. proprietary platforms, poor skills at Java, SOA and other advanced IT architecture and programming paradigms, long and costly development cycles) to standard IT, the more this supplier will take as a threat the advent of an all-IP and open IMS era.
How IMS positioned itself a couple of years ago
This was a mixed bag.
Despite what some people think and claim, 3GPP always ensured that IMS was fully interoperable with non-IMS SIP networks. I already addressed this topic in a past post, from which I will only reuse a telling example: IMS session setup.
In order to permit IMS calls to replicate the experience an end-user has when establishing a call in the circuit-switched network, IMS opted for a more complex procedure than the basic IETF SIP one, permitting network resources to be reserved before the call is established. An IMS device is mandated to follow this procedure. While this procedure and the related SIP extensions can also be used in non-IMS networks (these are not 3GPP-specific extensions), it cannot be assumed that all SIP clients will ever support it. Not doing anything about this would have prevented an IMS device to set up sessions with most of non-IMS devices. However, 3GPP did something about this: in case the peer device does not support the complex session setup procedure, the IMS device (or a network based agent acting on its behalf) is mandated to revert to the basic IETF procedure.
The technical ingredients to support service innovation were also there: the intrinsic power of IP and SIP, the powerful IMS service architecture, the SIP servlets specification permitting the integration of SIP-related service logic into advanced and open J2EE platforms, the endorsement of SIP servlets by all the suppliers of J2EE platforms.
However, it did not work out that well, and this can be linked to multiple good and bad reasons: IMS was still a prospective technology (real deployments are starting now), focus was on short-term (hopefully) value generation services (e.g. VoIP, push to talk over cellular), IT-centric platforms were not mature yet, the capabilities of SIP and the IMS service architecture were not well known, no compelling IMS services were proposed, the legacy telecom culture was a handicap that was reflected in the old fashioned silo way OMA (the Open Mobile Alliance) was specifying IMS-based enablers...
I would not claim that all these factors have disappeared now, but some progress has been made in the recent time, as IMS is becoming real.
The last two years: hidden fight between various strategies
3GPP Communication Services are the textbook example of how suppliers and operators with conflicting strategies have used all the subtle (and less subtle) panoply of standardization tricks to push their agendas and counter-agendas in IMS standardization.
I already addressed the topic (here and there) at a time when the fight reached its heights, and I will soon dedicate a post to describe the current status and potential consequences of Communication Services standardization.
For now, suffice to say that:
- Would all the ideas pushed by Communication Services promoters have been accepted, IMS would certainly have become a walled garden preventing interoperability between IMS and non-IMS SIP devices, and huge barriers to innovation by IMS operators would have been erected.
- In the present state of standardization, these risks have been globally averted (thanks to the IETF and some companies active in 3GPP).
I personally view Multimedia Telephony as an initiative that goes in the same control direction. As I already wrote, Multimedia Telephony can be seen as an attempt at defining multimedia sessions as an incremental, person-to-person communication centric evolution of voice telephony. Moreover, at the moment, the content of Multimedia Telephony specifications is limited to the emulation of classical voice telephony services over an IMS network. From this you can derive that, from a target perspective, MMTel is a half full or half empty evolution in direction of the true multimedia experience SIP can provide, and that in any case there is not much hurry to move toward this target.
Another initiative I would strongly liken to MMTel is OMA PoC phase 2. While PoC phase 1 can be described as a 2-party or group walkie talkie service (essentially) for mobile phones, PoC phase 2 significantly enriches the user experience with other media, permitting for instance to transform a session from half duplex voice (original PoC) to full duplex voice, to use text messaging or send images, files or video streams in the session. This is still not full multimedia, but a controlled step in the direction, defined as an enrichment of a service silo looking for a future. As such a silo, PoC has a very interesting feature for companies which are not that thrilled with the idea of interworking with non-IMS devices: PoC is the only IMS service that can be described as fully IMS centric. It was totally specified by the IMS community and has no equivalent in the non-IMS SIP community.
On the other side of the fence, you can undoubtly place the ongoing OMA Converged IP Messaging (CPM) initiative. CPM intends to use the full capabilities of SIP sessions and IMS convergence features. It is multi-access, multi-party, multi-media in the most advanced meaning, and multi-device, supporting both person-to-person and person-to-service sessions. If every thing goes well, instead of a fully standardized service like telephony or PoC, CPM should end up being an architectural framework permitting operators to place or allow any media component one can think of in an IMS session, thus realizing (and possibly improving on) everything one can implement in the Internet using the SIP protocol.
Until recently, I tended to see 3GPP as the standardization body with the most coherent and liberal approach to IMS, and OMA as the organization which, through its heavy pre-IMS heritage and its inadequate organization, would keep on standardizing good old service silos (with overlapping features). However, it looks like this time is over, at least for OMA. This said, thinking about it, this OMA organizational problem (the fact that each group standardizing a service works in parallel to the others while the architecture group works on its own topics instead of ensuring the overall coherency of the OMA architecture like SA2 does in 3GPP) is more obvious than ever when you consider the current situation of OMA specifications: as an operator, you now have no less than three alternatives if you want to deploy an IMS messaging solution, OMA SIMPLE Messaging, OMA PoC phase 2 and OMA Converged IP Messaging, among which the last two can claim to support multimedia sessions as well. Finally, I may withdraw my positive comment about OMA as a whole.
Christophe
Stumble It!
