Today we are pleased to announce the release of the DOCSIS 4.0 specification, which incorporates both full duplex and extended spectrum capabilities. A part of the suite of technologies that support the 10G platform, DOCSIS 4.0 technology achieves a downstream speed of up to 10 Gbps (doubling the maximum download speed available with the implemented DOCSIS 3.1 technology) and an upstream speed of up to 6 Gbps - quadrupling what DOCSIS 3.1 technology could do. These speed increases build on the ample capacity deployed by cable operators today–with gigabit services nearly saturating the US cable footprint–and will enable cable broadband to deliver symmetric multigigabit services, with significantly enhanced upstream capabilities. As cable operators respond to the evolving connectivity needs of customers in our current public health crisis, remote work, learning, and health services stand to benefit from upstream broadband enhancements as DOCSIS 4.0 technology is deployed. 

Specification development started in August 2016. The full duplex capabilities were described in an October 2017 blog post, and now the extended spectrum capabilities have been completed as described in a September 2019 blog post.  

With these speed increases, we intend to change the consumer broadband industry by ushering in a new era of application development. Although speed numbers are important, broadband is about so much more than speed: it’s about changing the way we collaborate to make the world a better place. We have more devices, and our experiences increasingly rely on connectivity. Streaming video continues to explode. We’re video-chatting instead of making calls, we’re playing music off the web instead of our own media, and we’re playing games with people around the world. As technology continues to advance, we don’t know what the next trend will be, but we do know that the Internet will be central to whatever it is.

DOCSIS 4.0 Technology Increases Upstream Speed

A key piece of this story is the DOCSIS 4.0 multigigabit upstream capability, which greatly increases how fast information can be uploaded from your computer. Traditionally, businesses have required faster upload speeds to move large files around or to perform in-house web hosting. Now consumers are expecting more upstream speed as they work and learn from home. In addition, upstream speed is important to do things such as the following: 

• Hard drive backups
• Uploading videos and pictures
• Cloud applications
• Video conferencing
• Smart homes and IoT devices
• Home security cameras
• Distance learning and visual classrooms

These applications are just the beginning. The higher speeds available with DOCSIS 4.0 technology will serve as a catalyst for the next wave of innovations.

The 10G Platform

The DOCSIS 4.0 specification takes to heart the four pillars of the 10G platform initiative. Below are quick descriptions of these pillars, and links to more information. 

• Speed is addressed in this blog post. Multigigabit symmetric speeds raise the bar for consumer broadband.

• Lower latency was incorporated into the DOCSIS 3.1 specification and has been brought forward into the DOCSIS 4.0 specification. Lower latency will provide a better experience for consumers on applications such as online gaming and multimedia.

• Increased security comes with every new DOCSIS release. Our security experts are constantly monitoring network threats to the network and taking measures to increase the confidentiality, integrity and availability of communications.

• Higher reliability must be planned into the network and DOCSIS technology takes this to a new level by including methods to proactively identify and address network issues before consumers are even aware of them.

CableLabs continually makes advances in these areas and others, bringing state-of-the-art breakthroughs to cable broadband. 

Mapping Out the Next Steps for DOCSIS Technology 

Delivery of the specification is the first step of a three-part DOCSIS lifecycle. The second step includes interoperability events and the final step is certification, which will be discussed in future blog posts. These three steps—specification, interoperability and certification—have been part of the DOCSIS process for over 20 years and constitute a time-proven method to deliver high-speed, low-cost, interoperable cable modems to consumers. 

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.

Toward 10G

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.

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.

Latency-Sensitive applications   

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.

Next Steps

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”  Room: 243-244,  Monday, September 30, 2019: 3:30 PM - 4:30 PM”.  Hope to see you there!

Over the past year, a quiet revolution in broadband services has been happening, thanks to investments cable operators are making around the globe: gigabit services are available to tens of millions households for the first time ever. Already, over half of households in North America can buy a 1 Gbps service from their cable operator, and the percentage is growing rapidly. This shift is driven by a new technology making it economically feasible for operators to provide gigabit services in most areas. And the technology is not limited to a single gigabit – it is capable of much higher speeds over time.

The technology? DOCSIS® 3.1. This innovation is now being quickly deployed by operators.

While the broad availability of gigabit services may have escaped notice, there is even less awareness of the potential for DOCSIS technology to provide higher speeds. With existing DOCSIS specifications and comforming vendor gear, operators could use DOCSIS to:

• Provide shared, downstream capacity of over 15 Gbps
• True downstream speed tiers of 10 Gbps or more for individual households

How can DOCSIS provide that much speed?

The technology is actually already in the DOCSIS 3.1 specifications. However, getting to these speeds will require an evolution of DOCSIS silicon, along with some outside plant improvements. Here is the roadmap:

As you can see, the first generation of DOCSIS 3.1 silicon has been available for deployment for over a year, and it enables downstream speed tiers of roughly 1-2 Gbps. As demand materializes for higher speed tiers, operators may ask silicon providers for a second and third generation of DOCSIS 3.1 silicon. Each new silicon generation supports broader frequency ranges for DOCSIS, possibly up to the full DOCSIS 3.1 limit of about 1.8 GHz. At the 1.8 GHz range limit, over 1.5 GHz of spectrum can be used for downstream DOCSIS 3.1 channels. At 10 bits per Hertz that is more than 15 Gbps of total capacity.

Expanding Spectrum

Most operators are using 1 GHz of spectrum (or less) in their networks today. If an operator wanted to use spectrum as high as 1.8 GHz in a high-demand neighborhood it can push fiber to within 800 feet of many homes, and install taps that can pass the full 1.8 GHz of spectrum.

Thanks to the work of our CableLabs members, homes in the tens of millions are gaining access to 1 gigabit services for the first time ever. With more homes enjoying gigabit and even higher speeds, there will be a growing market for application developers and artists to develop immersive entertainment and interactive network services such as those in our Near Future video series. Radiologists working from home will be able to move massive files back and forth from medical centers. Grandparents will join their grandchildren in virtual family rooms for a game of virtual Uno. Immersive holographic movies will stream to a new generation of entertainment devices. And this is only the beginning.

If you have been yearning for a gigabit service at your home, check with your local cable operator – gigabit services may already be available to you. And, if you want to learn more about the DOCSIS roadmap to 10 Gigabit services, please subscribe to our blog.

The cable industry is always trying to find ways to improve service. When the cable industry made proactive network maintenance (PNM) a part of the DOCSIS® specifications, we showed great commitment to service. CableLabs supports that commitment through its work in specifications, and particularly through its PNM project.

This blog entry in our PNM series focuses on cable modem validation. Cable modem (CM) validation is the work to assure that the CMs can fully support PNM. When CMs can be assured to report data about impairments in the network, service providers have a tool for finding and fixing network issues before they impact service. CableLabs built the cable modem validation application (CMVA) to help bring that assurance to the industry.

Validating CM PNM functionality for DOCSIS 3.1 network deployments might seem like a small step in a large technology life cycle. But it’s an important step, and one we wish to highlight.

Why is it important to validate PNM data reporting from CMs?

• Continuous service improvement: Before deploying a technology, it is important to know ahead of time whether CMs will be capable of supporting network maintenance and troubleshooting. We never want to introduce a new technology that costs more to maintain than the previous. Ideally, a new technology will cost less to build, be less expensive to maintain, and provide superior service. PNM capabilities are an important part of this needed improvement. A consistent approach with CMs is the first step toward CMTS testing and having integrated PNM capabilities for the entire architecture.
• Getting ready for future technology evolutions: New DOCSIS 3.1 modems provide more information about the plant and its ability to support enhanced services and deploy new technologies like FDX. This capability can become an important source of information for all sorts of planning and engineering activities. It is a critical first step toward many possible futures for DOCSIS.
• Best practices we can share: With a consistent industry approach to PNM data reporting, collection, and certification testing of modems, everyone can validate and verify consistent reporting. Therefore, we can build best practice operation solutions on that strong foundation.

You can’t manage what you can’t measure, so having modems capable of reporting PNM measurements allows cable operators to manage their networks effectively, inexpensively, and reliably! 

Realize: It’s always too late to start thinking about reliability!

You can’t add in reliability as if it’s a separate feature. You need to design it into the system as early as possible for the lowest cost, or work it in later at a much higher cost. DOCSIS is a sophisticated system, especially 3.1 and Full Duplex DOCSIS. This complexity is why having PNM within the DOCSIS specification is an important move for the industry, supporting its ability to evolve. But, this is only a first step. We need to make sure these PNM capabilities work as intended in systems before we deploy and assure we can take full advantage of the capabilities once deployed.

The Common Collection Framework (CCF) and the Cable Modem Validation Application (CMVA)

CableLabs built two solutions that together help address this industry need:

1. The Combined Common Collection Framework (XCCF): The XCCF provides management of data requests to network elements, and provides the data to a REST API to support applications of all kinds. The CMVA, one of those applications, uses the data provided by the XCCF to validate modem performance in support of PNM. If you want to learn more about the XCCF, you can read the previous entry in our PNM blog series here, or access the public version of the architecture document here. We are building the future of the XCCF right now, so it’s a great time to get involved.
2. The Cable Modem Validation Application (CMVA): The CMVA allows any of us to test CMs for compliance to DOCSIS 3.1 specifications, specifically the PNM portions. The tests conducted are based on the Acceptance Test Plans (ATPs) supported here at CableLabs, specifically the DOCSIS 3.1 PHY and OSSI ATPs, based on the DOCSIS 3.1 specifications. But not only does CMVA provide concise test results based on these ATPs, but it provides nice graphical output (plots, tables) so you can visually confirm the results too. Sometimes what passes a specification is still not desirable or functional necessarily. Looking at the results is a great way to get introduced to the wealth of data available in DOCSIS 3.1 CMs, allowing the CMVA to be useful toward confirming specific results you may envision for your own PNM deployments. To facilitate that idea further, we are adding to the CMVA a few extra capabilities so that users can test additional PNM workflows, look for test anomalies, or further experiment with PNM capabilities.

We use it…

CableLabs and our subsidiary, Kyrio, are using the CMVA in our own CM certification testing. CableLabs will use it further to explore improved workflows for PNM, in support of the InGeNeOs Forum’s planned work on PNM Best Practices for DOCSIS 3.1 technology. Just like the XCCF is the foundation for a lot of PNM related capabilities, the CMVA is a step beyond and toward greater PNM capabilities that support low cost and high effectiveness in DOCSIS 3.1 network deployments.

…Others use it…

We envision a couple of important use cases for our partners.

• Vendors can use it to validate their modem for compliance to the PNM portions of the specifications, test chip capabilities, improve firmware, or explore potential PNM developments. We’re aware of a vendor using XCCF to test silicon, so, for example, the CMVA could be added to find issues and share them with their suppliers during design testing.
• MSOs can verify compliance in their own labs, develop CM builds that help them differentiate, and examine CM sensitivity and capability at PNM tasks and operations workflows. For example, if a particular modem is vulnerable to LTE ingress at the interface, a few lab tests might detect it before deploying the problem, and the CMVA would be one way to detect and display the problem.

…Wouldn't you like to use it too?

CMVA was designed specifically for Kyrio and CableLabs to use in certification testing of CMs, with vendors and members able to use it for their own equivalent needs. But, CMVA is well suited for exploring a lot of other needs. Thus, we look forward to working with you to get the full benefit from the XCCF, CMVA and all the CableLabs PNM developments completed and yet to be built.

If you first just want to learn more, please look for our demonstration video to be announced soon. When you are interested in gaining access or discussing it with me further, please feel free to contact me directly by clicking below.

In November, CableLabs announced the opening of our new Telecom Infra Project (TIP) Community Lab. Today, CableLabs joins TIP in releasing a whitepaper, making public deeper insights into the vRAN fronthaul interface under development in the TIP vRAN Fronthaul project group. With this new interface, the addressable market for virtualized RAN (vRAN) deployment architectures can grow significantly. This increased market is evidenced by the diverse set of use cases being sponsored by the growing set of operator-based TIP Community Labs.

With the release of the white paper, the project group highlights key milestones which have been reached, including agreements further defining the open API and a set of interoperability metrics to be used in validating the interface in multi-vendor configurations.

As the project continues, work on the CableLabs DOCSIS network vRAN fronthaul use case will take place at the CableLabs TIP Community Lab. We look forward to sharing more as we continue to check milestones off our list, so check back soon for updates.

You can find the whitepaper "Creating an Ecosystem for vRANs Supporting Non-Ideal Fronthaul v1.0." here. 

Last week, Craig Cowden (Charter), John Chapman (Cisco) and I jointly presented a webinar on improving latency for mobile backhaul over DOCSIS. Moderated by CableLabs’ Rob Alderfer, we:

• Discussed cable’s wireless strategy and business case for mobile backhaul
• Did a deep dive into the technical details on how our Bandwidth Report (BWR) proposal can reduce the DOCSIS latency to ~1ms to enable mobile backhaul.

More background on the BWR protocol and the joint development project between CableLabs and Cisco can be found in my blogs “Powering the Future of Mobile Backhaul” and “Enabling the Cable Networks for Mobile Backhaul.”

The webinar was attended by a record number of audiences from operators, equipment suppliers and members of the public. With a large amount of interest building from cable operators, we have gathered a group of CMTS and LTE vendors this week and began the standardization work on the BWR protocol. Please contact me if you are interested in joining the standardization group.

You can watch the replay of the webinar below

For those of you attending the Mobile World Congress, stop by the CableLabs booth 5J81, Hall 5. I am also holding a joint demo with John Chapman at the Cisco booth number 3E30, Hall 3.

With 5G and small cell densification on the near horizon, mobile networks need economically viable backhaul solutions. Cable operators are well positioned with fixed networks to bridge that gap, and many operate mobile networks themselves. Could we be on the verge of fixed-mobile network convergence? Things seem to be pointing in that direction, but it won’t happen without technology developments to make DOCSIS and LTE networks compatible.

A big element of this compatibility is aligning the typical network latency between DOCSIS and what is required for backhauling LTE. Today’s DOCSIS upstream access latency is higher than the allocated budget (Fig 1) and solving the latency problem is key to enabling cable networks for mobile backhaul.

Fig 1. DOCSIS latency today, vs. where we want to get to

Our solution: together is better

About a year ago, a lightbulb moment led to a solution which led to a joint project between CableLabs and Cisco that I wrote about last October. You can read about it here.

To recap, instead of operating as two independent networks, we want to coordinate the DOCSIS channel access procedure with information made available by LTE, so that the DOCSIS process can start while the LTE transactions are still going on. When two systems work hand-in-hand, we achieve better end-to-end latency. (Fig 2)

Fig 2. Pipelining LTE and DOCSIS operations

With the CableLabs team supplying expertise in mobile and John Chapman’s (Cisco Fellow and CTO Cable Access) team developing the pipelining API on the CMTS, we jointly built a proof-of-concept (PoC) using open source LTE small cells and the Cisco cBR-8 CMTS.

What we have been working on

Since my blog last October, we have been working on characterizing DOCSIS latency with increasing load on the DOCSIS channel. Using the pipelining method, the series of ping packets we sent from the User Equipment (UE) achieved an upstream latency of ~1-2 ms on the DOCSIS link (Fig 3). The latency remained consistent when we loaded up the DOCSIS link with other upstream traffic of up to ~60% of the channel capacity. Above this loading point, the latency gain with our pipelining method became more significant compared to no pipelining, albeit creeping above the 1-2 ms range.

Fig 3. Ping packets achieved ~1-2 ms of upstream latency on the DOCSIS link

At this point, skeptical readers might be wondering, what’s the penalty for sending the LTE scheduling information across the DOCSIS link? We coded our LTE scheduler to send a “Bandwidth Report” (BWR) messages every 1 ms. A 80-byte BWR message, therefore, incurs 640 kbps, a minute amount compared to DOCSIS speeds that are now in the multi-Gbps range.

On the other hand, it is possible that the data predicted by the LTE scheduler might not actually arrive at the DOCSIS link, causing under-utilization of the DOCSIS grants. So, how many DOCSIS grants are issued by the CMTS but are not used with the BWR method? We performed tests and observed a respectable number. We will be reporting more on the upcoming webinar (details see below).

We have also been working on a fronthaul setup. Initial results showed that more latency gains can be expected with BWR compared to backhaul. More on that later.

What’s next

• We have been demonstrating the proof of concept to CableLabs members since last summer. CableLabs and Cisco will once again hold a joint demo at the upcoming Mobile World Congress.
• The joint team is wrapping up the PoC work. We worked together on perfecting the pipelining operation and designing the new BWR message. We will take this baseline design to the CableLabs Mobile Backhaul Working Group that I am currently leading. Given the interest from CableLabs members, my goal is to get LTE and CMTS vendors together to agree on protocol and message details, so that cable operators can get the latency benefit regardless of which LTE and CMTS equipment they choose to deploy.
• Additionally, in building the PoC, we have accumulated expertise on how to perfect the BWR algorithm to optimally predict the amount of data and time egressed from the LTE side. We will pass this knowledge on to the LTE implementers during the specification work.

I am holding a webinar with John Chapman on Thursday, February 15^th at 8am Pacific / 11am Eastern / 5pm Central European Time. It is open to the public and we hope to see you there.

For those of you attending Mobile World Congress, I am holding a joint demo with John Chapman at the Cisco booth number 3E30, Hall 3 Hybrid Hall.

Full Duplex (FDX) DOCSIS® (now a part of DOCSIS 4.0 technology) is an update to DOCSIS 3.1 specifications that builds on the core Orthogonal Frequency Division Multiplexing (OFDM) technology. This additional set of features significantly increases upstream capacity and allows for the same spectrum to be used as downstream or upstream.

The set of MAC Layer technology changes to support FDX DOCSIS has now been incorporated into the next version of the DOCSIS 3.1 MULPI specification. This supports the PHY layer FDX functionality introduced last October. The new FDX DOCSIS capability and functions are introduced as changes across the MULPI (MAC and Upper Layer Protocols Interface) specification and is now an official part of the specification. This important milestone is the result of a great deal of work by CableLabs members, vendors and employees during the past year, and we take this opportunity to acknowledge their valuable contribution to the cable industry. 

New MAC Layer Functionality Introduced

The MAC layer functionality introduced supports the new FDX DOCSIS operation on the hybrid-fiber-coax (HFC) link.  It is focused on MAC management messaging and operation needed to enable FDX DOCSIS between the CMTS (Cable Modem Termination System) and CM (Cable Modem). This includes FDX DOCSIS channel acquisition/initialization process by a CM, and new processes such as Sounding, Echo Cancellation training, and Resource block assignment.

How it Works – Cable Modem to CMTS Communication

An FDX DOCSIS CMTS will simultaneously receive and transmit in the same FDX DOCSIS spectrum, while FDX DOCSIS (now a part of DOCSIS 4.0 technology) CMs can either receive or transmit in the same FDX DOCSIS spectrum. Thus, communication is full duplex from the perspective of the CMTS but frequency division duplex from the perspective of the CM.

The FDX DOCSIS band is divided into sub-bands and the CMTS assigns which sub-band(s) each CM uses for upstream or downstream operation. This is referred to as a resource block assignment (RBA). Different CMs will have different bandwidth demand for both the upstream and downstream directions which can change over time, and FDX DOCSIS allows for the RBA to be changed dynamically.

A sounding method is used to identify groups of CMs, called Interference Groups (IGs), that would interfere with each other if they were allowed to transmit and receive at the same time in a sub-band. IGs are grouped together into a small number of Transmission Groups (TGs), CMs in the same TG either transmit or receive on any given sub-band and time, as signaled by the CMTS in the RBA. CMs from different TGs have enough isolation to transmit and receive at the same time in the same sub-band.

FDX DOCSIS uses a combination of interference cancellation and intelligent scheduling at the CMTS. On the CM, in order to prevent upstream transmissions from interfering with adjacent downstream channels in the FDX band, echo cancellation techniques are used.

What’s Next for the Full Duplex DOCSIS Technology?

As the FDX DOCSIS specifications mature, we will start to see products with full-duplex capabilities over the next year as silicon designs become available and are incorporated into product designs. In an effort to increase the pace of product development, CableLabs has announced a series of FDX DOCSIS Interoperability events , starting in February. These will start from basic node level echo cancellation and gradually progress into full-blown product interoperability.

The collaborative model at CableLabs for developing common cable industry specifications minimizes interoperability issues and gets the best in class features into the specifications. This accelerates time to market for a product, with the operator getting to deployment faster, and ultimately the consumer gets to reap the benefits of the latest technology.

In the meantime, the big wheels of CableLabs specification work continue to turn:

• We are developing the OSS (Operations Support Systems) changes needed to support FDX DOCSIS.
• We have initiated work for the changes needed to support FDX DOCSIS within the Remote PHY realm. (FDX, now a part of DOCSIS 4.0 technology, assumes a distributed architecture and a plant which supports a node plus zero actives due to the CMTS node echo cancellation functionality)
• As suppliers build the FDX DOCSIS products, the feedback loop into the FDX (now a part of DOCSIS 4.0 technology) specifications remains open and the PHY & MAC specifications continue to be refined.

Full Duplex DOCSIS significantly increases upstream capacity on the HFC network, allows flexible splits of upstream and downstream capacity, and enables cable operators to deploy multi-gigabit symmetrical services. With all the innovations being developed by the industry, it is a great time to be a consumer of high-speed data services over cable.

Karthik Sundaresan is a Principal Architect at CableLabs responsible for the development and architecture of cable access network technologies. He is primarily involved in the DOCSIS family of technologies and their continued evolution.

Subscribe to our blog to stay current on Full Duplex DOCSIS technology (now a part of DOCSIS 4.0 technology). 

The wireless ecosystem is a rapidly moving marketplace, and the next milestone is the large-scale deployment of small cells to augment network capacities and to support 5G deployments. There are three main elements required to deploy small cells:

1. Location
2. Power
3. Backhaul

These requirements put cable operators, many of whom are also mobile operators, in an advantageous position for deploying mobile small cells.

According to the NCTA, 93% of US households are reachable via the hybrid fiber coaxial (HFC) network. While the HFC provides the necessary elements for deploying small cells, the cable infrastructure can further extend its capabilities by offering low latency mobile backhaul. Reducing latency in the DOCSIS® network will unlock that additional potential for cable operators.

Backstory

Small cells are deployed to provide capacity or coverage augmentation for the macrocell network. This results in overlapping coverage areas between the various cells (between small cells and small cells, as well as between small cells and macrocells). There is significant interference generated in these overlapping areas, as the user can hear multiple cells’ transmissions. In order to provide a good quality experience for these users, the mobile operator needs to deploy advanced interference management techniques that are currently supported by LTE-Advanced and LTE-Advanced Pro. But, for these techniques to work well, adjacent cells need to be able to talk to each other quickly - at a latency of generally no more than 5 milliseconds. And because these cells talk to each other through the DOCSIS backhaul network, the DOCSIS round-trip latency must be 5 ms or less. This is not achievable today. See Fig. 1:

Fig. 1: DOCSIS backhaul supporting LTE X2 interface for LTE-A and LTE-A Pro features

Searching for Solutions

We found that traditional cable equipment suppliers were also innovating in this space and working on enabling DOCSIS to provide better mobile backhaul. Together with my colleague John Chapman, Cisco Fellow and CTO Cable Access, we came up with a simple solution that reduces the DOCSIS upstream latency to 1-2 ms consistently. We developed a proof-of-concept (PoC), each supplying expertise and resources in the mobile and CMTS space.

Looking closely, LTE and DOCSIS are two independent systems – their operations occur in serial. The overall latency is the sum of the two system latencies. The two technologies have similar mechanisms to access the channel, and that is through a request-grant-data transfer loop.

Here comes the lightbulb moment: The LTE loop is much longer than DOCSIS, resulting in much higher latency than DOCSIS. This presents a hidden opportunity for DOCSIS. Rather than waiting for the LTE transaction to complete and then start the request process on the DOCSIS side as it is today, we proposed that LTE tell DOCSIS about the data that is on its way so that the DOCSIS request process can start earlier and in parallel with the LTE transaction. This will lead to much lower overall system latency. This is illustrated in Fig. 2:

Fig. 2. Pipelining LTE and DOCSIS operations. (REQ-UE: LTE request; GNT-UE: LTE grant; REQ-CM: DOCSIS request; GNT-CM : DOCSIS grant; BWR: bandwidth report)

Industry Partnership

Our joint team worked together on perfecting the pipelining operation and designing a new message called the “bandwidth report,” or the “BWR.” This simple solution reduces the DOCSIS upstream latency to a consistent 1-2 ms.

To build the proof-of-concept (PoC), we inserted a minimal amount of code into an open source LTE small cell and added an API on the Cisco cBR-8, enabling the CMTS to optimize its scheduling and to align it with the small cell transmissions in real time. We demonstrated the PoC to cable operators and received very positive feedback. See Fig. 3:

Fig. 3. LTE Open Air Interface (OAI) and Cisco cBR-8 CMTS testbed

Our proof-of-concept was also demonstrated recently in the Cisco booth at SCTE Cable-Tec Expo 2017, as Cisco explains here. The next step for this is to make the solution available industry-wide by standardizing it through CableLabs and have it ready for the HFC network to be at the forefront of the mass deployment of small cells.

I will be holding a webinar with John Chapman in early 2018. You can find more information here.