Out-of-the-Box Compatibility? - Excerpts from a TMC Article on IMS Interoperability
Richard Grigonis of of TMC (IMS Magazine, Internet Telephony Magazine) published an article on "Interoperability and Other Testing in IMS". A portion of the article was based on an interview I did with him several weeks ago.
See the whole article here.
Out-of-the-Box Compatibility?
At Empirix, one of the most respected names in the testing hardware and software business, Chad Hart, Product Marketing Manager, says, “Interoperability is still a challenge. It has come along way but it still has a ways to go. As a result of my conversations with network operators who are actually deploying IMS, most of them are choosing to go with a single vendor as opposed to many. It’s not the best time for achieving interoperability, but it’s good for IMS in that operators are actually deploying it. Interoperability is one of the bigger challenges faced by IMS adoption. The way the IMS/NGN Plugfests are set up, they are usually done in stages. The first stage is just establishing a basic call or doing a basic registration between different vendors, which is what practically the whole first Plugfest was about. At the most recent Plugfest, vendors achieved the first step very quickly. It’s a sign of real progress for interoperability. How quickly can vendors’ equipment actually work together practically right out of the box?”
“Are operators now so comfortable with multivendor operability that they’re willing to make deployments in their live networks?” asks Hart. “I don’t think that’s true on a large scale yet. Certainly some of the larger operators have pretty sophisticated interoperability labs where they’re demonstrating multivendor interoperability internally, but they haven’t deployed to the networks yet, though of course they have plans to do so. Another trend is that many vendors are aware of the interoperability issues and have partnered with some of the best-of-breed component vendors out there to make sure they can interoperate with at least specific vendors or devices.”
“There are of course economic considerations,” says Hart. “While it might be theoretically possible to mix-and-match all of these various IMS functions from different vendors, that doesn’t necessarily imply that such a practice is economically viable. If you buy a lot of equipment from one vendor, they’re going to give you a better price than if you just buy one component from one vendor and one from another vendor. The reality is that interoperability is probably going to be done in ‘layers’. Certainly there are many different kinds of application servers out there, along with many different services. One main goal appears to be to achieve pretty broad interoperability with the service layer. Similarly, there’s a lot of different kinds of network edge access equipment. So you need to have pretty board interoperability with that equipment. Interestingly, in the network core it doesn’t seem to be as important for most operators to have a variety of different vendors represented there in their infrastructure. A typical operator is quite happy dealing with one vendor who controls the core network, as long as they’re compliant with the IMS specification.”
“Also, there are vendors out there such as BEA that are working on service delivery platforms or the app server layer, and companies like Broadsoft, that has made excellent traction in this space with their IP Centrex-type business VoIP tech services,” says Hart. “But those are application server vendors who plug pretty neatly into the IMS architecture, at least in its simplest form today. There are things on the horizon that may muddy the picture a bit. Today, many vendors just plug into an IMS core via an ISC interface. [IMS architecture identifies the interface between a SIP applications server and the S-CSCF as an ISC or ‘IMS Service Control’ interface, to perform multimedia session control.] There are other interfaces specified in the IMS architecture and those interfaces are getting to be much more complex and there are things that allow application servers to talk to other application servers or to have app servers ‘share’ common elements amongst them, such as presence. The interoperability of devices with those interfaces is probably a few years off, so it won’t be commercially viable for a while yet.’
“There’s also data sharing among these applications servers,” says Hart. “The IMS architecture allows applications to store user profile information and application-specific information on the HSS [Home Subscriber Server] user database in the IMS architecture. But it doesn’t appear that very many vendors are supporting that capability today, and the specifications for actually putting and sharing that user data in a common location is not a mature practice yet. More standardization work needs to be done.”
“The MSF, or MultiService Forum (News - Alert) holds an event every two years called the GMI, or Global MSF Interoperability event,” says Hart. “The MSF is backed by the major service providers. The most recent one was in 2006 by BT, France Telecom, NTT and Verizon here in the U.S.
At the GMI, they test multivendor operability, such as aNortel ( News - Alert) device talking to one from Ericsson. But they also test network-to-network interoperability. There will ultimately be multiple IMS networks out there, and the networks themselves will talk to each other, as opposed to just the vendors’ devices within those networks. That’s another layer of complexity, since every IMS-based operator is faced with hundreds of configuration options. If some of those configurations are a bit ‘off’ they can cause interoperability issues between the networks when you try to pass a call from one network to another.”
One should note that the MSF has a permanent test bed at the University of New Hampshire InterOperability Lab (UNH-IOL) with the aim of testing NGN (Next Generation Networks (News - Alert)) components and interfaces. The MSF NGN Test Bed supports testing of all MSF Implementation Agreements (IAs) and will grow to encompass future IAs on topics includingIPTV, Quality of Service, Location Management and support for Operational Support Systems. Aside from in-depth testing based on key GMI interoperability scenarios such as the optimal media routing of IMS interconnection between subscribers in the MSF R3 domain and legacy networks, the MSF NGN Test Bed will provide demonstration and test facilities supporting MSF members' in-house laboratories.
“Our test and monitoring equipment at Empirix continues to be refined, and we help quite a bit with the challenges of IMS interoperability testing, such as complexity,” says Hart. “We help simplify test scenarios and help make the automated tests easier and able to handle more tests. There are so many tests you can run today, simply because there are so many more things to test than previously. In other areas, you could be dealing with a standards ambiguity of IMS, since there are always changes to specifications. Fortunately, it looks like the Release 7 specifications are pretty locked down. Most operators, however, are still implementing Release 6, but all vendors are working with Release 8 specs, which are largely still to be defined or are otherwise in progress. Adapting to all of these changes is important along with being able to adapt quickly, which is another key capability that we’ve built into our products.”
“Our monitoring system, Empirix Hammer XMS, has also become an important piece of equipment,” says Hart. “Basically we took the concept of our Call Analyzer and asked ourselves, ‘What if we wanted to do analysis and diagnostics on a live operational network?’ Instead of the Call Analyzer being a kind of a spot diagnostics tool, we wanted to create a network-wide monitoring system that could call upon multiple distributed probes and scale up to millions of subscribers. That’s our monitoring system.”
