 |
Telecom equipment manufacturers can ease the telecom software crunch by using open architectures and COTS software
By Terry Pearson, VP Product Management at Enea Embedded Technology
Speed the development of complex distributed telecom applications by using Network software platforms based on open architectures and industry-standard interfaces
According to industry analyst Venture Development Corporation (VDC; Natick, MA), the amount of code deployed in today's network equipment is growing exponentially—currently accounting for more than 50% of total project costs. Meanwhile, the number of available developers is growing at a relatively flat pace, thereby creating a serious mismatch that makes it increasingly difficult to meet time-to-market windows. Already, VDC estimates that 50% of device projects fall behind schedule by an average of four months.
Most equipment makers abandoned the practice of creating their own proprietary DSPs, network processors, operating systems, protocol stacks, and management tools long ago.
Many, however, are still creating significant pieces of their application-specific hardware and software infrastructure from the ground up, constantly inventing and reinventing the wheel from one project to the next. For these equipment makers, many of whom are trimming engineering staffs in order to contain costs, this home-grown approach is becoming increasingly untenable.
To ease their software crunch, and make do with leaner engineering staffs, many equipment makers are embracing a new development paradigm known as Device Software Optimization. DSO represents a fundamental rethinking of the design process, leveraging products and practices that embrace reusable code, open standards, and pre-integrated commercial off-the-shelf (COTS) technology, standardized across the enterprise (not just across a single development group).
DSO Telecom Platforms
Pre-integrated DSO telecom platforms transform the lengthy platform design/integration process into an evaluation and purchasing process that can take as little as two months. All told, this COTS approach can shorten the application development cycle by up to 50%. It also enable equipment makers to trim their platform teams by up to 80%, thereby reducing manpower cost and enabling NEPs to reallocate precious engineering resources to value-added application and service development.
Open architecture platforms provide a layer of abstraction that enables a clear separation between telecom applications and the underlying hardware and system software. This layer of abstraction, coupled with the use of standard interfaces, enables designers to use best-of-breed, COTS hardware and software from multiple vendors. It also enhances portability, allowing NEPs to upgrade hardware and software at later dates with minimal disruption to their proprietary applications.
Figure 1: Open-architecture telecom platform
Open-architecture telecom platforms provide the basic components needed to develop and host telecom applications and services. These components typically include (see Figure 1):
Operating Systems
The foundation of a telecom software platform is the operating system (OS), which provides basic multitasking, program loading, memory management, I/O, storage, and network access services. Ideally, the platform should support multiple operating systems in both homogeneous (i.e., Linux or an RTOS deployed throughout the system) and heterogeneous configurations (i.e., a combination of Linux and one or more RTOSes deployed on multiple CPUs, shelves, and blades).
This flexibility enables developers to select the OS or processor combination best suited to their application. For example, some NEPs may prefer to run Linux on one set of blades to host IT-oriented supervisory and enterprise management functions, while using an RTOS on another set of blades to host DSP-based media processing applications with tight size and performance constraints.
Figure 2: Basic LINX Architecture
Interprocess Communications
In a distributed network, interprocess communications (IPC) frameworks like Enea's LINX provide the glue needed to integrate platform components and applications across multiple processors, operating systems, blades and shelves (see Figure 2). Ideally, this framework should provide dependable, high-speed transport for both the control and data plane over reliable as well as unreliable interconnects and protocols. It should also support the encapsulation of other bearer protocols—such as TCP, UDP, and SCTP—for data transport.
To maximize performance, the IPC services should utilize direct message passing, which enables application processes to communicate directly with each other on a peer to peer basis, without having to synchronize through intermediate mechanisms such as mailboxes, semaphores/mutexes, event flags, Unix-style signals, or even sockets. This direct approach also simplifies communications and facilitates logical process separation, thereby enhancing reliability and simplifying fault recovery, particularly in distributed systems utilizing multi-core devices and complex network topologies.
To maximize scalability and portability, the IPC services should provide transparency, independent of the underlying processor, operating system, or interconnect. This transparency enables distributed platform components and applications to communicate in a seamless fashion, as if they were residing on a single processor under a single operating system. When combined with the ability to dynamically discover communication endpoints, this transparency also enables developers to locate applications on any node in the system, and change the configuration at run time. The resulting system provides a high degree of flexibility, enabling developers and service providers to dynamically change and scale the system configuration, redistribute applications across multiple blades, and upgrade the hardware with minimal changes to the application code.
Middleware Framework
The flexibility provided by the network platform's IPC layer lays the foundation for more advanced distributed communications, instrumentation, monitoring and high availability services, collectively referred to as middleware. The middleware extends the IPC's process-to-process communications services, providing one-to-many communications that facilitate system wide communications, instrumentation, and event notification. These extended communications services, in turn, lay the groundwork for high-availability monitoring, detection, recovery and reporting services that are essential for building a true non-stop computing platform.
The middleware's event logging services, for example, enhance visibility into application operation by enabling processes to log and report events and state transitions such as start-up sequences, slot/service availability, diagnostics and critical network events (i.e., alarm conditions). These services enable developers and network operators to interactively inspect these logs (i.e., through an HTTP browser). They also make it possible to aggregate the logs system wide and archive them to persistent media (including remote file systems) for live or post-mortem analysis.
To simplify configuration and management at the slot, blade, and chassis level, COTS middleware solutions provide shelf management services, typically utilizing standard interfaces like HA Forum and ATCA's Hardware Platform Interface (HPI). Shelf management performs a hardware inventory each time a system powers up to ensure that all the cards, blades, and chassis have been properly activated and initialized. It also tracks revision numbers and ensures that the correct software is running on each card. Once the system is initialized, shelf management monitors key parameters like temperature, voltage, fan speed, power consumption, and memory/CPU utilization. It also provides alarm management and hot swap services that enables individual blades to be inserted and removed from a live chassis.
Complementing the middleware's shelf management services are heuristic fault management services, which provide monitoring, detection, recovery (i.e., restarting a failed application or failing over to a redundant blade) and reporting for every resource in the system. Active heartbeat monitoring and passive error detection allows the fault management system to ensure the health of key hardware and software components at the system, slot and application levels. The fault management system can also handle upgrade management, treating in-service upgrades as a special fault/failover case.
Database Management
To simplify information (data) management and sharing across multiple nodes, the network platform may provide a relational database management system (RDBMS). Unlike traditional desktop databases, these embedded databases must often work in a diskless environment. They must also deliver higher levels of performance and availability than traditional desktop databases. Enea's small-footprint Polyhedra RDBMS, for example, uses a memory-resident design that boosts performance by 10x relative to conventional disk- and flash-based RDBMSs. It employs an active, event-driven push technology (applications are immediately notified of data changes), which further increases performance by eliminating the need for polling. And it provides journaling and fault-tolerant mechanisms such as failover control and fast reconnection that enhance data persistence and system availability.
In the past, NEPs have been content to roll their own OS, middleware, and database solutions. But a growing number are recognizing that they can no longer remain competitive by creating, maintaining and porting platform software in house. The emergence of field-proven, pre-integrated COTS network platforms like Enea's NASP allows NEPs to outsource their platform design, focus their engineering resources on value-added applications and service development, and get their completed designs to market on time and on budget.
Terry Pearson is VP Product Management at Enea Embedded Technology. He has been a key designer and contributor to Enea's Element Middleware solution. Prior to Enea, Terry spent more than 15 years developing and leading software teams which were chartered to build distributed, high availability datacom and telecom platforms at Tier 1 TEMs and early stage startups.
|
|
