OSS/BSS - The complexity of IMS testing
Testing interactions between elements, and simulating real-life traffic, will be crucial 
to the timely development and deployment of IMS architectures, says Bruno Deslandes
The move towards an IMS architecture for delivering services on all IP backbone networks of wireless and wireline carriers is undoubtedly on the way. In a recent report on IMS and VoIP sales, Infonetics predicted worldwide IMS equipment sales will more than double in 2009 as compared to 2008, and reach $1.6 billion by 2013. Because Evolved Packet Core, the 3GPP 3GPP release 8 core network architecture, is based on IMS for its service delivery architecture and the solution to the voice over LTE problem may well be based on IMS, LTE should be a strong driver for IMS adoption. Right now, 12 major carriers have already announced LTE commercial openings for as early as 2010. According to a study by 3G Americas, 120 telcos have voiced commitments to deploy or at least trial LTE before end 2014.
When deploying an IMS architecture, carriers are facing a wealth of challenges. IMS has been designed to be a modular architecture where functions are implemented in specialized network nodes, each node interacting with the others through standardized interfaces. This standardisation enables IMS, for instance, to operate over GSM/UMTS/LTE, WiMax, WLAN and PSTN access networks.
One of IMS's assets resides in the isolation of services (like ring back tone, multi-party voice and video conference,...) in the Application Server nodes (AS); the role of the AS being to coordinate and synchronise the resources and functions of the network to implement the required service. Deploying a new service is then a matter of deploying new software in an existing AS or deploying a new AS. Since interfaces of AS are well defined, such a new service can be set up without disrupting the overall network architecture.
Such a modular architecture opens up the competition in the network equipment market resulting in rich and innovative offer. Carriers can then escape the traditional vendor lock and cut down CAPEX. On the other hand, this expandable design multiplies the number of nodes, exponentially raises the number of interfaces between the nodes and brings about yet another complexifying factor to the signalling call flows for delivering a call.
Getting the benefits of a multivendor environment means carriers have greater responsibility for building their network. Where before, they could rely on vendors to provide a working solution, they now have to endorse the role of network integrators.
One of the first challenges is making sure that all the selected components interwork well. Because of the diversity of the vendors, of the node functionalities and the carrier-specific configuration, no vendor would fully guarantee that its equipment interoperates with the others selected by the carrier in the configuration chosenby the carrier. Requirements can be put on conformance to protocol and interface specifications and carriers can check this conformance. But, there is no standard defining the conformance rule for SIP or Diameter, the two main signalling protocols used in IMS. Initiative is left to the market. The UNH-IOL test lab has developed a SIP conformance test suite and proposes conformance testing services. Most testing tool vendors covering SIP and Diameter propose SIP conformance tests suites. Protocol specification coverage and completeness depends on the tool's vendor.
Moreover, conformance does not necessarily mean interoperability. Effective interworking of equipments has to be tested. The interdependency of equipment in the IMS architecture should lead carriers to build an IMS network dedicated for testing. With such an IMS testing infrastructure, they will be able to check interoperability with the equipments they selected but also conduct end-to-end testing which is in the end what counts the most for delivering high quality services to their customers.
IMS testbeds blend real equipment as deployed in the network, test tools and simulators. Test tools and simulators bring flexibility and improved testing capabilities. They are essential for producing well defined traffic patterns in a reproducible way. They make the production of error conditions, that would have been tedious to produce with off-the-shelf equipment, easy.
Simulators also are a way to reduce costs. The Home Subscriber Server (HSS) is the IMS central identity repository delivering authentication. An IMS testbed must include an HSS, but this is a very expensive piece of equipment and it requires specific knowledge to be set up and operated. Using an HSS Simulator that offers test and debug facilities in addition to HSS functions cuts down the costs, enriches the workbench testing capabilities, and gives flexibility in operation. Vendors are proposing tools capable of emulating multiple instances of different kinds of IMS nodes. These tools can be used to enlarge the topology of the testbed, making it closer to what is deployed in the field without the expense of buying real network equipment.
Given the price of an IMS test bed most operators will not be able to afford several such units. With market pressure to deliver new services at a steady pace, there is a risk that IMS test beds become a bottle neck slowing down the release of new commercial offers. With their flexible configuration and test automation capabilities, test tools and simulators are critical for the IMS testing infrastructure to be efficient (run the fastest possible test campaigns) and agile (quickly switch between different testing conditions). They significantly contribute to increasing the quality of delivered services and reduce testing time and costs.
With an IMS testbed, carriers can submit their new services and equipment to functional, load, stress, robustness and performance tests in conditions close to their real deployment. It gives them the ability to assess the new services efficiency, reliability and impact on their existing network.
While this assessment is required, it is not sufficient. IMS empowers carriers to deliver feature-rich services and customers to combine the use of these services. Trying to reproduce the diversity of invocations and combinations that may occur in real life would sky-rocket testing costs.
To deal with this issue, labs testing can be complemented in the early deployment stage and during ramp-up by monitoring the network. Watching alarms and statistics on a per equipment basis notifies problems and gives hints on their cause, but this does not offer the global and comprehensive view which is required to diagnose them. IMS call flows can be very complex - involving dozens of message exchanges in many different protocols (SIP, Diameter, H.323, H.248 ...). The more sophisticated the services are, the higher the complexity will be. Manually analysing is a tedious, very time consuming task and hinders correction responsiveness.
An effective strategy can consist in deploying a network monitoring tool that captures, archives and analyses signalling traffic in real-time. When a problem occurs, such a tool will be able to recollect the complete history of multiprotocol signalling message exchanges and will enable network specialists to quickly locate errors and their causes. Such tools often offer on-the-fly traffic analysis automatically flagging errors or abnormal behaviours like slow response time, message loss or other deviant traffic patterns which are not errors but indicate service quality degradation. This observation of network behaviour enables preventive maintenance to take place before the problems become noticeable at a large scale and contributes to watching and maintaining network service QoS.
Because coupling between network and OSS/BSS is tighter in IMS, testing shall cover the interaction with the OSS/BSS system. Many IMS nodes have a Diameter protocol interface with the billing system for real-time charging. For instance, an AS may query it to check the customer has enough credit before delivering a service. This means OSS/BSS may be directly involved in the call signalling and should be part of network testing.
Provisioning or service activation is also a concern. With the distributed nature of IMS, a user service profile change is likely to impact several IMS nodes. Tests shall guarantee that such kinds of changes are correctly and consistently performed. With customer self care now being the common rule, the rate of such changes can reach several tens of thousand per day in big carriers' network. This is real challenge!
IMS open standards is a tremendous opportunity for carriers to leverage multivendor market offers to reduce costs for building their IMS network and getting a richer services portfolio. This heterogeneity combined with OSS/BSS interaction results in a complexity that raises the cost and length of pre-deployment tests. IMS testbeds equipped with test tools, HSS simulators and other IMS node simulators, traffic generators... are powerful means to keep these costs and times compatible with market pressure. Tools for monitoring IMS signalling and protocol exchanges complement the testing approach in the deployment and operation phases, and make sure the required service quality is effectively delivered.
About the author:
Bruno Deslandes is IMS Product Manager,
Marben Products.
Share this article with others
Post to del.icio.us
Printed from http://www.eurocomms.com/features/113516/OSS%252FBSS_-_The_complexity_of_IMS_testing.html
Comment on this article
Skip to comments
We encourage users to analyse, comment on and even challenge European Communications's articles, including the one above - 'OSS/BSS - The complexity of IMS testing'
User reviews and comments that include profanity or personal attacks or other inappropriate comments or material will be removed from the site.
Additionally, entries that are unsigned or contain "signatures" by someone other than the actual author will be removed. We will take steps to block users who violate any of our posting standards, terms of use or privacy policies or any other policies governing this site.