Mid-split with OFDMA: Keys to a Successful Deployment
By Chris Topazi
Here at Cox, we have converted thousands of DAA based RPD nodes to mid-split upstream with OFDMA. Previously, we had discussed the impact of over-the-air television broadcasters in this band, and what we planned to do about those issues. For those who would like to review that information, the article is here (https://broadbandlibrary.com/ofdma-and-ingress/).
As we’ve continued down the path of migrating more mid-split nodes from ATDMA-only to OFDMA, we have learned many lessons that we thought may be useful for others on this journey.
LESSON 1
If you can’t see it, you can’t fix it.
As with any change or new technology, visibility is key. Fortunately, we have a strong analytics team to monitor any unanticipated changes in transactions or performance. We have leveraged that capability in this node transition process. When a minor increase in transactions initially after conversion to OFDMA was noted, we leveraged that team to slice different views of the data and narrow in on specific issues. One example in this case was ruling out specific cable modem models as causing the issue. To successfully deploy new technology, it is imperative to ensure that you have the data collection necessary and a team in place to help analyze it and provide concise and timely feedback. In addition, these data wizards can work their magic and help with tracking the impact of various changes—proving or disproving hypotheses that are driven from Engineering, Field Services or Outside Plant Maintenance.
LESSON 2
Network performance matters, and consistent network performance matters more.
Prior to this large-scale deployment, we created and instituted a pre-check process that would examine the performance of a node in terms of RxMER/SNR and ingress susceptibility. Without a doubt, this prevented numerous customer issues and transactions. However, what became apparent in nodes with higher transaction rates is that variable RxMER/SNR performance of a node translated to a much worse customer experience than a node that had lower RxMER/SNR performance but was consistently mediocre.
Why is this the case? With OFDMA, we are now using higher modulation orders. Those modulation orders are also now dynamic, as opposed to being at a fixed 64-QAM prior to the use of OFDMA.
Using that scenario if we take a node with a consistent RxMER that ranges from 28 to 30 dB, cable modems on that node will typically land on 256-QAM. While that is less than ideal from a service group capacity perspective, customers do not perceive any inconsistency in their service.
Now, take another node with performance that is typically excellent, let’s say 39 to 40 dB RxMER. At certain times, this node may experience periods of much lower performance, for instance when it hits 29 dB RxMER. In that node, most modems will start out at 2048-QAM, and everything is wonderful. We have the service group capacity gains we desire, and customers can achieve their provisioned speeds. However, when the performance degrades, those modems at 2048-QAM can no longer operate at that high of a modulation order. They may begin to experience packet loss due to uncorrectable FEC codewords until the system can adjust down the modulation order. That packet loss can impact many different real-time applications: gaming, video chat, audio calls, etc.—and customers will notice. If this continues, our customer service representatives’ phones begin to ring, and our trucks start to roll. Worse yet, if the performance is that variable, this can result in many “no problem found” resolutions.
Now, imagine those same two nodes with a fixed 64-QAM. Both operate consistently, though you have lower margin on the first node. From a customer perspective, the upgrade is actually worse in the node that is typically performing better, which can be somewhat counter intuitive.
So, how do we address these issues?
- The pre-check process must include a look at historical performance of the node from an RxMER/SNR perspective. Nodes with inconsistent performance need attention prior to OFDMA conversion.
- The most common reason for this type of large variation in performance is impedance mismatches in the HFC plant creating common path distortion (CPD). There are many tools for identifying and localizing these mismatches, and it is wise to invest in some of those for optimizing customer experience in OFDMA with its dynamic modulation. Because CPD typically affects the entire upstream band, these issues can be observed and corrected prior to enabling OFDMA, thus preventing transactions.
- CMTS settings can be tweaked as well so that modems remain on the lower modulation order for longer after uncorrectable FEC codeword events. This helps in two ways—by keeping modems on modulation orders that can be achieved when plant performance is lower, and if you are monitoring modulation order distribution in the node (see Lesson 1), it is much more apparent that the node has an issue and needs some work.
LESSON 3
In-home network performance matters, too.
One of the more interesting findings of this deployment has been that in many nodes where transactions increased, it was driven by a few individual homes. In this case, having the data is critical—and especially being able to tie given home performance metrics to actual call-in rate post-conversion. In fact, we have seen 40% of the issues after conversion being related to in-home issues.
As an example, after conversion to OFDMA, we had one specific node that landed on the list of nodes most urgently needing attention. This was driven by high reported call-in rates, and the sheer number of modem boot indicators. Upon investigation, over 90 percent of those modem reboots and calls were from three customers. When we peeled the onion another layer, we discovered that those three homes were approaching or exceeding RF limits but managing to hang on before conversion. After conversion, when modem maximum transmit power levels decreased, those modems became unstable—sometimes able to range or not, depending on fluctuations in plant levels with temperature and time of day.
So, how do we address those individual customer experience issues, provide better service, and reduce churn as we upgrade our network?
- We are in the beginning stages of modifying the node pre-check process to examine a few key metrics: transmit level and in-channel frequency response, as examples. This allows us to proactively identify customers who may experience issues after conversion and scope the level of effort needed to successfully convert that node.
- We are also exploring the business case of a customer notification and proactive truck roll model, which allows us to tell the customer that we suspect they will have a problem, and request that they allow us to resolve the issue prior to conversion. We believe that the benefits of this will be improved customer satisfaction and reduced churn.
- Even without a proactive model, we are considering implementing a mechanism to flag that account prior to conversion, which will allow us to skip many unnecessary troubleshooting steps if the customer calls in, resulting in faster resolution times.
With over a year of this deployment, and nearly 10,000 nodes converted to OFDMA, these are just a few of the important lessons we have learned. We plan to carry many of these learnings forward into high-split deployments and then DOCSIS 4.0 over the next few years.
We have found that as technology moves forward, it is truly critical to monitor properly and be willing to adapt business processes and bring fresh ideas to improve reliability and customer satisfaction. We hope that sharing these with the industry can help us all to better serve our broadband customers.
Chris Topazi
Principal Architect
Cox Communications, Inc.
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
