Virtualizing network functionality is the aim of a surprisingly large number of initiatives these days, for a surprisingly large number of reasons. In NFV, operators focused on cost savings versus custom devices in their seminal paper on the initiative, but in SDN the focus is on improving network operations and stability. Other operators have been looking to define a framework for hosting service features that would be both agile and operationalizable.
One of the most interesting topics in the virtualize-my-functions game is IMS. Mobile services monetization, in the advanced form I’ve called “mobile/behavioral symbiosis” has been the second-most-important goal on the operators’ list (after content) but it’s also the area where they’ve made the least progress. Some, at least, say the reason is that IMS is a key element in mobile services.
In theory, IMS is mostly about voice services, which many would say are strategically unimportant. The problem is that it’s hard to offer wireless services that don’t include voice, and intercalling with the public voice network. It’s also true that as we evolve to 4G, things like mobility management (part of the Evolved Packet Core or EPC) are more often linked to the deployment of IMS than run on their own. I don’t even know of any plans to run EPC without the rest of IMS. Finally, if we presume that we might eventually get wireless services from WiFi roaming and have some service continuity among WiFi hotspots or roam-over to cellular services when you’re not in one, we’ll likely need something like IMS.
The problem is that IMS isn’t known for its agility. Words like “ossified” or “glacial” are more likely to be used to describe IMS, in fact. People have been talking about changing that, and today I think there are a half-dozen initiatives to make IMS itself cloud-compatible. Most are players who had IMS elements supported on fixed platforms or appliances and are now moving them to the cloud. One vendor who’s taken a different approach is Metaswitch, who’s promoting a cloud IMS that was “cloud” from the first, and it’s an interesting study in some of the issues in cloud-based virtualization of network features. Their cloud IMS is called “Clearwater”.
Metaswitch starts where most people will have to start, which is the structural framework of IMS defined by 3GPP. You need to support the standard interfaces at the usual spots or you can’t work with the rest of your own infrastructure, much less with partners. You also need to rethink the structure of the software itself, because cloud-based virtual components (as I noted in a previous blog) can’t be made reliable by conventional means. So Metaswitch talks (if you let them) about N + M redundancy and scalable distributable state and automatic scale-out and RESTful interfaces. Underneath all this terminology is that point about the fundamental difference of virtual, cloud-hosted, functionality. You can’t take a non-cloud system and cloud host it and get the same thing you started with in reliability, availability, and manageability. Skype and Google Voice didn’t implement a virtual bunch of Class 4s and Class 5s. You have to transport functionality and not functions.
While it supports the externalized IMS interfaces, its intercomponent communications is web-like, and it manages state in a web-friendly way. That means that if something breaks or is replicated, the system can manage a load-balancing process or fail-over without losing calls or data. The web manages this by “client-maintains-state”, which is what RESTful interfaces expect. You can make that stable by providing state storage and recovery via a database, something I did on an open-source project out of TMF years ago. This is why they can claim a very high call rate and a very low cost-per-user-per-year; you can use generic resources and you can grow capacity through multiplicity using web-proven techniques. It’s telco through web-colored glasses.
Does Metaswitch answer all the questions about cloud IMS? I don’t think even they would say that. The fact is that we have, as an industry, absolutely no experience in the effective deployment and operationalization of cloud-hosted network services. Metaswitch tells me that they’re involved in a number of tests that will help determine just what needs to be done and what the best way to do it might be. Some of this activity may contribute further understanding to initiatives like SDN and NFV, because the central-control notion of IMS makes it easier to adapt IMS to an SDN framework and cloud-anything is an NFV target.
Because Clearwater is planned for release early this month under the GPL, there are some delicate questions regarding how you could deploy it in situations where commercial interfaces or components might also be involved. My personal concern here is that the value of cloud IMS might be diminished if it can’t be tightly coupled with elements that are already deployed outside GPL, or that are developed with more permissive licenses like Apache. I’d recommend that the Metaswitch people look into this and make some decisions; perhaps GPL isn’t the best way to do this.
The most important aspect of IMS evolution is an area where this licensing may hit home. While Clearwater includes native WebRTC support, integrating IMS into a web world is likely to mean writing services that are web-coupled and also IMS-coupled. Even implementations of SDN and NFV might run afoul of licensing issues in creating composite functionality, and if the goal of bringing IMS into the cloud is in part driven by a goal of bringing it into the web era, the licensing could be a big issue.
This is a good thing, though, not only because we need to have virtual functions virtualized to deploy in the cloud in the network of the future, but because we need a model on how to do it. IMS is one of the most complex functional assemblies of networking that we’re likely to encounter in the near term, so if we can figure out how to deploy IMS in the cloud, we can deploy pretty much anything there. Which is good, because many operators plan to deploy everything there.