Comments
DOCSIS

Webinar Recap: Enabling Cable Networks for Mobile Backhaul

Jennifer Andreoli-Fang
Distinguished Technologist, Office of the CTO / R&D

Feb 23, 2018

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.

Comments
Wired

Pinpointing Signal Leakage and Noise Ingress Demo

Tom Williams
Principal Architect, Network Technologies

Feb 15, 2018

The CableLabs Proactive Network Maintenance (PNM) effort develops technologies and systems to proactively detect network problems before they impact the customer. In essence, our revolutionary technology turns every cable modem into a troubleshooting device, transferring that information to cable operators. Deploying PNM technologies results in faster and more accurate diagnoses of problems, faster repairs and ultimately a happier customer - all of which lead to lower costs for cable operators.

One of our PNM efforts tackles signal leakage and noise ingress.

The demonstration in our video is of an automatic data capture system that could be mounted on a vehicle that normally spends much of the day driving through neighborhoods, such as a garbage truck, a dry cleaning delivery service, or a taxi cab. The system can be completely automated to capture, upload, process and prioritize network maintenance. Watch our video below to learn more about this groundbreaking technology.

Don't forget to subscribe to our blog to stay current with our PNM effort.

Comments
DOCSIS

Enabling the Cable Networks for Mobile Backhaul

Jennifer Andreoli-Fang
Distinguished Technologist, Office of the CTO / R&D

Feb 14, 2018

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.

Mobile Backhaul DOCSIS Latency Today

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)

mobile backhaul pipelining

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.

Mobile Backhaul Ping Pockets

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 15th 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.

Comments
Virtualization

Container Workloads: Evolution of SNAPS for Cloud-Native Development

Feb 8, 2018

Application developers drive cloud-platform innovation by continuously pushing the envelope when it comes to defining requirements for the underlying platform. In the emerging application programming interface (API) and algorithm economy, developers are leveraging a variety of tools and already-built services to rapidly create new applications. Edge computing and Internet-of-Things (IoT) use cases require platforms that can be used to offload computing from low-power devices to powerful servers. Application developers deliver their software in iterations where user feedback is critical for product evolution. This requires building platforms that allow developers to develop new features rapidly and deploy them in production. In other words, to adopt DevOps.

In the telecommunications world, network function virtualization (NFV) is driving the evolution of telco clouds. However, the focus is shifting towards containers as a lightweight virtualization option that caters to the application developer’s requirements of agility and flexibility. Containerization and cluster-management technologies such as Docker and Kubernetes are becoming popular alternatives for tenant, network and application isolation at higher performance and lower overhead levels.

Container is an operating system level virtualization that allows execution of lightweight independent instances of isolated resources on a single Linux instance. Container implementation like Docker avoids the overhead and maintenance of virtual machines and helps in enabling portability and flexibility of applications across public and private cloud infrastructure.

Microservice architectures are enabling developers to easily adopt the API and algorithm economy. It has become imperative that we start to look at containers as an enabler for carrier-grade platforms to power new cloud-native applications.

Edge computing and IoT require containers

Edge Computing and IoT are introducing new use cases that demand low-latency networks. Robotics, autonomous cars, drones, connected living, industrial automation and eHealth are just some of the areas where either low latency is required, or a large amount of data needs to be ingested and processed. Due to the physical distance between the device and public clouds, the viability of these applications depends on the availability of a cloud platform at the edge of the network. This can help operators and MSOs leverage their low-latency access networks—their beachfront property—to enable such applications and create new revenue streams. The edge platforms require cloud-native software stacks to help “cloud-first” developers travel deep inside the operators’ networks and make the transition frictionless.

On the other hand, the devices also require client software, which can communicate with the “edge.” The diversity of such devices such as drones, sensors or cars makes it difficult to install and configure software. Containers can make life easier since they require a version of Linux operating system and container runtime to launch, manage, configure and upgrade software to any device.

The role of intelligence and serverless architectures in the carrier-grade platform

Let’s consider the example of a potential new service for real-time object recognition. By integrating artificial intelligence (AI) and machine learning (ML) algorithms, operators can enhance the edge platform so developers can create applications for pedestrian or obstacle detection in autonomous driving, intrusion detection in video surveillance and image and video search. The operator’s platform that hosts such applications needs to be “intelligent” to provide autonomous services. It requires the ability to host ML tools and support event-driven architectures where computing can be offloaded to the edge on-demand. Modern serverless architectures could be a potential solution for such requirements, but containers and cloud-native architectures are a near-perfect fit.

Are containers ready for carrier-grade workloads?

Containers as a technology have existed for over a decade. Linux containers and FreeBSD Jails are two early examples. However, it was not easy to network or manage the lifecycle of containers. Docker made this possible by simplifying container management and operations, which led to the ability to scale and port applications through containers. Today, the Open Container Initiative of the Linux Foundation is defining the standards for container runtime and image formats. APIs provided by container runtimes and additional tools help abstract low-level resource management of the environment for application developers. Container runtimes can download, verify and run containerized application images.

The production applications are typically composed of several containers that can independently scale. To manage such deployments, new software ecosystems have emerged that primarily orchestrate, manage and monitor applications across multiple hosts. Kubernetes and Docker Swarm are examples of such solutions, commonly called container orchestration engines (COE).

Some of the key challenges for carrier-grade deployments of container-based platforms are:

  • Complex networking with several alternatives for overlay and underlay networks within a cluster of containers
  • Lack of well-defined resource-management procedures like isolating containers with huge pages, CPU pinning, GPU sharing, inter-POD, node-affinity, etc.
  • Complex deployment techniques are required to deploy multi-homed PODs
  • Large ecosystems for securing container platforms as it is not easy to deploy and manage large container security solutions

SNAPS and Containers

SNAPS, which is short for SDN/NFV Application Development Platform and Stack, is an open-source platform developed by CableLabs. The platform enables rapid deployment of virtualized platforms for developers. SNAPS accelerates adoption of virtual network functions by bootstrapping and configuring a cloud platform for developers so they can focus on their applications. Aricent is involved in the SNAPS-OpenStack and SNAPS-Boot projects and contributed to the platform development with CableLabs.

An obvious next phase is to enable containerized platforms. A key first step was already achieved in the SNAPS-OpenStack project where Docker containers are used for executing many OpenStack components. The next obvious step is to create a roadmap for enabling containers for application developers. A cursory look at the cloud-native landscape reveals that this ecosystem is huge. There are several options available for DevOps, tooling, analytics, management, orchestration, security, serverless, etc. This can create confusion for developers regarding what to use and how to configure these components. They will have to “learn” the ecosystem, which will delay their own application development. The future roadmap for SNAPS is to enable developers by bootstrapping a secure and self-service container platform with the following features:

  • Container orchestration and resource management
  • In-built tooling for monitoring and diagnostics
  • A reference microservices architecture for application development
  • Easy management and deployment of container networking
  • Pre-configured and provisioned security components
  • DevOps-enabled for rapid development and continuous deployment

These are exciting times for developers. The availability of platforms and technologies will drive innovation throughout the developer community. The SNAPS community is focused on ensuring that the best-in-class developer platforms are created in the spirit of open innovation. The SNAPS platform roadmap adopting cloud-native ecosystem is going to provide developers an easy-to-use platform. We are looking forward to a larger participation for the developer and operator community. As a community, we must solve the key challenges and create a resilient platform for containerized application platform for network applications.

Have Questions? We’d love to hear from you: 

--

The author, Shamik Mishra, is the Assistant VP of Technology at Aricent. SNAPS, CableLabs’ SDN/NFV Application Development Platform and Stack Project, was developed leveraging the broader industry’s open source projects with the help of the Software Engineering team at Aricent. CableLabs selected Aricent for this specific project because of their world-class expertise in software-defined networks and network virtualization. In a little less than a year, CableLabs and Aricent worked closely to extend CableLabs’ initial code base to the full SNAPS platform. The SNAPS platform has now been released to open source to enable the wider industry to collaboratively build on our work and to use it to test new network approaches based on SDN and NFV.

Comments
Wired

CableLabs Remote MACPHY Project Launches

Feb 7, 2018

Last month, we announced the launch of the Remote MACPHY working group. As part of our Distributed CCAP Architecture program (DCA), the Remote MACPHY working group is comprised of operators, equipment manufacturers, and CableLabs’ engineers that help cable operators distribute their access networks. The charter is to develop one or more specifications that allow vendors’ Remote MACPHY solutions to interoperate when deployed.

Remote MACPHY Background

The cable industry has been working on replacing the old Cable Modem Termination Systems (CMTSs) with a Converged Cable Access Platform (CCAP) for some time. CCAP hardware simplifies the network by putting ports for both data and cable video on a single device, saving space and power. Now that operators have transitioned to CCAP, there has been a movement to distribute those functions out of the headened, closer to the edge of the network. This is being done through Remote MACPHY and Remote PHY. These Distributed Access Architectures provide several key benefits to the Hybrid Fiber Coax (HFC) networks that deliver cable TV and broadband and we highlight Remote MACPHY in our video below. 

Watch now to learn more about Remote MACPHY technology and its benefits.

For more information or to join the Remote MACPHY working group contact Jon Schnoor. Participants must sign a DOCSIS non-disclosure agreement and a DOCSIS IP right agreement. Don't forget to subscribe to our blog to stay current on our work in Remote MACPHY.

Comments
Wireless

A Step Towards Better Wi-Fi

John Bahr
Lead Architect, Wireless Technologies

Feb 2, 2018

CableLabs is excited about the publication of the Wi-Fi Multi Access Point (AP) Specification draft by Wi-Fi Alliance®. With the release of this draft specification, the Wi-Fi industry is moving towards greater interoperability and coordination between APs from different vendors. The Wi-Fi Multi Access Point (AP) Specification defines the control protocol, as well as the underlying data objects, that will allow access points to talk to each other using a common language. This topic is near and dear to our hearts, so we at CableLabs helped develop this specification and are contributing to the forthcoming Multi-AP certification program.

Need for Multiple APs in the Home

As my previous blog post, Multiple Access Point Architectures and Wi-Fi Whole Home Coverage explains, Wi-Fi is an integral part of just about every home today. As consumers, we expect ubiquitous high-speed coverage wherever we are in our home. However, as both home sizes and client device counts increase, the traditional Wi-Fi setup using a single AP in a home, is increasingly incapable of meeting these expectations. This is especially true for buildings that contain signal interfering materials in the walls, floors and/or ceilings (e.g. HVAC metal ducts, mesh wire supported plaster, brick, and concrete).

To address this problem, many people try to build their own high-performance network in their home by deploying multiple access points.

An access point is a device that creates a wireless local area network, or WLAN, usually in an office or large building. An access point connects to, or is packaged together with, a wired router, switch, or hub via an Ethernet cable or via another Wi-Fi signal, and projects Wi-Fi to a location in your home or business. (How large this location is depends on many factors, but is called the coverage area).

One drawback to the solutions currently available is vendor lock-in. Once you’ve chosen a brand, you’re stuck with that brand and its proprietary chatter between APs. This is because, until now, there has been no standard AP coordination protocol. As the idea has grown in popularity in recent years, moving from the enterprise networks we use at work to the APs we use in our homes, vendors have created their own protocols along the way.

To help standardize the interface between APs, the Wi-Fi Alliance Multi-AP specification defines procedures for:

  • Onboarding and automatic configuration of new APs
  • Control and management of the APs
  • Client steering mechanisms that allow the system to move Wi-Fi clients to the best AP and band (2.4 GHz or 5GHz) to ensure fast connection speeds

These standard procedures enhance the capabilities of the APs, allow vendors to innovate and focus on other cool features and enables a better customer experience. To the end user, this means:

  • Adding new APs to enhance coverage in your house is easier
  • Your cable operator can help remotely ensure that the system is working correctly
  • Your devices seamlessly move from one AP to another as you move around your house, maintaining the highest quality connection

Specifications move the industry forward

Standard interfaces are great; they make the internet work. As an idea gains popularity, to help keep the industry from splintering, defining a standard way of doing it becomes more and more valuable. Standards do just that - they provide a common way to do things, a reference to certify equipment against and help grow new technology ecosystems. CableLabs contributes to specifications in many standards development organizations, including Wi-Fi Alliance, Wireless Broadband Alliance, Broadband Forum, IEEE and MoCA.

Along with the release of the new Wi-Fi Multi-AP draft specification, Wi-FI Alliance is working toward introducing a certification program based upon the specification. To take a deeper dive, you can download the draft Multi-AP Technical Specification on the Wi-Fi Alliance Specifications page here.

CableLabs has been working on multiple APs in the home solutions since 2015 with numerous R&D projects. Subscribe to our blog to stay current with our work on Multi APs.

 

Comments
DOCSIS

Full Duplex DOCSIS® Technology Gets MAC Layer Support

Karthik Sundaresan
Principal Architect, Network Technologies

Jan 30, 2018

Full Duplex DOCSIS® 3.1 (FDX) is an update and extension 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 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 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 operation on the hybrid-fiber-coax (HFC) link.  It is focused on MAC management messaging and operation needed to enable FDX between the CMTS (Cable Modem Termination System) and CM (Cable Modem). This includes FDX 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 CMTS will simultaneously receive and transmit in the same FDX spectrum, while FDX CMs can either receive or transmit in the same FDX spectrum. Thus, communication is full duplex from the perspective of the CMTS but frequency division duplex from the perspective of the CM.

The FDX 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 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 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.

Full Duplex DOCSIS® MAC Layer Support

What’s Next for the Full Duplex DOCSIS 3.1 Technology?

As the FDX 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 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.
  • We have initiated work for the changes needed to support FDX within the Remote PHY realm. (FDX 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 products, the feedback loop into the FDX specifications remains open and the PHY & MAC specifications continue to be refined.

Full Duplex DOCSIS 3.1 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.

 

FDX MAC Layer Support

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. 

Comments
Virtualization

Kyrio NFV Interop Lab: Powered by SNAPS

Robin Ku
Director, Kyrio NFV Interop Lab

Jan 25, 2018

On Dec. 14, 2017, CableLabs released two new open source projects, SNAPS-Boot and SNAPS-OpenStack. SNAPS, which is short for SDN/NFV Application Development Platform and Stack, is an open source platform with the following objectives:

  • Speed development of cloud applications
  • Facilitate collaboration between solution providers and operators
  • Ensure interoperability
  • Accelerate adoption of virtual network functions and platform components.

In this post, we explore some of the synergies between the SNAPS projects and the Kyrio NFV Interop Lab.

Background: Delivering on the NFV Promise

The Kyrio NFV Interop Lab is designed as an open, collaborative system integration environment where multiple solution providers can work together in a neutral setting to develop concept systems and then showcase them to the operator community.

At last year’s Summer Conference, we displayed proof-of-concept systems demonstrating orchestrated deployment of SD-WAN with firewalling and LTE to WiFi call hand-off over a D3.1 R-PHY access network connected to a virtual CCAP Core and a virtual mobile core.

These technologies are fundamental enablers for converged networks composed of virtualized network functions running on virtual network cores. The SD-WAN, firewall and mobile calling use cases represent a significant opportunity for operators to offer efficient, flexible and agile services to their customers.

The systems were envisioned and designed by Kyrio NFV Lab sponsoring partners, integrated at CableLabs, and demonstrated at the CableLabs Summer Conference. They remain on display in the Kyrio NFV Lab in order to provide operators with ongoing access to the systems and to enable solution providers to continue development of new functions and features. Further system details are available in this webinar.

Running on Open Source: The Way of the Future

Kyrio NFV Lab systems are designed by lab sponsors using a variety of hardware and software components. However, open source software and generic commercial-off-the-shelf (COTS) hardware are the preferred environment for operators. To that end, SNAPS has been developed to provide a cloud environment that is freely available to operators and developers, based on and synchronized to OPNFV OpenStack, one of the world’s largest open source projects delivering cloud software.

Project code is publicly available and located here:

SNAPS-Boot: Automates the imaging and configuration of servers that constitute a cloud.

SNAPS-OpenStack: Automates the deployment of the OpenStack VIM on those servers.

Together they provide a powerful method for creating a standard development and testing environment.

For details on project objectives, timelines and participation contact Randy Levensalor, the SNAPS project lead. 

The Mobile Call Hand-off system mentioned above was built on a beta version of SNAPS, based on Newtown OpenStack. New systems in the Kyrio NFV Lab are running on the public release of SNAPS, based on Pike OpenStack. OpenStack synchronization is a key benefit for operators, solution developers and interop testing.

Kyrio NFV Lab: Taking the Next Steps

New system development planned for the next two quarters include orchestration of multi-vendor software firewalls and orchestration of a virtual CCAP Core.

Latest generation Intel COTS servers have arrived featuring dual Xeon 6152 CPUs (44 cores/host), 364 GB RAM, four 1 TB SSDs, plus two 250 GB SSDs and multiple 40/10 Gbs NICS.

Evaluation is underway to determine data throughput under various BIOS settings, using select versions of Linux. Work is also underway to measure power consumption baselines under various load conditions.

A stable, well-characterized hardware/software platform is the foundation of the Kyrio NFV Lab’s work toward evaluation of SDN/NFV component interoperability, and Virtual Network Function on-boarding. The main questions operators will ask when considering trial or deployment of a virtual application will be:

  • “Does it work as designed?”
  • “Does it interoperate with other elements in my environment?”
  • “How easy is it to deploy?”

These are the questions that the Kyrio NFV Lab, working over the SNAPS platform, will consider on behalf of the operator community. The faster we can answer “Yes”, “Yes” and “Very”, the faster the ecosystem will advance, the faster operators will adopt, and the faster customers will have access to newer and more reliable services. Stay tuned for progress updates from the Kyrio NFV Interop Lab - powered by SNAPS.

For further information or Kyrio NFV Lab programs and participation opportunities:

Email: Robin Ku, Director Kyrio NFV Lab

For further information on SNAPS and open source software development:

See Broadband Technology Report’s article and Randy Levensalor's blog post "CableLabs Announces SNAPS-Boot and SNAPS-OpenStack Installers

Email: Randy Levensalor, Lead Architect Application Technologies

For CableLabs members:

Attend the Inspir[ED] NFV workshop February 13-15, in Louisville CO, for business and technical track sessions and access to all demo systems.

 

Comments
Strategy

CableLabs Asia Summit – Impact with a Difference

Chris Lammers
Chief Operating Officer

Jan 19, 2018

On December 6-7, CableLabs hosted its first CableLabs Asia Summit and, by all accounts, it was a genuine success. We invited cable’s top leaders from across Asia – including our members in Australia, China, Indonesia, Japan, Singapore and Taiwan – to come together to in Shanghai gain insight, collaborate and learn about the innovation impacting our networks.

CableLabs, together with nine of our members in Asia and key technology leaders from Comcast in the US and Liberty Global in Europe and Latin America, spent two days of complete immersion developing a greater understanding of the unique business, operations and competitive dynamics of the cable operators in Asia, exploring technologies advancing the competitive positioning of operators today, and the innovative technologies that will assure cable’s competitive positioning in the future. Three additional cable operators from China participated in the first day of the summit by way of exploring membership with CableLabs.

All in, 61 individuals across 14 MSOs, CableLabs, and other participants contributed to a highly interactive event. With NPS scores of 75 and 88 across the two days of the summit, value was very much delivered, success defined not only through the content provided by CableLabs, but equally so by way of presentations from across several of our members.

CableLabs presented:

  • How innovation is done at CableLabs – and how we are bringing the technologies of the future to reality
  • LPWAN IoT opportunities through CableLabs open source LoRa server solution
  • Wired and wireless proactive network maintenance
  • Machine learning and AI with applications for full band capture for proactive network maintenance, multicast channels for predictive video lineups, cable modem and set-top box patterns to monitor network health
  • DOCSIS roadmap – including Full Duplex DOCSIS technology by which cable’s HFC networks can deliver up to 10 Gbps symmetrical speeds
  • Coherent optics enabling substantially greater capacity over the same fiber
  • 5G and wireless technologies enabling converged networks

Topics presented by our members:

  • Comcast provided an overview of its network strategy
  • Liberty Global outlined their customer premise equipment (CPE) strategy
  • Presentations from our Asian members provided an overview of some of the advanced technologies implemented in their respective regions, including facilitating intelligent communities from Wasu Digital Media, OTT and Android STB solutions implemented by Taiwan Broadband Communications, functional requirements for development of the C-DOCSIS 2.0 specification in China led by Gcable, led by Gcable, and broadcasting video content to connected devices by Henan Cable
  • CTO roundtable with senior technical leadership from Beijing Gehua, Chongqing Cable Network, J:COM from Japan and Shenzhen Topway exchanged insights to technical, strategic and competitive challenges confronting their businesses.

Projecting our support internationally by way of regional events is a critical part of our strategy at CableLabs. Through summits and conferences delivered in the regions we represent around the world, we are able to:

  • More effectively support member engagement through exchanges and interaction between CableLabs and our members
  • Develop critical insights and gain a deeper appreciation of issues that are driving our members in each region
  • Assure that the technologies CableLabs is developing are universally applicable across all members
  • Create and develop collaboration and community between and across members
  • Foster ideas and strategies that feed an innovation engine by way of developing innovative technologies that can be applied across our members

Are you a European member – or a member elsewhere across the regions we serve – interested in collaborating with and learning from your fellow European members? Register now and join cable’s top executives across Europe to gain insight and learn more about future innovative technologies at Inform[ED] Europe May 3-4 in London.

Comments
Culture

Meet CableLabs Tech Policy Whisperer Rob Alderfer

Jan 17, 2018

Spectrum is the bandwidth in the sky that has fueled our wireless technology revolution. However, there's been a lot of talk about spectrum shortages recently. With an essential resource in such high demand, the focus has become how do we free up more spectrum and make the best of what we have? Now, meet the man shaping technology policy and standards to meet these challenges.

Rob Alderfer is Vice President of Technology Policy at CableLabs. An expert in wireless spectrum, Rob is responsible for CableLabs’ technology policy and standards strategy. His team has been instrumental in the development of wireless spectrum and broadband policy, as well as cybersecurity and energy efficiency standards.

Rob has been involved in communications technology policy for over a decade. Before joining CableLabs, he was the Chief Data Officer for the Federal Communications Commission’s Wireless Bureau, where he guided United States wireless broadband policy. While at the FCC, Rob engaged regularly with the Chairman and other senior Commission leaders as a trusted advisor on spectrum policy and data analysis. Previously, he was an analyst at the White House Office of Management and Budget and was responsible for the development and implementation of communications policy and programs across two administrations.

Outside of CableLabs, Rob serves as chair of the Telecommunications Policy Research Conference (TPRC) program committee, the world's foremost communications policy research conference. He is also a partner with Social Venture Partners of Boulder County, helping non-profits deliver strong results. When not preparing policy, you may find him enjoying beautiful Colorado with his family, hiking, biking, and skiing.

Now, watch the video below to learn more about the man working on freeing up spectrum for broadband use.

 


You can read more about what Rob’s working on in his blog posts and Inform[ED] Insights: “Cable: 5G Wireless Enabler” and “Cable Broadband Technology Gigabit Evolution.” Subscribe to our blog to learn more about CableLabs and spectrum in the future.

 

Comments