A New Industry Value-Adding Architecture

Phase I

In a consent decree AT&T divested itself of its regional operating companies, the IBM PC-AT, with its hard drive, was introduced, and DOS, with its openness and the imprimatur of IBM, gained traction through the support of thousands of independent developers. This was all that was needed for a Parsippany (NJ) start-up called Dialogic to develop and market a PC add-in board that interfaced four loop-start trunks to a PC. It was marketed as a value-adding component for the system developer. Suddenly, millions and years were no longer required to enter the voice-processing market?$3,000 and a decent-sized garage were all that was needed. The computer-telephony industry was born.

Clayton Christensen, a renowned scholar at the Harvard Business School who specializes in “the management of technological innovation” explained this frequent occurrence in technology markets well in his article, Impact of Disruptive Technologies on Telecommunications:

When the performance of available products or services overshoots what customers in a given tier of the market can absorb, the nature of competition begins to shift. Customers no longer reward further improvements in functionality with premium prices. Instead, innovators are forced to strive for advantage by getting to market faster, and by customizing the features and functions of products to the needs of customers in ever-smaller niches of the market. In order to compete successfully in this disruptive environment, companies must adopt modular, rather than integral, product architectures. This enables them to mix and match components, tailoring the character and cost of their offerings to the needs of specific customers. When modular interfaces are defined between each of the pieces in the value-added chain, it enables independent organizations to supply those pieces.

The market Dialogic created is also called open communications, digital media, CT, and CTI, but the essential common factor is the industry’s value-adding structure. Industry participants were able to focus their resources on a particular value-adding segment: The Dialogics and Natural MicroSystems of the market concentrated on the core enabling technologies of the new market?their customers on the application-specific software. And hundreds of companies were founded to take advantage of the opportunity to develop voice mail, automated attendants, and interactive voice response systems by adding application-level value, leaving the task of developing the system platform to others. This innovation defined the industry’s Phase I architecture.

Nearly all of these applications were for enterprise-premises equipment, with the most prevalent being voice-mail systems. Suddenly early stage companies were offering voice mail systems for $20,000 that were being sold by the voice- messaging industry incumbents for $100,000.

“Our customers won’t be satisfied with PC-based systems.”, said the market-share leaders. “That’s not our business.”, was the refrain. They were correct. It was the companies that weren’t their customers that wanted these new affordable systems. It was the perfect example of Christensen’s “disruptive technology”.

The new business ecosystem worked well because the “board vendor’s” very large investment in product development could be spread over the entire market since it had little or no application-specific features. That was and is the job of the end-equipment or application-level developer: know the vertical market segment and satisfy its needs by adding market-specific and even customer-specific value. The host-level computing engine and its operating systems were supplied by the incredibly productive PC industry, itself a disruptive technology.

But these late-‘80s systems-call them Phase I-were based on an architecture constrained by the functions offered by the platform vendor. And since those platforms employed a closed architecture below the API level, there was no viable opportunity for the OEM to extend a system’s resource-level function. He was confined to the functional scope offered by his platform vendor.

Phase II

So, until the late ‘80s, when vendors, such as Mitel, came out with T1 network interfaces and Gammalink and Brooktrout introduced the multi-line fax board, Phase I applications were limited to low-port-count voice-only systems. But with one company developing the network interface (Mitel), another the voice board (NMS), and yet another the fax board (Gammalink, since purchased by Dialogic), a way was needed to route PCM media streams between these multi- vendor boards. The idea of how to solve this problem was advanced internally at NMS as early as late 1988, and in 1990 the Multi-Vendor Interface Protocol (MVIP) was brought to the industry by NMS and 6 like-minded companies. This event defined the industry’s Phase II architecture.

Phase II caused yet another burst of innovation and commercial activity (more disruptive technology) as the functional scope of the industry rapidly expanded to include not just voice and fax, but nearly every conceivable media. Companies jumped into the market, which has grown at over 30% per year ever since, to leverage their various core competencies?DS-3, speech recognition, text-to-speech, video?by developing and marketing MVIP-compatible fixed- function boards. OEMs could now develop functionally complex systems supporting hundreds of ports. GO-MVIP, the industry group that governed MVIP, had over 100 members with over 70 marketing conforming products in the mid-‘90s.

But the industry’s value-adding architecture had inherent limitations:

• Resource boards were generally limited to one media- processing capability since media-specific competencies were confined to one per company, and there were no multi-vendor standards at that level.
• The cost of integrating multiple fixed-function resource boards, each with its own vendor-specific software environment, limited the economic feasibility of the systems that could be developed.
• Although much larger systems became practical, with no client-server telephony middleware products, it was extremely expensive to expand a system beyond the boundaries of one PC. Computer telephony systems earned a reputation for a lack of scalability.
• With systems based on the PC, carrier-class applications proved elusive.

But change, the only constant in technology markets, was taking place. Once again, it was time for disruptive technologies to come to the rescue.

Phase III

In the latter half of the decade, it became obvious to many that the staid hidebound carrier-equipment industry was in for some dramatic changes.

• The Telecom Act of 1996 made it much easier to become a local-exchange carrier; the CLEC was born.
• Voice-over-packet began to emerge from the hobbyist phase.
• Fax-over-packet became an ITU standard.
• Cable operators began to provision for convergence, and standards development began in earnest.
• DSL became available.
• DSPs became an order-of-magnitude more powerful.
• The “access network” emerged as the technology battleground for facilities-based competitive carriers.
• Technology churn and market growth made time-to- market the catch phrase of the access-network market.

This convergence of events created an opening into the carrier-equipment market?in particular the access network?for the enabling-technology vendor. There is now an opportunity to bring the value-adding efficiencies of the open-communications business ecosystem to the carrier- equipment market.

Why the opportunity? The access network — just a few years old — was birthed as a competitive animal. Venture funding quickly filled the vacuum and scores of companies were founded to develop and market the multi-service access, media-gateway, and service-platform systems the new CLEC industry needed to get to market quickly.

Why quickly? A new market that generated a land-grab mentality is one reason. Another is technology churn. Standards were new, conflicting, or non-existent. For the competitive carrier, standing by to wait and observe would not be rewarded. Only by jumping in and getting to market could a market entrant hope to be able to hold on after the incumbent carriers finally entered the fray. But how much can you compress the schedule of a project that must develop a proprietary chassis and backplane? What about ASIC-based media-processing chips, and media technologies from several licensors? Over 36 months is the norm.

But adopting a value-adding platform or intermediate technologies and products can enable an equipment vendor to get to market in 12 months. Equipment vendors must weigh the value of developing proprietary platforms and their attendant time-to-market and investment penalty against focusing development investment on application-level value. This can be done by leveraging the lowered development investment and time-to-market advantages of value-adding platforms.

But must it be an all-or-nothing proposition? Many of the available value-adding platforms are closed architectures between the application interface and the resource board’s backplane connector. If the OEM’s product strategy requires a media technology not offered by the platform vendor, does that mean the OEM must develop the entire platform? Suppose the OEM’s product strategy requires proprietary hardware, must the OEM also develop a host-level environment? What about third-party media technologies on the platform vendor’s DSP-resource board? Must the OEM add hardware to support third-party media technologies even when the primary platform vendor’s DSP boards have adequate MIPS headroom?

These questions, although raised in the early ‘90s were never as important as they are today. Why? Because the needs of the access-network equipment developer are more complex than the enterprise equipment developer that has been the mainstay of open-communications for its first 15 years. Not only does the access-network market vendor have more complex needs, but often the capital resources to meet them. So, for example, if CompactPCI does not support the OEM’s product strategy a new backplane and proprietary boards must be developed ($3-5M); third-party media technologies must be licensed ($2M); a media-processing software framework must be developed ($500K-1M); a client-server telephony environment must be developed ($3M); the platform can then be integrated and tested ($750K).

CompactPCI finally gives the carrier-equipment OEM the option of avoiding the very large development investment that is the consequence of choosing a proprietary backplane. CompactPCI gives the OEM the option of choosing one board from vendor A and another from vendor B to complement the functionality of the OEM’s proprietary board. But what about a hardware- and vendor-independent integrating software environment? Current industry practice is for each board to include a proprietary host-level software framework, with each duplicating common system-level functions such as media- specific file I/O, system configuration and management, resource and client authentication, and call routing. So in many ways it is impracticable for the OEM to select resource boards from multiple vendors, this restraint on vendor and, therefore, functional flexibility pushes many OEMs to the all- proprietary option.

So, what is the answer? A more decomposed industry. The industry must examine the need for a more finely partitioned modular industry structure to give the carrier-equipment OEM the necessary options. The all-or-nothing approach to open- communications must give way to an “a la carte” value-adding industry structure, as shown below.

This begins with an examination of the five major aspects of a digital-media telecommunications system platform: the system chassis, along with system-level processor boards and operating systems, the DSP-resource and network- access boards, the media technologies (DSP-based stream- processing software), the software environment to support integrated-media DSP software on shared DSP resources (media framework), and the application-software framework.

System Chassis, Processors, And Operating Systems

For years, the open-communications industry was based on the Wintel technology ecosystem, including DOS, OS/2, and NT. ISA then the PCI bus were the norm. But the industry- standard PC form factor was ill suited to the carrier-equipment industry’s needs. The VME standard, which offers higher system availability designs, has been used for years to lower the development costs of industrial-control and defense- related systems. But it did not reach out effectively to the open-communications industry, which began as a DOS- oriented community, and it never gained the critical mass that was required for success in the telecommunications industry.

CompactPCI (cPCI) changed all that when it borrowed the same general chassis and interconnection designs of VME and combined them with the popular PCI bus. The addition of H.110, the cPCI version of the ECTF’s (now CompTIA) H.100 PCM highway, which provided the inter- board transport of PCM stream data, and a specification that supported hot swap completed the prerequisites for broad adoption of the cPCI standard by carrier-equipment vendors. The rapid acceptance of cPCI has prompted the development of hundreds of system-level processor, storage, and other boards and the software necessary to build a full-function communications system.

CompactPCI, as it evolves, will likely be the predominant chassis and backplane open standard for carrier-equipment for the bulk of the decade.

System-Resource Boards

Digital media require media-processing resources and the boards to support them (unless host MIPS are used). This usually means DSPs (digital signal processors), the processing staple of the access network. Signal processing can also come in the form of fixed-function silicon or imbedded in proprietary ASICs. Either way, the need to terminate and transcode media streams must be met, and the most open and flexible approach is to use DSPs (digital signal processors).

In the access network, space and power are at a premium; minimum cost is always a major design criterion. Add to that five-nines availability plus on-board packet processing and you have the requirements of the next-generation network DSP-resource board.

Network access resources must also be available. Ethernet, T1, E1, DS-3, OC-3, are required. These interfaces can be provided on daughterboards or on separate cPCI add-in boards. Interconnection with stream-processing resources is either via PCM highways (H.110) or packets transported via the PCI or, perhaps, across the soon-to-be-standardized cPCI packet bus.

So the OEM with a product strategy that requires unfettered access to the media-processing resources should have the option of purchasing so-called “raw boards”, with the necessary board-level developer’s kit. This would allow the OEM to skip the time-to-market delay and the added development expense of developing hardware, yet create a fully proprietary system in all other respects.

Media Technologies

One of the defining characteristics of the access network is media integration. With packet-based transport becoming preferred, multi-service access equipment must handle any media stream that comes its way. But media-processing technologies, such as voice and fax over packet, take years to develop and are generally produced for licensing by organizations that specialize in the technology. The only viable option for the equipment OEM is to license or otherwise acquire the technology from a specialty vendor. Another approach would be to purchase fixed-function ICs which, by definition, have the technology embedded in a ROM.

Once the technologies are acquired, the OEM must integrate them into the processing environment. Since this step can itself consume significant development resources, Texas Instruments, one of the major suppliers of catalog DSPs with a 50% market share, has taken the initiative to do something about it. TI has promulgated a packaging specification or “algorithm wrapper”, the eXpress DSP Algorithm Interface Standard, that can reduce the expense of integrating third- party DSP software into an integrated-media software environment.

Media Framework

But a standardized algorithm wrapper does no good without a supporting media-processing software framework. This software must support the packaging standard and provide a productive environment for the creation of resource managers that expose the media-processing functionality to client applications. There is now one open vendor-independent environment, the M.100 specification of the MSP Consortium.

M.100 specifies a framework that allows board vendors and other imbedded-systems developers, and media-technology developers to work cooperatively yet anonymously to develop their respective products that the OEM can purchase separately and easily integrate in a “plug-and-play” fashion.

So an OEM can purchase a board that either offers an M.100- conforming software environment, develop his own implementation of M.100, or license an implementation of M.100 in order to enjoy the benefit of either “dropping in” M.100-conforming media resources or eXpress DSP- conforming algorithms.

Application Framework

Eventually, someone has to develop the application software that gives the OEM’s product its distinctive system-level functionality. The OEM should look for an API with the supporting framework that has the following characteristics:

• Client-server architecture for scalability
• Transparent client and server computer expansion
• Vendor independent
• Hardware independent
• Open, enabling resource and system-service additions by the OEM

Fortunately, the ECTF has specified an open API in its S.100 recommendation that can support the above requirements. All implementations of S.100 do not meet these requirements; fewer than half of them do. But those that do give the OEM the option of using resource boards from multiple vendors without exposing the application software to proprietary APIs.

Choices For The OEM

Historically, the OEM has had a choice between basing his product on a value-added platform that is open at the API level, but otherwise closed, or developing the entire system, possibly licensing certain technologies and possibly procuring DSP boards. But for the carrier-equipment OEM this is generally not acceptable.

A “decomposed” or modular, value-adding industry architecture is needed to bring unprecedented and required choice to the OEM. The recommendations of three industry consortia, PICMG, with its CompactPCI, the ECTF, with its S.100, and the MSP Consortium, with its M.100, mean the OEM can now purchase system elements from different vendors, add proprietary system elements as required, and easily piece them together to form an integrated system.

The OEM can mix and match by choosing to use standards- based system elements in any combination of five areas:

• System chassis, backplanes, boards, and operating systems
• DSP-resource boards
• Media technologies
• Media framework
• Application-software framework

This means the MSP Consortium’s M.100 can be used, but any DSP-resource board that has a supporting M.100- conforming environment can also be used. If an ECTF S.100 host-level environment meets the requirements, it is also available. If it doesn’t, a proprietary environment can be substituted. It the OEM wants to use S.100, but has his own media framework, that will work. If a fully proprietary platform is required the OEM can simply license the media technologies.

Alternate Phase II Diagram is given above.
Alternate Phase III diagram is given below.