Watching the PacketCable Barometer

CableLabs‘ current activities may not be a foolproof indicator of cable’s future service offerings, but history indicates that they correlate well with how we got to where we are today.

DOCSIS-compliant plant and customer premises equipment (CPE) implementations preceded high-speed data offerings as a way to meet customer needs for data transport that matched the rapidly increasing processing power of personal computers. Similarly, PacketCable 1.0 through 1.5 found its way into cable networks in anticipation of the carrier-grade residential telephony offerings that have become a staple of cable’s marketing mix.

These technology implementations have a common thread. Technology that has gained acceptance has been defined by CableLabs specifications.

If the pattern holds, a look at current PacketCable work might be a way to sort out what’s most likely to appear in 2008 from applications that will be waiting in the wings. Among those apps, business voice may be most ready to take a bow. A caveat There’s more method than madness in focusing on CableLabs. After all, the CableLabs agenda is set by its membership, which includes the major cable operators.

Before making too many conclusions, however, it might be wise to heed a caveat about CableLabs output. "PacketCable, like all CableLabs documents, is not a standard," says Mike Schwartz, CableLabs senior VP communications. "It is a set of specifications."

The distinction is subtle, but important. Standards are mandates, established by an American National Standards Institute-accredited body, such as the SCTE, or other official national or international standards-making bodies. Specifications are more like guidelines, and neither operators nor vendors are obliged to implement every part of every specification. Compliance can therefore be specific to individual subpoints within any given document.

How closely operators and vendors follow the specs depends upon markets, existing operator architectures, vendor activity, and independent trials and tests by the operators and vendors. Comcast Senior Vice President New Technology Steve Craddock told attendees at last November’s CableNEXT event that Comcast was planning PacketCable 2.0 trials for the first half of 2008. For a look at what Cox Communications trialed in 2007 and aims to deploy this year, see sidebar. Platforms and apps As a sort of safety valve, CableLabs not only creates specs, but also maintains both development and interoperability labs to verify product compatibility. Interoperability can pertain both to cable-specific designs and also to equipment that may have been created for other environments but is used in cable plant.

The inaugural PacketCable Application Lab interoperability event, which took place in Louisville, CO, in August 2007, provides some insight into near-term plans for the industry. Voice feature testing continues to dominate, which is an indication that even though the Internet protocol (IP) multimedia subsystem (IMS) core has become part of the PacketCable architecture, the focus remains on applications and on voice telephony in particular.

Therein lie two ways to look at this overall initiative. "PacketCable today has two dimensions: IP platforms and IP applications," says PacketCable Director Eric Rosenfeld.

The most recent activity on the core infrastructure or platform side was the September 2007 update of PacketCable 2.0 to align with the Third Generation Partnership Project IMS specifications.

"Other core infrastructure activity included publication of extensions to PacketCable Multimedia (PCMM) to work with DOCSIS 3.0 and updates to PacketCable 1.5," Rosenfeld says. "The applications side has been focused on residential SIP (session initiation protocol) telephony and cellular integration, with specifications issued in both areas during 2007." Next 24 months A plausible scenario for new cable services over the next 24 months can be derived from these published and planned PacketCable specifications. Based upon the work already done for residential SIP services and operator activity in business services, the next near-term applications work will most likely be for SIP business voice services. That provides good reason for placing SIP business voice services at the top of the next list for industry initiatives.

Although the concept of the IMS core in PacketCable 2.0 came from the wireless industry, PacketCable emphasis is still on services over the HFC infrastructure. Before cable embraces new wireless access methods, it will therefore most likely be looking at ways to extend its existing networks further into the customer premises via the PacketCable provisioning infrastructure.

Rosenfeld confirms a focus on business voice services. "There is a large community already building products," he says, "so our goal is to leverage as much as possible and be sure capabilities are supported through interoperability." Vendors that have participated in CableLabs interoperability events agree.

Randy Fuller, VP business development for policy server vendor Camiant observes that business voice is important to operators as a near-term service. "Businesses require services that are not based in NCS. There is a migration toward hosted services that mirror IP PBX functionality, and the business market is the first place where PacketCable 2.0 capabilities will be required."

As for wireless, although the PC 2.0 specs include lots of input from that industry, it doesn’t necessarily imply a massive cable operator commitment to wireless access will occur in the near term. The focus in the cellular integration specification is on the handoff between a premises-based Wi-Fi network and a Packetcable infrastructure. Other emerging wireless developments, such as mobile WiMAX, are not yet addressed. "Wireless is a brand-new infrastructure," says Rosenfeld. "We’re in a wait and follow mode with our members." Home and provisioning Customer premises networking applications, although not as hot as business voice services, will probably emerge as service offerings faster than new wireless access methods.

CableLabs issued a PacketCable specification in 2007 on provisioning existing clients embedded in a cable modem. "In 2008, we will look at how to use existing cable infrastructure to provision devices not embedded in a CM," says Rosenfeld. Examples of such devices could be an "IP widget" with a screen and Wi-Fi or other non-cable connection to the Internet.

"People will be putting in firewalls into their homes," Rosenfeld explains, "and we will need to be sure we can deliver services to these devices."

Resolving all the issues of provisioning these clients may require more than a year. Chris Busch, VP broadband technologies, Incognito Software, suggests that provisioning across multivendor platforms will require more discussions between CableLabs and standards bodies that have examined remote CPE provisioning in detail.

"LAN (local area network)-side discovery has been addressed in detail by the DSL Forum‘s TR-69," Busch says, "and substantial work could be re-applied for provisioning networks on the subscriber side of the cable modem." Another caveat A final comment on future-gazing is in order. While PacketCable activity may be a good predictor, other factors will also influence the emergence of new services.

That is certainly the case in the business services market. Fiber-based offerings that support primary rate interface (PRI) or T-1 links and metro Ethernet services are one example. "We have to look at the services we are trying to offer and match them to what we have," says Bresnan Communications VP of Strategic Engineering Pragash Pillai.

It bears repeating that CableLabs’ MSO members set the organization’s agenda. But the industry’s R&D consortium by design aims to work several steps ahead of these members, whose own natures remain persistently pragmatic.

"Cable doesn’t apply infrastructure for the sake of infrastructure," Pillai says.

For all of the standardization that the industry has embraced, MSOs nonetheless still test, trial and tinker on their own. For instance, some are "building an infrastructure to mimic IMS, but not the full IMS," says Pillai.

That said, and granting that Cox for one is committed to a full IMS migration (see sidebar) legacy and updated PacketCable specs will continue to serve the industry’s telephony business and have a strong potential to impact business services and home networking. Justin J. Junkus is president of KnowledgeLink and telephony editor for Communications Technology. Reach him at [email protected]. Sidebar: An Interview with Cox’s Bruce McLeod Is wireless part of your voice portfolio?

From a technology development standpoint, we want the services and applications that we deploy to be very flexible, regardless of what the access methodology is. One of the promises of a technology like IMS is that the network does the job of discovering what is the current state of the subscriber.

What’s your view on PacketCable and SIP alternatives?

What we’re looking for is a convergent strategy based on a core technology, and SIP certainly fits the bill. When we look at PacketCable 2.0, we still have some questions around the NAT (network address translation) traversal issues. In the meantime, for our business services, since that consists of a variety of HFC and Ethernet access, we’re going as aggressively as we can to deploy the service capabilities without a whole lot of regard to PacketCable 2.0 requirements.

Are your NAT traversal questions are related to STUN server concerns?

Correct. We think there are some serious challenges there. And it really gets down to the timing of our needs, whether we’re going to come up with our specific implementation for our residential customers or work through those challenges.

You’re been looking closely at IMS core infrastructure. Will we see more action in 2008?

Absolutely, we have a committed plan. We spent most of 2007 doing in-network trial work. So we deployed a production quality IMS core and then launched trial services in our Orange County market, as well as a number of trial users in Atlanta.

So what’s the driver, apps or infrastructure?

It’s really the cost of delivering apps. In the past, we’ve made these platform decisions, multi-million dollar investments, where if you’re wrong, you really pay the price. The network level and the application layer infrastructures give you the ability to roll an app at a very low cost compared to a dedicated platform and also without a whole lot of complexity. We can do it faster, as well.

What apps did you trial?

One that we built in-house was called "intelligent disposition," which allows you to manage your phone calls from your computer screen. We used the standard SIP soft-client, but customized it so that when an incoming call occurs, an instant messaging window pops up and says, "You’ve got a call coming in from John Q Customer; what would you like to do?" We also deployed an application called "click to call," which allows you to click on any phone number embedded in any MS Office document and place that call from your PC.

What’s your plan this year?

Our ’08 plan is to launch services in three markets by the end of the third quarter. We’re going to start with a smaller set than the eight applications we trialed.

What’s your CMS to IMS transition story?

In our trial, we used two methods for interconnecting voice to the PSTN: a SIP to TDM or SS7 gateway that we tied in to one of our switches in Orange County; and a SIP interconnection to Level 3. PacketCable 2.0 and IMS provide a mechanism for interfacing with the PSTN called the MGCF (Media Gateway Control Function), and we’re working with our legacy vendor to implement MGCF now. That’s really how we take a CMS and evolve it to IMS.

Bruce McLeod is executive director, voice technology and engineering, for Cox Communications. He spoke with CT Editor Jonathan Tombes.