10G Integrity: The DOCSIS® 4.0 Specification and Its New Authentication and Authorization Framework
One of the pillars of the 10G platform is security. Simplicity, integrity, confidentiality and availability are all different aspects of Cable’s 10G security platform. In this work, we want to talk about the integrity (authentication) enhancements, that have been developing for the next generation of DOCSIS® networks, and how they update the security profiles of cable broadband services.
DOCSIS (Data Over Cable Service Interface Specifications) defines how networks and devices are created to provide broadband for the cable industry and its customers. Specifically, DOCSIS comprises a set of technical documents that are at the core of the cable broadband services. CableLabs manufacturers for the cable industry, and cable broadband operators continuously collaborate to improve their efficiency, reliability and security.
With regards to security, DOCSIS networks have pioneered the use of public key cryptography on a mass scale – the DOCSIS Public Key Infrastructure (PKIs) are among the largest PKIs in the world with half billion active certificates issued and actively used every day around the world.
Following, we introduce a brief history of DOCSIS security and look into the limitations of the current authorization framework and subsequently provide a description of the security properties introduced with the new version of the authorization (and authentication) framework which addresses current limitations.
A Journey Through DOCSIS Security
The DOCSIS protocol, which is used in cable’s network to provide connectivity and services to users, has undergone a series of security-related updates in its latest version DOCSIS 4.0, to help meet the 10G platform requirements.
In the first DOCSIS 1.0 specification, the radio frequency (RF) interface included three security specifications: Security System, Removable Security Module and Baseline Privacy Interface. Combined, the Security System plus the Removable Security Module Specification became Full Security (FS).
Soon after the adoption of public key cryptography that occurred in the authorization process, the cable industry realized that a secure way to authenticate devices was needed; a DOCSIS PKI was established for DOCSIS 1.1-3.0 devices to provide cable modems with verifiable identities.
With the DOCSIS 3.0 specification, the major security feature was the ability to perform the authentication and encryption earlier in the device registration process, thus providing protection for important configuration and setup data (e.g., the configuration file for the CM or the DHCP traffic) that was otherwise not protected. The new feature was called Early Authorization and Encryption (EAE), it allows to start Baseline Privacy Interface Plus (BPI) even before the device is provisioned with IP connectivity.
The DOCSIS 3.1 specifications created a new Public Key Infrastructure *(PKI) to handle the authentication needs for the new class of devices. This new PKI introduced several improvements over the original PKI when it comes to cryptography – a newer set of algorithms and increased key sizes were the major changes over the legacy PKI. The same new PKI that is used today to secure DOCSIS 3.1 devices will also provide the certificates for the newer DOCSIS 4.0 ones.
The DOCSIS 4.0 version of the specification introduces, among the numerous innovations, an improved authentication framework (BPI Plus V2) that addresses the current limitations of BPI Plus and implements new security properties such as full algorithm agility, Perfect Forward Secrecy (PFS), Mutual Message Authentication (MMA or MA) and Downgrade Attacks Protection.
Baseline Privacy Plus V1 and Its Limitations
In DOCSIS 1.0-3.1 specifications, when Baseline Privacy Plus (BPI+ V1) is enabled, the CMTS directly authorizes a CM by providing it with an Authorization Key, which is then used to derive all the authorization and encryption key material. These secrets are then used to secure the communication between the CM and the CMTS. In this security model, the CMTS is assumed trusted and its identity is not validated.
The design of BPI+ V1 dates back more than just few years and in this period of time, the security and cryptography landscapes have drastically changed; especially in regards to cryptography. At the time when BPI+ was designed, the crypto community was set on the use of the RSA public key algorithm, while today, the use of elliptic-curve cryptography and ECDSA signing algorithm is predominant because of its efficiency, especially when RSA 3072 or larger keys are required.
A missing feature in BPI+ is the lack of authentication for the authorization messages. In particular, CMs and CMTS-es are not required to authenticate (i.e., sign) their own messages, making them vulnerable to unauthorized manipulation.
In recent years, there has been a lot of discussion around authentication and how to make sure that compromises of long-term credentials (e.g., the private key associated with an X.509 certificate) do not provide access to all the sessions from that user in the clear (i.e., enables the decryption of all recorded sessions by breaking a single key) – because BPI+ V1 directly encrypts the Authorization Key by using the RSA public key that is in the CM’s device certificate, it does not support Perfect Forward Secrecy.
To address these issues, the cable industry worked on a new version of its authorization protocol, namely BPI Plus Version 2. With this update, a protection mechanism was required to prevent downgrade attacks, where attackers to force the use of the older, and possibly weaker, version of the protocol. In order to address this possible issue, the DOCSIS community decided that a specific protection mechanism was needed and introduced the Trust On First Use (TOFU) mechanism to address it.
The New Baseline Privacy Plus V2
The DOCSIS 4.0 specification introduces a new version of the authentication framework, namely Baseline Privacy Plus Version 2, that addresses the limitations of BPI+ V1 by providing support for the identified new security needs. Following is a summary of the new security properties provided by BPI+ V2 and how they address the current limitations:
- Message Authentication. BPI+ V2 Authorization messages are fully authenticated. For CMs this means that they need to digitally sign the Authorization Requests messages, thus eliminating the possibility for an attacker to substitute the CM certificate with another one. For CMTS-es, BPI+ V2 requires them to authenticate their own Authorization Reply messages this change adds an explicit authentication step to the current authorization mechanism. While recognizing the need for deploying mutual message authentication, DOCSIS 4.0 specification allows for a transitioning period where devices are still allowed to use BPI+ V1. The main reason for this choice is related to the new requirements imposed on DOCSIS networks that are now required to procure and renew their DOCSIS credentials when enabling BPI+ V2 (Mutual Authentication).
- Perfect Forward Secrecy. Differently from BPI+ V1, the new authentication framework requires both parties to participate in the derivation of the Authorization Key from authenticated public parameters. In particular, the introduction of Message Authentication on both sides of the communication (i.e., the CM and the CMTS) enables BPI+ V2 to use the Elliptic-Curves Diffie-Hellman Ephemeral (ECDHE) algorithm instead of the CMTS directly generating and encrypting the key for the different CMs.Because of the authentication on the Authorization messages, the use of ECDHE is safe against MITM attacks.
- Algorithm Agility. As the advancement in classical and quantum computing provides users with incredible computational power at their fingertips, it also provides the same ever-increasing capabilities to malicious users. BPI+ V2 removes the protocol dependencies on specific public-key algorithms that are present in BPI+ V1. , By introducing the use of the standard CMS format for message authentication (i.e., signatures) combined with the use of ECDHE, DOCSIS 4.0 security protocol effectively decouples the public key algorithm used in the X.509 certificates from the key exchange algorithm. This enables the use of new public key algorithms when needed for security or operational needs.
- Downgrade Attacks Protection. A new Trust On First Use (TOFU) mechanism is introduced to provide protection against downgrade attacks – although the principles behind TOFU mechanisms are not new, its use to protect against downgrade attacks is. It leverages the security parameters used during a first successful authorization as a baseline for future ones, unless indicated otherwise. By establishing the minimum required version of the authentication protocol, DOCSIS 4.0 cable modems actively prevent unauthorized use of a weaker version of the DOCSIS authentication framework (BPI+). During the transitioning period for the adoption of the new version of the protocol, cable operators can allow “planned” downgrades – for example, when a node split occurs or when a faulty equipment is replaced and BPI+ V2 is not enabled there. In other words, a successfully validated CMTS can set, on the CM, the allowed minimum version (and other CM-CMTS binding parameters) to be used for subsequent authentications.
In this work we provided a short history of DOCSIS security and reviewed the limitations of the current authorization framework. As CMTS functionality moves into the untrusted domain, these limitations could potentially be translated into security threats, especially in new distributed architectures like Remote PHY. Although in their final stage of approval, the proposed changes to the DOCSIS 4.0 are currently being addressed in the Security Working Group.
Member organizations and DOCSIS equipment vendors are always encouraged to participate in our DOCSIS working groups – if you qualify, please contact us and participate in our weekly DOCSIS 4.0 security meeting where these, and other security-related topics, are addressed.
Cable’s 10G Platform to Provide Synchronization for 5G
Cable service providers operate an extensive hybrid fiber coax (HFC) infrastructure to serve residential and business fixed broadband. In recent weeks, the world witnessed how cable networks around the globe have withstood the test of a dramatic surge in capacity demand due to the work-from-home (WFH) and other xFH practices induced by COVID-19 pandemic and are holding up extremely well.
As the economy opens again and 5G deployments resume, a large part of the time lost due to the COVID-19 pandemic can be regained by leveraging the extensive wireline networks to transport the mobile 5G traffic, be it fronthaul, midhaul or backhaul (collectively termed “xhaul”) between the radio units (RUs) or Base Stations (BSs) and the RAN Infrastructure. A critical impediment that stood in the way of leveraging the ubiquitous HFC infrastructure was the inability to provide timing and synchronization to the radio units which is crucial to their operation.
For nearly two years, the CableLabs Mobile Xhaul vendor and operator team has been working on equipping the DOCSIS® technology to provide better xhaul for mobile traffic.
Today, we are happy to announce the publication of the first release of the Synchronization Techniques for DOCSIS Technology Specification. When coupled with the Low Latency Xhaul Specification (LLX) standardized last year, which specifies requirements to reduce the latency on the DOCSIS network for mobile traffic, the two together provide the performance needed for DOCSIS network to xhaul mobile traffic. The ubiquity of the HFC plant will greatly assist the economic and timely deployment of these new 5G radios.
Synchronization Over DOCSIS Network
The mobile network is synchronous by design and requires the sharing of a common clock. This is achieved in practice by means of the radios and “their controllers” connecting to the Global Navigation Satellite System (GNSS). This works well for outdoor macro deployments. For small cell deployments, especially indoors, more often than not GPS signals are either not available or not economical. Instead, an equivalent global clock signal is transported over the IP network using precision time protocol (PTP), specified in the IEEE 1588-2008 family of specifications.
Transporting PTP over the DOCSIS network is particularly challenging due to the asymmetrical nature of the DOCSIS network. Leveraging the DOCSIS Time Protocol (DTP) to address the asymmetry issue offers a practical solution. A high-level architecture of the solution framework is illustrated in the figure below (technical details can be obtained in this SCTE white paper). DTP was invented back in 2011 and incorporated into the DOCSIS 3.1 specifications in 2013. In the newly issued SYNC specification, the Mobile Xhaul team updated the DTP profiles, defined timing system architectures and specified requirements on the DOCSIS network equipment to make PTP work end-to-end. As a result, the DOCSIS specification when bolstered with the newly issued SYNC spec and the LLX spec, is capable to support the LTE and 5G timing requirements.
The Mobile Xhaul team invites cable and mobile operators as well as vendors to provide input to these latest set of specifications. Several HFC equipment vendors have already demonstrated the feasibility of DTP in various proof of concept (PoC) implementations. In the upcoming months, our team will complete additional requirements and timing architectures.
Soon, cable MSOs will be upgrading their HFC plants to the distributed access architecture (DAA). DAA nodes are already PTP-compatible, as PTP is needed for the R-PHY device and the CMTS core to be on the same timing island. The MSOs and cable equipment vendors are better off designing their new network architectures with mobile requirements in mind and ensure that the DAA nodes can support the 1.5µs of end-to-end timing requirement needed for LTE and majority of the 5G deployments as specified in the SYNC spec.
We are excited to offer the ability of the DOCSIS technology to provide reliable and precision timing services. This will aid the ubiquitous HFC wireline network to become an obvious choice for the mobile operators as a low CAPEX and fast-to-deployment xhaul solution. We are working hard to converge the 10G and the 5G technologies, and SYNC is one of the areas that has come to fruition.
We acknowledge the tremendous efforts of the Mobile Xhaul team in driving these specifications to a timely publication, specifically those who did heavy lifting in the SYNC spec: John Chapman (Cisco), Elias Chavarria Reyes (Cisco), Peter Meyer (Microchip) and Yair Neugeboren (CommScope).
The 10G Converged Optical Network
Those of you who’ve heard me speak on the topic of Point-to-Point (P2P) Coherent Optics have probably noticed that I’ve placed this technology in the context of the cable industry’s move to Distributed Access Architectures, and as a result, the dramatic change in the way networks are architected. It’s a change that I would argue is as dramatic as the move from single-direction all-coax networks to bidirectional hybrid-fiber coax (HFC) networks that occurred a couple of decades ago. And it’s a change that enables a range of new services and business opportunities.
The cable industry’s roadmap to the 10G Platform is making that change—and its implications—clearer.
As most followers of these blogs are likely aware, the majority of today’s cable systems leverage an HFC network with analog optics: RF signals are generated in a hub or headend, converted to optical, then converted back to electrical at a fiber node for distribution over coax to the home. Broadband service over that network is provided via a DOCSIS® cable modem termination system (CMTS) at the hub or headend, working with a DOCSIS cable modem in a customer’s home; the cable modem provides customers with access to high-speed Ethernet network connections via coax. As a result, high-speed data transmissions over a cable operator’s network are generally only accessible via DOCSIS cable modems connected to the coax portion of the network rather than the fiber portion.
However, that’s now changing.
Although it can take many forms, it’s often assumed that the Aggregation Node with a Coherent Termination Device depicted here (which is expected to sit where a Fiber Node resides today) would be an Ethernet switch. This has dramatic implications for how this network can be leveraged: There’s now a fiber-based Ethernet connection point deep in the network with 100 Gbps or more of capacity and very low latency.
In essence, the cable operator’s core Ethernet network has been expanded deep into the field. Just about anything can be attached to it. And with high capacity and low latency, a host of potential new service offerings becomes possible.
Figure 1 makes just this point: Not only does it depict a Distributed CCAP device (such as a Remote PHY or MACPHY device) connected to the network, but also a Remote OLT, a mobile base station, a fixed wireless access point and a direct enterprise connection. And that’s only a sampling of the nearly endless possibilities, because everything is converged onto a single, high-speed, low-latency, high-reliability fiber Ethernet network.
That’s ultimately what the 10G Converged Optical Network is about: not just providing a network that supports today’s or even tomorrow’s known services but also providing the network on which to enable all sorts of innovative new services that no one has even thought of yet. P2P Coherent Optics—and the move to Distributed Access Architectures—is a key enabler of that.
The various pieces required to support this new reality are starting to come into place: Remote PHY devices are being deployed, and interoperable P2P Coherent Optics technology has been demonstrated, with new equipment to support outdoor deployments expected in the not-too-distant future. If you have new and innovative ideas for ways in which to leverage this emerging new network, please use the contact form below. We’d love to hear from you. Otherwise, keep watching for these blogs to see how things progress.
The Path to 10G: 2020 Update
The future of connectivity holds technical enhancements that are meant to change the way we live, work, learn and play. A fully realized connected network that enables all the different use cases and provides ubiquitous coverage through a seamless experience will need to rely on multiple access technologies and choices. Seeing this paradigm shift in the future of connectivity, the broadband industry came together to announce the 10G Platform in January 2019, led by CableLabs, SCTE•ISBE, NCTA and GIGAEurope. 10G will enable broadband connectivity with higher connection speeds, lower latency, higher reliability and increased security, and it also will enable and complement other access technologies.
Today, DOCSIS 3.1 technology enables the cable industry to offer 1 Gbps service to 80% of U.S. households. Just one year after the announcement of 10G, we have made some exciting progress towards this milestone in just 12 months.
As we march towards the frontier of 10G, new cable modems already being certified are capable of 5 Gbps capacity, with integrated standard 2.5 Gbps Ethernet ports that make it easier to distribute that capacity throughout the home. With full duplex and extended spectrum capabilities integrated into next-generation DOCSIS 4.0 technology, the industry will be able to deliver on that 10 Gbps promise over hybrid fiber coax networks.
The 10G optical network (Figure 1), is the backbone of the distributed access architecture and will provide the industry with opportunities for true service convergence that leverages the flexibility and tremendous capacity provided by fiber optics.
Figure 1: The 10G converged optical network
This year, CableLabs released an update to the 100 Gbps point-to-point coherent optics specification and released a new 200 Gbps specification – both intended to support the aggregation requirements of the distributed access architecture. While operators currently deploy 10G passive optical network technology (PON) where fiber to the premise is preferred, the IEEE standard for next-generation 25G-PON and 50G-PON technology remains on track for mid-2020 completion.
Lower latency is an important network characteristic that is quickly becoming a key service differentiator for connectivity, especially when considering delivering top cloud gaming or telemedicine experiences. This year, CableLabs and industry partners completed the DOCSIS specification updates to include Low Latency DOCSIS (LLD), a technique allowing traffic that requires low latency to transit the HFC network in just 1-2ms. Implementation of this technology quickly ramped up with seven vendors attending the LLD interoperability events.
Additionally, as part of the convergence of HFC networks with 5G networks, latency becomes critical when looking to use HFC as the transport layer. In 2019, we trialed two new technologies that enable mobile deployments over DOCSIS networks:
- Low Latency Xhaul pipelines DOCSIS bandwidth requests from mobile base stations, and was trialed and showed average DOCSIS network latency below 2ms.
- We also lead a trial of the TIP vRAN Fronthaul project, which is vRAN fronthaul designed to handle DOCSIS network latencies up to 30ms.
Another key pillar of the 10G Platform is security, to which we have dedicated significant efforts over the last year, advancing four leading technologies:
- Transparent Security uses the programmable data plane inside the access network to perform in-band telemetry and traffic processing. This increases protection against distributed denial of service attacks and provides flexibility to the network operator in active defense techniques.
- Device Onboarding makes good on the 10G promise by requiring easy and secure onboarding and provisioning of devices connecting to the platform made possible through strong device identity credentials and lifecycle management.
- Endpoint Identity provides unique, immutable, and attestable identities for networked devices. Strong device identity provides the trust framework to enable all other security controls, making it fundamental for securing the 10G Platform.
- Network Independent Credentialing, an essential part of 10G security, allows for authentication and risk management across access networks. Supporting this vision, Release 2 of the CBRS-A specifications included CableLabs’ work on Extended Credentials Authentication Framework (TS-1003) which extends the possibility to authenticate to CBRS-A Networks with different types of credentials – e.g., X.509 Digital Certificates. Building on that, the work is now focused on providing a common credentials management framework that can be integrated across the 10G platform (EAP-CREDS).
Proactive network maintenance (PNM) has long been a key element to increasing the reliability of the HFC network and providing an excellent quality of experience for cable service subscribers, and it is no different with 10G. This year CableLabs has a more robust portfolio of PNM activities than ever before. By measuring key “health” parameters from millions of cable modems, operators are able to create solutions on the Pro Ops platform to solve problems before customers experience any degradation in service.
Our PNM accomplishments extend to Wi-Fi where CableLabs led the pursuit of establishing a standard set of health metrics and their reporting format for Wi-Fi networks – now officially called Wi-Fi CERTIFIED Data Elements– to optimize residential Wi-Fi networks. Soon, PNM for cable industry optical networks will integrate seamlessly with traditional industry network health solutions.
In addition to PNM, we have delivered Dual Channel Wi-Fi™, which enables a 10G reliable Wi-Fi connection by ensuring optimized delivery of data services used in video, gaming, large file downloads, and time-sensitive services like video conferencing. A Dual Channel Wi-Fi reference implementation is currently available to the operators and vendors.
Looking into 2020
The connectivity catalyst of the future needs to occur across many spaces, including cyberspace, geospace, and electromagnetic space and it will all be coming to you in a virtualized cloud-native form. Technologies need to evolve to meet the vision through cost-effective solutions; wired, wireless, fixed, mobile, terrestrial, satellite, HAPS, unlicensed, licensed, low-band, high band, low-speed, high-speed, will all play a role to meet the demand of humans and things.
Over the past year, the industry has worked to create and introduce technologies that bring us one step closer to the promise of a 10G network, and are excited by the progress we have made. At CableLabs, we are excited about 10G and are actively involved with 5G, IEEE, and many other industry forums which are also working on advancing the future of connectivity.
The March to Budget-Friendly vRAN Continues!
As with most of my recent blog posts, I’m here to share some exciting updates on the work that CableLabs has been doing in the Telecom Infra Project (TIP) with virtualized RAN for non-ideal transport networks—for example, DOCSIS networks, passive optical networks (PONs) and really anything not on dedicated fiber. Over the past 6 months or so, we’ve reached some milestones that are worth a blog post blast. I’m going to keep each update brief, but please follow the links to dig in further where you’re interested.
TIP vRAN Fronthaul White Paper #2
On November 13, TIP’s vRAN Fronthaul Project Group is releasing a white paper discussing the results of Phase 1 of the project. The paper covers the combined learnings from the four Community Lab efforts led by Airtel, BT, CableLabs and TIM. We also include some key takeaways with which operators can assess the network assets that can be used in future vRAN deployments. You can find the paper here.
TIP Summit vRAN Fronthaul Demo
Also this week, the vRAN Fronthaul team has assembled a demo for TIP Summit ’19 in Amsterdam. The demo is showing the newly containerized multi-vendor vRAN solution running two remote radios (RUs) from a single CU/DU virtual baseband unit. In the LTE software stack, the Layer 2 and 3 containers come from Altran, and the Layer 1 container comes from Phluido, with RUs from Benetel. The containerized setup increases CPU efficiency by over 80 percent relative to our previous virtual machine–based architecture. If you’re in Amsterdam at TIP Summit, be sure to stop by the vRAN stand on the show floor.
TIP vRAN Fronthaul Trial with Shaw Communications
In July of this year, Shaw Communications, CableLabs and TIP collaborated to trial the vRAN Fronthaul LTE solution from Altran, Benetel, and Phluido over the Shaw commercial grade DOCSIS networks. In a fantastic result, we were able to demonstrate the ability of the Shaw DOCSIS networks to support Option 7-2 split fronthaul traffic for LTE services. In addition, we replicated all of our lab findings over the Shaw DOCSIS networks, validating the ability of our lab results to transfer to real world networks. “The trial demonstrated that Shaw’s hybrid fibre coaxial FibrePlus network is well positioned to support not only existing wireless services but the significant densification coming with the deployment of 5G,” said Damian Poltz, Vice President, Technology Strategy and Networks, Shaw Communications.
O-RAN Specification Includes Non-Ideal Fronthaul
While the team was busy hitting all these milestones in the TIP vRAN Fronthaul project, during the first half of the year CableLabs also led a collaborative effort to bring non-ideal fronthaul support to the O-RAN Alliance CUS plane specification. As of July, the 2.0 version of the CUS plane specification now includes support for non-ideal fronthaul with latencies up to 30ms over a common Option 7-2 interface. In addition, a new appendix was added to provide further detail on the implementation and operational specifics of deploying the lower-layer split over non-ideal transport such as DOCSIS networks, PON or managed Ethernet.
You can find out more by clicking the link below.
A Major Leap Toward 10G: CableLabs to Complete DOCSIS® 4.0 Specification in Early 2020
In a continuing effort to meet the industry’s recently announced 10G goal, CableLabs is wrapping up the first major update to its DOCSIS specification since DOCSIS 3.1. DOCSIS 4.0 technology will enable the next generation of broadband over cable’s existing hybrid fiber coax (HFC) networks, delivering symmetrical multi-gigabit speeds while supporting high reliability, high security and low latency.
What is DOCSIS 4.0 Technology?
Building on the success of DOCSIS 3.1 technology, which the cable industry is leveraging globally to deliver 1 Gbps services to end users, DOCSIS 4.0 technology supports a rich and flexible feature set of capabilities. The technology will enable multiple system operators (MSOs) to deliver on the 10G vision and includes support for Extended Spectrum DOCSIS (ESD) and Full Duplex DOCSIS (FDX) capabilities. These are complementary technologies that jointly or individually represent key elements to deliver on the 10G promise. By supporting these technologies, cable operators can deliver a richer feature set of capabilities and facilitate a cost-effective upgrade to a better, faster and more efficient network.
- Full Duplex DOCSIS Capabilities
FDX DOCSIS technology allows for concurrent use of spectrum for both upstream and downstream traffic, thus doubling the network efficiency by leveraging the HFC network characteristics, self-interference cancellation technology and intelligent scheduling. DOCSIS 4.0 technology is also backwards compatible with previous generations of DOCSIS technologies.
- Extended Spectrum DOCSIS
With ESD, operators can leverage a lot more usable spectrum on their existing HFC networks—up to 1.8GHz. That’s 600MHz more than the 1.2GHz available to them under the current DOCSIS 3.1 standard. The DOCSIS 4.0 working groups are in full swing, focusing on developing and adding the ESD requirements to the DOCSIS 4.0 specifications.
This boost in capacity provided by DOCSIS 4.0 technology will enable MSOs to provide multi-Gbps symmetric services to residential and business customers, and support the next generation of user experiences such as immersive media experiences in addition to serving as a catalyst for a new wave of innovations.
DOCSIS 4.0 technology is a major step toward reaching the industry’s 10G goal. You can learn more about the road to 10G and its technologies here. If you’re near New Orleans or attending the SCTE Cable-Tech Expo next week, register for our vendor forum, Envision, to get the exclusive opportunity to learn about the technologies the industry is working on. At Envision, which will take place on September 30, you can expect to hear updates about DOCSIS 4.0 technology and 10G, including how 10G will enable mobile and wireless networks.
Gearing Up for 10G: Download the Technical Brief on CableLabs’ Low Latency Technologies for DOCSIS Networks
If you’ve been following our blog and our recent 10G announcement, you know that one of the main areas of focus for us is latency. Achieving a near-zero latency on DOCSIS networks is one of the goals of the 10G initiative and is just as important as increasing speed or bandwidth. The success of future 10G networks that can support seamless communication and next-level interactive experiences like holodecks and 360° video is heavily dependent on finding technological solutions that decrease latency to imperceptible levels, delivering consistent, real-time responsiveness that our customers desire.
The good news is we are well on our way to getting there. So far we’ve released a number of specifications, including Low Latency DOCSIS (LLD) and Low Latency Mobile Xhaul (LLX), aimed at reducing latency in the DOCSIS networks that provide residential services and also serve as backhaul, midhaul and fronthaul (collectively known as xhaul) for mobile traffic.
Low Latency DOCSIS (LLD)
In modern households, there are often multiple applications and devices connected to the same network at the same time, sending and receiving a variety of traffic. Some, like streaming video and large file downloads, send repeated large bursts of data and expect the network to buffer and play-out those bursts, while others, like online gaming and voice chat, send traffic smoothly. Ordinarily, the traffic from the smooth senders is subjected to the widely varying buffering latency caused by the bursty senders. LLD technology is optimized for these two different types of traffic behavior, and decreases delays for smooth sending applications (many of which are latency-sensitive) without affecting the other traffic. Low Latency DOCSIS technology can support a consistent sub-1ms latency round-trip for the smooth sending applications, resulting in a much better network performance overall.
Low Latency Mobile Xhaul (LLX)
LLX leverages collaboration between the mobile network scheduler and the DOCSIS scheduler to provide a low latency xhaul solution that achieves a consistent DOCSIS upstream delay of just 1 to 2 milliseconds. LLX also defines a common quality of service framework for both mobile and DOCSIS so that the relative priorities of different traffic streams are maintained across the two systems. In the foreseeable future, deploying LLX technology will help solidify DOCSIS cable networks as the xhaul transport of choice, capable of supporting the latency requirements of 5G and beyond.
For more detail, please download the following member-only technical brief on Low Latency Technologies for DOCSIS Networks which includes information about sources of latency, how we address them, implementation strategies and more.
If you’re not yet a CableLabs member, find out how you can become one here.
CoMP over DOCSIS: Femtocells in the Age of vRAN
As promised in the last couple blogs discussing DOCSIS based femtocells, we’ve saved the best for last. So far in the series, we’ve made the case for femtocells over DOCSIS networks and laid out the total cost of ownership (TCO) benefits of this deployment model. In this final blog post, I’ll share the results of some testing we’ve been doing at CableLabs on using Coordinated Multipoint (CoMP) to optimize femtocell performance in dense deployments.
Decluttering the Radio Signal
Let’s step back and look at a key issue that has limited the benefit of femtocells in the past: intercell interference. When femtocells (or any cells, for that matter) are placed in close proximity, the radio signals each cell site produces can bleed into its neighbor’s territory and negatively affect network performance.
With CoMP, neighboring cells can coordinate their transmissions in a variety of ways to work collaboratively and prevent interference. They can share scheduling and beamforming data to avoid creating interference. Or, they can use joint processing, which allows multiple cells to talk to a single cell phone at the same time, increasing the signal quality.
Although it’s not a perfect analogy, it’s a bit like trying to listen to a bunch of people singing their favorite song at the top of their lungs versus listening to a choir following a conductor, as you see in the following figure. The former is old femtocells, and the latter is virtualized RAN (vRAN) femtocells using CoMP.
Since its inception, CoMP has been largely believed to require fiber transport links to work. For example, in TR 36.819, there’s a whole section devoted to the impact of “higher latency communication between points,” where “higher” refers to 5ms, 10ms or 15ms of latency. In that text, gains decrease as latency increases, ultimately going negative (i.e., losses in performance).
However, with the increase in attention on vRAN, particularly lower-layer splits like the work going on in Telecom Infra Project (TIP) vRAN Fronthaul and O-RAN Alliance WG4, latency takes on new meanings with respect to CoMP.
For example, what matters more, the latency from one radio unit to another or the latency from one virtualized baseband unit (vBBU) to another? And if it’s the latter, does that mean CoMP can provide benefit even over long-latency non-ideal vRAN fronthaul like DOCSIS?
To find out the answers to these questions, we set up a test bed at CableLabs in collaboration with Phluido to explore CoMP over DOCSIS. We used the hardware from the TIP vRAN Fronthaul project, with an LTE SW stack provided by Phluido that supports CoMP. We installed two radio units in different rooms, each radio connected via a DOCSIS® 3.0 network to the vBBU. We designated two test points, one with a phone located at the cell center, the other with both phone in the cell edge/cell overlap region.
Notably in our setup, the latency from radio unit to vBBU and radio unit to radio unit were both about 10ms. However, the latency between vBBUs was essentially zero as both radios shared the same vBBU. This setup is specifically designed to test whether vBBU-to-radio latency or vBBU-to-vBBU latency is more important for CoMP gains.
What we found is that radio-to-radio latency and radio-to-vBBU latency can be quite large in absolute terms, and we can still get good CoMP performance provided that latency is low between the vBBUs and that vBBU-to-radio unit latency is similar for the radios in the CoMP cluster, as you see below.
In other words, to realize CoMP gains, the relative latency between a set of cells is more important than the absolute latency from vBBU to each radio.
We tested four configurations of phones at the cell center versus the cell edge, or some mix thereof, as the following figure shows.
In case 1, we see full cell throughput at each phone with CoMP enabled or disabled. This is great; this result shows that we haven’t lost any system capacity at the cell center by combining the cells into a single physical cell ID (PCI) and enabling CoMP.
In case 2, the phone throughput jumped from 55 Mbps to 78 Mbps when we enabled CoMP, showing a CoMP gain of almost 50 percent.
In case 3, when we enabled CoMP, the phone at the cell edge saw a throughput gain of 84 percent. In this scenario, the throughput of the cell center phone saw a decrease in throughput. This illustrates a tradeoff of CoMP when using legacy transmission modes (TM4, in this case) where the operator must choose whether it wants to favor cell edge users or cell center users. With more advanced transmission modes (e.g., TM10), this tradeoff is no longer an issue. Note that this is true of any CoMP deployment and not related to our use of DOCSIS network fronthaul.
In case 4, we expected to see significant gains from CoMP, but so far we haven’t. This is an area of further investigation for our team.
vRAN Femtocell CoMP in MDUs
Let’s look at an example use case. Cell service in multi-dwelling units (MDUs) can be challenging. A combination of factors, such as commercial construction materials, glazing and elevation, affect the indoor signal quality. As discussed in my previous blog, serving those indoor users can be very resource intensive.
As an operator, it would be great to have a low-cost way to deploy indoor cells. With vRAN over DOCSIS networks supporting CoMP, the operator can target femtocell deployments at heavy users, then build CoMP clusters (i.e., the set of radios that collaborate) as needed to optimize the deployment.
Putting It All Together
The testing described here has shown that CoMP gains can be realized even when using long-latency fronthaul over DOCSIS networks. As these solutions mature and become commercial-ready, deployments of this type will provide the following for operators:
- Low-Cost Hardware: vRAN radios, particularly for femtocells, are low-complexity devices because the majority of the signal processing has been removed and put in the cloud. These radios can be built into the gateway customer premises equipment (CPE) already deployed by operators.
- Low-OPEX Self Installs: With vRAN radios built into DOCSIS CPEs, operators can leverage the simplicity of self-installation. The ability to dynamically reconfigure CoMP clusters means that detailed RF planning and professional installation aren’t necessary.
- High-Performing System: As shown in our testing results, CoMP gains can be realized over DOCSIS network–based vRAN femtocells. This eliminates another of the previous stumbling blocks encountered by earlier femtocell deployments.
Enabling 5G with 10G Low Latency Xhaul (LLX) Over DOCSIS® Technology
I am a GenXer, and I am addicted to my iPhone. But it’s not just me, today’s consumers, millennials and baby boomers and everyone in between, are increasingly spending more and more time on their mobile devices. Have you ever wondered what happens to your traffic when you interact with your iPhone or Android devices? The traffic reaches a radio tower, but it doesn’t just stop there – it needs to reach the internet via a connection between the cellular base station and a distant data center.
Traditionally, that connection (a.k.a., “xhaul”) is mostly provided by fiber. Fiber has great speed and latency performance but is costly to build. With advancements in LTE and 5G, mobile operators are increasingly deploying more and more radios deeper into the neighborhoods. They will need a more scalable solution to provide that xhaul without sacrificing the performance. This is where the hybrid fiber coaxial (HFC) network can help.
With ubiquitous cable infrastructures that are already in place, the cable operators have the scalability to support today’s LTE and tomorrow’s 5G networks without the cost of building new fiber networks. With DOCSIS 3.0+ as well as Low Latency Xhaul (LLX) technology, the DOCSIS network has performance that is virtually indistinguishable from fiber. The CableLabs 10G technologies make the HFC network a better xhaul network, which is a win-win for the consumers, mobile operators, and cable operators.
How Low Latency Xhaul (LLX) Works
Today’s DOCSIS technology provides a good starting point for mobile xhaul but may not be enough to support the ultimate latency requirements needed for future mobile traffic. DOCSIS upstream latency can range from a typical of 8-12 milliseconds to around a maximum of 50 milliseconds under heavy load. We want to see that latency down to 1 to 2 milliseconds range in order to support 5G.
The LLX technology is specifically designed to reduce the latency experienced by mobile traffic while traversing the DOCSIS transport network on its way to the internet. The LLX technology development started about 3 years ago as a joint innovation project between CableLabs and Cisco. I wrote about it here and here.
So, how does LLX work? Let’s look at the case of LTE backhauled over a DOCSIS network as an example. Today, LTE and DOCSIS are two independent systems – their operations occur in serial, and the overall latency is the sum of the two system latencies. But from an engineer’s point of view, both technologies have a similar request and grant-based mechanism to access the channel. If the two processes can be pipelined, then LTE and DOCSIS operations can take place in parallel, removing the “sum” from the latency equation. To enable pipelining, we designed a protocol that utilizes a message called the bandwidth report (BWR) that allows the LTE network to share information with the DOCSIS network. Pipelining is a unique and inventive aspect of LLX and is the heart of what creates a low latency transport.
So, just how well does LLX work? We have recently teamed up with Shaw, one of our Canadian members, as well as our technology development partners Cisco and Sercomm to perform a series of lab trials. The detail of the trials will be published in the upcoming SCTE Cable-Tec Expo in October. But as a preview, we demonstrated that even when the DOCSIS network is heavily loaded, LLX consistently reduced the DOCSIS upstream latency down to 1 to 2 milliseconds, all without adversely affecting other traffic.
Deploying LLX Technology
The LLX specification was published a few months ago, the result of collaborative efforts from key cable and mobile equipment vendors in the CableLabs-led LLX working group.
LLX technology is designed to work for a variety of deployment models, including backhaul and fronthaul, over DOCSIS as well as over PON networks. To this end, we have taken the technology to mobile industry standardization organizations such as the O-RAN Alliance whose current focus is fronthaul.
LLX works in the DOCSIS 3.0 and later networks as a software upgrade to the CMTS. It has been implemented on commercial DOCSIS and mobile equipment. More information on LLX is available here.
For those attending the SCTE Cable-Tec Expo in New Orleans, we will be discussing the innovation on the Innovation Stage at 12:45pm local time with my industry partners from Shaw, Cisco, and Sercomm. I will also dive deep into the technology and the Shaw trial results in my SCTE panel “Mobile X-haul and DOCSIS”, Wednesday October 2nd at 9am local time. Hope to see you there.
CableLabs Low Latency DOCSIS® Technology Launches 10G Broadband into a New Era of Rapid Communication
Remember the last time you waited (and waited) for a page to load? Or when you “died” on a virtual battlefield because your connection couldn’t catch up with your heroic ambitions? Many internet users chalk those moments up to insufficient bandwidth, not realizing that latency is to blame. Bandwidth and latency are two very different things and adding more bandwidth won’t fix the internet lag problem for latency-sensitive applications. Let’s take a closer look at the difference:
- Bandwidth (sometimes referred to as throughput or speed) is the amount of data that can be delivered across a network over a period of time (Mbps or Gbps). It is very important, particularly when your application is trying to send or receive a lot of data. For example, when you’re streaming a video, downloading music, syncing shared files, uploading videos or downloading system updates, your applications are using a lot of bandwidth.
- Latency is the time that it takes for a “packet” of data to be sent from the sender to the receiver and for a response to come back to the sender. For example, when you are playing an online game, your device sends packets to the game server to update the global game state based on your actions, and it receives update packets from the game server that reflect the current state of all the other players. The round-trip time (measured in milliseconds) between your device and the server is sometimes referred to as “ping time.” The faster it is, the lower the latency, and the better the experience.
Interactive applications, where real-time responsiveness is required, can be more sensitive to latency than bandwidth. These applications really stand to benefit from technology that can deliver consistent low latency.
As we’ve alluded, one good example is online gaming. In a recent survey we conducted with power users within the gaming community, network latency continually came up as one of the top issues. That’s because coordinating the actions of players in different network locations is very difficult if you have “laggy” connections. The emergence of Cloud gaming makes this even more important because even the responsiveness of local game controller actions depends on a full round-trip across the network.
Queue Building or Not?
When multiple applications share the broadband connection of one household (e.g. several users performing different activities at the same time), each of those applications can have an impact on the performance of the others. They all share the total bandwidth of the connection, and they can all inflate the latency of the connection.
It turns out that applications that want to send a lot of data all at once do a reasonably good job of sharing the bandwidth in a fair manner, but they actually cause latency in the network when they do it, because they send data too quickly and expect the network to queue it up. We call these “queue-building” applications. Examples are video streaming and large downloads, and they are designed to work this way. There are also plenty of other applications that aren’t trying to send a lot of data all at once, and so don’t cause latency. We call these “non-queue-building” applications. Interactive applications like online gaming and voice connections work this way.
The queue-building applications, like video streaming or downloading apps, get best performance when the broadband connection allows them to send their data in big bursts, storing that data in a buffer as it is being delivered. These applications benefit from the substantial upgrades the cable industry has made to its networks already, which are now gigabit-ready. These applications are also latency-tolerant – user experiences are generally not impacted by latency.
Non-queue-building applications like online gaming, on the other hand, get the best performance when their packets don’t have to sit and wait in a big buffer along with the queue-building applications. That’s where Low Latency DOCSIS comes in.
What is Low Latency DOCSIS 3.1 and how does it work?
The latest generation of DOCSIS that has been deployed in the field—DOCSIS 3.1—experiences typical latency performance of around 10 milliseconds on the access network link. However, under heavy load, the link can experience delay spikes of 100 milliseconds or more.
Low Latency DOCSIS (LLD) technology is a set of new features, developed by CableLabs, for DOCSIS 3.1 (and future) equipment. LLD can provide consistent low latency (as low as 1 millisecond) on the access network for the applications that need it. The user experience will be more consistent with much smaller delay variation.
In LLD, the non-queue-building applications (the ones that aren’t causing latency) can take a different path through the DOCSIS network and not get hung up behind the queue-building applications. This mechanism doesn’t interfere with the way that applications go about sharing the total bandwidth of the connection. Nor does this reduce one application's latency at the expense of others. It is not a zero-sum game; rather, it is just a way of making the internet experience better for all applications.
So, LLD gives both types of applications what they want and optimizes the performance of both. Any application that wants to be able to send big bursts of data can use the default “classic” service, and any application that can ensure that it isn’t causing queue build-up and latency can identify its packets so they use the “low latency” service. Both then share the bandwidth of the broadband connection without one getting preference over the other.
Incorporating LLD Technology
Deploying Low Latency DOCSIS in a cable operator’s network can be accomplished by field-upgrading existing DOCSIS 3.1 CMs and CMTSs with new software. Some of the low latency features are even available to customers with older (pre-DOCSIS 3.1) CMs.
The technology includes tools that enable automatic provisioning of these new services, and it also introduces new tools to report statistics of latency performance to the operator.
DOCSIS equipment manufacturers are beginning to develop and integrate LLD features into software updates for CMTSs and CMs, and CableLabs is hosting Interoperability Events this year and next year to bring manufacturers together to help iron out the technology kinks.
We expect these features to become available to cable operators in the next year as they prepare their network to support low latency services.
LLD provides a cost-effective means of leveraging the existing hybrid fiber-coaxial (HFC) network to provide a high-performance network for latency-sensitive services. These services will help address customers’ requirements for many years into the future, maximizing the investments that cable operators have made in their networks. The cable industry is provisioning the network with substantial bandwidth and low latency to take another leap forward with its 10G networks.
For those attending the SCTE Cable-Tec Expo in New Orleans, Greg will be presenting the details of this technology on a SCTE panel “Low Latency DOCSIS: Current State and Future Vision”