This article presents a top-down view of the technologies that drive the architectural decisions for IP Multimedia Subsystem (IMS) and AdvancedTCA. IMS organizes complex functions to form autonomous and loosely coupled network elements and emphasizes the interconnecting protocols. The challenge for system architects is to map traditional and new network applications to the specific IMS services utilizing the specific protocols. Using techniques learned from Web development, high availability of the services can be provided at a significantly lower cost. Balancing vertical versus horizontal implementations, IMS applications count on stable reusable core services. IMS deployments create major opportunities for equipment providers, especially utilizing AdvancedTCA, blade servers, and MicroTCA hardware platforms. Understanding the decision influencers of IMS helps in selecting the most appropriate technology for each IMS network element.
Technology trends
Both IMS and AdvancedTCA have been influenced by several disruptive technology trends worth elaborating on. Such trends have shaped the system/network architecture and the shelf/platform implementation of network elements. Let’s look at the influence each of the following has on IMS and AdvancedTCA:
The hardware world is becoming serial
Hardware scales but software does not
Autonomous and loosely coupled computing engines are in
Less porting to new buses and operating systems results in more innovation
Protocols replace buses, operating systems, and specialized APIs
Functional interconnectivity replaces linear application development
Platform is a new term for distributed software
Hardware architects have realized that the cost of device pins, connector pins, and printed circuit board real estate is much higher than gates and flip-flops within the silicon chips. Changing parallel buses to serial interconnects not only solves timing skew problems, but also makes economic sense. Serializer/deserializer (SerDes) devices have become the norm for most modern designs. The hardware world is becoming serial.
Creating applications using the classical computer architecture has served the industry well for many decades. In order to reduce the Bill of Materials (BOM) cost, engineers attempted to replace specialized hardware functions with software modules. But as software became more complex, the cost of developing and maintaining software modules became higher than the cost of hardware, especially in the case of commodity hardware. Developing and maintaining 10 million lines of code for one computer is much harder than creating 1 million (different) lines of code for 10 computers, especially as developers can use between four and six of those computers for more applications. For large systems, hardware scales, but software does not.
Sharing the same computing engine with multiple applications has two additional benefits: Engine vendors can create competitive products, and computing engines become more robust and cheaper over time. Modern telecom applications can now utilize several best of breed computing engines. As the number of common engines increases, so does the robustness and economics of the applications. Autonomous, loosely coupled computing engines make sense.
A decade ago, everyone from OEMs to telecom system integrators had to respond to questions about the form factor of buses used, the operating system type and version, and the development environments. OEMs faced a serious dilemma: A perpetual porting of their technology to new bus and OS form factors in place of creating new functionality and new features. In the telecom space, porting to new buses or OSs has minimal risks and the most rewards, so including innovative features or exploring new technologies has slowed significantly. On the other hand, the Web community has introduced functionally rich applications and superb development tools. Less porting to buses and OSs results in more innovation.
Traditional application development included writing libraries and combining them with higher-level application logic. With the efforts of the various standardization organizations, especially IETF and 3GPP, we now have a set of high-level protocols that separate the computing engines. Functional entities can now be separated in diverse OSs, using different hardware architectures and buses and with Application Programming Interfaces (APIs) neutral to the development environment. System architects can now select the relevant protocols of interest and derive the computing engines for implementation. Protocols have replaced buses, OSs, and APIs.
A new era has begun where system engineers interconnect chips serially to build commodity computing engines, and multiple computing engines are clustered. Each computing engine runs autonomously with a well-specified functionality (service), supplied by multiple vendors and under different OSs. Each computing engine offers services via standardized protocols. Application architects are challenged to make such clusters of autonomous computers function as one system – they are taking on the challenge of functional interconnectivity rather than linear application development.
In the telecom industry the word platform has taken on a slew of meanings:
The development environment of complex ICs is a platform
A board with a set of ICs is a platform
A 1U box with the OS is a platform
A complete AdvancedTCA chassis with management software is a platform
But in the context of clustered autonomous subsystems, a platform is the enabling environment for functional interconnectivity – platform is the new term for distributed software.
High availability of what?
The importance of high availability is well documented among the ranks of the Central Office technologists. Meanwhile, the Internet experience, the Web 2.0 world, and the 1U to 2U pizza boxes have disrupted the telecom industry and cannot be ignored in new architectures like IMS. Typical (loose) interpretations of the high availability term imply that:
The hardware does not fail for a long time
The hardware and software combination (including the OS and applications) does not fail or need to reboot for a long time
The service provided by a system is not interrupted
It does not take much to restore outages because failed sub-units are Commercial Off-the-Shelf (COTS) components
We do recognize that the telecommunications industry has precise definitions for component or module reliability, serviceability, and availability. It is not our objective to reiterate or elaborate on the established terms, but it is worth noting that the Internet world has managed to create highly available services using a different paradigm. Today’s Web servers are based on rather unreliable computing engines, but with the appropriate connectivity protocols, load balancers, and similar tools, they have solved the availability problem and do provide excellent services. Functional interconnectivity has enabled Web application developers to offer inherent service availability. Furthermore, such servers are very scalable at a significantly lower cost than classic telecom equipment.
The telecom industry with the IMS architecture is well positioned to take advantage of Web server designers’ ingenuity and the respective protocols. It is envisioned that by using AdvancedTCA, blade servers, or even 1U and 2U servers to implement IMS network elements, the industry could create very robust service solutions at significantly lower capital and operating costs. Consistent with the technology trends just noted, the serial interconnects and autonomous blades are the basis of AdvancedTCA and MicroTCA. In addition, blade servers have commoditized computing engines with architectures that are almost identical to AdvancedTCA. The challenge to those building new IMS applications lies in how to provide functional interconnectivity to achieve service objectives on those computing engines.
Vertical silos or reusable services?
In the context of traditional network services, applications have been developed vertically by Network Equipment Providers (NEPs). IMS instead takes a horizontal approach. A set of computing engines, called network elements or nodes, conforms to a set of standardized interfaces, and all work well together. The premise of this new approach aims to:
Maximize reusability of network elements and interfaces
Make each network element vendor-independent
Enable competition for the network elements
Enable multiple network applications to control the interaction between available services and significantly reduce capital expenses
These excellent objectives are likely to be attainable. In the new world of the IMS platform, network applications are created by designing and controlling the interaction of well-defined IMS services.
Let’s not forget that truly innovative services involve end-to-end interactions, that is, media exchanges between subscribers and the terminating network services. If the system architecture is too horizontal, it will become hard to maintain a top-down, high-level picture of where thingshappen. Therefore, the following recommendations apply to IMS application developers:
Always maintain the end-to-end picture of the network application you try to create
If the portfolio of available IMS services is incomplete, include the appropriate extensions in the application platform
Differentiate by the application logic over the standardized protocols – not by introducing more layers or complexity
Techies love reusability of services. Product managers focus on innovating user experience and the respective revenues. IMS system architects are challenged to find ways to introduce new and innovative services utilizing reusable components.
The right technology for each network element
It is well known that the IMS specifications are dauntingly complex and constantly evolving. As of today, at least 3 major releases exist. Each release consists of several hundred documents, with more than 60 different network elements defined and using more than 2 dozen standardized interfaces.
To make the implementation task even worse, 3GPP (the standardization group for IMS) only defines functionality and interfaces – they leave the physical realization to the implementing vendors. Other organizations, such as the MultiService Forum (MSF) utilize the recommendations from 3GPP and attempt to create interoperable network elements at the physical layer. Therefore, before attempting to position AdvancedTCA, blade servers, and MicroTCA in the IMS space, we need to consider the perspectives of the decision influencers.
The hardware group’s perspective: Select the most flexible hardware platform because we have no idea what the application software might require
The software group’s perspective: Since software costs 10 times more than hardware, select the application first and acquire whatever hardware it is tested on
The system group’s perspective: For each system module, consider scalability, modularity increments, common equipment cost, system provisioning, and availability
The procurement perspective: Select the vendor with the lowest price and best service level agreement
The internal IT perspective: Use what my support staff knows best
The senior management perspective: Maximize the benefits to subscribers at the lowest possible lifetime cost
Since all perspectives are correct, who will make the top-down decision and under what guidelines? We will not be able to answer this question, but we will be able to make system-level recommendations taking into account many of the considerations already mentioned. See Table 1.
Components
Architecture
Rationale
Remote access elements
AdvancedMCs in MicroTCA shelves
• Multiplicity of external interfaces, primarily purpose built
• Extreme scalability
• Easy replacement without affecting too many subscribers
CO access elements
AdvancedMC either on MicroTCA or AdvancedTCA carriers
AdvancedTCA CPUs with specialty accelerator blades
• Large number of ports/sessions, high availability, some modularity
• Maximize functions on COTs CPUs for software flexibility and maintenance
IMS services layer
AdvancedTCA CPUs or blade servers with minimal purpose built add-ons
• Large number of ports/sessions, high availability of services, some modularity
• Maximize functions on COTs CPUs for software flexibility and maintenance
Application servers
Blade servers, 1U to 2U services, AdvancedTCA
• Easy to attach to the services layer, geographically distributed, high availability of services
• Primarily COTs
Table 1
Summary
IMS has been architected by combining multiple network elements with well-specified interface protocols. The IMS service is a horizontal layer of fundamental building blocks enabling new applications. AdvancedTCA, MicroTCA and blade servers are perfectly suited to implement various IMS network elements because they consist of autonomous loosely coupled subsystems, ensuring scalability and broad vendor availability. The paradigms from the Web world are applicable to the new generation of telecom applications on IMS, offering better development tools and inherent service availability. Network application developers need to utilize IMS services and computing engine protocols to implement the desired application logic.
George Kontopidis is the senior vice president of Products and Technology Strategy at NMS Communications. He has been managing development activities for the telecom industry for the past 18 years. He has a PhD and MSEE from the University of New Hampshire, and he is a member of the IEEE and ACM.
