Demystifying OOB and R-PHY

By Brady S. Volpe

Benefits and Limitations, Choose your R-PHY Wisely

In this article we dive into Data-Over-Cable Service Interface Specifications (DOCSIS) remote PHY (R-PHY) testing challenges and how these can be overcome using out-of-band (OOB) channel communications.

Test and Measurement Challenges with R-PHY

Let’s understand the fundamental challenges with testing in an R-PHY world. Today’s radio frequency (RF) test equipment, such as sweep, return path monitoring, and leakage is based on analog signals. Figure 1 illustrates how typical headend / hub test equipment signals traditionally flow to or from an analog RF fiber node.

When we move into the R-PHY domain, the analog optical link in the forward and return is replaced with a digital optical link. This means traditional test equipment can no longer send RF signals over the fiber link to the R-PHY node. Figure 2 illustrates this new scenario.

The digital optical link is a benefit of the R-PHY architecture since eliminating the analog optical link places the modulators and demodulators closer to the subscriber. This improves the signal quality on the upstream and the downstream.

The tradeoff is that analog test signals are not able to traverse the digital optical link without digitizing the test signals and transporting them over the digital link using technologies and standards provided in the DOCSIS / R-PHY specifications. This creates the testing challenges with R-PHY.

R-PHY Out-of-Band Communication

There exists a number of technologies and standards in the DOCSIS R-PHY specifications called OOB communication protocols. A separate specification is devoted to these standards called the remote out-of-band (CM-SP-R-OOB) specification. This specification has enabled vendors to digitize analog signals between the R-PHY and CCAP. The following paragraphs provides a high level summary of the sub-specifications contained within the CM-SP-R-OOB.

First is SCTE 55-1 which is a legacy General Instrument / Motorola / Arris OOB protocol adopted by the SCTE Digital Video Subcommittee in 1998. This protocol is primarily for set top box communications. It supports a downstream frequency of 70 MHz to 130 MHz with a data rate of 2.048 Mbps ± 0.01%. In the upstream it supports 5 MHz to 42 MHz with one 3.2 MHz channel or three 192 kHz channels.

The RPD MUST support SCTE 55-1 while the CCAP core forwards the downstream external PHY interface (DEPI) encapsulated traffic from the RPD.

Second is SCTE 55-2 which is a legacy Scientific Atlanta / Cisco OOB protocol adopted by the SCTE Digital Video Subcommittee also in 1998. It is also primarily used for set top box communications. In the downstream it supports a frequency range of 70 MHz to 130 MHz with a data rate of 1.544 Mbps for Grade A or 3.088 Mbps for Grade B. In the upstream it supports a frequency range of 8 MHz to 26.5 MHz +/- 50 ppm with the following data rates:

• 200 kHz for Grade A (256 kbit/s)
• 1 MHz for Grade B (1.544 Mbps/s)
• 2 MHz for Grade C (3.088 Mbps/s)

Given a 50 kHz step size for Grade A, Grade B, and Grade C.

The RPD MUST support SCTE 55-2 and the RPD MUST connect to one SCTE 55-2 controller which sends and/or receives OOB traffic.

Finally, is R-OOB Narrowband Architecture consisting of narrow band digital forward (NDF) and narrow band digital return (NDR). This protocol is new and was introduced for telemetry signaling specifically for R-PHY devices. NDF digitizes analog signals of the downstream spectrum at the headend and sends these as packets to the remote PHY device (RPD), and then re-creates the original analog signal at the RPD. Similarly, the NDR digitizes portions of the return band and sends these as packets back to the CCAP core and recreates the original analog signal at the headend. The headend A/D interface for NDF/NDR is usually a third-party device rather than the CCAP itself.

The NDF compliance matrix is shown in Figure 3, which is taken from section 7.1.2 of the CableLabs CM-SP-R-OOB specification.

The NDR Compliance matrix is shown in Figure 4, which is taken from section 7.2.2 of the CableLabs CM-SP-R-OOB specification.

Notice in Figure 3 and Figure 4 that while the RPD MUST support many of the features the CCAP is under “SHOULD” requirement, which means it may not be supported by all vendors.

R-PHY Test and Measurement with OOB

In practice today, we have made good use of the aforementioned OOB protocols to enable test and measurement to the R-PHY node. These techniques are more complex than traditional analog systems to develop and require collaboration between the test equipment vendor and RPD vendor to develop working solutions. Further, RPD vendors are finding opportunities to differentiate themselves by extending testing support, such as extending the frequency range, enhancing the spectral capture capabilities, and enabling special testing features.

Most RPD vendors have started with SCTE 55-1 and 55-2 as the supported protocols. This ensures they are able to support legacy set top signaling. Some RPDs can generate on a standalone basis certain types of test signals (e.g., alignment tones, AGC pilots, and leakage test signals) to support on-going plant maintenance and testing. Similarly, vendors are extending the upstream frequency to as high as 204 MHz. This enables operators to expand their upstream spectrum usage to as high as 204 MHz. As well, RPD vendors are working with test equipment vendors to integrate support for return sweep.

RPD vendors are also finding unique ways to differentiate themselves by adding functionality such as custom controls on the RPD fast fourier transform (FFT) engine, which does the conversion of time-domain data to frequency domain. The importance of this lies in how fast the data is returned, the ability to trigger on certain modems and more.

The end result is a system that effectively makes us feel like we are using legacy test and measurement equipment in our hybrid fiber/coax (HFC) plant regardless of whether the fiber terminates in an R-PHY node or a R-MAC/PHY node. The combination of NDF, NDR, and triggered spectrum capture in conjunction with a suitable interface in the headend or hub allows existing field test equipment to be used as is. This means the field tech can use his or her existing test equipment (e.g., upstream sweep) in the same way as before the deployment of an R-PHY architecture.

What about RPD Performance?

During the research of this article I spoke with many RPD vendors about the impacts to R-PHY when using OOB channels to perform test and measurement. The answer was a unanimous and resounding, “it depends.” There are many factors and we are early in the RPD lifespan such as generation 1 vs generation 2 ASIC in addition to FPGA-based architectures. This means the fundamental architecture of your RPD will impact its overall capabilities and RPD vendors are finding really interesting ways to add cool testing features based on requests from cable operators. So what’s in your RPD?

In most cases the response is that there are no negative impacts to the RPD or the channel carrying data to/from the RPD if the test equipment vendor designs the test system correctly and OOB has been properly implemented in the RPD. Some of these work arounds include not using more channels than are provided in the OOB channel, not triggering the FFT too often as it will over-utilize the IP channel between the CCAP and RPD, and using non-OOB channels as often as possible and more.

The bottom line is that OOB channels provide a way to perform test and measurement on the HFC plant, but the developers of these tests must be aware of what they are doing as they are using the same data link and processing resources that are being used to transport subscriber data and video. Having knowledge to properly utilize these resources means one should work closely with the RPD vendor as not every RPD is the same. Further, some RPDs provide many more options than others including advanced testing capabilities.

What about PNM MIBs

Why don’t we use CableLabs’ PNM MIBs to communicate with the RPD?

If you are wondering why I have not mentioned the many CableLabs’ PNM MIBs, which define how to perform functions such as upstream spectrum analysis, sweep, etc., in the CM-SP-R-PHY specification, it’s because large operators have not requested these features as of yet. We live in a world of supply and demand and so far, operators are not demanding PNM or MIB-based software solutions (although I feel 98% of this could be done with a software based solution today). Large operators are currently driving demand for hardware return path monitoring and hardware-based sweep solutions.

Hardware-based solutions requiring a field tech with a meter have been the easiest solution to deploy and adopt for operators that are the early adopters of R-PHY nodes. This in turn has directed RPD vendors to focus on enabling solutions to support hardware-based solutions and thus on OOB.

Currently there are no RPD vendors who indicate that operators are driving CableLabs’ PNM MIBs in North America, however some European operators appear to be more skeptical of OOB and I will likely follow up on this article with further information.

Future Hurdles

Orthogonal frequency division multiple access (OFDMA) is the upstream version of orthogonal frequency division multiplexing (OFDM) in the downstream. When enabled in the upstream for DOCSIS 3.1 modems, the channel bandwidth will be much wider than any DOCSIS 3.0 upstream channel today. Further, OFDMA will have subcarrier spacing of 25 kHz or 50 kHz, making ingress detection or impairment detection under the subcarrier quite difficult compared to legacy SC-QAM channels. This will require triggering on individual modems and having the ability to briefly disable and enable individual (or groups of) subcarriers to identify ingress or the abiltity to know when no modems are transmitting in the upstream. This is not possible with a free-running return path spectrum analyzer, unless the CCAP scheduling is able to be used to establish modem transmit “quiet times” so that the noise floor under the OFDMA signal can be seen.

Some vendors I spoke with are aware of this while others have not considered the implications. Of the vendors aware of the challenge only one is working on PNM OOB integration at this point in time, but I am certain this will be on the radar for all very soon.

I reached out to several sources (operators and vendors) for this article and I would like to acknowledge the following vendors for their support by providing information and interviews for this article in alphabetical order: Cisco, Harmonic, Intel, and Vector. I unfortunately didn’t hear back from everyone by the time this article was due.

---

Brady S. Volpe
brady.volpe@volpefirm.com
Brady Volpe is Founder of The Volpe Firm, Inc and Nimble This LLC. He has over 25 years of broadband cable and telecommunications industry experience specializing in RF, DOCSIS, PNM, and Internet Protocol. Mr. Volpe has been providing a wide range of troubleshooting, design solutions, services and seminars for cable operators and broadband companies specializing in DOCSIS, System Design, PNM, and Troubleshooting. He is a highly respected published speaker, both domestically and internationally. He also hosts a popular industry YouTube and Podcast – “Get Your Tech On“.  Mr. Volpe holds a BSEE and a MSEE.

---

Image: Shutterstock.com