RTC Magazine

In this day of service-oriented architectures that offer converged data, voice, video and mobile services on the same IP-based network, continuous service is an increasingly important requirement. However, designing a network element for deployment in a network expected to provide uninterrupted service is a complex task. Such a task requires specialized expertise, and significant resource and time commitment. While the availability of commercial-off-the-shelf (COTS) building blocks makes it easier, designers must follow a disciplined approach to ensure the resulting system meets the most critical requirements.

#1: COTS or Not?

The first decision to make is determining where to leverage COTS components throughout the system. A vibrant COTS ecosystem including standards-based hardware—shelves, blades, components, etc.—and high-availability middleware makes it very compelling to put together a system that accelerates time-to-market and revenue for even the most complex telecommunications applications. Empirical data in the industry is emerging that reinforces this assertion (Figure 1). This data shows that in-house development of a network element takes anywhere from two and one-half years to four years from concept to commercial deployment. Before revenue-generating applications are developed, significant R&D time and effort goes into designing the platform. Cost and effort can be saved if such a platform is acquired from the ecosystem, and resources quickly applied to the development of applications and services. A side benefit of such an approach is that since the platform has already been put together with pre-tested and pre-integrated COTS components, the overall testing and quality assurance effort is also reduced.

Choosing a standard platform like ATCA does not however mandate the use of COTS components throughout. Equipment providers can opt to use in-house solutions for any or all of the system, taking advantage of the standard platform with custom or cost-optimized components as required. Many companies use a mix of COTS and in-house design, working with suppliers to integrate and test a common platform for multiple products.

#2: Choosing a Platform

Once the COTS question has been answered, it’s time to choose a hardware platform. While the market offers many compelling choices, traction around ATCA is rapidly increasing. According to a recent survey conducted by Light Reading, 50 percent of the NEPs reported that they are developing systems using ATCA hardware. Furthermore, the survey data shows that an increasing number of telecommunications applications are beginning to use the ATCA systems. When choosing ATCA hardware, careful consideration must be given to several factors; key among them are switching options, fabric capacity, configurability, and thermal and NEBS validation.

The ATCA specifications provide many options for configuration of interfaces and switching across the backplane. Options for the fabric interface include Gigabit Ethernet, Gigabit Fibre Channel, 10 Gigabit Ethernet and RapidIO. The designer must keep in mind future upgradability when choosing a particular switching option. Over the past five years the performance of Ethernet-based ATCA systems has grown dramatically. In 2004, the first ATCA systems with a single gigabit Ethernet interface per blade had a total chassis capacity of less than 70 Gbits/s. With 10 Gigabit Ethernet switching, the capacity of second-generation ATCA systems has grown to almost 160 Gbits/s, and will grow further to 600 Gbits/s for third-generation systems with 40 Gigabit Ethernet (Figure 1).

ATCA systems not only offer many different options for ATCA blades but also enable the use of advanced mezzanine cards (AMCs). AMCs are hot swappable and have integrated system management functions. AMCs can be used in ATCA, MicroTCA and other platforms. There are multiple configurations for AMCs including single or double width, and full, mid or half-size modules.

Thermal and NEBS validation are a key part of ATCA-based system development. Quad core CPUs, 16 core NPUs and multicore DSPs are pushing the limits on power delivery and cooling. Chassis airflow varies from slot to slot, cooling efficiency depends on the airflow direction and distribution, airflow depends on board topology, and theoretical airflow data is typically based on unrealistic lamina flow tests. To ensure compliance, operating limits should be verified over the entire large range of target conditions and environments.