PacketCable 1.x architecture enters the zone

Sat, 03/31/2001 - 7:00pm
David Iler, Contributing Editor

The promise of pure Internet Protocol (IP)-based cable telephony, long on the advanced services wish list of cable operators seeking to maximize the revenue potential of their upgraded networks, is moving closer to reality as the crucial PacketCable specification reached a major milestone late last year.

When Cable Television Laboratories Inc. (CableLabs) released version 1.2 of PacketCable, it marked the end of 1.x versions of the spec which focused on delivering voice applications over cable networks.

Since then, operators wasted no time testing the IP voice waters as Comcast Cable Communications, AT&T Broadband, Time Warner Cable, Charter Communications and Cablevision Systems either have commenced IP voice trials, or have announced plans to do so.

With Data-Over-Cable Service Interface Specification (DOCSIS) 1.1 certification waves underway and six PacketCable 1.0 compliance waves scheduled for this year—the first has begun—most expect interoperable, standards-based telephony gear to become available later this year or early next.

DOCSIS 1.1 is a crucial aspect of PacketCable, as it provides for dynamic Quality of Service (QoS) to allow an operator to identify different streams—such as a voice stream—with service identifiers or SIDs. In this way, a voice call, which needs to reach its destination as fast as possible, can be identified with a higher priority than an e-mail message, for example, which is not as dependent on reaching its destination in real-time.

By "painting packets different colors" with service identifiers, cable operators, using the DOCSIS 1.1 protocol, can guarantee crucial QoS needed for latency-dependent voice service.

Building upon these Quality of Service provisions of DOCSIS 1.1, PacketCable, according to Glenn Russell, director of the PacketCable project for CableLabs, uses DOCSIS channels on a cable network to establish service flows for voice and other IP-based traffic. PacketCable provides the session management to referee the bandwidth and establish QoS that DOCSIS channels provide on a cable network.

With the release of PacketCable version 1.2, the industry now has a set of standards in place to exchange real-time, IP-based multimedia session traffic, including IP voice traffic, between different cable systems or "zones." Zones, according to Ed Miller, Russell's predecessor at CableLabs and now vice president of voice solutions for Terayon Communications Systems, can be defined as comprising all the subscribers, and the Multimedia Terminal Adapters (MTAs), that can be served by one call management server or CMS. (MTAs can be an IP phone integrated with a DOCSIS cable modem or a terminating unit that is mounted in a basement or mounted outside the home. The form factor will depend on each operator's IP voice business model.)

A zone, which could be served by a regional data center that consolidates several headends, can serve from 10,000 to more than 100,000 subscribers, says Miller.

"A zone is really all of the end points controlled by the call management server," says Russell. (The CMS is often referred to as the Call Agent, particularly with respect to Media Gateway Control Protocol or MGCP, the network signaling protocol selected for PacketCable.)

Thus PacketCable 1.2 describes how two operators, for example, AT&T and Rogers, can exchange IP traffic, building upon PacketCable 1.0 definitions for signaling, QoS, audio and video codecs, client provisioning, billing event message collection, Public Switched Telephone Network (PSTN) interconnection and security interfaces for a single-zone PacketCable network.

PacketCable 1.2 extends that single zone to an architecture that can support millions of subscribers across several cable networks and specifies CMS to CMS signaling, inter-domain Quality of Service, event messaging and security.


While PacketCable 1.0 described the interfaces for single-zone communication, version 1.2, according to Russell, addresses the fact that more and more phone calls will take place that are end-to-end IP, without traversing the PSTN. "We need a way for a CMS to talk to another CMS," he says. The CMS signaling protocol chosen by CableLabs is based upon the Internet Engineering Task Force's Session Initiation Protocol (SIP) version 2.0, which is a highly scalable protocol and helps perform a voice call set-up, tear-down and communications between CMSs. It's implemented in software on a server and conducts the "soft switch" functions.

At the boundary of each cable operator's managed IP network is an Exterior Border Proxy (EBP), which Miller points out, provides the signal aggregation point and security control point for the domain. As the signaling messages pass between domains, the EBP is responsible for security and billing in addition to routing between domains.

It's still unclear what exactly the network physical connection between zones will be, the so-called Inter MSO IP Backbone. The @Home and Road Runner networks are possible solutions for an inter-domain, managed IP network, but no agreements are yet in place. Theoretically, such a network can also be provided by any major IP backbone provider, such as Qwest or Global Crossing. But this issue is beyond the scope of the PacketCable project. "In general, we tried to just focus on the technology and allow for a wide range of business models and traffic exchange models," says Russell.

Inter-domain QoS

On a basic level, this portion of PacketCable, Miller notes, ensures that a network interconnection across the country, or from one operator's domain to the next, has enough bandwidth all the way through to complete and maintain a voice call.

PacketCable, according to Russell, takes a segmented approach to backbone Quality of Service. For the access portion of networks, that is, MTA at the subscriber premises and the Cable Modem Termination System (CMTS) at the operator headend, PacketCable relies on the dynamic QoS described by PacketCable 1.0.

Between CMTSs is the managed IP backbone network, which includes all edge, border and core routers that transport PacketCable session traffic. In the PacketCable QoS architecture, the CMTS is the entry and exit point to the backbone from each operator's DOCSIS network. Russell explains that inter-domain QoS, between a local and remote CMTS, is based on the IETF's DiffServ or Differentiated Services set of technologies. DiffServ, says Russell, "is a simple way to mark packets and give them priorities." Under a DiffServ configuration, border routers perform the packet marking. By implementing simple packet prioritization at the edge of the network, a PacketCable network then relies on routers to move the packets through queues quicker. DiffServ, says Russell, "is a simple but rich tool set."

Russell notes that there are other ways to establish end-to-end reservations of bandwidth to facilitate a voice call, including the Resource Reservation Protocol (RSVP), but it was felt that DiffServ offered the quickest time-to-market answer. Importantly, "today's off-the-shelf routers do support (DiffServ)," Russell says.

However, PacketCable 1.2 does define how Per-Flow and Aggregated RSVP signaling can be used to manage session bandwidth on the backbone. PacketCable also allows for the use of Multi Protocol Label Switching (MPLS) as a bandwidth optimization tool and for traffic engineering and re-route. The decision whether to use MPLS is left up to the operator.

Who's picking up the tab?

Important business and billing considerations are addressed in the event messaging portion of PacketCable 1.2, including how to provide sufficient per-call information for customer billing, as will as settlement between cable operators for exchanging traffic.

There are a total of six components described in this aspect of PacketCable 1.2, including interfaces between CMS and CMTS, CMS and Media Gateway Controller (or MGC, which receives, controls and mediates call signaling information between the cable network and PSTN), and between the CMS, CMTS and MGC and the Record Keeping Server.

Hello, is that really you, Uncle Fred?

The focus of the security in PacketCable 1.2 is to make sure the signaling messages between CMSs (using SIP) aren't hacked, intercepted or modified. Security is addressed between all elements of a PacketCable network, and seven network interfaces are described.

At one level, says Miller, when the CMS sends out a message to another CMS, the security provisions of PacketCable 1.2 make sure that it is indeed a CMS that's receiving the message, not a hacker.

Key management based on the Kerberos authentication is used to establish security associations between CMSs. The security provisions of 1.2 establish "trusted" paths for intra and inter-zone media and signaling, billing and usage tracking information, privacy protection between calling and called party, and control of QoS resources between CMTSs.

PacketCable 1.1

Not to be lost in the PacketCable 1.x architecture is the 1.1 iteration, which addresses primary line service, including powering of the MTA and how to monitor battery status. It is possible, Miller notes, to spark up a PacketCable 1.2-based network and not use 1.1 specs.

Issues addressed by 1.1 include an "end-to-end" availability model which defines conditions under which there will be equivalent availability for voice-grade PSTN service and PacketCable-based IP telephone service. Also, the model defines the crucial network elements needed to provide voice grade service and analog line interfaces that conform to Bellcore/Telcordia specs.

It remains to be seen to what degree operators pursue primary line service. In its IP voice trials in Rochester, N.Y. and Portland, Maine, Time Warner Cable is marketing its service, Line Runner, as a secondary line service.

Also, Steve Craddock, vice president of new media development for Comcast, says that the MSO's Philadelphia-based IP trial, scheduled to take place this year, will "probably" be a secondary line service.

Beyond 1.2

With single zone, primary line and inter-zone specs now complete, PacketCable will soon jump to the 2.0 iteration, says Russell. "The 1.x architecture, we view, is complete." The focus is now making sure that PacketCable interoperable equipment is brought to market.

Future iterations of PacketCable will develop extensions that address applications other than voice, using IP networks, including video codecs to support interactive gaming, peer-to-peer applications (Napster-like services) and video conferencing apps. Also under consideration, says Russell, is MPEG video over IP. The PacketCable architecture, Russell believes, is rich enough to support all these services.

PacketCable compliance testing

Meanwhile, the testing crew at CableLabs will be kept busy conducting PacketCable 1.0 compliance testing waves of every component defined in the specification, including the CMS, provisioning server, media gateway, signaling gateway, media gateway controller and record-keeping server, according to Russell. CMTSs and MTAs must first pass DOCSIS 1.1 certification.

For PacketCable compliance testing, vendors, says Russell, will be required to bring into CableLabs' facilities the products in the form factors they'll sell in the marketplace. Vendors, says Russell, may combine components in any way they see fit; for example, the media gateway controller, which controls and mediates call-signaling between the PSTN and PacketCable network, may be implemented in the CMS, says Russell.

Likewise, the record-keeping server may also, if vendors prefer, be packaged with the CMS.

Compliance testing for 1.1 and 1.2 PacketCable gear won't happen until early next year.

For vendors, Russell says that PacketCable will allow for more feature differentiation than DOCSIS, partly because the PacketCable spec resides higher up the OSI model protocol stack, closer to the application layer, than DOCSIS.

Circling the wagons

Anticipating a move into the marketplace, vendors are now forming partnerships, because offering a complete end-to-end PacketCable product will require collaboration, given all the components necessary. For example, CMTS maker Cadant Inc. has forged partnerships with Clarent Corp. for its soft switch technology, Future Networks (recently acquired by Tellabs) for its indoor and outdoor MTAs, and General Bandwidth for voice gateways.

"There will be additional partners," says Tom Ruvarac, Cadant's director of business development. He predicts operators will embrace both an "a la carte" and "end-to-end" approach to the full PacketCable equipment and service set. Operators with larger staffs, he says, will be able to choose "best of breed" components, while those with smaller staffs most likely will turn to end-to-end options.

In the near term, CMTS vendors such as River Delta and Cadant are both focused on implementing and winning qualification for DOCSIS 1.1.

River Delta Networks has also been working on partnership alliances, as well as interoperability testing of its own with vendors, including Tollbridge and Motorola, that may include its CMTS platform as part of a complete PacketCable product, according to Jeff Walker, vice president of marketing for River Delta. The company, like Cadant, will also offer its PacketCable CMTS separately, if operators prefer.

Gerry White, River Delta's VP and CTO, suggests that partnerships are more important in the early stages of PacketCable. In the meantime, he predicts the industry will see "a loose-knit set of alliances that change faster than the alliances at the U.N."


Share This Story

You may login with either your assigned username or your e-mail address.
The password field is case sensitive.