April 17, 2001
In 1948 AT&T needed a transistor, so Bell Labs invented it.
In the ‘60s the monopoly needed a very special relay, the
"Ferreed Switch", for the only non-solid state component in
the talk path of a new generation of central office switch, so
the Labs spent millions developing it. In the early ‘80s VMX,
Octel, and other early developers of voice-messaging
systems did not have to develop their own integrated circuits,
but they did have to develop their systems all the way up from
the component level, including the operating systems. But in
1984 several things happened that ushered in the beginnings
of a new era in how telecommunications systems are
developed.
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.
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.
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.
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) (www.picmg.org) 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
(www.ectf.org) 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.
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.
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.
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
(www.msp.org).
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.
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.
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.
Mike Coffee is the president of Commetrex Corp. Commetrex
develops, enabling-technology produces, and markets
products for telephony original equipment manufacturers
(OEMs), system developers, and integrators. For more
information, visit their Web site at www.commetrex.com.
Alternate Phase II Diagram is given above.
Alternate Phase III diagram is given below.
| 
