Flexibility in IMS/VoLTE UE Design: Too Much of A Good Thing
One of the hallmarks of the IP Multimedia Subsystem (IMS) is the flexibility it affords developers. From something as simple as the validity of SIP headers abbreviations to the wide variety of mechanisms designed to interact with legacy technologies, IMS permits a broad range of equally valid implementations.
There are multiple technical specifications relevant to IMS and VoLTE, including the 3GPP’s TS 34.229 specification and the GSMA’s technical recommendations IR.65 (IMS Roaming and Interworking Guidelines), IR.88 (LTE Roaming Guidelines) and IR.92 (IMS Profile for Voice and SMS). All of these documents provide ample evidence of the flexibility in the requirements. For example, from IR.92:
• “The profile does not limit anybody, by any means, to deploy other standardized features or optional features...” “Service configuration… is optional.”
This flexibility can result in differences between individual operators’ and vendors’ interpretations, leading to the risk of implementation and interoperability issues between devices and networks, despite all the specifications and recommendations. Complicating matters further is that LTE is finally driving convergence towards the ITU’s long-term goal of a single global standard for mobile communications is underway. This means that UEs being designed today must be equally adept at handling a variety of SMS message formats, network equipment implementations, and operator-specific implementations.
The history of wireless technology provides precedent as to what can happen when UE designers implement devices that must work across an expansive assortment of equally valid network equipment and operator implementations. When 3G technology was introduced with Wideband Code-Domain Multiple Access (W-CDMA), the breadth of options led to a multiplicity of possibilities at every stage of the service chain. The focus on data services forced engineers to concentrate on ensuring the viability of upper-layer functionality, resulting in little emphasis on fundamentals such as voice services. The result was that subscribers invested in brand new high-end mobiles tied to premium service packages, and often found they couldn’t make reliable voice calls.
Stories from the Field
Our position as a leading test and measurement vendor for LTE obviously gives Spirent insights into progress through the product development cycle. Here’s an example of one anecdote from early-stage prototype development which found its way to our offices and paints a cautionary picture:
• A network-side developer learned to accommodate some SIP header abbreviations used by his counterpart UE developers. However, he missed some valid abbreviations for non-mandatory SIP header fields. In one case, a SUBSCRIBE request containing the non-intuitive abbreviation “o” for “Event” tripped him up.
Technology updates are not new to wireless, of course, but each new generation brings with it increased dependency on details. History has taught us that ambitious transformations bring greater risks, and in the case of IMS, the network is literally new to the core. Furthermore, the UE is always a special case when it comes to unforeseen anomalies; it is the one part of the network that is out of the operator’s control if an issue comes to light after deployment.
The Effects on UE Design
In legacy technologies, UE designers became used to applying patches to correct issues found in field testing. While the process was not ideal, it was a sufficient way to bring a UE to market with confidence. But given the layered technical complexity of IMS, what were once patch-fixes might now require significant re-design. A strong argument has been made for a concerted effort to isolate UE bugs early in the development cycle.
Until recently, UE designers depended on script-based network emulations to test designs in process. While they were clunky compared to the automated state-machine-based tools used in functional and acceptance testing, they were deemed good enough for use in early development. In the midst of all this new complexity behind IMS, R&D teams are being asked to do more with less, and to do it faster. They no longer have the luxury of spending days or weeks writing and maintaining scripts traditionally used in UE design verification.
This need for realism and configurability has driven the availability of a new generation of test equipment designed to offer efficient flexibility in the R&D lab. For example, Spirent’s CS8 Design Tester marries state-machine-based core network emulation (designed to test network elements and validated over several years of the LTE development cycle) with a completely configurable implementation of the IMS subsystem. The platform also integrates GUI-based control and efficient presentation of decoded message flows, features long available in testing labs but rare in R&D labs.
As a result of these new tools, UE developers have the ability to replicate a wide variety of operator-specific and network-equipment-specific implementations. This allows them to isolate and resolve issues early in the design, eliminating the need to apply patch-fixes to nearly finished products. Engineers can even capture messaging from live networks and set up CS8 to replicate the actual network.
One of the long-term promises of IMS and IMS-based services like VoLTE has been the promise of cost containment. The plan is to realize the cost benefits of a modular network, including more efficient network access, reduced churn (creating subscriber loyalty by tying services to specific operators), and reducing the cost of multimedia applications by developing each as a “one-size-fits-all” IMS version rather than multiple access-specific versions.
The stakes are high, of course. The industry is clearly depending on IMS to deliver revenue-enhancing services far into the future; VoLTE is just an early example of the many that will follow. For a variety of reasons, R&D teams no longer have the options to rely on the relatively rudimentary tools used in earlier technologies… they simply don’t have the time to write scripts. Neither do they have the opportunity to make material changes based on issues uncovered in live field testing. These needs have driven the development of new R&D testing tools to enable efficient and comprehensive testing early in the UE development cycle.
Posted by Sara Cohen, Editorial Intern
July 2, 2012