IMS is promoted as the long term core network architecture solution
IMS (IP Multimedia Subsystem) is a core network architecture based on IP protocols. It uses SIP (Session Initiation Protocol) to setup and teardown connections. Unlike traditional telephone networks based on circuit switched protocols such as SS7 and ISDN, these SIP sessions can be used for voice, video, instant messaging and a variety of other purposes. Sessions can be extended, expanded and modified whilst in progress.
There has been a strong technical drive to adopt IMS as the core network of choice. A large group of operators endorsed OneVoice, a simplified version of the IMS standard which specified a restricted and focussed implementation for mobile networks. This was adopted by the GSM Association with the name VoLTE (Voice over LTE - the new 4G radio interface).
The cost to adopt IMS and migrate from existing systems is seen by some as substantial. Whilst most commentators now expect mobile networks to adopt it in the long term for use with LTE, there remains skepticism from others about the whole idea. There is a view that operators need not adopt IMS immediately when launching LTE and instead will adopt a staged approach, perhaps with some taking much longer to attain the final objective.
- LTE as a data only service (e.g. using USB data dongles, embedded laptops only)
- LTE with fallback to 2G/3G for voice services (e.g. with dual mode smartphones)
- IMS (VoLTE) providing both voice and data, with handover to 2G/3G when out of coverage
But there are alternatives
Both CS Fallback (which switches the handset into 2G or 3G mode when making/receiving voice calls) or VoLGA (which re-uses an existing protocol designed for WiFi dual-mode to carry the voice service across the LTE interface) have been promoted as commercially attractive for initial deployment.
Last year, I attended ITEXPO, a conference dedicated to IP based voice services. What surprised me was that the most popular aspects were SIP trunking (which deals with cost effective bulk transport of billions of voice minutes for wholesale purposes) and Business VoIP (offering a wide range of telephony services for commercial enterprises). Both areas seemed to be commercially successful. Neither required IMS.
Femtocell vendors are including this in their designs
We've discussed the principles behind SIP based femtocells in a mini-series in the past. The CDMA femtocell standard incorporates a SIP component. What now appears to be considered is mass deployment of IMS capable 3G CDMA femtocells which would work with both existing 3G CDMA phones and future ones capable of native IMS protocol.
Ubiquisys have also incorporated an IMS client in their 3G UMTS femtocell, as discussed by their CTO Will Franks in his blog. He believes an IMS client within the femtocell could be used to provide those telephony services within the home or enterprise. I'm still uncertain about the suitability of this.
Global Wireless, a new entrant, have designed a femtocell platform which uses software to support either CDMA or UMTS to a common IMS core network.
I'm not convinced of all the claims made for IMS within the femtocell
I can't really see the need/demand for an IMS client to handle telephony/switchboard style services in domestic environment, where we've all become more used to direct access with our own personal mobile phones. Call transfer typically consists of passing the phone to the other family member.
In an enteprise situation, there have been several innovative and well executed schemes which provide telephony call handling/switchboard type services available for many years. Why would these be different if they were built into the local device? Any services delivered by the femtocell would need to be matched when outdoors. This means that the scope of the IMS client would exclude any additional or specific call processing logic which only operates when within the femtocell area.
Instead, where I can see IMS being useful is in providing QoS - guaranteed levels of throughput and latency which match the type of service being used. This would allow end-users or content providers to pay a premium for higher quality connection rather than best effort which would improve the perceived service delivered. This can be managed by the femtocell internally, ensuring that the additional speed and performance available through it is shared fairly amongst family members.
Will CDMA operators have a head start with IMS using 3G femtocells?
By deploying 3G CDMA femtocells with built in IMS clients connected to an IMS core network, CDMA operators can deploy this technology in a carefully controlled manner to a limited number of known end users. This would allow them to gain early insights into the issues, operation and compatibility of their IMS networks planned for use with LTE. It would also allow them to pilot new IMS services within small target groups.
The latest news I've heard from those working in the 3GPP2 standards committees are that the IMS based architecture continues to be developed and should be finalized and published by the summer of March 2010. I hope to post more up-to-date information on this shortly. But there is no absolute requirement to wait for a standards compliant 3G CDMA femtocell before these can be deployed.
With LTE deployments about to commence in earnest, especially by CDMA operators in North America, there remains debate about what architecture will initially be used for voice services.
In the long term, a specific implementation of IMS (known as VoLTE or OneVoice - they are the same thing) is likely to be the architecture of choice.
Both CDMA and UMTS femtocell vendors are building in IMS clients into their products today which can be used with existing 3G phones. This architecture would allow an operator to deploy and gain experience with an IMS core network before deploying LTE with relatively low risk.
CDMA operators deploying femtocells using a IMS architecture could gain a lead into IMS operating experience which prepares them for early mass rollout of their full LTE/IMS solutions in due course.