The Cable Television Laboratories Inc. PacketCable group
has met its deadline for delivering specifications for version 1.0 of its protocols,
setting the stage for vendor production of supporting equipment in the year ahead.
It will take a while yet for all of the hardware and
software to fall into place on the production lines, including the vital components
embodied in cable modems that conform to version 1.1 of DOCSIS (Data Over Cable Service
Interface Specification).
But MSOs are in position to confidently move ahead with
technical tests and, soon, market trials, en route to commercial rollout of voice-over-IP
(Internet protocol) and other advanced packet services.
"For commercial deployments, we have to have DOCSIS
1.1 equipment, including the low-power versions of DOCSIS 1.1 modems," said Mark
Coblitz, vice president of strategic planning at Comcast Corp. 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," he added.
Coblitz wouldn'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 wasn't ready to talk about a market trial, which 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 said.
"But we're very confident in the approach we're taking to delivering voice
services."
While CableLabs officials anticipate that the DOCSIS 1.1
certification process could be tough on vendors, much as 1.0 certification has been,
Coblitz and other MSO executives said 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 said, "I believe
so, but I expect that we'll have certified equipment."
Hardware compatibility is the most crucial aspect, and most
vendors appear in conformance there, said 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. That's why any delays in certification aren't likely to slow people
down who want to move ahead with commercial IP-voice deployments."
CableLabs made the PacketCable 1.0 specs public last week.
What follows is a distillation of some of the key points of the architecture and
underlying protocols of the highly complex system.
It is clear from the description of what can be done with
hybrid-fiber coaxial cable networks employing the PacketCable architecture that the
industry has created a template for the interactive broadband age that other industry
sectors will be hard-pressed to compete with.
By structuring a system that works in the pure-packet
domain -- where commands applied to applications can turn any application into a two-way
voice- and video-enhanced service -- the cable industry has established a means to ride
the digital wave for a long time into the future.
At the highest level, the PacketCable 1.0 architecture
contains thee networks: the DOCSIS HFC-access network, the managed IP network and the
public switched telephone network.
The cable-modem-termination system provides connectivity
between the DOCSIS HFC-access network and the managed IP network. Both the signaling
gateway and the media gateway 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 premises and the cable headend. This access
network may provide all DOCSIS 1.1 capabilities, including quality of service.
The DOCSIS HFC-access network includes the following
functional components: the cable modem, the multiple-terminal adapter 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. The managed IP network also
provides long-haul IP connectivity between other managed IP and DOCSIS HFC-access
networks.
The managed IP network includes the following components:
call-management server, announcement server (ANS), several operational-support-system
back-office servers, signaling gateway, media gateway and media-gateway controller.
A PacketCable zone consists of the set of MTAs in one or
more DOCSIS HFC-access networks that are managed by a single functional CMTS. Interfaces
between functional components within a single zone are defined in the PacketCable 1.0
specifications.
Interfaces between zones have not been defined, and they
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; QOS; media-stream transport and encoding; device
provisioning; event messaging; security and privacy; and OSS.
Because of space limitations, the synopsis presented here
focuses on the call-signaling and QOS components.
CALL SIGNALING
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 their current phone number
via local number portability; ensures subscriber choice of interexchange carriers for both
inter- and intra-LATA (local access and transport area) calls, including pre-subscription
and "dial-around" agreements; and allows the customer to set call-blocking
restrictions to 900, 976 and similar toll numbers.
Call signaling requires multiple interfaces within the
PacketCable architecture, interconnecting MTAs with CMTS equipment; CMTS equipment with
signaling gateways and MGCs; signaling gateways and MGCs with each other; MGCs 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 CMTS -- and places device-control
intelligence in the MTA. The MTA passes device events to the CMTS and responds to commands
issued from the CMTS. The CMTS -- 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.
To illustrate: The CMTS would instruct the MTA to inform
the CMTS when the phone goes off the hook and a phone number has been dialed. When this
sequence of events occurs, the MTA notifies the CMTS. The CMTS may then instruct the MTA
to create a connection, to reserve QOS resources through the access network for the
pending voice connection and to play a locally generated ring-back tone.
The CMTS, in turn, communicates with a remote CMTS to set
up the call. When the CMTS detects an answer from the far end, it instructs the MTA to
stop the ring-back tone, to activate the media connection between the MTA and far-end MTA
and to begin sending and receiving media-stream packets.
By centralizing the call-state and service processing in
the CMTS, the service provider is in a position to centrally manage the reliability of the
service provided.
In addition, the service provider gains full access to all
software and hardware in the event of a defect. Software can be centrally controlled and
updated in quick debugging and resolution cycles that do not require sending technicians
to customer premises.
The service provider also has direct control over the
services introduced and the associated revenue streams.
Another key call-signaling framework is the PSTN-signaling
framework, which consists of the set of interfaces that provide access to PSTN-based
services and to PSTN subscribers from the PacketCable network.
The PacketCable PSTN-signaling framework consists of a PSTN
gateway that is subdivided into three functional components: the MGC, the media gateway
and the signaling gateway.
The MGC and the media gateway are analogous to the CMTS and
the MTA, respectively, in the NCS framework. The media gateway provides bearer and in-band
signaling connectivity to the PSTN. The MGC controls the operation of the media gateway
through the telephony-gateway-control protocol, which is a profile of the MGCP similar to
NCS.
These functions include creating, modifying and deleting
connections, as well as in-band signaling information to and from the media gateway.
The CMTS and MGC may each send routing queries (e.g.,
800-number lookup, local-number-portability lookup) to an SS7 service control point via
the signaling gateway. The MGC, via the signaling gateway, also exchanges ISUP (ISDN user
part) signaling with the PSTN's SS7 entities for trunk management and control.
The ISTP (Internet Signaling Transport Protocol) provides
the signaling-interconnection service between the PacketCable network-control elements
(CMS and MGC) and the PSTN SS7 signaling network through the SS7 signaling gateway.
ISTP contains features for initialization; address mapping
from the SS7 domain to the IP domain; message delivery for SS7 ISUP and TCAP
(transaction-capabilities application protocol, which is used for performing remote
database transactions with a signaling control point in the SS7 domain); congestion
management; fault management; maintenance operations; and redundant configuration support.
ISTP bridges the gap between basic IP-transport mechanisms and application-level
signaling.
These capabilities allow the IP network to interact with
and receive all of the services of the PSTN. As service capabilities evolve over time,
these same signaling capabilities may be used to support PSTN access to the PacketCable
network's own routing and service databases.
QUALITY OF SERVICE
Protocols in this category support a rich set of policy
mechanisms that provide and manage the QOS aspects for PacketCable over the access
network, including admission and control mechanisms for both upstream and downstream
directions and the means by which QOS is dynamically changed in the middle of PacketCable
calls.
The QOS specs provide for transparent access to all of the
QOS mechanisms defined in DOCSIS 1.1, which means that the PacketCable clients working off
the DOCSIS 1.1 interface don't need to be aware of the specific DOCSIS QOS primitives and
parameters.
The QOS specs also provide a priority mechanism for 911 and
other priority-based signaling services, and they are designed to prevent abusive attacks
on QOS policy, such as activation of denial of service or theft of QOS authorization.
QOS signaling interfaces operate between many components of
the PacketCable network, with signaling for these interfaces occurring at the applications
layer, the network layer or the data-link layer, where DOCSIS 1.1 QOS is operative.
The QOS supplied by DOCSIS 1.1 between the CMTS and the
cable modem is especially vital to the success of PacketCable applications. Some of the
features of DOCSIS 1.1 that are used for the QOS in PacketCable include:
Multiple service flows, each with its own class of
upstream traffic;
Both single- and multiple-voice connections per
DOCSIS service flow;
Prioritized classification of traffic streams to
service flows;
Guaranteed minimum/constant bit-rate-scheduling
service;
Constant-bit-rate scheduling with
traffic-activity-detection service;
DOCSIS packet-header suppression for increased call
density; and
DOCSIS classification of voice flows to service
flow.
QOS signaling from the MTA can be performed either at layer
two (DOCSIS) or layer four, where an enhanced version of the IETF protocol RSVP (Resource
reSerVation Protocol) is put into play. If layer-two QOS signaling is initiated by the
MTA, the MTA must be embedded in a module with the cable modem, allowing it to use the
implicit interface for controlling the DOCSIS media-access-control service flows.
A stand-alone MTA uses the layer-four interface, which can
also be used by the embedded MTA, to signal the CMTS, which then utilizes layer-two QOS
signaling to communicate QOS-signaling changes to the cable modem.
RSVP+, as the layer-four interface is called, is used for
bandwidth and QOS resources related to the bandwidth.
This interface runs on the layer-four protocols that bypass
the cable modem. As a result of the message exchanges between the MTA and CMTS using this
interface, service flows are activated using CMTS-originated signaling on the DOCSIS 1.1
QOS interface.
The layer-four interface allows devices that are one or two
hops removed from the RF (radio frequency) boundary of the DOCSIS-access network to
communicate with the CMTS and MTA.
PacketCable also supports dynamic QOS, which uses the
call-signaling information at the time the call is made to dynamically authorize resources
for the call. Dynamic QOS prevents various theft-of-service attach types by integrating
the QOS messaging with other protocols and network elements.
The function within the CMTS that performs traffic
classification and enforces QOS policy on media streams is called a gate. The
gate-controller element manages gates for PacketCable media streams.
