OFDMA and Ingress
Some frequently asked questions (and a few answers)
At Cox, we have begun to convert more of our upstream network to an 85 MHz return using OFDMA. Looking toward a high-split 204 MHz upstream return path soon, we have found that ingress from over-the-air broadcasters can significantly impair our ability to get the capacity upgrades that we are expecting and desire. Let us briefly touch on some of the questions and answers we have been working on in this new return spectrum world.
Is this really a problem?
We have converted, at the time of this writing, over 10,000 nodes to 85 MHz return. In those nodes, we started with populating the new spectrum with ATDMA channels. While we started with a standard frequency plan for those new upstream channels, we quickly learned that customer call volume was elevated in areas with strong ingress. This resulted in creating a channel plan for those markets that avoided these ingress sources.
Based on performance data collected across these nodes before moving the ATDMA frequencies away from the ingress, a low percentage of nodes experience this issue — on the order of less than 5%. However, that does not tell the whole story. These nodes tend to be clustered together, and the service volume and time-consuming nature of finding ingress sources can easily overwhelm a market’s network technician workforce. Likewise, the labor costs associated with resolving the issues can ramp quickly.
Finally, resolving the issue can be challenging due to the locations of the ingress sources. Numerous industry studies have shown that roughly 80% of ingress comes from inside the customer premises. At Cox, we recently completed a study for these over-the-air ingress issues in two markets that showed similar results.
Why is this a problem now?
Simply put, we are turning this spectrum around for return use for the first time. Previously, any leaks in the plant only affected customers downstream of those locations. Now, because of funneling, it affects the entire node. For those of us who were around during the days of the first two-way operation of HFC plant, this feels very familiar.
Additionally, we cleared the mid-split spectrum years ago in preparation for this move, and we have not been looking for leaks in this spectrum, so it is likely that there are numerous areas that will need work.
But isn’t OFDMA some sort of magic?
Unfortunately, no. The laws of physics still apply to OFDMA. In fact, there are a few characteristics of OFDMA that make it more challenging to operate in an environment with this type of ingress.
- OFDMA does not spread information from a modem across the entire channel width. It is not like OFDM and does not have the same resilience to narrowband noise. It operates in minislots which are like small 400 kHz channels.
- Despite the use of these minislots, in many implementations, the entire channel is evaluated for MER to set the IUC, which defines modulation order. The worst performing minislot is the one that sets the IUC. The result is that over-the-air interference is going to drive our modulation order down and reduce the capacity of the channel, in the best case.
- Because of the channel width of the interferers, it is possible, even likely, that enough minislots will be impaired to an extent that they can’t even use the lowest defined IUC. In that scenario, the modem will be placed into partial service with OFDMA impaired. This results in reduced capacity for the service group, and if that modem in partial service is provisioned for a high upstream speed, serious congestion occurs on the sub-split ATDMA channels.
Why can’t we just ignore this and try to use the channel anyway?
The alternative of allowing the customer to try and blast through this ingress will result in uncorrectable FEC codewords, and hence packet loss, when trying to use those minislots that are impaired. That is unpredictable, as it depends on where in the spectrum grants are given by the scheduler. So, the customer experience is something like this:
- Works well sometimes.
- When using impaired minislots, packet loss, which they will see as intermittent service.
- The uncorrectable FEC due to those impaired minislots will potentially put the modem in partial service with OFDMA impaired. See above for why modems in partial service is not desirable.
- After a period of time, the modem is eligible to come out of partial service. The cycle starts again.
Overall, the customer gets an inconsistent experience, with intermittent issues. At the time of a trouble call or truck roll, there is nothing that a customer service representative or the technician visiting the home can do to fix it — a vicious circle that no one wants our customers or our technicians to experience.
So what about tailoring the OFDMA channel to fit the over-the-air interference profile/ exclude impaired minislots, etc.?
This is the primary use case for a profile management application (PMA) in the upstream. There are several key items that must be in place for use of a full-blown PMA solution.
- Data collection to get the OFDMA receive MER data.
- Integration with the CMTS platform to communicate the new channel definitions and get them configured.
- Robust monitoring of the PMA tool for bandwidth capacity planning purposes and for scoring nodes.
PMA is a powerful tool, and it also requires significant work with other systems to get in place and integrated. The timeframes required for that work sometimes do not match with proposed timing for upgrades to plant and product offerings.
If there is not a PMA solution in place, this approach is not going to be scalable. If humans must look at each location and “notch out” frequencies, it will be a constant struggle of “notch this, notch that, but don’t kill the capacity of the channel.”
While we continue to work on PMA, the approach we have taken at Cox is to build channel profiles that avoid the known broadcast channels in each market and to apply those to nodes for which it is necessary. This determination is made via a pre-certification process that takes place once the plant conversion is done, but the OFDMA channel has not yet been activated.
This is a middle ground between “just light up everything” and full PMA.
So, what else should we do?
Given these factors, we have tried to put the safeguards in place so that if the performance will not be good, the device does not try to use OFDMA. This also has the benefit of being able to use two key metrics to determine node health for OFDMA:
- Percentage of modems in partial service with OFDMA impaired
- IUC distribution
By operating in this manner, we provide more of a red/green for our network technicians and make it easier to set thresholds/score nodes.
Is it all doom and gloom?
Absolutely not. There are many nodes in which OFDMA will work flawlessly with no additional effort whatsoever. These are just extra steps to preserve a good customer experience across the entire footprint. We also want to be prepared and have a plan for the nodes requiring some additional TLC from our outside plant maintenance organization, so that they are properly budgeted, staffed and trained, and have all of the necessary tools.
What about looking forward to high-split?
The bad news is that the problem is potentially worse. We will have higher provisioned upstream speeds and more spectrum that is susceptible to over-the-air ingress sources. High-split is especially challenging, as we are relying on excellent performance and high modulation orders to be able to get to competitive product offerings.
That said, there is good news in that if we get the process and plan in place for mid-split, nearly everything we learn will apply to high-split service as well.
These were just a few concerns that we have addressed in our journey to using more of the upstream spectrum. We hope that you find some of these questions and answers to be thought-provoking and useful as our industry continues to move forward toward the future of higher upstream speeds and broader use of OFDMA.
Chris Topazi,
Principal Architect,
Cox Communications, Inc.
chris.topazi@cox.com
Chris Topazi is a Principal Architect at Cox Communications, where he is responsible for testing and development of deployment guidelines for DOCSIS 3.1/4.0 technology. He has worked in the cable telecommunications industry for nearly 25 years, including the past 10 years at Cox. Prior to joining the Cox Communications team, Chris designed and developed products for both headend and outside plant applications at Scientific Atlanta and Cisco.
Shutterstock
