A move to COTS also requires a close examination of the software architecture.
Throughout the world, carriers are moving from PSTN to IP networks and rolling out a wide range of new packet-based triple play and other enhanced services, including IMS, 3G/4G, IPTV, and fixed mobile convergence. Network equipment providers (NEPs), meanwhile, are working overtime to deliver the improved infrastructure and flexible equipment needed to support these new services.
Traditionally, NEPs have developed their own infrastructure platforms in-house using proprietary hardware and software. A growing number, however, are beginning to adopt open architecture COTS platforms like AdvancedTCA (ATCA) and MicroTCA that enable them to get to market faster with more versatile equipment at a reduced cost.
As NEPs make the move to commercial off the shelf (COTS) architectures, many are also reevaluating their approach to platform software development. Here again, many NEPs are abandoning homegrown platform software in favor of COTS solutions that reduce cost and time to market. For established NEPs with legacy platforms, who have a large installed base of application software and customers to protect, the switch is more problematic. Even so, many of these NEPs are already faced with having to make significant software changes in order to take advantage of open architecture ATCA and MicroTCA hardware. For these NEPs, the time is ripe for a move to a new COTS software platform.
COTS Platforms Reduce CAPEX and OPEX
Most NEPs abandoned the practice of creating their own proprietary DSPs, network processors, operating systems, protocol stacks, and management tools long ago. However, they still create significant pieces of their application-specific hardware and software infrastructure from scratch. And they must still provide the overarching framework needed to integrate these discrete components into cohesive systems with unified management and control.
Unfortunately, it can take a team of engineers anywhere from 12 to 36 months to design, build, integrate, and debug this custom platform software, at a cost of a couple million dollars or more. Very large NEPs can sometimes justify this time and expense by amortizing it over a large number of platform projects. But for a growing number of NEPs, many of whom face mounting cost and time-to-market pressures with fewer engineering resources, this homegrown approach is becoming increasingly untenable.
Moore's Law meets distributed software
In 1965, Gordon Moore predicted that transistor density would double every two years for the foreseeable future. Since then, the semiconductor industry has consistently vindicated this prediction. In fact, the industry has done Mr. Moore one better, doubling hardware functionality every 18 months, all the while vaulting over one seemingly insurmountable obstacle after another.
Unfortunately, while hardware technology has steadily advanced, software productivity has lagged behind. As a general rule, every time chip performance doubles, the amount of software needed to tap into this increased performance must quadruple. So if, as Moore's Law predicts, chip performance doubles every two years, the amount of code must double almost annually.
Unfortunately, that's just not happening. One industry analyst estimates that the amount of telecom code being produced is growing at only half that rate. Given the relatively slow growth in the pool of available programmers (about 8% worldwide), this gap is likely to grow barring significant gains in programmer productivity.
Putting aside for a moment the sheer volume of code that will be needed for next-generation telecom systems, developing embedded software for networking gear presents unique challenges that further hamstring the development process. By its very nature, telecom software is difficult to develop, debug, and maintain. In particular, close proximity to and dependence on the underlying hardware, coupled with the desire to squeeze every ounce of performance and scalability out of devices, makes it difficult to build a layered architecture with a high level of abstraction.
This hardware dependency has made it difficult for telecom developers to take advantage of the advanced tools, APIs, middleware, libraries, and other components that have elevated programmer productivity in the PC/IT world. It also makes the resulting applications harder to scale and port. The net result is that NEPs today are still building embedded software roughly the same way they did 10 years ago, continuing to lock themselves into proprietary platforms and re-invent the wheel each time they develop a new product.
Further complicating matters for telecom developers is the highly distributed nature of telecom systems. Developing large real-time, high-availability multitasking applications for a single operating system running on a single processor is challenging enough. Distributing those applications across multiple operating systems running on multiple processors, nodes, blades and shelves is another matter altogether, requiring systemwide communications, supervision, and management infrastructure that dramatically increases development complexity.
Pre-integrated platforms boost software productivity
Runaway software complexity is taking its toll on NEPs. Already, some estimate that software accounts for more than 50% of total project costs, and that 50% of device projects are falling behind schedule by an average of four months. This shortfall will only increase as carriers and their customers demand more advanced services with shrinking time-to-market windows.
To remain competitive, NEPs are beginning to adopt new platform strategies that substantially boost programmer productivity. In particular, NEPs are emphasizing flexible, scalable, portable solutions that promote code reuse and enable them to serve a broader range of applications with fewer platforms. They're also adopting portable, layered architectures with standard, open interfaces that make it easier for them to access best-of-breed third-party technology and outsource a greater portion of their platform design.
NEPs have been utilizing COTS components such as development tools, operating systems, and protocol stacks for some time. But NEPs have had to assume responsibility for integrating these piecemeal components. Moreover, most of these components haven't traditionally been optimized to address distributed design at the system level. As a result, NEPs have been left with the complex task of creating the communications infrastructure needed to facilitate the development, management, and maintenance of applications distributed across multiple processors and operating systems.
NEPs need a complete, preintegrated telecom services platform that makes it easy to outsource their platform design. They need a platform that provides all of the RTOS, protocol, middleware, database, IPC, and tools components needed to develop, host and manage telecom infrastructure applications (see Figure 1). Equally important, the platform must provide the communications infrastructure needed to partition, control, supervise, and service applications distributed across multiple nodes in a reliable, secure fashion.
NEPs need a platform that can also provide an abstraction layer to separate telecom applications from the complexities of the underlying hardware and system software. This layered architecture, coupled with standard interfaces and intuitive, well-documented APIs, would make the platform easy to integrate with other infrastructure and enhances portability, enabling NEPs to upgrade their hardware and software with minimal disruption to applications. Using a layered architecture also makes it easier for NEPs to utilize best of breed, COTS hardware and software from multiple vendors.
LINUX/RTOS tandem provides a foundation
The first order of business for most NEPs who are evaluating COTS platforms solutions is selecting the target operating system. Not surprisingly, given its broad third party-support, familiar programming model, standard interfaces, built-in high-availability features, and open-source licensing model, Linux is a favorite among many NEPs. The problem is that many COTS suppliers have focused exclusively on Linux, ignoring the broader OS requirements of many distributed telecom infrastructure systems.
Homogeneous Linux configurations (Linux on every node) can provide an optimal solution for many distributed systems. Many distributed applications, however, have performance and throughput requirements, hard real-time constraints, and/or space limitations that require the services of a real-time operating system on some subset of the nodes. Some NEPs, for example, may prefer to use Linux on one set of blades to host IT-oriented supervisory and enterprise management functions, while employing real-time operating systems on another set of blades to host DSP-based media processing applications with tight size and performance constraints.
In-house is out
In the past, NEPs have been content to roll their own operating system, 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.
Terry Pearson is the vice president of product management for application development frameworks at Enea Embedded Technology. He can be reached at .