AdvancedMC Insider April 2006

This spring at 3GSM, SBS Technologies announced a new BladeCenter T AdvancedMC carrier to support IBM's BladeCenter. The new carrier houses four AdvancedMC modules and enables the rapid development of convergent IMS media processing and signaling gateway solutions. Hal A. Humrickhouse, Worldwide Product Manager - eServer Group, IBM BladeCenter T, recently took time to answer a few of our questions about the addition of AdvancedMC modules to the BladeCenter T solutions portfolio.

Q: As an open, modular architecture, eServer BladeCenter T seems like a good candidate for AdvancedMC modules. What factors tipped the scales for IBM in choosing this form factor?

Simple. We think the AMC form factor will be a de facto industry standard for converging legacy I/O applications into an IP-based, NGN network. Our strategic commitment to COTS, coupled with listening to our customers and the marketplace, led us to this decision.

Q: What were the biggest technical hurdles to making AdvancedMC fit seamlessly with the existing BladeCenter T environment?

IBM has always appreciated (and has driven) the flexibility of a modular computing platform environment. Our challenge to integrating AMCs into the BladeCenter AMC-Carrier was hitting the moving target of the AMC standards, which are still in flight. By acknowledging our weakness in understanding the dynamics of the AMC standards within PICMG, IBM's Engineering and Technology Services (E&TS) division chose to partner with SBS Technologies who we feel possesses deep domain knowledge in the AMC market place, and has been a major player in the development of the AMC standards.

By understanding our own limitations, we were able to jointly develop a superior solution that has seamlessly enabled AMC modules into the IBM BladeCenter platform by partnering with a domain expert like SBS.

Q: Have any of your customers or prospects commented on the AdvancedMC deployment, and if so, what has been the general reaction?

Since our announcement at SuperComm 2005, IBM has received extremely favorable and positive reaction worldwide to our partnership with SBS and the joint deployment of the AMC carrier blade. Network Equipment Providers, Operators, ISVs and other strategic integrators have universally supported our adoption of the AMC standard and leverage of AdvancedTCA technology ideally suited to supporting transport/data plane applications such as gateway and signaling applications in the IBM family of BladeCenter chassis.

The BCT-4 AMC-Carrier Modular Communications Blade is available today from SBS Technologies and support in the IBM BladeCenter chassis family is targeted for late 3Q06. As recently witnessed at 3GSM (Barcelona) and TelecomNext (Las Vegas), we see strong sales momentum.

Q: Strong momentum is now gathering behind the commercial off-the-shelf approach to telecom equipment. How is the IBM BladeCenter T offering benefiting from this?

The transition to NGN is driving the need for standards and changes in business models. The legacy Telecom Development Model of yesterday built on proprietary, costly platforms is transitioning to an NGN Telecom Solution Development model in which emerging applications such as VoIP, IMS, and IPTV will be based upon a common, open standards hardware, OS and middleware greatly reducing cost.

Key IBM early NGN standards efforts began with our founding and investing of millions of dollars beginning in the mid-90s in the Carrier Grade Linux (CGL) working group to work with the open source community to develop specs to make it more robust. We worked with companies like Nokia to found Service Availability Forum (SAF) with the goal of driving a common way of creating the HA aspects of NGN solutions and stopping the wasted reinvention of the wheel by every solution team and supplier as they created new telecom applications.

We created the notion of Carrier Grade Open Framework (CGOF) by working with partners to decide where to focus and how to really productively create NGN applications. As we shared the notion of CGOF, many of our partners encouraged us to make this a public open standard, and so the notion of Open Communications Architecture Forum (OCAF) was born to bring in the whole industry to refine the concept and make it an open standard.

In summary, by helping drive open standards for NGN application platforms and our adoption of a COTS strategy many years ago, IBM BladeCenter T is now benefiting handsomely. We have deployed hundreds of units since our delivery to market in June of last year with very strong sales momentum and pipeline. We are innovators driving the technology curve with TTM advantage vs. laggards.

Q: AdvancedTCA and BladeCenter T would appear to be in direct competition with each other in the telecom space. How will the inclusion of AdvancedMC strengthen the IBM position?

BladeCenter T and AdvancedTCA complement each other well in the marketplace, with BladeCenter T supporting the fastest and most integrated turnkey server platforms in the industry and AdvancedTCA being well suited to the needs of transport layer applications. Standards activities like CGL, SAF, OCAF reinforce a common framework for software that enables applications to be supported across both products, and AMCs extend the ability to leverage common components in each platform.

IBM BladeCenter T is a high performance, compute centric carrier grade platform ideal for telco Service and Control plane applications. IBM's inclusion of AdvancedMC strengthens our ability to support the wide array of legacy telco network interfaces and network processors that Operators will require as they migrate to a converged IP network.

Given that AMC form factor cards will likely be the de facto industry standard for I/O in the future, our adoption of the technology now extends our value proposition from the core to the edge of the network.

In addition, new ecosystem partnerships have resulted broadening the ability to integrate once independent solutions into pre-integrated and tested, network ready solutions.

Q: IBM has an extremely strong position in the server market. Is there any discussion within the company of including AdvancedMC directly on some of those blades?

Most computer platforms only do two useful things with data—they inhale it (IO) or chew on it (compute). Mixing both operations in the same time and place can be hazardous, like choking. A Blade design that attempts to do both (AMCs and serious Processing) struggles to do either well (i.e., an AdvancedTCA Blade with 4 AMCs has little real estate or power left for any significant computing). That is precisely why IBM chose to develop the AMC-Carrier as a separate packaging entity from its powerful compute blades which deliver 250-430 Watts of computing per slot.

The BladeCenter AMC-Carrier enables flexible IO and PrAMC options for our customers without sacrificing the compute capability that has earned BladeCenter worldwide leadership and #1 market share.

Q: One of the original arguments for an open, standards based telecom architecture was volume pricing. How does this play into your strategy?

Hugely important—make no mistake about it. IBM development costs for BladeCenter T and accompanying blade servers are spread across the entire blade market, telco and enterprise. If you believe the industry analysts, the enterprise blade server market is 7X the size of telco blade servers. So, by spreading our costs across a much larger pie, our individual unit costs are much lower.

Furthermore, we design NEBS compliance into our blades and do not have to charge a premium for it.

Q: Considering the high power dissipation and density of these systems, how big an issue has cooling been?

Good question. Certainly cooling is a major challenge for IBM and likely any supplier of blade architecture given the nature of higher and higher performance processor roadmaps and obvious density issues. Having been in this industry for almost 20 years with several companies, I have not seen a company more committed to innovation leadership working with partners to deliver integrated, cost effective solutions rapidly to the market.

Cooling is the sleeping bear in the ATCA chassis closet. An ATCA blade with four AMCs lined up in a row may face a challenge properly cooling the last module, due to the pre-heating from the other three. The IBM AMC-Carrier Blade has arranged its four AMC bays as two separate bay pairs and does not suffer the three-module pre-heating issue. The BladeCenter chassis family has superior air flow, optimized for both Telco and Enterprise platform environments. BladeCenter offers a number of chassis form factors (with 3 in market today) enabling the customer to choose how to best accommodate his platform environment.

Q: AdvancedTCA system management is based largely on IPMI. How well did that structure fit into the existing BladeCenter T system management scheme?

The IBM BladeCenter T supports IPMI. It is the fundamental protocol for the chassis management system within the BladeCenter chassis between blades and the management module. Adapting to support AMCs was not a huge task, insuring that everything interoperates properly and in a turnkey fashion has been our focus—integrating in our labs so the customer doesn't have to.

Demonstrating true interoperability between customer-chosen Blades and AMC modules is a real concern for the customer. You'll note that IBM's BladeCenter platform came out years before AdvancedTCA, and BladeCenter was architected in collaboration with the founders of IPMI. BladeCenter blade management is centered on the IPMI architecture. Adopting and managing AMCs thru their IPMI interfaces is a natural extension of the BladeCenter IPMI-based management Architecture. Together, we need to watch that AMC vendors comply with the AMC IPMI requirements. SBS always has, and has been a dominant player in the interoperability workshops.

The several hundred companies that are participating in the PICMG consortium are struggling to demonstrate Standards compliance and true interoperability. IBM respects that challenge and has learned to deliver Server-Proven interoperability to the customer, under one roof, that high-reliability customers have come to appreciate.

We need to do a better job of communicating IBM BladeCenter T support for IPMI in the marketplace.

Rubin Dhillon, V.P. Communications & Enterprise I've gotten used to hearing wireless operators complain that the cost of their radio access network, or backhaul network, represents an increasing drain on profitability.

Backhaul services allow telecommunication carriers and Internet Service Providers (ISPs) to aggregate network data like Internet traffic and phone calls to a central point and then from there, on to a Wide Area Network (WAN). This ability to aggregate network traffic is important for new carriers who can connect their customers in places where they don't own the network.

However, the increasing costs of backhaul services are killing carriers mostly because of the price they have to pay to lease expensive T1/E1 lines. These lines are a recurring cost to carriers and ISPs, and that cost increases every time they improve service by increasing bandwidth to base stations. I'm not privy to the exact numbers, but I have heard that the cost of backhaul as a percentage of overall network operating expenses ranges from 20-40% for G2 networks, to as high as 50-60% for G3 networks.

As you can imagine, the wireless guys did not take this situation sitting down. They developed a number of packet-based backhaul approaches to make more efficient use of their T1/E1 bandwidth. The most familiar of these strategies are Carrier Ethernet, xDSL, cable HFC, passive optical networks and broadband packet radio technologies like WiMAX.

One of the greatest challenges to implementing these broadband packet technologies has been accurate clocking, especially for TDM-based voice traffic. A fairly popular solution to the timing dilemma was Pseudo-Wires, but for equipment makers and system designers these days, the use of an external GPS clock is starting to look like a better, more economical approach. This seems to be especially true for new WiMax implementations which may not have physical access to a telecom network clock that allows synchronization with other devices on the network.

The most obvious advantage of GPS-based timing is that it allows the base station to achieve complete independence from any physical connection to the network. Without the GPS clock, even radio broadband technologies such as WiMAX need some form of physical connection to the network clock. However, with the addition of a GPS clock, all traffic in both directions can be synchronized and transmitted wirelessly. I consider this quite amazing considering the timing tolerances involved, which are in the range of parts per billion.

The simple addition of a GPS clock like the Telum GPSTC-AMC module, solves the synchronization problem by using GPS satellite signals to provide an extremely precise clock. For SBS, the goal in creating our new GPS AdvancedMC was to offer this key enabler to further the adoption of modular architectures like AdvancedTCA and MicroTCA in next generation communications equipment. Personally, I would love to see WiMAX succeed, and this module is a key part of that puzzle.

Our GPS clock card provides a very stable 30.72 MHz clock output that is phase aligned to GPS-derived 1 pulse per second (PPS) input. It uses a temperature-compensated voltage-controlled crystal oscillator (TCVCXO) with a 30.72 MHz center frequency and a minimum Stratum 3 stability of 0.37 parts per million (PPM). The onboard Intelligent Platform Management Interface (IPMI) subsystem monitors board voltage and temperature conditions, maintains system status, and manages hot swap operation. There's always a chance that the GPS signal could be lost, but phased error detection allows the GPS clock module to free run in that case.

The whole idea behind AdvancedTCA and AdvancedMC is to offer telecom equipment makers the cost and time economies of standardized equipment. SBS is committed to making that strategy a reality. My hope is that this module will make it easier and more economical for wireless equipment makers and providers to design new networks from standard hardware so that exciting applications like WiMAX can become part of our everyday lives.

By Jeff Marden, Technologist - Communications Considering the amount of interest being generated by AdvancedMC modules and the MicroTCA concept, this might be a good time to provide an update on specification activities within the PICMG for MicroTCA and the AMC.0 ECNs. There has been a great deal of activity behind the scenes, including requests for literally hundreds of changes.

On the one hand, the sheer volume of requests has been an obstacle to speedy completion of the ratification process. But on the other hand, the number of proposals for change is encouraging because it indicates a high degree of interest in these specifications. Even with this amount of change in the air, the MicroTCA subcommittee is projecting public release of the base specification within a matter of months.

It is never easy to reach consensus on certain issues, but the importance of interoperability cannot be overstated for the entire AdvancedTCA ecosystem. It might seem expedient to gloss over differences among members concerning some thorny issues. However, for an open specification to be truly successful it must be clear enough and precise enough to ensure an extremely high level of uniformity and consistency from vendor to vendor. PICMG and the committee members are committed to this goal.

PICMG MicroTCA
The MicroTCA Subcommittee met for three days at the end of March to review the Draft 0.9 version of the MicroTCA specification, having published this draft revision to the PICMG Executive Committee for review and comment. Several hundred Change Requests (CRs) were logged, discussed and closed at the review meeting. There were, however, several topics of discussion that were either not addressed at the meeting, or not completed and closed by the end of the meeting, including three sections of the specification which did not close on CR review.

Several MicroTCA committee conference calls have occurred since the face-to-face meeting, addressing issues from the meeting. There are however a number of open items still undergoing review and discussion. Specification section authors are updating their section text according to the CR closure review and subsequent discussion. The MicroTCA specification is scheduled for Release Candidate version 1.0 review in the next few weeks, with proposed public release by mid-year.

PICMG AMC.0 ECNs
The AMC base specification has been opened by PICMG for review and change via two Engineering Change Notices:

ECN001 - This ECN proposes changes to the AMC.0 specification to add alternative AMC connector foot-print definitions to the specification. After subcommittee work, AMC.0 ECN001 has been sent to the PICMG Executive Committee for Ballot Review and comment. This ECN is meant to be released in the next few weeks (without Ballot Review issues).

ECN002 - This ECN is meant to provide an input for proposals to change any and all elements of the Revision 1.0 AMC.0 Specification. The subcommittee has accepted Change Requests to all sections of the specification for discussion. The range of proposed changes to the AMC.0 specification has been quite large, but has narrowed over the past months of subcommittee work. A Draft 0.6 version of the AMC.0 ECN002 specification has been circulated to the subcommittee for review and comment as a first consolidation of all of the Charge Requests and their proposed and negotiated resolution. Several issues and CRs are still open at this point, but the AMC.0 ECN Committee is actively working to discuss and close these issues. While the original schedule for AMC.0 ECN002 was to complete the effort by the end of March, 2006, the subcommittee hopes to cope with the delays to this point and complete ECN002 work in the next few months.