From the beginning, ATCA initiators and advocates aimed high. For every given parameter, they wanted more, and better. In fact, they sought ‘much better’ rather than just ‘better’. The founding fathers, united under the PICMG consortium, confronted three of the most troubling bottlenecks found in many modern telecom systems: power, space and bandwidth. The solution they created was an impressive antidote for these pains: 200W per blade (recently pushing towards 400W!), more than twice the space given by the compact PCI and 2.4 TB/second for the full-blown chassis.

Does ATCA fit? What’s missing?

Was this solution good enough? Yes, it was as a framework, but not from a practical perspective. To make it work, we needed to build on the framework with some much needed inner-workings. For starters, there was the addition of an advanced and (more importantly) standard management mechanism, followed by built-in high-availability capabilities to allow redundancy, an essential for telco environments. Finally, we brought in a ‘mix and match’ approach, fully supported by the AMC modular architecture.

After developing the framework and making the standard public, we set about developing a healthy ecosystem, firmly and surely. Today, one can select a multitude of off-the-shelf elements from a rich variety of vendors, covering all types of hardware and software: chassis, backplanes, processing and DSP blades, switches, signaling and line interface cards are all generally available and ready to go. The selection is overwhelming and everyone who is someone in the server and COTS blade industry has an ATCA portfolio. Another good sign indicating the well being of our precious ecosystem is the fact that most Tier 1 network equipment manufacturers have already launched an ATCA-based portfolio along with their proprietary product lines.

The solution is making progress, but is it ready for actual system integration? Can we really pick a chassis, add management modules and stacks, plug in some of the finest high-end processing blades, and then head straight into developing our killer application? Is this vision a reality?

The road ahead goes in two directions, vertical and horizontal. The vertical direction connects the interfaces between the different layers within a system while the horizontal direction ensures interoperability between different systems/elements and allows integration into a complete solution.

Think vertical!

The relatively new standardization effort of the SAF (Service Availability Forum) answers the requirements for vertical progress. The SAF is a consortium of communications and computing companies that have joined forces to develop high-availability and management software interface specifications. This specification is mainly defined by the AIS (Application Interface Specification) and the HPI (Hardware Platform Interface). These standards define the interfaces between hardware and management software, resulting in the ability to build effective, high-availability mechanisms. The adoption is quite impressive and it is becoming a de-facto industry standard.

But let’s take a moment here to play devil’s advocate: we know that high-availability features (99.999%), essential for most Telco grade equipment, are also known to be in the core of the proprietary know-how for any system designing vendor.

Is it too presumptuous to assume this can be standardized?

The answer is again yes - and no. On the one hand, we see good signs that it is feasible. One can find a few software/firmware packages offered to answer this need. In a nutshell, these tools are formalizing standard resource allocation and redundancy mechanisms that can be customized quite elegantly to almost system architecture. Maybe it’s a bit too soon to say, but judging by the feedback of a few of these software vendors, they see good potential, specifically with Tier 2 and 3 NEPs, probably since they do not carry the heavy burden of legacy proprietary know-how as Tier 1 NEPs do. Let’s not forget that these types of solutions owe their existence to the recently-adopted industry standards (AIS and HPI set by the SAF). It’s a long process, penetration is difficult, but the curve is at the right gradient.

Now, think horizontal!

The horizontal road is focused on ensuring interoperability between different elements. One might ask, “What’s the big deal with interoperability? Don’t we have a well-defined standard? Can’t we pick what we like off the shelves of the ‘ecosystem supermarket’ and let the standard do the rest?”

Don’t be surprised if real life proves differently. Every engineer with sound practices realizes that ‘open standards’ are too good to be true. It may be a nice concept but someone has to pre-check it to make it work! Interoperability is the key here.

The good news is that a few bodies have recently been established to answer this need. Here is a quick tour of the interoperability standards bodies:

The CP-TA is an association of equipment providers with a charter to expand the adoption of open standards by setting the framework for interoperability certification. Its goal is to drive the market towards a standard platform and they believe that the way to achieve this is by creating an ecosystem of pre-certified building blocks and platforms. This initiative is the first time we can see this issue being practically mastered, by defining what has to be pre-tested, organizing the forums and certifying the interoperable elements. Previous to this, all interoperability was vendor-to-vendor specific and rarely open to others in the industry. CP-TA focuses on ATCA and works closely with PICMG and SAF and thereby, in a way, completes the picture.

Another significant forum is the SCOPE alliance which was established by leading network equipment providers such as Alcatel, Ericsson, Motorola, NEC, Nokia and Siemens. These NEPs are interested in creating a stable ecosystem, but, more than that, in ensuring that vendors will know what is expected of them in order to provide the building blocks for carrier grade equipment. In other words, adhering to ATCA is nice, but it’s not enough. SCOPE will review industry standards (ATCA, SAF, OSDL, etc.), list important attributes which are of necessity, and indicate the requirements that need to be filled by the vendors. SCOPE then creates a ‘profile’ which is a subset of the relevant specifications reflecting requirements of interfaces and building blocks sufficient for building Carrier Grade Platforms. SCOPE will also provide reference architectures which serve as a set of guidelines for building carrier grade systems.

Now, the CP-TA takes SCOPE profiles into consideration when it defines its test protocols. Noticeably, all these bodies are quite coherent and synchronized to the benefit of the designing vendors aiming at the Service Provider and Telco markets. Assemble these parts of the puzzle, and we can begin to see a more complete and comprehensive picture: starting from the hardware layers, continuing with management, control and high-availability protocols, through interoperability of different elements, and finally ensuring that it will all meet the ‘real-life’ requirements of the target customers.

Following the application roadmap

Another good indication of the health and maturity of our growing ecosystem is the evolution of the applications that are targeted by the vendors. In the early days, vendors provided mainly data and control layer applications to set the infrastructure of networks. Nowadays, the aim is more to provide revenue-generating applications driven by the adoption of 3G networks and the growing adoption of IMS (Internet Multimedia Subsystem) architecture. Looking at the ecosystem, we see this market influencing a growing variety of voice and video processing elements being released and made available. The industry grew from generic and general-purpose processing elements to an era of application-specific and optimized media processing building blocks.

Media processing blades were one of the most sensitive elements suffering from bottlenecks in the former architectures (Remember? Power, bandwidth and space?), so they’re now expected to flourish with ATCA. For example, AudioCodes’ IPM-1610, a media processing blade reaching the power limits of the cPCI, is capable of 480 voice channels. In the future, the capacity of AudioCodes’ IPM-12610 ATCA blade will be 4032 channels. This change is dramatic. It impacts the cost efficiency and space efficiency of the whole solution. Isn’t this, in fact, what we aspired towards in the first place, when developing ATCA?

Approaching the finish line

Looking over on the ATCA evolution on a whole, we can be proud to have developed a healthy ecosystem. Besides its rich diversity, it is clear that health is not only about the number of vendors or the variety of available components. There are other more critical elements needed to make this bundle stick together. They are: a well-defined set of service provider requirements, defined by the SCOPE alliance; a robust set of interoperability tests defined by CP-TA, aimed at easing integration pains; complementary standards such SAF; and finally, software packages designed to formalize the high-availability mechanism, which until now has been kept well hidden in obscure proprietary zones.

Let’s not forget that there is still a long way to go for a significant industry adoption of open standards. ATCA adoption is not yet the common practice. The secret is interaction and communication between all members of the community. The more we interact, test, interoperate, and learn from each other, the more our solutions will be ready to use, the more rapidly deployable they’ll become, and the more commercially attractive they’ll be.

If we stay on this road and work together as an industry, we’ll eventually reach the finish line and be able to deliver highly reliable and interoperable systems.