AI & Machine Learning: Register for Our Next Innovation Boot Camp in April 2019
No matter your title or job description, you probably hear the term “innovative” a lot around your office. It’s what drives all of us to come to work, push boundaries and solve the unsolvable. Sounds inspiring, but how do you become innovative or lead others to be more innovative? This is the premise behind CableLabs’ Innovation Boot Camp, an intensive three-and-half-day workshop that helps you understand a more predictable way to generate breakthrough ideas and uses proven strategies, real-world scenarios and small group exercises to ignite your innovation leadership skills.
2019 Innovation Boot Camp: The New Assistants - AI & Machine Learning
We usually structure our Innovation Boot Camps around a single area of focus and this April’s topic is “The New Assistants: AI & Machine Learning.” It’s a hotly debated topic and an area ripe for innovation. Just consider the latest announcements at CES 2019, where smart appliances and virtual assistances of all shapes and sizes were capturing our imagination. During your time at Innovation Boot Camp, we will discuss the latest breakthroughs in AI as well as the challenges faced by the innovators in this field. And you will have the opportunity to practice innovation and generate new ideas in this space.
Why You Should Attend
Participants often describe CableLabs’ Boot Camp experience as an intense learning journey that teaches you how to apply new creative practices, build on your influence and present your best ideas with more confidence. It’s also a great networking opportunity that allows you to foster valuable relationships with a whole community of innovators.
But don’t take our word for it. Here’s what our Boot Camp graduates have to say about the program:
- Jeremy Swenson, an Operation Analyst from Midco, said: “It brought a lot of common-sense approaches, but also a lot of new information that I never would have thought about—new tools and strategies that I can take to my company and implement on day one.”
The Boot Camp program is based on the FIRE framework for Innovation (Focus, Ideate, Rank, Execute) developed by author, radio host and our CEO, Phil McKinney. Each exercise is designed to build on new information and show you how it could be put into practice immediately. Even if you’ve never thought of yourself as the “creative type,” our skilled innovation coaches and speakers will show you how you can become one. By the end of the program, you will build an arsenal of useful strategies that will help you generate and pitch ideas in your professional sphere.
- Pam Lloyd, a VP from G.C.I, said: “The external speakers were all top notch and each one built on the framework…the flow was great!”
Aside from our own CableLabs innovation experts, we like to bring in industry leaders from external companies. Because this year’s Innovation Boot Camp is focused on AI and Machine Learning, we will select experts from this field. They’ll share their thoughts on the future of AI and its current progress as well as the role of innovation in their lives.
- Sian Morgan, a Senior Director from Videotron, said: “The tours were great. We got to see innovation in more of a working context by visiting large organizations that were integrating innovation into their day-to-day work.”
If you think our Boot Camp is all lectures and group exercises, think again. Our participants go out in the field for private tours of Silicon Valley companies that are known for their focus on innovation and are willing to share the truth about it (in the past we have toured Google, Salesforce, Toyota, Ford, Autodesk, etc.)
The Final Pitch
Our Innovation Boot Camp is designed to foster innovation leadership skills in industry professionals. In other words, it’s all about you, and building your skills and a custom toolkit which you can then take back to your team. That’s why the program culminates with what we like to call “the final pitch” where you will get to demonstrate your newly-learned skills by pitching your idea to a panel of battle-tested innovators. It’s a fantastic opportunity to test yourself and get valuable feedback that you can incorporate in real life.
Ready for your next Innovation Boot Camp? Early bird pricing is still available - register today!
CableLabs Silicon Valley
400 W California Ave
Sunnyvale, CA 94086
April 9-12, 2019
CableLabs Members Early Bird Discount: $997 (Register before February 8)
CableLabs Members: $1,347
General Industry Early Bird Discount: $1,497 (Register before February 8)
General Industry: $1,997
Pricing includes all materials, tours, meals and beverages. You will need to provide your own transportation and hotel (special hotel discounts available).
The Profile Management Application: Optimizing DOCSIS® 3.1 Networks
Cable operators are broadly deploying DOCSIS 3.1 technology around the world. Operators in North America and Europe have announced gigabit service offerings that use the technology across their footprint. In this blog, I focus on techniques by which operators can boost the capacity and robustness of their existing DOCSIS 3.1 network.
Introducing Toolsets for Optimizing the DOCSIS 3.1 Network
DOCSIS 3.1 specifications introduced orthogonal frequency division multiplexing (OFDM) technology to the access network. In DOCSIS 3.0 and prior technologies, a single-carrier downstream channel (6 MHz) would be configured with just the one modulation order (say, 256-QAM). The DOCSIS 3.1 technology divides a wider (e.g. 192 MHz) channel into a number of small subcarriers spaced at 25 kHz or 50 kHz apart, creating up to 7600 subcarriers. These subcarriers can be individually configured to operate at a different modulation order, anywhere from 256-QAM, to 1024-QAM, all the way to 4096-QAM.
A specific configuration of modulation orders for every subcarrier in the OFDM channel is known as a “profile.” A cable modem termination system (CMTS) can use multiple profiles on a channel; profiles differ in the modulation orders assigned to each subcarrier.
Different modems experience the network in different ways. Some modems may have a noisier environment, whereas others see a relatively clean plant. The figure shows an example of the interference seen by a modem in part of the OFDM channel.
Profiles allow the channel to operate at a higher modulation order in clean parts of the spectrum and then go down to more robust modulation orders when there is any interference present. The idea with multiple profiles is to have the CMTS use different profiles for such different groups of cable modems. This allows the operator to reach two goals:
- minimize transmission errors on the network and
- maximize network capacity.
The same concept applies to upstream OFDMA channels, where one can create upstream profiles for the channel, to increase reliability and throughput.
The Profile Management Application (PMA) Solution
If there are say 4 OFDM channels per port, 10 ports per line-card, and 10 line-cards on a CMTS, then there could be easily over a couple of million subcarriers requiring a specific configuration! This represents an immense configuration challenge which cannot be solved manually. This problem is made more difficult because profiles are not typically “one size fits all,” but rather they need to be tailored to the set of cable modems on the channel, the interference on the channel, and they also need to adjust to plant changes over time. The question then becomes: What is the most efficient method for automating the creation of multiple profiles to maximize robustness and capacity?
I am pleased to announce that CableLabs has met this tremendous challenge with the introduction of the Profile Management Application (PMA). The PMA creates a set of optimal profiles for each channel and assigns profiles to modems. And the PMA accomplishes this dynamically by proactively reading data collected from the network. The PMA can create optimized modulation profiles periodically, as well as backup profiles in case of errors. It can also intelligently decide when to roll out profile changes to the network. A single PMA instance can create and configure profiles for a number of CMTSs in a short period of time and help the operator understand the data capacity of each channel.
How It Works—PMA Architecture and Algorithms
CableLabs released a PMA Technical Report that describes the PMA architecture, use cases, and interface definitions. We also developed data models (YANG) and protocols to facilitate the design of a software application to configure and manage modulation profiles.
Determining the optimal set of modulation profiles to use on a DOCSIS 3.1 channel is a task for intelligent software, given the number of modems, the number of subcarriers and the differences in signal quality across the channel each modem experiences. This CableLabs paper on profile management algorithms describes methods to optimally compute the profiles. The paper also introduces a metric indicating the capacity gain a set of profiles obtains compared with running all traffic at 256-QAM. The key idea is to use clustering algorithms to group modems that have similar signal-to-noise signatures across the channel and then design a profile for each group. The PMA algorithm searches for the best set of profile definitions to maximize the overall capacity and at the same time keeps the individual profiles robust to observable interference patterns.
Some of the information that a PMA needs to compute the profiles includes the channel information from a CMTS, list of modems and network signal quality metrics (mainly, each modem’s per subcarrier RxMER data). Also using performance data (e.g., codeword error rates), a PMA can further refine the profiles.
How It Works—Deployment
A PMA field deployment would include the following:
- Data Collection: A centralized server is needed for modems and CMTSs to upload signal quality data. Operators can use the CableLabs DOCSIS Common Collection Framework (DCCF) to implement this.
- PMA: Using the data collected, this application creates optimized profiles per channel. It configures these profiles on the CMTS, assign CMs to profiles and can initiate performance tests.
- CMTS: Configures profiles for the individual channels, assigns the modulation profiles to CMs and ultimately sends/receives data using the profiles.
- CMs: Cable Modems use the profiles defined and assigned by the CMTS to receive/send data.
What’s Next? PMA Software Available
CableLabs has developed network-deployable software that operators can integrate and use within their DOCSIS 3.1 access network. This PMA solution can use the data generated by the network devices and create optimized OFDM/OFDMA profiles while considering different capabilities supported across CMTS platforms. The software is capable of calculating profiles for a channel with around 200 CMs in ~30 msecs using a single CPU process, so it is easily scalable across an operator’s network. Many operators are testing and planning PMA deployment using this solution framework. PMA is available via CableLabs C3. Contact us to try it out. (Watch for an upcoming video blog on this topic.)
Gains from PMA
A PMA will help increase the throughput per cable modem and maximize network capacity by optimizing the bit-loading of the subcarriers within a channel. Designing profiles around noisy areas in the plant make the system operation more robust. The bandwidth gains in running a well-designed set of profiles can be anywhere from 15% to 40% capacity increase on a channel, compared with running the whole channel at 256-QAM. This can translate to a solid 200 to 400 Mbps extra capacity on each OFDM channel! This enables an operator to match growing bandwidth demands and defer potential node-splits and new equipment costs.
With this profile management technology, operators can realize the full potential of their DOCSIS 3.1 network, by minimizing transmission errors and maximizing the data capacity of the OFDM/OFDMA channels.
Subscribe to our blog to learn more about PMA in the future.
Security for Blockchains and Distributed Ledgers
Empirical evidence reveals an inimical belief that blockchains and distributed ledger technologies (DLTs) are inherently secure because they use cryptography, employ hashing algorithms and have public/private keypairs—in short, a belief that the data in these systems is extremely unlikely to become exposed. After evaluating requirements and deciding to utilize a blockchain solution, security is important to consider from the start.
Over the past several years, the Security Technologies arm of CableLabs’ Research and Development organization has been tracking blockchain attacks and compromises. From this work, several hazard groupings have been identified. The following list is intended to act as an aid to architecture, design and implementation efforts surrounding enterprise projects that use these technologies.
Smart Contract Injection
The Smart Contract engine is an interpreter for a (sometimes novel) programming language and a parser of data related to the decisions the engine needs to make. The hazard in this situation is when executable code appears inside smart contracts in an effort to subvert the contract language or data. Implementers need to consider sanitizing inputs to smart contracts, proper parsing and error handling.
Not only is there a threat in transaction processing and validation, but also in node behavior, authentication, and the securing of confidential messaging. Adding nonces to check against prior transactions is critical.
History Revision Attacks
Blockchains that rely on fault-tolerant consensus models do well when there are many participating nodes processing, competing and collaborating on the next block. When the number of nodes drops, or if there is predictably cyclic behavior, lulls can be leveraged in a history revision attack where a new branch is created, effectively deleting a previously accepted transaction. Designers should consider how to best guarantee minimum support and the diversity of nodes.
Due to the permanence of blockchains and the cost to fork, it’s possible to sabotage a chain with even claims of illegal content to draw the ire of regulators and law enforcement.
Confidential Information Leaks
Permanence increases the risk of data being exfiltrated out of the chain. Even encrypted data is at risk for future threats against those algorithms or brute-force attacks. Designers need to make sure that they understand the data being stored, how it is protected, who owns it and how it could be re-associated with any pseudonymized users.
Participant Authentication Failure
Are transaction creators cryptographically signing their transactions? Is that signature verified by the protocol? Is transaction receipt confirmed (non-repudiation)? Are sessions managed? Architects need to consider the proof of possession of private keys in the verification and authentication of participants.
Nodes are the entities that create and agree on the next new blocks in a chain. Nodes should be authenticated like any other user or system, and authentication must be verified, with multiple votes prohibited. Designers who fail to look for voting irregularities open their implementation to risk.
Nodes that behave incorrectly, intentionally circumventing fault-tolerance mechanisms, or trojan nodes (nodes in public chains that follow the standard protocol but have non-standard implementations) are problematic. Transaction propagation non-compliance is another concern—where nodes don’t convey transactions quickly to other nodes, nodes consistently act in opposition to other nodes, or verifications align consistently within small fiefdoms. In addition, architects need to consider what happens to the chain operations when the chain, the nodes or a subset of the nodes is subject to a denial of service attack.
Untrustworthy Node-Chain Seam
The cryptographic difference between what was intended by the participant, what happens in the node, and what happens on the chain must all be consistent. Architects should enforce a design such that the node is unable to modify a transaction (signing and hash verification), skip a transaction (non-repudiation) or add new transactions (source verification).
General Security Hazards
The hazards fall into this meta-category of general security concerns that have specific implications in the blockchain/DLT realm. Architects, designers and implementers all need to take heed of these practices and work to ensure a complete solution:
- Unproven Cryptography: Look for best practices and proven cryptography in cipher suites, hash algorithms, key lengths, elliptical curves used, etc.
- Non-Extensible Cryptography: Should a foundational algorithm aspect of the chain become compromised, can the chain easily migrate to another suite/hash/key pair? Is there a mechanism and process among node operators to agree and deploy this quickly?
- Security Misconfiguration: Be aware of all code libraries used, stay abreast of the latest security information about deployment technologies such as Docker, and ensure that defaults present in test systems are not available in production systems. Ask if there are any components with known vulnerabilities, determine whether any open ports or file-system permissions may be at risk, and understand protection mechanics for private keys.
- Insufficient Logging and Alerts: If something goes wrong, are there sufficient methods in place to capture actions that occurred (voting, smart contracts, authentication, authorization)? Project managers must ensure that alerts have been added to the code, that the correct recipients have been added at deployment time, and that procedures for constant monitoring and updating of those recipients take place.
- Weak Boundary Defense: Development teams need to be aware of, and shore up, defenses so that there are no exploitable holes in client code or node software, smart contract engines, mobile applications, web applications, chain viewers or administrative tools.
Clearly, this list doesn’t contain everything that must be reviewed in a blockchain or DLT application, but the objective is to provide a few key areas to focus on and provide insight to dive deeper where it makes sense in your own applications. Blockchains can help bridge trust gaps in an ecosystem, but security is foundational to that trust.
Want to learn more about security for blockchain and distributed ledgers in the future? Subscribe to our blog by clicking below.
10G Platform: Coming to Homes, Offices and Cities Near You
In just 2 years, the cable industry has made an unparalleled technological leap by increasing availability of 1 gigabit broadband Internet from only 4 percent to 80 percent of U.S. households. Today, we’re excited to announce that this accomplishment is just the first step toward realizing cable’s 10G vision in the next decade.
Is 10G Technology a Future Vision or Can I Get It Today?
10G is not a single technology; it’s the cable broadband technology platform that can handle more data from more devices 10 times faster than today’s fastest cable broadband networks. But network speed isn’t the only feature of 10G. Its reduced latency, enhanced reliability and security features will open doors to a myriad of new immersive digital experiences and other emerging technologies that will revolutionize the way we live, work, learn and play.
The foundation for 10G technology already exists. The capacity of the cable networks that now deliver 1 gigabit speeds to more than 100 million homes across America will be incrementally expanded over the next few years. Plus, cable’s footprint will allow for deployment of new technologies on a massive scale, bringing multi-gigabit speeds to more homes and businesses globally.
Limitless Possibilities Powered by the 10G Platform
The cable industry has a track record of delivering on its promises. A few years ago, when we were talking about the impact of 1 gigabit speeds on the connectivity industry, we envisioned a world of lag-free 4K streaming, blazing fast upload and download speeds, and smoother gaming—experiences that are now available to 93 percent of U.S. cable customers.
The 10G technology promise, however, takes us into a whole new realm of possibilities that will impact every aspect of our lives:
- How We Work—Telecommuting is already favored by many businesses around the world, but the new 10G platform-powered remote presence technology will make this practice commonplace. Coworkers will be able to securely and effectively collaborate via distance VR, video walls and realistic light field displays from various locations, maximizing productivity and minimizing business expenses.
- How We Learn—10G technology will enable the advancement of many emerging technologies, such as head-mounted displays, that can be used in the classroom to integrate VR with real-life objects. This technology can help our children engage with the physical world, distant cultures and the entire universe in new and interesting ways, revolutionizing our approach to education.
- How We Live—The data capacity and enhanced security of multi-gigabit networks will give rise to a new wave of remote diagnostics technology. Doctors will be able to remotely monitor their patients’ vitals in real time, providing better care, quality of life and peace of mind to the elderly and their families.
- How We Play—10G networks’ capacity and speed also comes with one-tenth the latency, making sluggish connections a thing of the past. Gamers will be able to enjoy a truly seamless, life-like experience with more control and zero lag time. Plus, very low-latency networks can boost innovation and open more opportunities for VR/AR applications in other areas of our life.
Based on the double-digit bandwidth usage growth that we continue to see every year, we know our customers and the industry are ready for the next step in network innovation. The 10G platform will enable creators and innovators to fulfill their dreams while providing reliability and security that consumers can trust. We believe that 10G is the next leap into the future, and we’re already well on our way there.
To support the rollout, Intel will deliver 10 gigabit ready technology from the network infrastructure to home gateways. To learn more about the technologies enabling the 10G platform click on the link below.
2019 Tech Innovation Predictions
Now that 2019 is here, it’s time to share my tech innovation predictions for the year. Watch the video below to find out what you can expect to see in 2019.
What are your innovation predictions for 2019? Tell us in the comment section below. Best wishes for a great new year!
Subscribe to our blog to see how CableLabs enables innovation.
Something Old, Something New: CableLabs Holds First P2P Coherent Optics Interop
No, it wasn’t a wedding—but it was a major gathering of great importance! Nine prominent manufacturers participated in the very first CableLabs Point-to-Point (P2P) Coherent Optics Interoperability Event.
The highly successful Interop·Labs event took place at the CableLabs offices in Louisville, Colorado, December 4–6. Participants included nine manufacturers from the coherent optics space, including both silicon and module/system makers, each of whom brought a coherent optics transceiver: Acacia Communications, ADVA Optical Networking, Ciena, Finisar, Fujitsu Optical Components, Inphi, Lumentum, NeoPhotonics, and NTT Electronics. The event was focused on testing interoperability between coherent optics transceivers designed to be compliant with the CableLabs P2P Coherent Optics PHYv1.0 specification (issued in June of this year), which defines requirements for interoperable devices operating at 100 Gbps on a single wavelength.
A Common Goal
If you’ve been following CableLabs and this blog for some time, you’re aware that we’ve been holding interoperability events at CableLabs for many years—for example, for each successive generation of DOCSIS® technology. For those of us who’ve been around CableLabs for a while, in some ways this was something old: an event we’ve done many times before.
But this was something new: this was the first time CableLabs held an interoperability event for P2P coherent optics devices—an entirely different class and type of device from those we’ve held events for in the past. As a result, this event included a set of companies and engineers that have never been a part of such an event before; it was definitely something new for them!
This fact was highlighted by some feedback I received during the event. One participant remarked, “This was a great session, and everyone involved worked together for a common goal, which doesn't happen much with competitors.” This comment was mirrored by other messages I received during the event: attendees praised the open and collaborative environment we created for the interop, allowing engineers from companies that otherwise compete to collaborate one-on-one to address interoperability and get their devices working together.
By the end of the event, all nine companies had an opportunity to work with one another, and all of them reported successful interoperability running at 100G. This is particularly significant given how many manufacturers were involved, and that it’s been less than 6 months since the specifications were issued. The event represents a major milestone in making this technology available to the cable industry.
During a recent company meeting, our President and CEO Phil McKinney advised us to avoid getting into a rut and to instead look at things with fresh eyes. This event reminded me of the same: seeing people participate together like this for the first time, and hearing about the immense and immediate value they were getting from their participation, helped me to see this event with fresh eyes and reminded me just how special it is for all of us to be able to work—as one—toward common goals that benefit the industry as a whole.
Till Next Time
I’m looking forward to the next event with fresh eyes and a desire to do even more to move this technology forward. Please keep an eye on the CableLabs Events page for an announcement of our next event, and if you’d like to get involved with our efforts to make coherent optics technology available to the cable industry, please get in touch to learn more.
CableLabs Announces Major Update to the Open Source LoRa Server
Last week, in my blog post “CableLabs Open Source LPWAN Server Brings Diverse LPWAN Technologies Together,” we announced our LPWAN Server. This project is open source and:
- Provides new capabilities to bring IoT LPWAN wireless technologies together
- Is a flexible tool to enable the use of multiple servers across multiple vendors
The LPWAN Server was designed to work with the CableLabs sponsored open source LoRa Server and, together, provide a comprehensive solution to enable many LPWAN use cases. It has been nearly 18 months since we released the first major revision of the LoRa Server and, during this time, many improvements have been made.
In this blog, I’ll discuss why we invested in the LoRa Server, how the project continues to improve and how it aligns with the latest specifications released from the LoRa Alliance. If you need a refresher on the LoRa Server, please see my blog post “CableLabs Announces an Open Source LoRaWAN Network Solution.”
Why Did CableLabs Invest in the LoRa Server?
The LoRa Server project was conceived and started by Orne Brocaar. His goal was to develop a fully open source LoRa Server that could be used by anyone looking for the opportunity to gain an introduction into LoRaWAN and LPWANs. Due to limited time and resources, the project remained minimal in functionality and progression for nearly a year.
CableLabs had a goal to find a fully community-based open-source LoRaWAN server to provide the cable industry with the ability to easily prototype, test and trial LPWAN services using unlicensed RF spectrum. We discovered the LoRa Server and began investing heavily into developing the functionality to align with our goal. Shortly after this, Orne joined the CableLabs team to lead the development of the LoRa Server into the exceptional tool it has become.
Our design strategy began and continues to focus on these key areas:
- Full functional compliance with LoRa Alliance specifications
- Extensive debug and logging tools
- Protocol transparency to the operator of the server
- Scalable for any sized testing, trial or use
While our goals are to provide a tool for testing, trials and related use, the server is fully open-source under the MIT license. This allows it to be used freely for any use from testing to production. We desire to enable growth and creativity in the LPWAN ecosystem using the LoRaWAN protocol.
Introducing a New Version of the LoRa Server
In the summer of 2018, we released LoRa Server v2. We have released several additional updates to introduce new features and improvements since then while maintaining backward compatibility with LoRaWAN 1.0. Where v1 (released in June 2017) was focused on the first stable release since many test versions, v2 focuses on an improved API, User Interface (UI), compliance with LoRaWAN 1.1 and additional interesting new features.
The major feature of LoRa Server v2 is support for LoRaWAN 1.1. LoRaWAN 1.1 is an important release for many reasons:
LoRa Server v2 enhances the security of LoRaWAN devices by providing LoRaWAN 1.1 support. Not only does LoRaWAN 1.1 add better protection against replay attacks, it also adds better separation between the encryption of the mac-layer and the application payloads. This also facilitates the implementation of roaming in the future. It is important to mention that LoRa Server v2 still supports LoRaWAN 1.0 devices.
Another major feature of LoRa Server v2 is the completely redesigned and re-written web-interface. The fantastic new interface is more responsive because of smarter caching and it is more user-friendly and easier to navigate.
As many users are integrating LoRa Server into their own platforms using the LoRa Server APIs, we want to make sure these APIs are easy to use and are consistent. LoRa Server v2 removes many inconsistencies present in the v1 API and makes it possible to reuse objects so that code duplication is avoided.
Multicast was a feature which was long requested and is finally present since LoRa Server v2.1.0. This feature makes it possible to assign devices to a multicast-group, so a group of devices can be controlled without the need to address each device individually, reducing the required airtime. One of its use cases is Firmware Updates Over The Air (FUOTA) which was recently released by the LoRa Alliance. In an upcoming version, we are planning to further integrate this into the LoRa App Server component of the LoRa Server.
Since LoRa Server v2.2.0, the server provides geolocation support. By default, it integrates with the Collos platform provided by Semtech, but by using the provided geolocation API, other platforms can be used. Please note this requires a v2 LoRa Gateway with geolocation capabilities, as a high precision timestamp is required for proper geolocation.
Google Cloud Platform integration
A common request we have received is how to scale LoRa Server. Since LoRa Server v2.3.0, it is possible to make use of the Google Cloud Platform infrastructure to improve scalability and availability. LoRa gateways can directly connect to the Cloud IoT Core MQTT bridge (using the LoRa Gateway Bridge), and the LoRa Server and LoRa App Server integrate with Google Cloud Pub/Sub.
Open Source Community
The open source community is encouraged to take advantage of our efforts and further functional support for even more gateways, solutions and use cases. There are many LoRaWAN gateways and applications and we would like the development community to help us integrate these.
To find out more information about the LoRa Server and become involved in this project, go to the LoRa Server site.
Subscribe to our blog for updates on the open source LoRa Server.
Say “Hoi” to VodafoneZiggo, Our Newest CableLabs Member
We are very happy to announce that VodafoneZiggo just became the 62nd member of our global CableLabs family. VodafoneZiggo is a Dutch joint venture formed from the union of two very well-known brands:
- Ziggo, the #1 cable network and entertainment provider in the Netherlands owned by Liberty Global, the largest international TV and broadband internet company; and
- Vodafone Netherlands, the #2 mobile operator in the Netherlands owned by Vodafone Group, one of the world’s largest telecommunications companies.
VodafoneZiggo provides 9.7 million fixed line services to its customers with nearly 4 million video, over 3 million broadband and 2.5 million telephone services, and provides mobile services to nearly 5 million customers. The joint venture now provides converged video, broadband and mobile services to over 1 million households just 18 months after launching its quad-play offering.
Why VodafoneZiggo Is a Perfect Fit for the CableLabs Family
VodafoneZiggo’s focus is an echo of our own future vision for the global cable industry – connected networks. By joining forces, VodafoneZiggo’s parent companies embarked on a path toward a seamless and reliable connectivity between networks, devices, and most importantly, people. Beginning in 2020, VodafoneZiggo will begin providing a 'network of the future' with converged mobile and fixed connections.
Liberty Global announced its next-generation TV entertainment platform, ‘Horizon 4’, in 2018 featuring a superfast set-top box with 4K Ultra HD picture quality and a remote control with voice capabilities. VodafoneZiggo is currently testing 'Horizon 4' and is working towards a commercial launch in the first half of 2019. DOCSIS 3.1 technology, the CableLabs innovation enabling multiple gigabit per second broadband speed, has been successfully piloted in the Utrecht region of the Netherlands enabling VodafoneZiggo to proceed with a nationwide 1 Gigabit network rollout by 2020.
As a next step in the realization of its network of the future, VodafoneZiggo has increased the bandwidth of a part of its mobile network and, as a result, download speeds of more than 1 Gbps are now possible. Mobile devices supporting these download speeds are expected to be broadly available in 2019. The joint venture is also carrying out 5G tests, working on innovative IoT solutions to make cities safer and more sustainable.
Benefits of CableLabs Membership
We believe that CableLabs’ international reach will help companies like VodafoneZiggo and many others achieve the technological alignment and global scale needed to ramp up the pace of innovation and drive down costs. A CableLabs membership gives them a direct link to the rest of the industry through which they can share experiences and collaborate to better serve their customers.
Other membership benefits include:
- Exclusive access to our quarterly R&D reports, competitive assessments of innovation focus areas and more.
- An invite to our annual Summer Conference and other member-only global events, plus other industry conferences, such as CES.
- A behind-the-curtain look at the latest innovative research not yet available to the general public.
- An opportunity to participate in Working Groups that drive industry standards in fiber, security, mobile, virtual networking and other innovative fields.
If you’d like to learn more about CableLabs member benefits and how to apply, please click the link below.
TCO of DOCSIS® Network XHaul vs. Fiber BackHaul: How DOCSIS Networks Triumph in the Indoor Use Case
In our recently published blog post, we demonstrated why indoor femtocells have reemerged as an attractive deployment model. In particular, indoor network densification has huge potential for converged cable/wireless operators who can leverage their existing Hybrid Fiber Coax (HFC) footprint to either backhaul from full-stack femtocells or fronthaul from virtual Radio Access Network (vRAN) remote radio units.
In the second blog in our series, we shift the focus from system level benefits to making the business case. As we walk through our TCO model, we will show a 40% to 50% reduction in Total Cost of Ownership (TCO) for an indoor deployment model served by DOCSIS networks compared to a more traditional outdoor deployment served by fiber. Yeah, that is big, so let’s break down how we got there.
Why DOCSIS Networks?
Before jumping into the TCO discussion, let’s revisit the key motivations for using DOCSIS networks as a tool for mobile deployments:
- Broad-based availability: In a Technical Paper prepared for SCTE-ISBE 2018 Fall Technical Forum, a major Canadian MSO pointed out that there typically is 3~5X more coax cable than fiber in its major metro markets. In the US too, per FCC’s June 2017 statistics, nation-wide cable Household Passed (HHP) stands at 85% (115M units), whereas fiber HHP stands at 29% (39M units)
- Gigabit footprint: As of June 2018, over 63% of US homes have access to gigabit service over cable. In other markets cable operators are pushing ahead with gigabit buildout as well
- Ease of site acquisition: No permitting, no make ready, limited installation effort.
- Evolving mobile-friendly technology: Ranging from latency optimization to timing/synchronization techniques and vRAN support for non-ideal fronthaul links like DOCSIS networks.
Scenarios We Looked At
For TCO comparison, we looked at the following 3 deployment scenarios:
Scenario 1: Outdoor small cell served by leased fiber backhaul
This is the traditional solution for deploying small cells. For our TCO model, we treated this as the baseline.
Scenario 2: Indoor femtocell/home eNodeB served by residential/SMB DOCSIS network links as backhaul.
In this scenario, we modeled the deployment of a full-stack femtocell in residential customer homes and small to medium businesses (SMB) served by the converged operator’s DOCSIS network. A converged operator here refers to a cable operator that deploys both DOCSIS network and mobile networks.
Scenario 3: Indoor vRAN Remote Radio Unit (RRU) served by residential/SMB DOCSIS network links as fronthaul
Scenario 3 is essentially scenario 2 but using vRAN. In this case, the virtual base band unit (vBBU) could be deployed on general purpose processors (GPP) servers in the distribution hub site with low-cost radio units deployed in DOCSIS gateways at the customer premise, or SMB location.
Apples to Apples
To build the TCO model, we start with a representative suburban/urban area we want to model. In our case, we used a 100 sq. km area with a total of 290k households (HH). At 2.4People/HH (the US average), our modeled area covered roughly 700K people.
Next, we considered that this area is already served by 10 outdoor macrocells, but the operator needs to boost capacity through network densification.
Under Scenario 1, the operator deploys 640 outdoor small cells that cut existing macro cells’ traffic load by half and boost the spectral efficiency (and therefore capacity) across the network. To create an apples-to-apples comparison of system capacity under all three scenarios, we applied the concept of normalized spectral efficiency (SE) and kept that consistent across the three scenarios. For SE normalization, we added up weighted SE for different combinations of Radio Location-User Location (e.g. In-In, Out-Out, Out-In) in each scenario.
In the end, we used the normalized SE to find the appropriate scale for each scenario to achieve the same result at the system level, i.e. how many femtocells/vRAN radios will be required in indoor scenarios (2 & 3) so the system capacity gain is comparable to the traditional deployment in scenario 1.
Work Smarter, Not Harder
Crucially, converged operators know who their heavy cellular data users are and among them, who consistently use the network during non-business hours, i.e., most likely from their residences. As an example, a CableLabs member shared empirical data showing that the top 5% of their users consume between 25%~40% of overall cellular network capacity on a monthly basis.
So as a converged operator, if you want to prevent at least 25% of network traffic from traversing through walls, you can proactively distribute home femtocells or RRUs to only the top 5% of your users (assuming their entire consumption happens indoor).
In our model, we used the following approach to get the scale of indoor deployment for scenarios 2 and 3:
Therefore, theoretically, if only 2.5% of subscribers start using indoor cellular resources, we can achieve the same SE improvement in scenarios 2 and 3, as observed under scenario 1’s fiber outdoor deployment.
However, we know assuming 100% of heavy users traffic is consumed at home or indoors is unrealistic. To account for a combination of real-world factors including that indoor doesn’t mean only at your residences, that some of those heavy user locations may not be serviceable by a DOCSIS network, and/or some users may opt out from using a home femtocell/RRU we boosted that percentage of the subscriber base we modeled using femtocell/RRU deployments to 12.5% (or roughly 35K units) to make sure that we can definitely capture at least 12.5% of cellular traffic in scenario 2 and 3.
Our Analysis and Key Takeaways
For the TCO model assumptions, we gathered a wide range of input from a number of CableLabs operators and vendors. In addition, we validated our key assumptions with quite a few Telecom Infra Project (TIP) vRAN fronthaul project group’s members.
Though configurable in our model, our default TCO term is 7 years. Also, we calculated the TCO per user passed and focused on the relative difference among scenarios to de-emphasis the overall cost (in dollars), which will differ by markets, the scale of deployment and supplier dynamics among other things.
According to our base case assumptions, we see the following:
- TCO in scenarios 2 and 3 can be around 40%~50% cheaper than the TCO in scenario 1.
- For scenario 1, Opex stands out as it involves large fees associated with outdoor small cell site lease and fiber backhaul lease.
- Scenario 2 commands a higher Capex than scenario 3, largely because of higher (~2X) unit price per full-stack home femtocell (vs. home RRU) and the need for security gateway, which is not required in scenario 3.
- Scenario 3’s Opex is nearly double (vs. scenario 2 Opex), as it requires a significantly higher DOCSIS network capacity for the upstream link. Yet, notably, despite the increased DOCSIS network capacity used by a vRAN deployment, the TCO is still the most favorable.
- We allocated 20% of DOCSIS network upgrade (from low split to mid split) cost to DOCSIS network-based use cases (scenarios 2 and 3). If we take those out (since DOCSIS network upgrades will happen anyway for residential broadband services) the TCO of these indoor use cases get even better compared to the fiber outdoor case (scenario 1).
- Other key sensitivities include monthly cost/allocated cost of the XHaul, number of small cell sites within a small cell cluster, radio equipment cost, and estimated number/price of threads required for vBBU HW to serve a cluster in the vRAN scenario.
In an upcoming strategy brief (CableLabs member operators only), we intend to share more details on our methodology, assumptions and breakdown of observed results (both Capex and Opex) along with a sensitivity analysis.
What Do These Results Mean?
To us, it was always a no-brainer that a DOCSIS network-based deployment would have favorable economics compared to a fiber-based model. The TCO model introduced here confirms and quantifies that perceived benefit and points out that for network densification, there is a business case to pursue the indoor femtocell use case where market conditions are favorable.
Subscribe to our blog because our exploration of DOCSIS networks for mobile deployments isn’t over. Coming up next we explore a similar TCO model focused on outdoor deployments served by DOCSIS backhual. Later we will shift back to technology as we look at the DOCSIS networks ability to support advanced features such as CoMP.
CableLabs Open Source LPWAN Server Brings Diverse LPWAN Technologies Together
CableLabs is excited to announce a new open source project called LPWAN Server. The LPWAN Server provides new capabilities to bring IoT LPWAN wireless technologies together.
Before we go into more details on the LPWAN Server, let us first get some background into this space. In my previous blog post, I discussed the Internet of Things (IoT) as a growing industry comprised of a massive number of devices that connect to each other to benefit our lives. For example, a soil moisture sensor can help a farmer determine when to water their crops rather than potentially wasting water through a legacy timed-based approach. In that blog post, CableLabs announced the release of an open source LoRaWAN solution, LoRa Server.
What is LoRa Server and LPWANs?
LoRa Server is a community-sourced open source LoRaWAN network server for setting up and managing LoRaWAN networks. LPWANs connect sensors designed to last for years on a single battery transmitting information periodically over long distances.
There are many potential use cases shown below:
LPWANs are designed to cover large geographical areas and minimize the amount of power required for sensors to interact with the network. There are many solutions available to enable these use cases, including:
- LoRaWAN™: LoRaWAN is a partially open unlicensed spectrum solution developed through the specifications efforts of the LoRa Alliance: While the specifications are developed within the Alliance, they are made available to the general public upon completion.
- Mobile solutions from 3GPP: 3GPP defined Cat-M1 and NB-IoT for varying connectivity requirements. These are also open standards, but they require licensed spectrum.
- Weightless: Weightless is an open specification effort but has struggled in gaining traction in the LPWAN space. It should be noted, there are many other proprietary LPWAN technologies with active deployments and use in this ecosystem.
Why No One Solution Will Own the Technology
We believe no one LPWAN technology will fully own this IoT space. Our reasoning for this belief comes from multiple factors. As we look at the sensors in this space, some are intended for real-time applications with consistent and verified uploads, while other sensors simply wake-up periodically and transmit small data payloads. Without going into more specific examples, we believe some LPWAN applications are better suited for licensed spectrum mobile networks, while other LPWAN applications are better supported with unlicensed solutions, such as LoRaWAN™. LoRaWAN services can be further explored through some of our member offerings via MachineQ™ and Cox℠ .
Our New Open Source Solution
With these considerations in mind, we developed a new open source solution to enable easily moving data from devices and applications across varying network types and related solutions. The LPWAN Server was designed to enable multiple use cases:
- First, it can be used to simply migrate or operate between two LoRaWAN™ network servers, such as the LoRa Server and The Things Network.
- Second, and more importantly, the long-term design intention is to enable the routing of multiple LPWAN technologies, such as LoRaWAN™ and SigFox or LoRaWAN™ and Narrow Band IoT (NB-IoT). In order to integrate IP-based devices, the server will include a “relay server” of sorts. This allows for the IP traffic to mix with LoRaWAN™ traffic for a single upstream interface to an application or data collector, such as Google Cloud and Microsoft Azure.
Our goal with this project is to see developers add more back-end integration with network servers and technologies to enable this routing of traffic across many LPWAN technologies.
LPWAN Server Use Cases
The LPWAN Server was designed to support the following use cases:
1. Multi-vendor LoRaWAN™ environment: Using the LPWAN Server in a multi-vendor LoRaWAN™ environment allows a network provider to:
- Test multiple servers from multiple vendors in a lab,
- Trial with multiple network servers from multiple vendors
- Run multiple vendor solutions in production
2. NB-IoT & LoRaWAN™ device deployment: The LPWAN Server will allow you to operate a single application for devices deployed on both LoRaWAN™ and NB-IoT networks. The LPWAN Server will enable an IP relay-server for connecting with NB-IoT (and Cat-M1) devices commonly behind a 3GPP mobile network Evolved Packet Core (EPC). It also allows for managing devices on the LoRaWAN™ The devices are managed under a single application within the LPWAN Server. This allows an application to receive data over a single northbound Application Program Interface (API) rather than maintain API connections and data flows to multiple networks.
3. Simplify device provisioning across multiple LPWAN network types and solutions: The LPWAN Server simplifies provisioning to one or more LPWAN networks. A major challenge for a back-office solution is to integrate provisioning into a new network server. This is further complicated with multiple new network servers and types. In order to simplify this, the LPWAN Server manages the APIs to the networks, and the back-office solution only needs to integrate with a single API to the LPWAN Server. The following figure illustrates this.
4. Create consistent data order and formats from LPWAN devices: The final use case explains how the LPWAN Server can normalize data from varying devices on one or more networks. Unfortunately, even in a single network environment, such as LoRaWAN™, there is no standard for data formats from multiple “like” sensors. For example, a weather sensor from two different vendors could send the same type of data but reverse the order. An application will need to interpret the data format from multiple sensors. In order to simplify this, the LPWAN Server can be used to reformat the data payload into a common format for sending up to the application server. In this way, the application server will not need to interpret the data.
CableLabs & the Development Community Together
The LPWAN Server is intended to be a community open source project. The initial release from CableLabs provides support for a multi-vendor LoRaWAN™ use case. The back-end has been designed for future support of all of the use cases, and the UI is flexible to support them as well. We currently are using the server for data normalization, too; however, this is via a back-end process.
The open source community is encouraged to take advantage of the initial CableLabs development and further the development into a useful application for even more servers, solutions and use cases. There are many network types and related servers, and we would like the development community to help us integrate these.
To find out more information about the LPWAN Server and become involved in this project, go to https://lpwanserver.com.
The LPWAN Server was designed to work with the CableLabs sponsored open source LoRa Server. In an upcoming blog, I will discuss how that project continues to evolve and align with the latest specification releases from the LoRa Alliance. The LPWAN Server and LoRa Server provide a comprehensive solution to enable many LPWAN use cases.