Now that the cable industry has united behind a uniform approach to delivering IP voice services over its networks, a growing number of MSOs are pushing ahead with plans to deploy the new platform on a wide scale as quickly as possible.

Time Warner Cable, Comcast Corp. and Le Groupe Videotron have made it known they're testing the technology in preparation for commercial launches, and vendors report that many other MSOs are beginning to conduct technical tests as they sort through their business options. This marks a significant gain for the commercial prospects of IP telephony from where things stood a few months ago, but it remains to be seen how quickly MSOs who have already launched voice services on proprietary packet systems will make the switch to IP.

In early December, Cable Television Laboratories' PacketCable group met its deadline for delivering specifications for version 1.0 of its protocols. As vendors scramble to bring their gear into final conformity with the specs, which in many cases can be done fairly simply through software upgrades, CableLabs' next big tasks in moving IP voice ahead involve certification of modems mapped to version 1.1 of DOCSIS (Data-Over-Cable Service Interface Specification) and completion of version 1.1 of PacketCable, which, among other things, will establish the parameters for interoperability between different MSOs' PacketCable systems.

"For commercial deployments we have to have DOCSIS 1.1 equipment, including the low-power versions of DOCSIS 1.1 modems," says Mark Coblitz, vice president of strategic planning at Comcast and chairman of the PacketCable group. "But I don't see anything standing in the way of moving through the test and market trial phases and on to commercial deployments when we're ready."

Coblitz won't say when that date will arrive for Comcast, which has begun a technical test of IP telephony over its facilities in Union, N.J. In fact, he's not ready to talk about details of Comcast's most immediate next step, which will be a market trial that is likely to involve offering packet voice service at a fee to several hundred subscribers.

"There's a lot to do to make sure we have the robust performance we're looking for before we set up a market trial," Coblitz says. "But we're very confident in the approach we're taking to delivering voice services."

While CableLabs officials anticipate the DOCSIS 1.1 certification process could be tough on vendors, much as 1.0 certification has been, Coblitz and other MSO executives say they're not concerned that this process could delay the timing of their service rollouts. Asked whether Comcast would proceed with offering service even if certification takes longer than anticipated, Coblitz says, "I believe so, but I expect we'll have certified equipment."

Hardware compatibility is the most crucial aspect, and most vendors appear in conformance there, says Mark Bakies, manager of voice solutions in Cisco Systems Inc.'s cable business unit. "If you fail because the software failed, that's fairly easy to fix," he says. "That's why any delays in certification aren't likely to slow people down who want to move ahead with commercial IP voice deployments."

In what promises to be a less daunting approach to rolling out IP telephony, Time Warner plans to begin a trial of second-line service over its Portland, Maine system during the second quarter.

The Time Warner service will be marketed at a monthly cost of $4.95, according to Time Warner Executive Vice President Ann Burr. "We'll keep it priced lower than the local exchange carrier in order to keep it attractive," she told a Western Show panel audience.

Time Warner spokesman Michael Luftman says the second-line approach represents a way to take advantage of the new PacketCable platform without incurring the costs of a lifeline toll service. "The jury's still out on where we're going with first-line," he says, noting that the question of AT&T's role as a provider of voice services over what is slated to be AOL Time Warner infrastructure remains unsettled.

But Time Warner isn't holding back on expanding the Portland model service elsewhere if the market trial is successful, Luftman notes. "Our usual strategy is to conduct a full market trial on a new service, and, if it performs up to our expectations, to go on and introduce it elsewhere," he says. "I don't see any reason that wouldn't hold in this case."

In contrast to Time Warner's approach, Comcast's trial is taking advantage of the PacketCable specs to deliver multiple lines of toll-quality service, complete with all the features customers get from the telephone companies. "Most of the discussion around cable telephony over IP has focused on the belief that this technology could not deliver the reliability, voice quality and number of services to satisfy customers' demands right now," Coblitz says. "Our experience shows otherwise."

But the trial is only in a first stage involving 25 users, which means the integrated access equipment supplied by Lucent Technologies will have to scale to thousands of users and deliver the same level of quality before Comcast can move to commercial deployments. In addition, the customer premise MTAs (multimedia terminal adapters) and headend CMTSs (cable modem termination systems) which Motorola Inc. is supplying as part of Lucent's CableConnect Solutions system must be shown to meet the specs set for DOCSIS 1.1.

Lucent is confident all the pieces will fall together to support commercial rollout of PacketCable-compliant IP telephony services on a wide scale by the second half of the year, says Dee Dee Nye, vice president of the vendor's cable communications group. "You can be sure IP telephony will be ready for deployment in that timeframe," she says.

Comcast isn't the only MSO testing Lucent's system, Nye adds. "We've been pretty quiet about what we're doing, but we think we have an integrated solution that is resonating with our target market,"she says.

That solution begins with the PathStar Access Server, which combines the functionalities of several products into one module, including the routing/switching process, IP voice gateway interface with the public switched telephone network (PSTN), call control and intelligent network feature provisioning and cable network access interfaces. These access servers can be positioned at the headend and at the distribution hubs in arrays supporting up to 100,000 customers, notes Harrison Miles, director of technical marketing and solutions management within Lucent's cable group.

"The system is designed so that you can start out at the headend with a single data shelf supporting up to 40,000 customers and then add units at the distribution hubs as your penetration expands," Miles says. The system is designed specifically for the cable environment, where MSOs will begin offering IP telephony at the local distribution level while interfacing with circuit-switched or ATM (asynchronous transfer mode) backbones to connect with networks outside the local cable "cloud," he adds.

Figure 1: PacketCable reference architecture. Source: CableLabs.

But MSOs will move quickly to an all-IP end-to-end paradigm, interconnecting their own systems as well as those of other PacketCable-compliant local IP telephony networks once terabit routers such as those Lucent is developing through its newly-acquired Nexabit subsidiary are deployed by suppliers of backbone networks, Miles says. Once that happens, operators will be looking for equipment at the local distribution level that is interoperable with all PacketCable-compliant gear, which will require conformity with version 1.1 of PacketCable, now slated for release sometime in April.

"Version 1.0 doesn't solve the zone-to-zone interoperability requirement," says David Bukovinsky, vice president for broadband services and technology at CableLabs. "We'll be addressing that along with some other things like IP address privacy in 1.1."

If MSO trials of PacketCable-based service pan out, the cable industry will find it can have its cake and eat it too, insofar as the cable companies who have chosen to forge ahead with voice services on proprietary, non-IP platforms are finding this option to be more cost-effective than originally anticipated. For example, AT&T Broad-band and Internet Services is gaining ever more confidence in the non-IP "constant-bit-rate" approach to delivering voice over cable networks, allowing it the luxury to wait on further maturation of IP voice technology, says BIS CTO Tony Werner. "We're getting really good results in the marketplace, and the cost model is improving significantly," Werner says.

Where the total per-customer cost of provisioning voice was about $890 at the outset of the company's first deployment in Fremont, Calif., Werner says the price now is about $590. "We're seeing more vendors, including Lucent and Motorola, coming into this space, which will have an impact on the costs," he says.

By the second half of this year, the anticipated cost drops will put the four-line constant bit rate cable option at close to cost parity with the IP option where voice services are concerned, Werner notes. Even so, however, IP voice represents "one more bite out of the apple" cost-wise, he acknowledges, because the network interface units supporting IP voice also support high-speed data, which eliminates the cost of the separate modem that's required for current voice customers who want high-speed data as well.

This is one reason why ever more MSOs who haven't put voice services into play on proprietary platforms want to skip that step and go right to IP. There is more to their confidence in this approach, of course, than just the successful completion of PacketCable specs. In the past six months, the IP voice world in general has come together on many basic architectural components that are common to the cable and non-cable networking environments, allowing some non-cable players to move ahead with planned service launches.

For example, taking the Internet Protocol model for voice services to an unprecedented scale, British Telecom has contracted with Nortel Networks Inc. for supply of a national IP telephony and data communications system in Spain, starting with service launches over 12 metro regional nodes in the first quarter of next year. And not far behind in terms of anticipated scale of operations is Canada's Le Groupe Videotron, which is deploying a router-based system supplied by Cisco Systems Inc. to support IP voice service rollout across its 2.1-million household base in Quebec following completion of a 2,000-home trial that just got underway.

While the two network operators are pursuing very different network architecture strategies with attendant variations in the way their voice provisioning and call control systems work, a key point of commonality between them and among a handful of other carriers planning IP telephony service implementations in 2000 is their reliance on a new generation of routers that use the same protocol base to deliver quality of service on par with switched voice circuits. The new router design strategy taps the benefits of two protocols, Differentiated Services (Diff-Serve) and Multi-Protocol Label Switching (MPLS), providing carriers assurance that different vendor systems will eventually interoperate with each other, once suppliers implement software upgrades to final standard specifications.

Figure 2: Call signaling interfaces. Source: CableLabs.

These emerging standards are now sufficiently stable to allow Nortel to implement a large share of Diff-Serve and MPLS processing functions in microprogrammable ASICs (application-specific integrated circuits), thereby eliminating the delays and jitter caused by an extensive amount of processing in software, says Ed Jasho, group manager for IP infrastructure at Nortel. "Our Versalar edge and core routers have been developed specifically for the carrier networks to provide redundancy in hardware and the other requirements that are needed to deliver five 9s reliability in an IP-only environment," Jasho says. "By moving most of the IP forwarding capabilities into ASICs, we've reduced latency to 100 microseconds or less, compared to the few milliseconds that has been the industry norm."

Diff-Serve and MPLS work in tandem as the linchpins to QoS in IP routing, with Diff-Serve used to identify traffic flows within pre-set classes so that bit streams are aggregated and treated according to the class specs on a per-hop basis from router to router. MPLS is applied on a systems-wide basis using labels assigned at Layer 3 to create "label-switched paths," thereby affording carriers a means of maximizing traffic flow efficiency across the network in accordance with the assigned priorities.

BT has no doubt that it can take on established carriers using the all-IP approach, says Pat Gallagher, BT's European director. "The new network will enable BT to adapt rapidly to future developments, offer new services more quickly and economically than in-country competitors, and will ensure our Spanish customers receive the most advanced communications in the world," Gallagher says.

Initially, BT will offer residential and business customers a range of advanced IP telephony services including direct and indirect dial facilities and virtual private network (VPN) applications and, from there, will extend its service range into value-added and other new multimedia services as the business develops, Gallagher says. The 12 nodes to be activated in the startup phase will extend network reach to several million potential customers, he adds.

It remains to be seen whether such confidence in the trafficking power of routers versus other modes, especially ATM, will be born out, but engineers disagree strongly on the state-of-the art at this point. For example, as previously reported (CED 10/99, p. 46), Sprint is moving to a voice-over-ATM DSL model for its ION (Integrated On Demand) service rollouts next year after an initial foray into voice-over-IP on the belief that IP QoS won't match ATM for another year or two.

Call signaling interfaces
Source: CableLabs

"MPLS begins to emulate the connection-oriented world, but IP isn't there yet," says Ed Thurman, director of advanced technology development of Sprint. "As IP takes on the functionalities of ATM we'll be in a position to exploit that." Cisco, as the lead vendor for ION, sees the question of whether or not IP routing is ready to support voice as more a matter of who's asking the question, says David Lively, product manager in xDSL marketing for Cisco. "IP also has the QoS mechanisms to support voice," Lively says. "It's just a different way of thinking than ATM, and not everyone is ready to take that step."

Lively adds: "The demand for voice transport directly over ATM is driven mostly by efficiency and carrier comfort level. For many of the new CLECs that want to offer local voice services over DSL, they see ATM as the easy route."

But, he warns, "The efficiency of ATM today comes at a price. Voice transport over ATM is limited to the WAN (wide area network) and does not integrate as well as VoIP with IP phones, network-based PBXs, unified messaging and many other IP-based voice services that we haven't even thought of."

Where cable is concerned, notes Cisco's Mark Bakies, there is even less need for concern about router support for QoS, insofar as the capabilities provided by Diff-Serve and MPLS outside the cable "cloud" are handled very effectively by the specifications established for PacketCable, which include features of version 1.1 of the DOCSIS (Data-Over-Cable Service Interface Specification).

"The way we're doing QoS in the Videotron network is an enhancement to DOCSIS 1.0," he says, noting that Cisco was a primary contributor to the means by which constant-bit-rate quality bandwidth in the upstream is allocated to modems on an as-needed basis.

But Bakies, who is manager of voice solutions for Cisco's cable business unit, makes clear there's an important role for MPLS and Diff-Serve in the cable model. "DOCSIS only takes care of that part of the IP network that operates across the HFC (hybrid fiber/coax) plant, which means you have to have a means of setting precedence for bits and controlling traffic flows at the metropolitan level and in the interface with backbone networks," he says.


PacketCable primer

Editor's note: The following descriptions are adapted from CableLabs documents. To view a table of PacketCable's call signaling interfaces, click here.PacketCable 1.0 consists of 11 specifications and three technical reports, which are designed to enable real-time multimedia communications across the cable network infrastructure. The general architectural goals of PacketCable 1.0 are to:

Enable voice quality capabilities comparable to or better than the PSTN (public switched telephone network) as perceived by the end user; Provide a network architecture that is scalable and capable of supporting millions of subscribers; Ensure the one-way delay for local IP access and IP egress (excluding the IP backbone network) is less than 45 milliseconds; Support primary and secondary line residential voice capabilities; Leverage existing protocol standards; Leverage and build upon the data transport and Quality of Service capabilities provided by DOCSIS; Define an architecture that allows multiple vendors to rapidly develop low-cost interoperable solutions to meet member time-to-market requirements; Ensure that the probability of blocking a call can be engineered to be less than one percent during the High Day Busy Hour (HDBS); Ensure that call cutoffs and call defects can be engineered to be less than one per 10,000 completed calls; Support non-cable modems (up to V.90 56 kbps) and fax (up to 14.4 kbps); Ensure that frame slips as a result of unsynchronized sampling clocks or resulting from lost packets occur less than 0.25 per minute.

At the highest level, the PacketCable 1.0 architecture contains three networks: the DOCSIS HFC Access Network, the Managed IP Network and the PSTN. The Cable Modem Termination System (CMTS) provides connectivity between the DOCSIS HFC access network and the Managed IP Network. Both the Signaling Gateway (SG) and the Media Gateway (MG) provide connectivity between the Managed IP Network and the PSTN.

The DOCSIS HFC access network provides high-speed, reliable and secure transport between the customer premise and the cable headend. This access network may provide all DOCSIS 1.1 capabilities including Quality of Service (QoS). The DOCSIS HFC access network includes the following functional components: The Cable Modem (CM), Multiple Terminal Adapter (MTA) and the CMTS.

The Managed IP network serves several functions. First, it provides interconnection between the basic PacketCable functional components responsible for signaling, media, provisioning and establishing QoS. In addition, the managed IP network provides long-haul IP connectivity between other Managed IP and DOCSIS HFC networks. The Managed IP network includes the following functional components: Call Management Server (CMS), Announcement Server (ANS), several Operational Support System (OSS) back-office servers, Signaling Gateway (SG) and the Media Gateway Controller (MGC).

A PacketCable zone consists of the set of MTAs in one or more DOCSIS HFC access networks that are managed by a single functional CMS. Interfaces between functional components within a single zone are defined in the PacketCable 1.0 specifications. Interfaces between zones have not been defined and will be addressed in future phases of the process. The zone or zones operated and managed by a single administrative entity are referred to as a PacketCable or administrative domain. Interfaces between domains will also be defined later.

PacketCable specifications define protocols in the following areas: Call Signaling Quality of Service Media Stream Transport and Encoding Device Provisioning Event Messaging Security and Privacy Operational Support Systems The following is a review of the way the call signaling components of this architecture operate.

PacketCable 1.0 call signaling protocols provide end-to-end basic call signaling for a variety of functions for calls that originate on the PSTN and terminate on the cable network, for calls that originate and terminate on the cable network within a single PacketCable zone and for calls that originate from the cable network and terminate on the PSTN.

The signaling protocols also support custom calling features such as call waiting, cancel call waiting, call forwarding, three-way calling and voice mail message waiting indicator. And they provide signaling to support CLASS (Custom Local Area Signaling Services) features such as calling number delivery, calling name delivery, calling identity delivery on call waiting, calling identity delivery blocking, anonymous call rejection, automatic callback and customer originated trace.

The call signaling functions also provide the means by which the cable company ensures that a new subscriber retains his current phone number via Local Number Portability, ensures subscriber choice of interexchange carriers for both inter- and intra-LATA calls, including pre-subscription and "dial-around" agreements, and allows the customer to set call blocking restrictions to 976 and similar toll numbers.

Call signaling requires multiple interfaces within the PacketCable architecture, interconnecting MTAs with CMSs; CMSs with Signaling Gateways and Media Gateway Controllers; Signaling Gateways and Media Gateway Controllers with each other; Media Gateway Controllers with Media Gateways, and Signaling Gateways and Media Gateways with the PSTN.

One of the key call signaling protocols is the Network-based Call Signaling (NCS) Framework, which is an extended variant of the Internet Engineering Task Force's Multimedia Gateway Control Protocol. The NCS architecture places call state and feature implementations in a centralized component-the CMS-and places device control intelligence in the MTA. The MTA passes device events to the CMS and responds to commands issued from the CMS. The CMS, which may consist of multiple geographically or administratively distributed systems, is responsible for setting up and tearing down calls, providing advanced services, performing call authorization and generating billing event records,