AdvancedTCA Provides Foundation for Next-Generation Telecom Equipment

AdvancedTCA Provides Foundation for Next-Generation Telecom Equipment

ATCA and AMC offer a level of open standards, high-level integration and flexibility that give telecom equipment manufacturers a higher level at which to start adding value.


As service providers build out their broadband packet networks to offer enhanced triple play services, telecom OEMs (TEMs) are working overtime to provide the equipment needed to deploy those services. Historically, TEMs have built this equipment from the ground up using proprietary platforms. A growing number, however, are finding it increasingly difficult to deliver homegrown equipment in a timely, cost-effective fashion.

To enhance their competitive position, many TEMs are beginning to utilize open architecture AdvancedTCA platforms, which make it easier for them to outsource their equipment design. Open platforms reduce the time and cost associated with designing and manufacturing telecom equipment, savings that are ultimately reflected in reduced capital expenditures for service providers. They also facilitate the design of modular, flexible telecom systems that are easier to scale, upgrade, service and maintain, benefits that are ultimately reflected in reduced service provider operational expenditures.

A Modular Telecom Framework

AdvancedTCA is an open architecture framework for building high-performance, high-density, high-availability, NEBS-compliant, 19-inch, rack-mountable telecom shelves.

ATCA’s centerpiece is its high-speed switched fabric, which supports a full mesh interconnect and provides a peak throughout of 10 Gbits/s per link, ten times higher than that of PICMG 2.16 backplanes. The ATCA switched fabric is also protocol-agnostic, enabling it to support multiple packet-oriented protocols, including Ethernet, InfiniBand, PCI Express and Rapid I/O.

In addition to its high-speed fabric, ATCA provides a number of other features that are critical for TEMs. Its large form-factor (8U) and high-power capability (200W per blade) give it the capacity to support complex functions and high-density configurations. Its redundant fabric, redundant power and hot swappability reduce susceptibility to point failures and enable individual blades to be serviced and upgraded without disrupting overall service. In addition, its Intelligent Platform Management Interface (IPMI) system control framework enhances availability by facilitating active monitoring of and control over individual ATCA blades (Figure 1).

AdvancedMC is a field-replaceable mezzanine interface for ATCA systems that enhances ATCA flexibility by extending its high-bandwidth, multi-protocol interface to individual hot-swappable modules. AMC’s high-speed, protocol-agnostic, serial packet interface provides up to 21 I/O channels, each supporting data transfer rates of 12.5 Gbits/s per channel. AdvancedMC modules are hot-swappable, enabling service providers to replace them in the field without taking entire ATCA blades off line. They offer high-power handling capability (up to 60W per module), which enables TEMs to implement complex functions at the module level. They also provide an IPMI interface, which enables shelf management to monitor and control individual modules residing on ATCA blades (Figure 2).

Interoperability and Compatibility

For TEMs who are considering a move from a proprietary in-house platform to an ATCA open architecture platform, interoperability and compatibility are top concerns. The promise of open frameworks is a plug-and-play shelf environment in which blades, system software and applications from multiple vendors and applications work together out of the box. What TEMs want to know, however, is how the promise of open architecture squares with the reality? How compatible is the platform hardware and software offered by COTS suppliers. How easy is it to integrate? What are the “gotchas” and higher level integration and development concerns?

As with any new standards, particularly in the OEM space, the AdvancedTCA and AdvancedMC standards are still evolving. However, the base standards are quite stable, and most interoperability problems are the result of faulty implementation rather than a lack of specificity in the standards.

Consider, for example, power management. ATCA blade suppliers may offer a carrier whose baseline power consumption falls within the ATCA limit. However, that blade’s total power consumption may exceed the allowable power allotment when populated with AdvancedMC modules. In such cases, shelf management will refuse the blade’s power request during the boot process, rendering the blade inoperable.

One of the principal sources of early ATCA compatibility problems has been shelf management. Some ATCA blade suppliers, for example, have elected to design their own IPMI controllers. This is perfectly allowable but some suppliers have misinterpreted the spec and/or have added their own proprietary functionality. As a result, shelf management can have difficulty recognizing and communicating with these blades, thereby complicating board bring-up and ongoing management.

The addition of AdvancedMC modules to ATCA carriers adds another level of complexity to the shelf management equation. AdvancedMC modules are essentially a blade within a blade, equipped with I2C management infrastructure that enables shelf management, through the blade’s IPMI controller, to monitor and control each module.

To facilitate communications with shelf management, each module is equipped with a module management controller (MMC), a kind of lightweight IPMI controller that provides information such as module ID, FRU data, power payload information and temperature to the blade’s central IPMI controller. The IPMI controller, in turn, aggregates this information for all the modules (and the carrier) and conveys it to shelf management (Figure 3). The problem is that some module providers are not adhering to the MMC design guidelines. This prevents the blade from locating the module and bringing it out of reset, thereby making the module invisible to the blade and shelf management.

Fortunately, both problems are easy to avoid. For example, blade designers can now purchase COTS IPMI controllers that follow the spec to a tee, thereby eliminating interoperability problems at the controller level. COTS MMC solutions are not yet available but this functionality is straightforward and can be readily implemented in a compatible fashion by simply adhering to the standard.

Blades Become More Shelf-Like

Beyond basic plug-and-play issues, what really concerns equipment makers who are selecting a COTS blade is how easy it is to integrate that blade with the rest of the shelf, including other blades, system software and applications. This is particularly true for complex blades equipped with multiple processors.

In the past, where single-processor, single-node blades were the norm, the only system software that a blade supplier had to provide was a set of drivers for the target operating system. The blade architecture was also straightforward and accessible, employing an internal PCI bus for memory access, a backplane interface for shelf access and an external TDM bus for telephony access. The task of creating a framework to facilitate management of and communications between multiple nodes/blades fell largely on the equipment maker.

Today’s high-density ATCA blades, however, are no longer individual nodes. ATCA’s large form-factor, high power budget and multi-module expansion capabilities enable a single blade to support a half dozen processors or more, a cluster of nodes on a single blade. Utilizing these processors requires a scalable blade-level system software framework that enables developers to develop, deploy and manage applications distributed across multiple cores and processors. It also requires a hardware framework with control, data and switched fabric pathways that provide the flexibility and throughput needed to coordinate the activities of multiple processors, both on the blade and between blades. In many ways, this framework mirrors the framework that equipment makers now provide at the shelf level.

Consider, for example, the blade-level architecture employed by an ATCA carrier that combines a PowerPC processor with four AdvancedMC sites, each of which may be equipped with a Pentium M-based AMC module. To support this multiprocessor network, a multi-channel managed Ethernet switch links the PowerPC processor and four AMC sites with each other and the ATCA switched fabric. In a sense, this blade-level switched architecture is simply an extension of the shelf-level switched architecture.

Now that blade suppliers are utilizing shelf-like switched fabrics, the pressure is on to deliver higher level switching capabilities. Most blade suppliers provide a basic API for interacting with the switch. What TEMs would like, however, are higher level Layer 2 capabilities like routing, VLAN and QoS, and ultimately a fully managed Layer 3 switch.

TEMs looking for an out-of-the-box solution are also demanding more robust management capabilities. IPMI is an important first step. But ultimately, TEMs would like a hierarchical reporting framework for system management that encompasses the blade, operating system, interconnect and application. To that end, blade suppliers are working to provide full shelf management capabilities up to the middleware level. Some application-specific blades and SIGTRAN signaling blades take system management to an even higher level, providing event, statistics, signaling and other reporting that extend past the middleware and into the protocol stack.

As blade manufacturers work to enhance their “value-added” and simplify system integration for TEMs, standards bodies like PICMG, OSDL and SAF are working to provide the standard operating system, shelf, middleware and application interfaces needed to facilitate interoperability and portability. At the same time, industry organizations are emerging that will provide functional and interoperability testing and certification for different classes of high-availability equipment utilizing open hardware and software platforms.

For TEMs accustomed to creating custom application-specific platforms in-house, the decision to relinquish control and move to an open platform is a challenging one.

Ultimately, though, TEMs must weigh the incremental performance advantages of custom platforms against the cost, time-to-market and flexibility advantages of open platforms. Blade suppliers can expedite this transition more easily by providing system level solutions that ease the integration process and enable TEMs to focus their precious engineering resources on value-added application and service development.

Emerson Network Power
St. Louis, MO.
(680) 831-5500.