CableLabs and Kyrio hosted a combined DOCSIS® 4.0 technology and Distributed Access Architecture (DAA) Interop•Labs event February 12–15 at our headquarters in Louisville, Colorado. This was the first combined interop between CableLabs and its subsidiary, and the involved suppliers and operators made it a success.

At this Interop•Labs event, the exercises included both DOCSIS 4.0 cable modems and Remote PHY equipment, including virtualized cores and Remote PHY Devices (RPDs) that support DOCSIS 4.0 technology. During the week, mixing and matching of systems and components demonstrated multi-supplier interoperability across the DOCSIS 4.0 ecosystem.

Interop Takeaways

Casa Systems, CommScope and Harmonic brought DOCSIS 4.0 cores to the interop, and Casa Systems, Cisco, CommScope, DCT-DELTA, Harmonic, Teleste and Vecima brought RPDs that offered a mix of DOCSIS 3.1 and DOCSIS 4.0 technologies. Arcadyan, MaxLinear and Ubee Interactive showcased DOCSIS 4.0 modems. Rohde & Schwarz also participated with its DOCSIS 4.0 test and measurement system. Operators attended to observe the interop, interact with the suppliers and talk about their DOCSIS 4.0 technology plans.

The focus of the interop was interoperability across the ecosystem. A common test scenario at the event involved a virtual core from supplier A, an RPD from supplier B and a DOCSIS 4.0 modem from supplier C, all connected and operating according to specifications. The products were mixed and matched to investigate interoperability scenarios, with suppliers pitching in to analyze the results. To demonstrate extra flexibility for cable operators, suppliers mixed DOCSIS 3.1 and DOCSIS 4.0 equipment because the specifications are written for cross-compatibility.

Above, engineers collaborate during the first combined DOCSIS 4.0 Interop•Labs event hosted by CableLabs and its subsidiary, Kyrio.

Interestingly, the interop illustrated how the traditional cable modem termination system (CMTS) has been disrupted by virtualization. Provided by one supplier, the CMTS used to be one box that did it all. Now, the software components have been abstracted into a virtual core that runs on servers in our data center, while the physical-layer components have migrated to the fiber node. This virtual architecture provides both better scalability and improved flexibility for the software, as well as better physical-layer performance on the coaxial cable. And in between, the fiber-optic cable uses much more scalable digital Ethernet connections.

The interop also demonstrated that the core and fiber node components can come from different suppliers because that interface is described in the CableLabs Remote PHY specifications. Looking at interoperability from all angles benefits all stakeholders. Interoperability enables a larger market in which suppliers can compete, which leads to varying competitive strategies and healthier ecosystems. Interoperability gives operators the confidence to plan large installations and the certainty that the equipment they put in the field this year will work for years to come.

Remote PHY interoperability events began in 2017 with DOCSIS 3.1 technology, so these solutions have been in the field for years and have matured. This interop shows that the migration to DOCSIS 4.0 technology is both very far along and proceeding smoothly — and that the supplier community has embraced interoperability among system components.

It's About Network Cohesion

The integration and optimization of the DOCSIS 4.0 ecosystem is underway. The goal has moved beyond simply booting DOCSIS 4.0 modems. Rather, we’re putting together all the parts, mixing and matching from different suppliers, demonstrating interoperability across the interfaces defined in CableLabs specification and achieving the multi-gigabit speeds and other advanced capabilities of DOCSIS 4.0 technology such as security, low latency and proactive network maintenance.

Other parts of the DOCSIS 4.0 ecosystem are also becoming available, including hybrid fiber coax (HFC) network equipment such as amplifiers, taps and passives.

To learn more about this exciting evolution, join us next month at CableLabs Winter Conference. This exclusive event for CableLabs members and the NDA vendor community will explore DOCSIS technology in two powerful sessions: “Unleashing the Full Potential of the DOCSIS 4.0 Network” and “A Vendor Perspective on DOCSIS 4.0 Technology Implementation.” You’ll hear from industry leaders about effective strategies, opportunities and benefits of the DOCSIS 4.0 network. Join us!

CableLabs and Kyrio hosted a DOCSIS® 4.0 Interop·Labs event November 6–9 at our headquarters in Louisville, Colorado. It was a busy, week-long experience that highlighted multiple facets of DOCSIS 4.0 technology, and the many suppliers involved worked together to make it a success.

The primary focus of the event was network reliability — in particular, DOCSIS 4.0 cable modem (CM) proactive network maintenance (PNM) functions in DOCSIS 4.0 cable modem termination systems (CMTSs). There also were Remote PHY Device (RPD) interoperability exercises.

At this interop, four DOCSIS 4.0 CMs from four suppliers were interconnected to both DOCSIS 4.0 and DOCSIS 3.1 CMTSs from three companies. Participating suppliers were Arcadyan, Casa Systems, DCT-DELTA, Harmonic, Sagemcom, Ubee Interactive, and Vecima Networks. Rohde & Schwarz also participated with its DOCSIS 4.0 test system. Operators attended to observe the interop and talk about their DOCSIS 4.0 technology plans.

Engineers collaborate in a DOCSIS 4.0 Interop·Labs event at CableLabs' headquarters in November.

Network Reliability at the Forefront

Every day, hundreds of millions of broadband consumers use DOCSIS technology, and they depend on a reliable connection. DOCSIS PNM, which uses data provided by DOCSIS equipment, is foundational to the reliability of that connection.

For operators to keep tabs on the network and their offered services, data elements need to be both available and accurate. The goal of PNM is to fix issues before customers even realize there is a problem — before any service impacts occur.

PNM technology can be summarized into three areas: data collection, algorithms that use the data to analyze the network, and network operations to ensure continuous service.

Data collection. DOCSIS equipment generates vast amounts of network performance data to detect and measure issues within the cable plant. What kind of data? Data about both downstream and upstream RF performance, data on the spectrum in use, data on the signals on the coaxial cable, data on how the transmitters and receivers are operating, and more. At the interop event, we verified that the data reporting is both there and correctly formatted. For operator systems to use that data effectively, it has to be standardized in order for every modem from every manufacturer to report apples-to-apples information so that operator systems can use that data effectively.

Analysis algorithms. Once data is collected from the CMs, it’s run through algorithms to examine the health of the network. Systems sift through this data constantly, looking for anomalies. At the interop, the algorithms were discussed and compared, with operators describing how the data is used and what is being looked for.

Network operations. The DOCSIS PNM team maintains a reference document that describes how the data must be formatted, how it can be collected and which algorithms can be run on the data. Numerous SCTE Cable-Tec Expo papers discuss how to interpret the data and use it to maintain the network at the highest levels of service. The interop event featured eight high-runner PNM tests, collecting data from the DOCSIS equipment and putting it through algorithms. In the lab, it’s possible to simulate errored network conditions and use the data and algorithms to verify the condition of the network. SCTE is also involved with preparations for DOCSIS 4.0 tools and deployments, as Jason Rupe describes in the blog post “Ready, Set, 4.0: Tooling Up for DOCSIS Technology’s Rollout.”

A Comprehensive DOCSIS 4.0 Interop Event

Attending the event was one participant’s DOCSIS 4.0 virtual core platform and fiber node, which included a DOCSIS 4.0 extended spectrum DOCSIS (ESD) remote PHY device (RPD). This solution was a DOCSIS 4.0 ESD CMTS, and the DOCSIS 4.0 CM suppliers were excited to work with it. The DOCSIS 4.0 ESD CMTS operated both on a DOCSIS 4.0 ultra-high-split as well as up to 1.8 GHz on the coaxial cable. Both speed testing and security testing were examined against the DOCSIS 4.0 CMTS, continuing the work from previous interop events.

Remote-PHY Interop Exercises

DOCSIS 4.0 technology requires a distributed access architecture (DAA). At this interop, suppliers exhibited an array of DOCSIS 4.0 virtual cores. One supplier, which manufactures fiber nodes and RPDs, brought its DOCSIS 3.1 RPD with enhanced DOCSIS 3.1 capabilities. CableLabs and Kyrio were ready to support this kind of interop too. In essence, then, this wasn’t merely a DOCSIS 4.0 interop, but also a Remote PHY interop!

Collaborative DOCSIS Technology Evolution

At the DOCSIS 4.0 Interop·Labs event, CMTS and CM suppliers continued their efforts to verify that their equipment works together, further peeling the onion and diving into the nitty-gritty details of the specifications. This is where interoperability really happens.

All of the participants, along with us at CableLabs, left with a stronger understanding of product functionality and multi-vendor interoperability — and new work to do. Moving forward, the suppliers will continue to collaborate to refine their products and add further functionality.

Interop events are a major step toward large-scale deployment of DOCSIS 4.0 technology. Another step is certification. To find out more about Cable Modem Certification, click the button below.

CableLabs and Kyrio hosted a second DOCSIS® 4.0 Interop·Labs Event August 14–17 at our headquarters in Louisville, Colorado. This event built on our successes in July, focusing on interoperability between DOCSIS 4.0 cable modems (CMs) and DOCSIS 3.1 cable modem termination systems (CMTSs).

Attendance was up from the July interop, along with the addition of more CMs, CMTSs and test equipment. For this interop, seven DOCSIS 4.0 CMs from four suppliers were interconnected to seven DOCSIS 3.1 CMTSs from five companies. Participating suppliers were Arcadyan, Casa Systems, Cisco, CommScope, Harmonic, Sagemcom, Ubee Interactive, Vantiva and Vecima. EPIDoX.solutions and Rohde & Schwarz also attended with DOCSIS 4.0 test systems. Operators attended to observe the interop and talk about their DOCSIS 4.0 technology plans.

Engineers collaborate August 15 at the CableLabs DOCSIS 4.0 Interop·Labs Event.

Securing Customer Data Is Essential

The focus of this interop was security. Every day, tens of millions of broadband users connect with DOCSIS technology, using it for everything from ordering a pizza to sharing a video, from remote learning and remote medical appointments to purchasing household items and booking family vacations. Security in these activities is paramount to ensuring the best broadband experience possible.

Here’s an interesting tidbit about DOCSIS security: The methods we use at CableLabs are all published and available to the public — and always have been. DOCSIS security doesn’t depend on the secrecy of the implementation or its components. Rather, DOCSIS security is based on the strength of the algorithms and protocols in use, and these tools are updated from time to time to keep the security level high.

The security technologies are somewhat complex but can be summarized in two areas: authentication and encryption.

Authentication is as simple as the CM trusting the CMTS and the CMTS trusting the CM. It’s accomplished using digital certificates. DOCSIS technology has pioneered the use of public key cryptography on a mass scale. The DOCSIS public key infrastructure (PKI) is among the largest PKIs in the world, with half a billion active certificates issued and actively used every day.

Once authentication is complete and trust is established, the CM and CMTS exchange materials to encrypt the user traffic. Encryption makes the user traffic look like gibberish; without the means to decrypt the traffic, anyone snooping in on it would find it’s unintelligible. This methodology keeps users’ information secret.

As this Interop·Labs event examined interoperability with DOCSIS 3.1 CMTSs, it also looked at authentication and encryption, which are enabled by the Baseline Privacy Interface Plus (BPI+). A deeper dive on DOCSIS security capabilities can be found here, and further details about the cable security experience here.

Engineers work together during the four-day event.

The Importance of Getting the Community Together

A big takeaway from the July interop was the importance of suppliers getting to know each other, creating relationships and collaborating ahead of this August interop. There’s been a lot of activity over this past month, at both CableLabs and supplier locations. The CableLabs security team was also busy ahead of time, working with suppliers to distribute materials and answer questions about DOCSIS security.

Because of this up-front work, we were able to get right to work on the August interop. With the latest products and software on hand, we stepped through all of the possible equipment combinations to explore how each worked to get CMs online with security.

Then, with security enabled, we again achieved the high speeds expected with DOCSIS 4.0 broadband — this time with line-rate encryption of the traffic. The highest downstream speeds were achieved with five 192 MHz OFDM channels (total of 960 MHz), which provided around 8.5 Gbps. On the upstream, a high-split channel lineup of QAMs and 2 OFDMA channels provided around 1.5 Gbps.

Everyone, including CableLabs, left the interop with new tasks to tackle, which is typically the case with maturing products and expected with events like these.

Overall, all of the participants left this interop in a good place, in terms of functionality and multi-vendor interoperability. From here, the suppliers can layer on additional functionality and add maturity to their products, working together in their own labs and at CableLabs.

Demonstrations at SCTE Cable-Tec Expo

The focus is now on successful technology demonstrations at the SCTE® Cable-Tec Expo® in October, in Denver, Colorado. Our experts will be on hand at booth 2201, so make plans to stop by if you’re attending.

We’re planning another in-person interop at CableLabs after Cable-Tec Expo. We’re actively working with the supplier community on both the timing and topics for this next interop. Stay tuned for more information.

For the first time since we published the DOCSIS® 4.0 specifications in 2020, the DOCSIS community recently came together for an Interop•Labs event. With Kyrio support, CableLabs hosted the interop July 17–21 at our headquarters in Louisville, Colorado. The event was a success on multiple fronts, and I was particularly excited by the strong turnout from suppliers and operators.

Both cable modem termination system (CMTS) and cable modem (CM) suppliers began the work to bring this technology to the field. For the in-person event, suppliers brought more than a dozen products to our lab. Operators also attended to observe, provide encouragement and offer operational perspectives.

The Importance of DOCSIS 4.0 Interoperability

In our lab, CableLabs provided an environment for all this equipment to come together — with a focus on the DOCSIS 4.0 specifications that are so important for interoperability. Interoperability allows:

• Suppliers to compete in a larger market.
• Operators to have more choices in the services they offer to subscribers.
• Competition and innovation to occur among a larger community of smart people.

It really is the cornerstone of what CableLabs and Kyrio bring to the table for the DOCSIS specifications.

Interoperability is pretty tricky to achieve and takes attention to details contained in the specifications. The CMTS and CM must both interpret and agree on a number of parameters to work together to provide service (e.g., the downstream and upstream channels that a CM can use). This sometimes comes down to an interpretation of the specification — expertise that’s right in CableLabs’ wheelhouse.

Pair, Re-Pair, Repeat: How the Interop Unfolded

For this interop, six DOCSIS 4.0 CMs from four suppliers were interconnected to six DOCSIS 3.1 CMTSs from five companies. Participating suppliers were Arcadyan, Casa Systems, Cisco, CommScope, Harmonic, Sagemcom, Ubee, Vantiva and Vecima. EPiDoX also attended with a prototype DOCSIS 4.0 test system.

The CMTS and CM suppliers iteratively paired CMs to CMTSs to test interoperability. During this pairing and re-pairing, participants investigated the functionality and interoperability of the CM and CMTS equipment against the DOCSIS specification requirements. This process ensured all connectivity options between the CMs and the CMTSs were investigated.

Suppliers worked diligently to meet the goals of the interop and then went the extra mile to pursue “stretch” goals. Everyone came prepared with a collaborative attitude.

The cable modems successfully connected to CMTSs the first time, which was reassuring because DOCSIS 4.0 technology can be seen as an extension of DOCSIS 3.1 technology. We discovered some issues, of course, and everyone — including CableLabs — left the interop with something to work on. This is par for the course for a first interop, and it’s exactly the reason we hold these events.

And, yes, the DOCSIS systems we investigated passed high-speed traffic. Very high speed, as in gigabits-per-second downstream and upstream. For me, a long-time DOCSIS expert who still remembers dial-up speed, DOCSIS 1.0 speeds and everything since, it really was quite amazing to witness the speeds that DOCSIS 4.0 technology makes possible. This included DOCSIS 3.1 CMTSs augmented with additional channels to support DOCSIS 4.0 modems, as referenced in this earlier blog post.

The Interop•Labs event also let me get reacquainted with several colleagues that I hadn’t seen in several years; it was good to refresh those friendships and working relationships. There were new faces, too — at least to me — and I got to meet and work with those folks, as well.

Marching Ahead to DOCSIS 4.0 Availability

Another in-person interop is scheduled for August 14–17, again at CableLabs’ Louisville office. We expect the same participants, and we’ll revisit the scenarios from July and take a look at some new ones. The goal is to keep pushing a more rigorous and deeper understanding of the DOCSIS 4.0 specifications and product maturity.

Although speed is fun to witness, the areas of lower latency, enhanced security and increased reliability are co-equal pillars of the 10G network and are all supported by DOCSIS 4.0 specifications. DOCSIS 4.0 technology is going to blow some minds when it gets unleashed, and it will raise the bar for consumer broadband higher than ever.

After the August interop, our focus will turn to the SCTE® Cable-Tec Expo® in October in Denver. Believe me: You’ll want to attend and see these developments for yourself. The industry is focused on bringing DOCSIS 4.0 technology to market, and it will be all over the show floor — including the hybrid fiber-coax (HFC) network equipment. End to end, suppliers have been working overtime to make this event a showcase. You won’t be disappointed.

Consumers are demanding increasingly immersive, interactive media experiences that require faster speeds, lower latency, increased network reliability and enhanced security. The future of the cable industry relies on interoperability to deliver what consumers need. That’s the goal of the industry’s full-court press toward 10G deployment, and it starts with DOCSIS® 4.0 compliance.

DOCSIS 4.0 Equipment Functionality

The DOCSIS 4.0 specifications were completed in early 2020. Since then, a lot of hard work has led to getting DOCSIS 4.0 cable modems and cable modem termination systems (CMTSs) ready for a first look. Last spring, CableLabs hosted a 10G Showcase at our Louisville, Colorado, office with impressive results. Now, the industry is ready to take the next step.

CableLabs and Kyrio will host an in-person DOCSIS 4.0 Interop·Labs event July 17–20 in Louisville. DOCSIS Interop·Labs events are a precursor to modem certification and provide suppliers an opportunity to test their products in a multi-vendor environment with state-of-the-art equipment to meet the letter of the specifications. Operators also will attend to get a look at the equipment and the environments, and to network with their industry peers on the operator and the supplier sides.

What can be expected from this event? Because this is early equipment with basic functionality, our goals include looking at basic functions, including whether a cable modem can become operational in the common configurations in use today. When a modem becomes operational, it will be exercised with back-office systems and data traffic.

The four-day Interop·Labs event will ensure that the fundamentals of interoperability are in place and capable of supporting subsequent interoperability events that will look deeper into modem functionality. The event also will focus on backward compatibility to build confidence that a DOCSIS 4.0 modem can be deployed on existing headend equipment and operations systems to provide the opportunity for faster speed tiers on DOCSIS 3.1 headend equipment. A DOCSIS 4.0 modem on a DOCSIS 3.1 CMTS will be an exciting milestone for the industry.

Since the CableLabs 10G Showcase last spring, CableLabs and Kyrio have upgraded the labs to support faster speeds to enhance the customer experience with cable broadband.

Cable Modem Certification

This Interop event has great synergy with the recent launch of the CableLabs DOCSIS 4.0 Cable Modem Certification program. Initial cable modem certification testing will focus on verifying operation on DOCSIS 3.1 systems, and this Interop·Labs event will provide suppliers an opportunity to see how their solutions work with others. Find more information on the CableLabs certification program here.

Gaining Momentum and Planning More DOCSIS Interop Events

Future DOCSIS Interop·Labs are planned to look deeper into the other three pillars of 10G: enhanced security, lower latency and network reliability. Our DOCSIS 4.0 Interop·Labs and Certification work is just beginning, and you can look forward to additional blog posts to keep you up to date with what is happening at CableLabs and Kyrio. And, with the Interop·Labs event being hosted in July, you can be sure this equipment will be on the show floor at the SCTE Cable-Tec Expo in October in Denver.

Thanks to two recent innovations, DOCSIS technology is bringing more speed to the table. First, DOCSIS 3.1 cable modem termination systems (CMTSs) can now offer more DOCSIS channels than they did just a few years ago. Second, DOCSIS 4.0 cable modems (CMs) can take advantage of those extra channels to provide even faster speeds. DOCSIS is the gift that just keeps on giving.

DOCSIS Expansion

As you can see in the middle row of the figure below, the original DOCSIS 3.1 systems (circa 2016) supported about 5 Gbps of downstream speed. Technically speaking, this includes 2 orthogonal frequency-division multiplexing (OFDM) downstream channels and 32 single-carrier quadrature amplitude modulation (QAM) channels.

As you see in the figure’s top row, upgraded DOCSIS 3.1 CMTSs (which are available now from multiple suppliers) can support a peak downstream speed of 8.8 Gbps by utilizing as many as 4 OFDM channels and 32 QAM channels.

Finally, illustrated in the figure’s bottom row, a DOCSIS 4.0 CM can use all the channels available with an upgraded DOCSIS 3.1 CMTS (actually more, as you’ll see in a moment). That means cable operators can almost double the downstream speed of their DOCSIS system by using a DOCSIS 4.0 CM on a DOCSIS 3.1 CMTS.

Faster Speeds

Confirming the strong performance of DOCSIS 4.0 technology, a recent press release about a live network field trial claimed that up to 15 Gbps of downstream speed is possible with a DOCSIS 4.0 CMTS and a DOCSIS 4.0 CM. This is possible because a DOCSIS 4.0 CMTS will provide even more capacity, supporting at least 6 and as many as 8 OFDM channels when complemented with an outside plant extending beyond 1.2GHz. This number is in line with DOCSIS 4.0 predictions of up to 16 Gbps of aggregate capacity.

How can one even quantify this explosion in speed? We’re talking about a leap from 5 Gbps to up to 15 Gbps downstream. This ensures support for evolving use cases that consume more and more downstream bandwidth. And once again, DOCSIS technology is up to the task, providing a useful roadmap of speed for the next generation of broadband applications.

How It’s Happening

To make this update to the DOCSIS 3.1 CMTS happen, suppliers are reusing a technology called channel bonding, which was added in the DOCSIS 3.0 specifications. The original DOCSIS 3.0 equipment supported 4 bonded downstream QAM channels (in North America, each 6 MHz wide), and the next generation of equipment supported 8, then 16, then 24 and finally 32 bonded downstream QAM channels.

DOCSIS 3.1 CMTSs are going through a similar evolution, evolving from bonding the original 2 OFDM channels (each up to 192 MHz wide) to 4 or more OFDM channels. And DOCSIS 4.0 CMs can use all these channels, which was part of the plan when the DOCSIS 4.0 specifications were developed. Channel bonding is a powerful tool—even more so now when using 192 MHz wide OFDM channels.

Utilizing the ability to bond additional OFDM channels when operating a DOCSIS 4.0 CM on a DOCSIS 3.1 CMTS not only supports more capacity, and therefore enhanced benefits for consumers; it also gets those benefits to consumers much sooner. Operators can confidently deploy DOCSIS 4.0 CMs with enhanced service offerings as soon as they’re available, and then transition to DOCSIS 4.0 CMTSs as appropriate.

The Importance of Community

The DOCSIS supplier community deserves a shout-out! Once again, suppliers have provided cable operators with an appealing method to transition to the next generation of DOCSIS technology by getting started with DOCSIS 4.0 CMs on now familiar and near-ubiquitous DOCSIS 3.1 CMTSs. Suppliers and operators are collaborating on smart ways to transition to a DOCSIS 4.0 network; using a more capable DOCSIS 3.1 CMTS should be an attractive option.

CableLabs has been upgrading our labs to support this speed explosion. We’ve recently added new testing capabilities ranging from RF testing to enhanced traffic-generation capability to support the capabilities of DOCSIS 4.0 technology. Utilizing upgraded DOCSIS 3.1 CMTSs, CableLabs is very excited to work with DOCSIS 4.0 CMs to prove both the interoperability of the systems and the speeds that are possible.

DOCSIS® 4.0 Certification

To support the deployment of DOCSIS 4.0 CMs, CableLabs and Kyrio are kicking off the DOCSIS 4.0 Cable Modem Certification Program this summer. Starting June 26, modem suppliers can submit DOCSIS 4.0 modems for DOCSIS 4.0 certification testing, which will include testing with DOCSIS 3.1 infrastructure such as virtual CMTSs, Remote PHY Devices (RPDs) and Remote MACPHY Devices (RMDs).

Have any questions about DOCSIS 4.0 certification? You can find further details on Kyrio’s CableLabs Certification webpage (which includes a FAQ and guidelines).

As we enter the new year, consumers, workplaces, and schools continue to rely on video conference applications. We previously studied Bandwidth Usage of Popular Video Conferencing Applications in November 2020 and February 2021.  In May 2021, we studied Hourly Data Consumption of Popular Video Conferencing Applications. Today, we share a study of bandwidth usage on a 50Mbps/10Mbps Service Tier by popular video conferencing applications and how they perform with the addition of background traffic in the upstream.

This blog is a snapshot of the conference applications' bandwidth usage in December 2021.

The current testing used a 50 Mbps downstream and 10 Mbps upstream service tier, which doubles the upstream speed from the previous work with a 50/5 Mbps tier. With the faster upstream tier, this effort looks at both

• Bandwidth consumed for 10 concurrent conference sessions, and
• The behavior of 10 concurrent conference sessions in the presence of additional upstream traffic, specifically an upstream 5 Mbps UDP (user datagram protocol) flow.

Apple FaceTime, Google Meet, and Zoom were examined. When possible, we tested the available desktop version of each video conference application.  To avoid any appearance of endorsement of a particular conferencing application, we do not label the figures below with the specific application under test. As described below, in the presence of the 5 Mbps UDP flow in the upstream the three applications behave similarly and without any negative impact to the video-conferencing application.

In addition to the video conferencing streams, we add a 5 Mbps UDP stream of upstream traffic in the background to illustrate the capability of a 10 Mbps upstream tier. Besides video conferencing applications, other popular activities that drive upstream usage are online gaming, Wi-Fi connected cameras, and file uploads. The additional 5 Mbps stream is meant to capture a wide range of common use cases. For example, concurrent use of one to two online gaming sessions (100 to 500 Kbps each), three to four Wi-Fi connected cameras (500 Kbps to 1 Mbps each), and a file upload of 2 Mbps (900 megabytes over an hour) would all fit within this 5 Mbps upstream budget. As we show below, even with this 5 Mbps traffic and 10 concurrent sessions of the video conferencing applications, there is still upstream bandwidth available for additional activity by a subscriber with a 50 Mbps/10 Mbps service tier.

The lab setup was modified from our previous testing. The ten laptops used during this testing were different than the previous blogs; this group of laptops consisted of five MacOS and five Windows 10 operating systems. The laptops were standard consumer grade laptops without any upgrades such as those commonly used by gamers.

What did not change is the same DOCSIS 3.0 Technicolor TC8305c gateway and same CommScope E6000 cable modem termination system (CMTS) from the previous testing were used during this testing. Additionally, like the previous testing, all the laptops used wired Ethernet connections through a switch to the gateway to ensure no variables outside the control of the broadband provider would impact the speeds delivered (e.g., all the variables associated with Wi-Fi performance).  Throughout testing, we ensured there was active movement in view of each laptop’s camera to simulate real-world use cases more fully.

As in the previous blogs, this research does not consider the potential external factors that can affect Internet performance in a real home -- from the use of Wi-Fi, to building materials, to Wi-Fi interference, to the age and condition of the user’s connected devices -- but it does provide a helpful illustration of the baseline capabilities of a 50/10 Mbps broadband service.

As before, the broadband speeds were over-provisioned. For this testing, the 50/10 broadband service was over-provisioned by 25%, a typical cable operator configuration for this service tier.

To establish a baseline, we began by repeating the data collections from the three previous efforts and were able to confirm the results.  In the seven months since our last testing, many of the application developers issued updates to the applications, thus we compared the current observations with past observations looking for consistency instead of identical results.

Conferencing Application A

Figure 1 shows total access network usage for the 10 concurrent sessions over 350 seconds while using App A. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that even with a 10 Mbps upstream tier, the total upstream usage stays around 2.5 Mbps. The downstream usage stays, on average, around 18 Mbps, which leaves roughly 32 Mbps of downstream headroom for other services, such as streaming video, that can use the broadband connection at the same time.

Figure 2 shows total access network usage for the 10 concurrent sessions and the addition of 5 Mbps of upstream traffic over 350 seconds while using App A. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that before the upstream 5 Mbps was applied the total upstream usage was around 2.5 Mbps. At about 60 seconds, the additional 5 Mbps UDP stream was added to the upstream which causes the total to increase to about 7.5 Mbps.  As shown in Figure 3, the addition of 5 Mbps of traffic causes no noticeable impact on the upstream conference flows. At about 320 seconds that 5 Mbps stream is removed, and the upstream usage goes immediately back to where it was before that stream was applied. During the entire test the downstream usage stays, on average, around 18 Mbps even when the additional upstream bandwidth is consumed.

Figure 3 shows just upstream usage where the upstream traffic for the 10 concurrent sessions of App A is shown with dark orange, and the additional 5 Mbps of upstream traffic is shown in light orange. This view emphasizes that the additional 5 Mbps of upstream traffic does not appear to have an impact on the upstream bandwidth usage of the 10 concurrent video sessions of App A.

Conferencing Application B

Figure 4 shows total access network usage for the 10 concurrent sessions over 350 seconds while using App B. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that even with a 10 Mbps upstream tier, the total upstream usage stays under 2.5 Mbps. The downstream usage stays, on average, around 13 Mbps, which leaves roughly 37 Mbps of downstream headroom for other services.

Figure 5 shows total access network usage for the 10 concurrent sessions and the addition of 5 Mbps of upstream traffic over 350 seconds while using App B. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that before the upstream 5 Mbps was applied the total upstream usage was around 2.5 Mbps. At about 60 seconds, an additional 5 Mbps stream was added to the upstream which causes the total to increase to about 7 Mbps.  As shown in Figure 6, the addition of the 5 Mbps of traffic causes no noticeable impact on the upstream conference flows. At about 270 seconds that 5 Mbps stream is removed, and the upstream usage goes immediately to where it was before that stream was applied. During the test the downstream usage stays, on average, around 13 Mbps even when the additional upstream bandwidth is consumed.

Figure 6 shows just upstream usage where the upstream traffic for the 10 concurrent sessions of App B is shown with dark orange, and the additional 5 Mbps of upstream traffic is shown in light orange. This view demonstrates that the additional 5 Mbps of upstream traffic does not appear to have an impact on data usage of the 10 concurrent video sessions of App B.

Conferencing Application C

Figure 7 shows total access network usage for the 10 concurrent sessions over 350 seconds while using App C. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that even with a 10 Mbps upstream tier, the total upstream usage stays around 4 Mbps. The downstream usage stays, on average, around 10 Mbps, which leaves roughly 40 Mbps of downstream headroom for other services.

Figure 8 shows total access network usage for the 10 concurrent sessions and the addition of 5 Mbps of upstream traffic over 350 seconds while using App C. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that before the upstream 5 Mbps was applied the total upstream usage was around 4 Mbps. At about 70 seconds, an additional 5 Mbps stream was added to the upstream which causes the total to increase to about 9 Mbps.  As shown in Figure 9, the addition of the 5 Mbps of traffic causes no noticeable impact on the upstream conference flows. At about 260 seconds that 5 Mbps stream is removed, and the upstream usage goes immediately back to where it was before that stream was applied. During the entire test, the downstream usage stays, on average, around 10 Mbps even when the additional upstream bandwidth is consumed.

Figure 9 shows just upstream usage where the upstream traffic for the 10 concurrent sessions of App C is shown with dark orange, and the additional 5 Mbps of upstream traffic is shown in light orange. This view demonstrates that the additional 5 Mbps of upstream traffic does not appear to have an impact on the data usage of the 10 concurrent video sessions of App C.

Summary

This investigation looked at three popular video conferencing applications over an upstream tier of 10 Mbps and a downstream tier of 50 Mbps.

The three applications exhibited similar behavior of using under 4 Mbps of upstream during 10 concurrent conference sessions. When an additional 5 Mbps of upstream traffic was added, these three conference apps took it in stride; there were no noticeable changes to either the upstream or downstream consumption of the 10 concurrent conference sessions and no negative impact to the quality of the video conferencing sessions.

The successful testing of 10 concurrent video sessions plus 5 Mbps of additional background traffic illustrates the capability of a 50/10 service tier to support the broadband needs of telework, remote education, telehealth, and other use cases that rely heavily on video conferencing applications. The testing also illustrates that a 50/10 service tier can readily support a household with multiple users engaging on video conference platforms as well as support other simultaneous uses.

On behalf of CableLabs, Kyrio will be hosting upcoming DOCSIS 4.0 interoperability events! 

DOCSIS 4.0 technology is the next evolution of the HFC network, moving the industry towards the 10G vision and offering multigigabit symmetric services as well as low latencies over the network.  

As vendors work to create the development of DOCSIS 4.0 products, CableLabs and Kyrio are busy preparing for the next phase of technology development: conducting interoperability events. CableLabs has established a rigorous process for technology development starting with DOCSIS 1.0 technology and ultimately leading to the robust ecosystem that exists today. The company’s proven approach has worked successfully at CableLabs for the past 24 years: 

Phase 1                               Phase 2                              Phase 3

Phase 1 is the specification stage, when CableLabs, members and vendors come together to collaborate on defining the DOCSIS technology. Phase 1 for DOCSIS 4.0 was completed in 2019, when the specifications were written and suppliers have began implementation.

Phase 2 is when interoperability events (aka interops) occur at CableLabs in Louisville, Colorado to make sure that systems work together. As the term implies, interops are held to ensure that components of a DOCSIS system — including the base technology, security and support — are interoperable for easy installation and proactive customer care.

For DOCSIS 4.0 technology, CableLabs will be prepared to host the first interop event this year after  SCTE Cable-Tec Expo 2021 in Atlanta, where the show floor promises to hold several DOCSIS 4.0 technology demonstrations.

At this time, 12 DOCSIS 4.0 interoperability events are planned to begin in October 2021 and will run through December 2022. This near-monthly spacing will give suppliers the opportunity to attend, learn and then run a sprint to add new functionality for the next interop.

The early interops focus on basic functionality of the DOCSIS chipsets. As the schedule progresses, the focus will shift to adding more software functionality. Always, the emphasis will be on interoperable solutions, including the cable modem, cable modem termination system (CMTS) and software support systems. Going forward, the interops will include Remote PHY and Remote MACPHY devices.

Interoperability gives operators the confidence to plan large installations and the certainty that the equipment they purchase today will also work tomorrow. Customers can buy a modem and take it with them if they move into a new cable territory, worldwide. Interoperability provides a larger market in which suppliers can compete, which, in turn, allows for healthier ecosystems and varying strategies.

Phase 3, the certification stage, will happen naturally as the interoperability process produces more mature products and systems. We’ll talk more about this phase when that time approaches.

The interop phase can be a fun, invigorating time. Some of us have been working on the DOCSIS project for two decades, and there are always new entrants. As we shift back to working in our offices post-pandemic, we’re all looking forward working face-to-face in the lab—all in the effort to bring forward the next generation of cable broadband and deliver on the 10G promise.

Interoperability is paramount to the DOCSIS ecosystem. The DOCSIS community is encouraged to once again come together for these upcoming interoperability events, contributing and collaborating to keep the DOCSIS 4.0 ecosystem healthy and sustainable. This fall, CableLabs will be ready!

Building on our prior work, this investigation explores the hourly data consumption of popular video conferencing applications: Google Meet, GoToMeeting, Microsoft Teams and Zoom. As video conference applications have become an integral part of our daily lives, we wanted to not only better understand the bandwidth usage as previously explored, but also the total data consumption of these applications. This investigation provides a first step in better understanding that latter dimension. To avoid any appearance of endorsement of a particular conferencing application, we have not labeled the figures below with the specific apps under test. In short, we observed that a single user on a video conferencing application consumed roughly one gigabyte per hour, which compares to about three gigabytes per hour when streaming an HD movie or other video. However, we did observe substantial variance in video conferencing app hourly data consumption based on the specific app and end-user device.

Key Components of the Testing Environment

Much like our prior work on bandwidth usage, the test setup used typical settings and looked at both upstream and downstream data consumption from laptops connected to a cable broadband internet service. We used the same network equipment from November and our more recent blog post in February. This includes the same cable equipment as the previous blogs — the same DOCSIS 3.0 Technicolor TC8305c gateway, supporting eight downstream channels and four upstream channels, and the same CommScope E6000 cable modem termination system (CMTS). The cable network was configured to provide 50 Mbps downstream and five Mbps upstream broadband service, overprovisioned by 25 percent.

The data gathering scenario:

1. 10 people, each on their individual laptops, participated in the conference under test
2. One person on the broadband connection under test, using either a lower-cost or a higher-cost laptop. The other nine participants were not using the broadband connection under test.
3. For the laptop under test, the participant used the video conferencing application for the laptop’s operating system, rather than using the video conferencing application through the web browser.
4. Total data consumption was recorded for the laptop using the broadband connection under test.

For all 10 participants, cameras and microphones were on. Conference applications were set to "gallery mode" with thumbnails of each person filling the screen, no slides were presented and the video conference sessions just included people talking.

The laptop under test used a wired connection to the cable modem to ensure that no variables outside the control of the service provider would impact broadband performance. Most notably, by using a wired connection, we removed the variable of Wi-Fi performance from our test setup. During data collection, the conference app was the only app open on the laptop under test.

Video conferencing sessions were set up and data consumption was measured over time. We collected 10 minutes of data for each conferencing session under test to calculate the total consumption for one hour. The charts below show the data consumed for each of the 10 minutes of the conference session. During the conference there was movement and discussion to keep the video and audio streams active throughout the period of data collection.

For each test scenario, only one laptop was connected at a time to the broadband connection under test. Our goal was to measure the data consumption of one conferencing user on the broadband connection. The other conference participants were on the internet; they were not in the lab. Once again, we used TShark (a popular, widely used network protocol analyzer) to capture and measure the data.

For the laptop under test, we chose two that have quite different capabilities. The first was a low-cost laptop with an 11-inch screen, like the ones students are often provided by school districts for at-home learning. The second was a higher-cost laptop with a 15-inch screen, like what we often see in an enterprise environment. Note the two laptops not only have quite different hardware components (e.g., CPU, graphics processors, memory, cameras, screens), but also have different operating systems. Once again, to avoid any appearance of endorsement, we are not identifying the specific laptops used.

Analysis

Table 1 shows hourly bandwidth consumption (combining both upstream and downstream) for the laptop under test, normalized to Gigabytes per hour. The table provides the data consumption for the low-cost and higher-cost laptops in each scenario with the four conferencing applications.

Table 1: Video Conferencing App Hourly Bandwidth Consumption in Gigabytes for Each User (Gigabytes/hour)

The following figures show the data consumption, in Megabytes, for each minute of the 10-minute data collection for each of the permutations of our testing.

A few notes on the charts:

• There was only one client behind the cable modem.
• Each bar represents one minute of data consumption.
• Each bar shows total consumption and includes both the upstream and downstream, and both audio and video, added together.
• App A is blue in each chart; App B is green; App C orange; and App D is purple.
• These charts show real-time consumption measured in Megabytes per hour to illustrate consumption over time.

Figure 1 shows the data consumed when using the lower-cost laptop in the 10-person meetings.

Figure 2 shows data consumed each minute for each of the four apps when using the higher-cost laptop was in the 10-person meetings.

Figure 3 shows the data consumed each minute using App A and compares the two laptops used for data collection. For each minute, the bar to the left is the lower-cost laptop and the bar to the right is the higher-cost laptop.

Figure 4 shows the data consumed each minute using App B and compares the two laptops. The bar to the left is the lower-cost laptop and the bar to the right is the higher-cost laptop.

Figure 5 shows the data consumed each minute using App C and compares the two laptops. The bar to the left is the lower-cost laptop and the bar to the right is the higher-cost laptop.

Figure 6 shows the data consumed each minute using App D and compares the two laptops. The bar to the left is the lower-cost laptop and the bar to the right is the higher-cost laptop.

Key Observations

A. Data Consumption Varies: The first takeaway is that different apps consume different amounts of bandwidth, as shown in Table 1, from 0.5 GBytes per hour up to 3.4 GBytes per hour, for video conferences using the different laptops, the same broadband connections, the same general setup (e.g., gallery view), the same people doing the same things on camera, etc.

1. 1. For a  given app on a given laptop, data consumption was consistent over the 10-minute collection time.
   2. App D using the higher-cost laptop consumed the most bandwidth.
   3. With App D on the lower-cost laptop, there was video quality degradation. We confirmed the broadband connection was operating as expected and was not the cause of the video degradation. Rather, it appeared that the combination of the hardware and operating system of the lower-cost laptop was unable to meet the resource requirements of App D.
   4. App B consistently consumed less bandwidth regardless of scenario.

B. Comparing Laptops: In Table 1, the two columns of data show the differences between the lower-cost and higher-cost laptops for the data collections. On the lower-cost laptop, Apps A, B and C consume about the same amount of data on an hourly basis.

C. Comparing Laptops: The second column of data show that all apps on the higher-cost laptop consumed more bandwidth than the lower-cost laptop. This difference implies that when using the actual conferencing app (not a web browser), processing power available in the laptop may be a determining factor in consumption.

D. Comparing Apps: App C was the most consistent in data consumption regardless of the laptop used. The other conference applications noticeably consumed more on the higher-cost laptop.

In summary, we observed a more than 7X variation in the data consumption of video conferencing with a very limited exploration of just two variables – laptop and video conferencing application. Notably, however, when data consumption was at its highest, it was of the same magnitude as the data consumption of an HD video stream.

This is an area ripe for further research and study, both to more comprehensively explore these variables (e.g., other device types, larger meetings) and to explore other variables that may meaningfully influence data consumption.

As working from home and remote schooling remain the norm for most of us, we wanted to build on and extend our prior investigation of the bandwidth usage of popular video conferencing applications. In this post, we examine the use of video conferencing applications over a broadband service of 50 Mbps downstream and 5 Mbps upstream (“50/5 broadband service”). The goal remains the same, looking at how many simultaneous conferencing sessions can be supported on the access network using popular video conferencing applications. As before, we examined Google Meet, GoToMeeting, and Zoom, and this time we added Microsoft Teams and an examination of a mix of these applications. To avoid any appearance of endorsement of a particular conferencing application, we haven’t labeled the figures below with the specific apps under test.

We used the same network equipment from November. This includes the same cable equipment as the previous blog -- the same DOCSIS 3.0 Technicolor TC8305c gateway, supporting 8 downstream channels and 4 upstream channels, and the same CommScope E6000 cable modem termination system (CMTS).

The same laptops were also used, though this time we increased it to 10 laptops. Various laptops were used, running Windows, MacOS and Ubuntu – nothing special, just laptops that were around the lab and available for use. All used wired Ethernet connections through a switch to the modem to ensure no variables outside the control of the broadband provider would impact the speeds delivered (e.g., placement of the Wi-Fi access point, as noted below). Conference sessions were set up and parameters varied while traffic flow rates were collected over time.  Throughout testing, we ensured there was active movement in view of each laptop’s camera to more fully simulate real-world use cases.

As in the previous blog, this research doesn’t take into account the potential external factors that can affect Internet performance in a real home -- from the use of Wi-Fi, to building materials, to Wi-Fi interference, to the age and condition of the user’s connected devices -- but it does provide a helpful illustration of the baseline capabilities of a 50/5 broadband service.

As before, the broadband speeds were over-provisioned. For this testing, the 50/5 broadband service was over provisioned by 25%, a typical configuration for this service tier.

First things first: We repeated the work from November using the 25/3 broadband service. And happily, those results were re-confirmed. We felt the baseline was important to verify the setup.

Next, we moved to the 50/5 broadband service and got to work. At a high level, we found that all four conferencing solutions could support at least 10 concurrent sessions on 10 separate laptops connected to the same cable modem with the aforementioned 50/5 broadband service and with all sessions in gallery view. The quality of all 10 sessions was good and consistent throughout, with no jitter, choppiness, artifacts or other defects noticed during the sessions. Not surprisingly, with the increase in the nominal upstream speed from 3 Mbps to 5 Mbps, we were able to increase the number of concurrent sessions from the 5 we listed in the November blog to 10 sessions with the 50/5 broadband service under test.

The data presented below represents samples that were collected every 200 milliseconds over a 5-minute interval (300 seconds) using tshark (the Wireshark network analyzer).

Conferencing Application: A

The chart below (Figure 1) shows total access network usage for the 10 concurrent sessions over 300 seconds (5 minutes) while using one of the above conferencing applications. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that the total upstream usage stays around 2.5 Mbps which may be a result of running 10 concurrent sessions. Also, the downstream usage stays, on average, around 15 mbps, which leaves roughly 35 Mbps of downstream headroom for other services such as streaming video that can also use the broadband connection at the same time.

Figure 2 shows the upstream bandwidth usage of the 10 concurrent sessions and it appears that these individual sessions are competing amongst themselves for upstream bandwidth. However, all upstream sessions typically stay well below 0.5 Mbps -- these streams are all independent, with the amount of upstream bandwidth usage fluctuating over time.

Figure 3 shows the downstream bandwidth usage for the 10 individual conference sessions. Each conference session typically uses between 1 to 2 Mbps. As previously observed with this application, there are short periods of time when some of the sessions use more downstream bandwidth than the typical 1 to 2 Mbps.

Conferencing Application: B

Figure 4 shows access network usage for 10 concurrent sessions over 300 seconds (5 minutes) for the second conferencing application tested. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that the total upstream usage hovers around 3.5 Mbps.  The total downstream usage is very tight, right above 10 Mbps.

Figure 5 shows the upstream bandwidth usage of the 10 individual conference sessions where all but one session is well below 1 Mbps and that one session is right at 2 Mbps.  We don’t have an explanation for why that blue session is so much higher than the others, but it falls well within the available upstream bandwidth.

Figure 6 shows the downstream bandwidth usage for the 10 individual conference sessions clusters consistently around 1 Mbps.

Conferencing Application: C

Figure 7 shows access network usage for the 10 concurrent sessions over 300 seconds (5 minutes) for the third application tested. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that the total upstream usage hovers right at 3 Mbps over the 5 minutes.

Figure 8 shows the upstream bandwidth usage of the 10 individual conference sessions where all stay well below 1 Mbps.

Figure 9 shows the downstream bandwidth usage for the 10 individual conference sessions. These sessions appear to track each other very closely around 2 Mbps, which matches Figure 7 showing aggregate downstream usage around 20 Mbps.

Conference Application: D

Figure 10 shows access network usage for the 10 concurrent sessions over 300 seconds (5 minutes) for the fourth application tested. The blue line is the total downstream usage, and the orange line is total upstream usage. Note that the total upstream usage hovers right at 5 Mbps over the 5 minutes, and there is no visible degradation to the conferencing sessions was observed.

Figure 11 shows the upstream bandwidth usage of the 10 individual conference sessions, where there is some variability in bandwidth consumed per session.  One session (red) consistently uses more upstream bandwidth than the other sessions but remained well below the available upstream bandwidth.

Figure 12 shows the downstream bandwidth usage for the 10 individual conference sessions. These sessions show two groups, with one group using less than 1 Mbps of bandwidth and the second group using consistently between 2 Mbps and 4 Mbps of bandwidth.

Running All Four Conference Applications Simultaneously

In this section, we examine the bandwidth usage of all four conferencing applications running simultaneously. The test consists of three concurrent sessions from two of the applications and two concurrent sessions from the other two applications (once again a total of 10 conference sessions running simultaneously). The goal is to observe how the applications may interact in the scenario where members of the same household are using different conference applications at the same time.

Figure 13 shows access network usage for these 10 concurrent sessions over 300 seconds (5 minutes). The blue line is the total downstream usage, and the orange line is total upstream usage. Note that the total upstream usage once again hovers around 5 Mbps without any visible degradation to the conferencing sessions, and the downstream usage is pretty tight right above 10 Mbps.

Figure 14 shows the upstream bandwidth usage of the 10 individual conference sessions where several distinct groupings of sessions are visible. There were 4 different apps running concurrently. One session (red) consumes the most upstream bandwidth at averaging around 2 Mbps, whereas the other sessions use less, and some much less.

Figure 15 shows the downstream bandwidth usage for the 10 individual conference sessions across the four apps and, again, there are different clusters of sessions. Each of the four apps are following their own algorithms.

In summary, with a 50/5 broadband service, each of the video-conferencing applications supported at least 10 concurrent sessions, both when using a single conferencing application and when using a mix of these four applications. In all cases, the quality of the 10 concurrent sessions was good and consistent throughout. The 5 Mbps of nominal upstream bandwidth was sufficient to support the conferencing sessions without visible degradation, and there was more than sufficient available downstream bandwidth to run other common applications, such as video streaming and web browsing, concurrently with the 10 conferencing sessions.