Building a carrier-grade network element capable of providing continued service availability in the presence of failures is a complex undertaking. Historically, telecom equipment manufacturers (TEMs) have designed and built such systems from the ground up using the specialized, in-house expertise they have developed and nurtured over decades. Many TEMs—especially the tier 1’s—have invested a significant amount of time and resources in developing software services, often referred to as high-availability middleware, essential to building network elements that provide five nines or better service availability.

Recently, however, such middleware is becoming the focus of various independent software vendors (ISVs), who are providing software products that package a collection of key services that can be acquired off-the-shelf and employed in system design and implementation. Helping this proliferation are the key standards efforts such as the application programming interface (API) specifications published by the Service Availability Forum. The Forum has provided two sets of API specifications: a hardware abstraction layer termed Hardware Platform Interface (HPI), and an application abstraction layer called the Application Interface Specification (AIS). Together these specifications, when implemented, allow for portability of service availability middleware as well as applications that comply with them. A specific example of how to build a highly available wireless network element using commercial-off-the-shelf (COTS) components can be given using the case of a Base Station Controller (BSC).

Anatomy of a Highly Available System

Broadly speaking, there are six categories of essential services that are required in building such a system. The centerpiece of any high-availability middleware is its availability management services. Systems management services enable the creation of both external and internal management functionality. Application services are targeted primarily at developers to simplify the development of applications for highly available systems. Platform management services interface with a particular hardware platform’s management capabilities, to ensure proper discovery of resources and subsequent population of a system model.

Foundational services provide a variety of functionality that system developers can utilize to build highly available systems. The kernel is a small, reliable, cross-platform foundation for all services, and helps abstract platform-specific capabilities into generic, platform-independent capabilities. The services that comply with the AIS specification are represented by the red blocks in Figure 1.

Assuming all of these services are conveniently available in a package to the system designer, let us dive into how one would build a base station controller that processes voice calls from a number of base stations that it aggregates. Designing such a system typically involves establishing system requirements, determining the deployment configuration and mapping middleware capabilities to the desired solution

In establishing system requirements, a base station controller must provide three key functional elements. Operations, administration and maintenance (OA&M) satisfy the requirements of the functional areas described by the acronym. Effectively, this element is the system manager responsible for monitoring the state of the system, and providing an interface to the outside world, e.g., to an element management system. Secondly, call control provides the voice processing services within the system. This element communicates with the OA&M element as well as with the third element, media control, which manages the switching configuration for the media on which the voice calls are transmitted and received.

For uninterrupted service availability, each of these functional elements needs to be highly available. One common and logical way to ensure this is to provide redundant pairs of each of these functional elements in the system, and to ensure that these elements operate in independent fault zones, with each element designed to run on its own node. We will assume that the system will be designed using some standards-based bladed system such as ATCA, Blade Center, etc., so that each of the functional element instances will run on a blade within the shelf.

Figure 2 depicts a deployment configuration for the base station controller. The hardware components or resources in this deployment configuration include the following: