Piecing together the VoIP puzzle
Like a nearly-complete jigsaw puzzle, the picture that will become PacketCable is finally starting to take shape.
Thanks to DOCSIS 1.1 certifications and qualifications recently handed out by CableLabs, the underpinning of the PacketCable infrastructure is more or less complete.
However, a difficult and complicated road still lies ahead before cable operators can begin rolling out fully-compliant PacketCable networks to foster IP-based services and applications, including telephony. In the meantime, PacketCable has outlined a protocol, dubbed Line Control Signaling, to help MSOs make a swift migration. But more on LCS later.
CableLabs has commenced testing cable modems, multimedia terminal adapters (MTAs) and cable modem termination systems (CMTSs) for PacketCable compliance. But making a move to a full PacketCable platform requires several more elements to populate the network, including PacketCable servers, gateways, softswitches and signaling gateways. On top of that, gear based on PacketCable must also comply with a stringent set of security and surveillance specifications.
CableLabs has slated four PacketCable certification waves in 2002, coupling them tightly with four planned DOCSIS testing waves. The second wave of the year kicked off April 15, and is slated to conclude June 14. The third wave is expected to launch on July 22.
For the moment, PacketCable certification tests are exclusively focused on multimedia terminal adapters and CMTSs for the 1.0 specification. Certification testing for other network elements such as the call management server and operational support systems could be added to the mix later this year, says PacketCable Director Glenn Russell. In the interim, CableLabs also plans to conduct interoperability testing on PacketCable 1.1 and 1.2.
PacketCable 1.0 "certification testing is a big objective for us this year," he says.
CableLabs is also testing provisioning systems designed to help operators turn on the service. Specifically, the equipment is leveraging Alopa Networks' Cable Telephony Provisioning Module, a technology baseline that mediates between the key distribution center, the call management server and the multimedia terminal adapter, notes company Vice President of Marketing and Sales Peter Szalay. He adds that the module is just one portion of Alopa's larger OSS platform.NCS vs. LCS
Although PacketCable originally set out to pour the foundation for a full-IP system, new developments within the specs also pave the way for VoIP architectures that leverage the Class 5 switches that CableLabs members have recently installed.
PacketCable 1.0, according to CableLabs documents, covers the full, pure-IP Network-based Call Signaling (NCS) protocol, assuming a call control architecture where the call control "intelligence" is located outside the gateways and is handled by external call control elements.
Meanwhile, PacketCable's Line Control Signaling (LCS) architecture is designed to enable a Class 5 switch to perform most of the call processing, but provides an IP-based transport in the local access cable network via GR-303 interfaces and Internet Protocol Digital Terminals (IPDTs), which convert IP voice packets into constant bit traffic that terminate at the Class 5 switch. Instead of employing NCS' record keeping servers, the LCS approach calls on the IPDT for access to the PSTN and a Class 5 switch for call control, announcements and billing.
LCS is considered an interim step toward the full PacketCable package.
Because some operators already offer or will offer telephony via traditional constant bit rate (CBR) technology, it's important for them to get a return on their multi-million dollar investments.
"In a move to VoIP, they don't want to junk those switches," notes Ed Miller, vice president of voice solutions at Terayon and the former head of the PacketCable project.
The advantage of the hybrid approach, notes Arris Broadband Director of Engineering Wade Carter, is that it can utilize Class 5 features, but also handle local number portability and surveillance requirements for the Communications Assistance for Law Enforcement Act (CALEA).
"In a pure softswitch world, all of these services have to be created," Carter says. "Over time, the softswitch will handle those things and, overall, provide a more cost-effective solution."
In addition to the pure IP architecture outlined in PacketCable 1.0 and NCS, a few MSOs see LCS as a potential migration path, Russell says. Easing the way was the fact that products for LCS already were under development.
Russell adds, however, that CableLabs won't conduct much testing for LCS equipment other than to ensure that the client devices are outfitted with the appropriate "hooks" for a migration to a pure PacketCable infrastructure.
LCS' drawback is that it's only intended to support IP telephony services, not the full PacketCable suite, which will handle myriad multimedia applications (see sidebar, p. 34). Still, LCS, by transforming the legacy IPDT into a media gateway, is designed to transition to a full PacketCable network.
For now, the LCS hybrid approach is the best approach if an operator wants to offer a full complement of IP-based primary line features right now. Some MSOs, including Time Warner Cable, have started out deploying second-line services with fewer features and no power back-up. Comcast Corp., meanwhile, is taking a carrier-class, LCS approach for a VoIP trial in the Detroit, Mich. area.
Terayon's Miller says the LCS method could play a big role in Europe, where more cable operators leverage Class 5 switches today.
Whichever way the momentum swings, most vendors are preparing themselves by supporting both options.
Motorola Broadband, for one, will support both, although most of the action today revolves around NCS, says Bruce Swail, vice president and general manager of Motorola Broadband's telephony systems group.
"LCS added very few changes or additions to the existing NCS specification," Terayon's Miller adds. "There are some little things they added for interoperability with the GR-303 gateway or access gateway."LOCKING DOWN SECURITY AND SURVEILLANCE
Looking beyond architectures, VoIP services are subject to a spate of potential security issues that PacketCable is attempting to address.
For one, it's conceivable that a hacker could write programs designed to disrupt the network because the PC shares the same packet network as the voice traffic, Arris' Carter notes.
CableLabs outlines a litany of potential threats in its PacketCable security specification, including theft-of-service, snooping and protocol manipulation. Among the theft-of-service threats, PacketCable lists subscription fraud, non-payment for services and a potential proliferation of MTA clones, which could register themselves under a fraudulent account. Another possible threat is denial of service, whereby someone tries to inject bogus packets into the system to bring the system down.
PacketCable also addresses "bearer channel information disclosure" attacks such as simple snooping, a privacy assault in which voice packets sent in the clear could be compromised. Protocol manipulation, yet another potential threat, could allow a hacker to discover bearer channel encryption keys.
PacketCable has adopted a conservative approach to these threats by layering on security specs designed to protect signaling and messaging channels and to essentially make VoIP as hackproof as possible. DOCSIS already provides encryption between the CMTS and the MTA, but on top of that, PacketCable mandates that the bearer channel is encrypted again and that the speech path is encrypted as well.
"The [security specifications] are there; now everyone is working toward implementing them," Carter says.
Another underlying issue for PacketCable is its unique handling of CALEA surveillance compliance. CALEA, enacted by Congress in October 1994, ensures that telecom carrier facilities are capable of providing legally authorized electronic surveillance and wiretapping. Further, mechanisms must be in place if a subject targeted under CALEA uses CLASS (custom local area signaling services) features such as three-way calling and call waiting.
If a cable operator becomes a carrier and uses PacketCable, then CALEA might apply to the MSO's network.
While CALEA requirements are spelled out in PacketCable's Electronic Surveillance Specification, how VoIP equipment providers handle or comprehend them can be a different story. "It's a rare vendor that understands CALEA," says Steve Craddock, senior vice president of new media development at Comcast. However, old telephony hands like Nortel Networks and even some newer vendors like CedarPoint Communications, whose engineering lineage tracks back to Excel Switching and other Class 5 switching developers, are extremely wise in the CALEA sphere, he says.PACKETCABLE GOES GLOBAL
PacketCable targets North American cable systems, but other initiatives already underway take a global approach to IP-based services.
For example, IPCablecom, a specification for Europe and other regions from around the world, defines a core "end-to-end" IP cable architecture for packetized applications and services. Formed last May, IPCablecom is backed by standards organizations such as the Society of Cable Telecommunications Engineers, the European Telecommunications Standards Institute and the International Telecommunication Union.
IPCablecom's roots are traced to North America's PacketCable specification, but are designed to fit the unique needs of international cable operators. Instead of using the GR-303 interface, for example, IPCablecom leverages Europe's v5.2 protocol.
In early April, the ITU set forth a broad set of recommendations for the IPCablecom initiative, an accomplishment that took just over a year. The 17rITU-T recommendations meet specifications defined by cable operators and vendors in North America, Europe and Asia.
In addition to IPCablecom, a separate organization, the EuroPacketCable Forum, emerged in October 2001. Though it doesn't have designs on re-inventing IPCablecom or PacketCable, the EPC Forum is modifying some documents, where it deems appropriate, to incorporate European market requirements.
Instead of developing specs, the EPC Forum is attempting to lower product costs and to simplify early deployments of packet-based services by organizing the work and sets plans on how to tackle it efficiently through product roadmaps. Every vendor contacted for this story says it recognizes both entities, and plans to support each one.