|
Archives
 August 1999 Issue
Columns
Cable Telephony's Oxymoron
By Justin J. Junkus
Cable telephony is moving too fast to just call it technology evolution. Because of some factors I will discuss in this column, I still cant call it a technology revolution. So, I am going to use an oxymoroncontradictory termsto describe what is happening in summer 1999 as cable telephonys "evolutionary revolution."
Revolution
First, lets look at the revolution. The marketing side of our businessboth vendors and operatorsseems to support a major commitment to telephony as a cable service. We definitely want the public and our technical staffs to perceive our industry as a full-service communications provider, right now. In particular, we want the public to know we are the alternative to the phone company, as well as their video and data services provider. The mergers, the product announcements and CableLabs PacketCable standards all add a very pointed focus to the general direction we have been taking for almost four years. The pace of the activity, as well as its volume, certainly makes it look like a technology revolution is occurring.
Evolutionor is it?
On the other hand, the evolution part of the description becomes appropriate when examining the status of the technology. Unlike cables apparent strategic marketing direction, its technical tactics are still somewhat blurred.
Take a look at Internet protocol (IP) telephony as an example. Probably because the term IP conjures up visions of data, packets, broadband and multimedia communications, anyone selling telephony products to our industry wants to demonstrate that they can deliver packet-based telephony over cable as soon as the industry wants to install and sell it. All the telephony vendors at Expo, for example, had a way to show how they can provide IP telephony now, in conformance with the Data Over Cable Service Interface Specification (DOCSIS).
If you consider that the first published PacketCable spec (NCS 1.0, short for network-based call signaling protocol) was released a mere two months earlier, on the surface it looked like the revolution has happened. You could actually make real IP telephony calls at all the telephony vendor booths.
But when you compared the NCS 1.0 document against what was being shown at Expo, you could see that this is the beginning of a path, not the destination.
The NCS 1.0 spec is based upon a standard called media gateway control protocol (MGCP). It is a different way to deliver IP telephony than the International Telecommunications Unions H.323 standard used by most existing vendors of IP telephony equipment.
Competing protocols
Without getting into all the details, the main components of MGCP as documented in NCS 1.0 are endpoints, gateways, embedded clients and call agents. Call agents within the network, rather than endpoints or terminals, control most of the call activity by monitoring call events or requesting signals to be applied. This tends to make it easier to initially implement a solution that looks like regular telephony to the subscriber and to make many changes at centrally located call agents with minimal need to dispatch to the subscriber location.
H.323, on the other hand, assumes the terminal device (call it a phone) looks a lot like a computer and places much more responsibility on that terminal to manage the call and its signals. The reason is that H.323 originally was developed as a general purpose multimedia data standard for local area networks (LANs), and the terminals on LANs usually are computers.
Neither standard is inherently better or worse than the other; however, H.323 is a data LAN solution, and NCS 1.0 was built specifically for a cable telecommunications distribution environment. Both will probably be around for a long time, and the choice of one over the other will be based on what makes technical sense for the particular application of IP telephony, or voice over IP (VoIP). The good news is that H.323 systems will be able to communicate with systems based upon NCS 1.0 and vice versa.
Even though H.323 probably will not be part of the PacketCable specifications, you can implement an H.323 solution on a DOCSIS 1.1-compliant network. After all, DOCSIS provides a way to implement a high-speed data LAN with cable modems, and H.323 is a specification for LANs.
State of the market
This type of implementation of "cable IP telephony" is what several vendors were showing at Expo. Essentially, it is data transport for the particular case of an IP telephony call, rather than an end-to-end IP telephony system.
ADC and Motorola, for example, used boxes for the IP telephony home interface that were physically separate from their network interfaces for circuit-switched telephony over hybrid fiber/coax (HFC) implementations.
The Tellabs demo looked more like an integrated solution because both circuit-switched and IP telephony calls were connected to the same remote service unit (RSU). However, even the Tellabs
EXPRESS/Path circuitry is still basically providing high bandwidth transport, rather than IP telephony functionality. (In fairness to ADC, its circuit-switched cable telephony product provides a similar way to handle IP telephony calls over reserved data bandwidth.)
The negative aspect of all these configurations is that H.323 implementations over DOCSIS 1.1 networks are neither the most efficient, nor the most cost-effective, way to do IP telephony over a cable network. The new PacketCable standards, including NCS 1.0, attempt to overcome the shortcomings. However, vendors must first manufacture the systems that conform to NCS 1.0 and other PacketCable specs before they can offer those systems to cable operators. As of Expo 99, no one had reached that point in the evolution yet.
Trends and directions
Getting there may be a long road. Several alternative vendor implementations will appear. Each will need to be evaluated by the operators and their customers, and each evaluation will take time. Some will win in the market, and some will disappear, but if history is any guideline, it will take three to five years before a stable solution for IP telephony over cable becomes a commercial offering.
In the meantime, cable must offer telephony now because the major established communications companies that have paid for the privilege of using its broadband distribution network are anxious to compete with telephone company access. The only proven commercial solution available now is circuit-switched technology, and the telephony equipment vendors realize that. Thats why, despite the marketing emphasis on IP telephony, each telephony vendor is continually improving its circuit-switched offering to make it more attractive than the competitions.
For example, when you look at Arris Interactives Cornerstone product, you could see they have introduced a larger capacity host digital terminal (HDT) and neatly packaged combiners and splitters into the same frame as the HDT. Tellabs has a new four-line version of its RSU for multiple dwelling units (MDUs) and hinted at Expo about how its RSU could be enhanced at a later date with an integral IP telephony module (as did ADC, for its interface unit). Even Motorola, which recently appeared to be downplaying circuit-switched technology for the U.S. market, has completely redesigned its Cable Access Unit (CAU) interface unit.
Before we close out this months subject, I suggest watching Lucent Technologies PathStar Access Server as an example of the type of equipment service providers will need in their IP telephony architectures. Jim Blake, the PathStar Access Server product manager, showed me a range of features offered and planned for this product that could make it possible to emulate a Class 5 central office switch. The PathStar Access Server architecture comes close to a real-world delivery of the "feature-server" concept I discussed in the April column. It will be interesting to see when individual features will be available for commercial deployment and how the traffic-handling capability of the server will hold up.
Justin J. Junkus is president of KnowledgeLink, a consulting and training firm specializing in the cable telecommunications industry. To discuss this topic further, or to find out more about KnowledgeLink, you may e-mail him at .
 Back to August Issue
Access Intelligence's CABLE GROUP
Communications Technology | CableFAX Daily | CableFAX's CableWORLD | CT's Pipeline
CableFAX Magazine | CableFAX databriefs | Broadband Leaders Retreat | CableFAX Leaders Retreat
|
