By Keith Perry –

The backstory

 

One of the caveats of rolling out new technology in a service provider environment is that you must accommodate older technology, until such point where it’s no longer needed. Unfortunately, you may have no control over the time frame required to reach the expiration point, which in a worst case scenario would stretch to infinity. A classic example for cable operators is the legacy set-top box out-of-band (OOB) signaling described in the SCTE 55-1/2 specifications. These two specs define the physical and data link layers used to transport requisite data carousels. They originated from the original set-top conditional access (CA) system vendor “duopoly” of General Instrument (55-1) and Scientific Atlanta (55-2). To simplify the plethora of vendors involved since inception, I will refer to these as “Moto/Arris” for 55-1 and “SA/Cisco” for 55-2.

Cox Communications is seeking to retire both the SCTE 55-1/2 plants and infrastructure. Part of this effort involves updating multi dwelling unit (MDU) gateways, which contain multiple CableCARD™ modules, to use Advanced DOCSIS Set-top Gateway (ADSG) in lieu of legacy SCTE 55-1/2 signaling. Another part is focused on tuning resolvers (TR), which were originally developed to provide a simple solution for Unidirectional Digital Cable Product (UDCP) devices with CableCARD™ modules to gain access to switched digital video (SDV) channels. SDV requires interactive communications to the headend to request and obtain mini-carousel tuning information. The TR, in bidirectional mode, uses the USB port on the back panel to communicate tuning information between the headend and the UDCP device, which is typically a TiVO digital video recorder (DVR). Tuning resolvers have no CableCARD™ and are designed to operate only in a single CA environment.

TiVo has an extremely faithful following of passionate, zealous owners who would just as soon cancel their cable subscription than give up their TiVo device. Consequently, there was a need for a new ADSG capable TR for both CA market types which would isolate the TiVO DVR from the outside plant and accommodate future changes in the DOCSIS downstream/upstream frequency split. Cox currently implements sub- and mid-split configurations with an enterprise wide SCTE 55-1/2 downstream frequency of 110 MHz. We are also currently trialing high-split configurations on an extremely limited basis.

The SCTE 55-1/2 specifications define an upper limit of 130 MHz for the downstream which precludes migrating to a high-split configuration (258 MHz cutoff) while continuing to support legacy SCTE 55-1/2 devices such as the TiVO DVR. This new device needed to perform three functions, without the need for embedded security or a CableCARD™ (a.k.a. MCard) module:

1. SDV TR for both SA/Cisco and Moto/Arris markets
2. DOCSIS ADSG to legacy OOB SCTE 55-1/2 conversion (LOC)
   1. Create localized and isolated SCTE 55-1/2 plant on customer premises.
3. Proxy for Moto/Arris MCards on the localized 55-1 plant
   1. Digital Addressable Controller (DAC) does not support one-way ADSG MCards

The importance of documentation

In April of 2021, Charter Communications authored a 35-page specification for a device called the high-split converter (HSC), primarily focused on hardware, and commissioned Vecima Networks to build the device. Software requirements were limited to general one line support of the following four specifications:

1. OC-SP-TRIF-I05-130607

Tuning Resolver Interface Specification

1. TWC-SDV-CCMIS-3.16/17

Switched Digital Video Channel Change Message Interface Specification

1. SCTE 55-1 2009

Digital Broadband Delivery System: Out of Band Transport Part 1: Mode A

1. SCTE 55-2 2008

Digital Broadband Delivery System: Out of Band Transport Part 2: Mode B

In late July of 2021, I was asked to review this specification and to be brutally honest, was completely underwhelmed. My main concern was that it was “open ended” and would result in an undocumented “black box” which very few people would understand or be able to support. We already had that with our current tuning adapters. So, I started writing a companion “Conceptual Specification” focused on Cox specific requirements. Over the course of 2022, working closely with the Vecima Networks, CableLabs architect Doug Jones, CommScope (Moto/Arris) and a host of internal Cox folks, this blossomed into a comprehensive 139-page document. I performed the dual role of SA/Cisco and DOCSIS consultant on this journey in addition to being the overall scribe. In August of 2023, this specification morphed into a 216-page Theory of Operation document, completely obliterating my “black box” concern.

Some unique DOCSIS attributes

The first order of business was to add a second system on chip (SoC) for a new embedded Service/Application Functional Entity (eSAFE) device type called the “eTR”. This required a change to the CableLabs eDOCSIS™ Specification. Without this, the device would have been limited to a single IP address (used by eCM) and unable to communicate to back-office servers. It also allowed us to define our own eTR/LOC CPE requirements, separate from Charter.

Charter and Cox still had to agree on a common set of eCM requirements. Vecima/Humax produced a clever implementation for our in-band SDV mini carousel (MC) QAM tuner requirement. The Broadcom BCM3383 16×4 DOCSIS 3.0 cable gateway SoC has 16-QAM demodulators, segmented in blocks of four. They reserved one block for the in-band SDV MC, two blocks for DOCSIS and left one unused. They accomplished this by having one block filter for the SDV MC packet identifier (PID) 0x1FEE instead of the DOCSIS PID 0x1FFE. They originally used 12 channels for DOCSIS, which we reduced to eight to avoid using a non-standard receive channel set and to limit the number of dynamic bonding groups on the CCAP.

The second change we implemented was the DOCSIS Upstream Ranging Class ID. Cox currently implements forced upstream steering via Channel Class ID TLV 19, a.k.a. the ranging class ID. We force all STB devices to initially range on a QPSK channel, then move certain types to 64-QAM. We also prevent STB devices from upstream bonding via a CM config file forbidden attribute mask. I wanted to treat the HSC like a residential gateway rather than a STB. The only way to accomplish this was to assign it a new ranging class ID (0x10), which required a change to the DOCSIS 3.1 MAC and Upper Layer Protocols Interface (MULPI) specification. CableLabs closed the 3.0 spec.

Market awareness and SDV files

The HSC inspects the DSG downstream channel descriptor (DCD) to determine operator (Charter vs Cox) and CA system (SA/Cisco vs Moto/Arris) to boot into the appropriate code branch. The CableLabs DHCP Options Registry specification was updated to include a SDV Auto-Discovery Web Service URL which provides two functions:

1. Customer account information to determine which URLs the HSC needs to retrieve the correct SDV files.
2. Customer account Moto/Arris MCard unit addresses for the Moto/Arris controller DSG one-way issue.

There are three SDV files required for registration with the SDV server.

1. SDV Autodiscover:
   List of five SDV QAM frequencies (which carries MC)
2. SDV Switched Channel List:
   Switched channel list of source IDs
3. SDV Address Map (IPv4 to IPv6):
   To support SDV MC version 2.1 in IPv6 only environment

Moto/Arris overview

Although the DAC supports one-way 55-1 MCards, it doesn’t support one-way DSG MCards, which is a somewhat egregious oversight of the CableLabs DSG specification. The solution was to trick the DAC into thinking the MCard in the UDCP device is two-way DSG, when in fact it is one-way 55-1. The HSC proxies for the MCard by sending Auto Discovery Registration Message (ADRM) messages upstream and handshaking with the DAC. This enables the DAC to communicate to the one-way MCards behind the HSC using specific DSG multicast flows via a specific DSG RADD. This also requires that the HSC be a configured device type on the DAC.

The Moto/Arris HSC receives three different DSG multicast flows from two different DSG servers: the DSG RADD and the EAS encoder/decoder, which in our case is the Monroe One-Net. All three flows are mapped to MPEG2 PIDs based on UDP port.

1. CA DSG Multicast = CA “Tunnel” using CA Client ID 700 consumed by MCard
2. SI DSG Multicast = SI “Tunnel” using CA Client ID 701 consumed by MCard
3. EAS Multicast = EAS “Tunnel” a.k.a. Broadcast Tunnel Type 2 consumed directly by host

The HSC passes both the CA and system information (SI) messages, but also processes SI which contains the virtual channel table (VCT) identified via the proxy handshaking with the DAC. It uses the VCT to overwrite (via USB connection) the one received and processed by the MCard. The HSC also removes the broadcast tunnel header and changes the MPEG-2 PID to the SI PID for EAS messages.

SA/Cisco Overview

The HSC for SA/Cisco does not need to communicate to the Explorer Controller because it sends comms to one-way MCards out to all the DSG multicast and 55-2 unicast flows. The controller has no awareness of the HSC or what state (DSG versus 55-2) a one-way MCard is in. While this aspect is much simpler than Moto/Arris, the LOC functionality is more complicated.

The SA/Cisco HSC also receives three different DSG multicast flows from two different source IP addresses: The Explorer Controller and the Monroe OneNet. Only two of these flows are mapped to a specific asynchronous transfer mode (ATM) virtual path (VPI) / virtual circuit (VCI) pair based on UDP port. SA DSG passthru and EAS messages also require deeper examination into payload for the passthru reservation number.

1. SA DSG Multicast = CA “Tunnel” using CA Client ID E00 consumed by MCard
2. SCTE65 DSG Multicast = SI “Tunnel” a.k.a. Broadcast Tunnel Type 1 consumed directly by host
3. EAS Multicast = EAS “Tunnel” a.k.a. Broadcast Tunnel Type 2 consumed directly by host

The SA DSG flow includes legacy SI with a single VCT. It also includes Emergency Alert System (EAS) messages the EC receives from the Monroe OneNet. These, along with other EC message types are mapped to five different VPI/VCI pairs and passed to the RF output.

The ANSI/SCTE 65 2016 (R2021) DSG flow terminates on the HSC, which determines its hub ID from UNCI messages on the SA DSG flow. It then selects the correct VCT (out of multiple) based on hub ID and then passes it to the TiVo host via USB, overwriting the one received and processed by the MCard.

There are three identical EAS flows that must be dealt with, two from the EC and one from the Monroe OneNet. The HSC removes the broadcast tunnel headers for EAS messages it receives directly from the Monroe OneNet and passes it to the RF output using the VPI/VCI for SI. It removes/blocks legacy EAS messages for OpenCable Hosts on the SA DSG flow using SI port 2001 and separate messages for legacy hosts using passthru port 13820.

That’s the HSC in a nutshell. Its timely creation has allowed us to resolve a SA/Cisco PowerKey expiration issue that will disable all legacy tuning adapters on 11/24/2024. We just have to replace them. The clock is ticking.

---

 

Keith Perry

Lead Communications / Network Engineer

Cox Communications, Inc.

keith.perry@cox.com

Keith Perry is 24-year veteran in the cable industry, 17 years at Scientific Atlanta/Cisco Systems in a systems development/integration role for the Digital Broadband Delivery System (DBDS) and the last seven years at Cox Communications in Access Engineering focused on CCAP/DSG set-top client integration and test in both lab and production environments. Prior to that, he spent 18 years with various Department of Defense (DOD) and space systems contractors honing his skills in creating documents that bridge the gap between architectural theory and real-world application.

—

Diagrams provided by author