Buddy Bertram on Ingress and Return Path Analysis
One of the big questions being asked by providers is how do I handle ingress encountered in the reverse path? To their exasperation, many are finding that there’s not an easy solution to this question. Different types of spectrum analyzers address different issues and return path monitoring systems require hardware and hassle and are prohibitively expensive for most operators. However, with the Broadcom chipset technology used in most DOCSIS 2.0 and 3.0 CMTSs and in conjunction with a product like ZCorum’s Upstream Analyzer, cable operators can now use their current CMTS as the spectrum analyzer without the need to purchase additional expensive hardware or introducing more points of failure into the plant. Utilizing this technology in conjunction with a software-based spectrum analyzer, providers can see the signals and noise floor from a remote location on everyday mobile devices (smartphones, tablets, laptops) or desktop computers.
We sat down with Buddy Bertram, ZCorum’s Director of Technology to talk about the basics of ingress and how to handle it.
Question: We know the dominant problem that operators are having with the upstream path has to do primarily with ingress. This is due to something called the noise funneling effect of the upstream path. Can you explain what this means?
Answer: The noise-funneling effect is described as the increase in the ingress noise levels as the number of homes passed is increased. You get noise from every home and, because of the noise funneling nature of a cable plant, noise from one source can, and does affect everyone. All signals from every subscriber’s home are funneled back to the headend or hub site to a single point. That single point is the CMTS.
Question: Subscribers impacted by noise would most likely complain about what issues?
Answer: The most common noise interference shows up as interference to the subscriber's TV reception. But noise also disrupts Internet connections or causes dropped phone calls. In the forward path, as noise levels rise, there will be visible degrading of the picture quality or slow Internet. It will be gradual but the provider will start getting calls.
It’s different in the world of the return path. The effect of high levels of noise and ingress may not even be noticed by the subscriber until they completely destroy communications or drastically slow down network performance. And trying to find the source after the fact eats up time and resources. Not to mention how frustrating it is for the field techs.
Question: Where does the noise come from?
Answer: Aside from the licensed sources of noise such as HAM radio use, LTE towers and their handsets, there are even more sources of noise. The license-free transmitters used in walkie-talkies, garage-door openers, video games, and other unlicensed, low-power radio transmitters can generate noise. Unintentional sources of noise include computer equipment, microprocessor circuits used in consumer electronics equipment or security-alarm systems, motors, neon signs, thermostats, touch-to-switch lamps, the electrical-power distribution system and even the new radio-frequency powered street lights.
Question: How does noise get in?
Answer: Just as with anything, there has to be an opening somewhere for something to get in or out. Whenever there’s a breach in the cable system, you get cable signal leaks and wherever cable signals leak out, noise can get in. Cable signal leaks occur when the RF signals transmitted within a cable system are not properly contained within the cable plant. These leaks can be caused by loose connectors, damaged and cracked or unterminated cables. One piece of bad cable or one poor connection can wipe out an entire node for upstream services.
Question: How long does it typically take a field tech to troubleshoot for the source of ingress?
Answer: It can take a technician from two hours to two days or more sometimes to find a single ingress source and weeks to find them all in a block of homes. And all the time it’s being investigated the subscribers could have poor TV reception, slow internet and having their phone calls drop off in the middle of a conversation.
Question: Can’t techs just see the ingress on a meter?
Answer: The problem with trying to troubleshoot ingress is that most ingress problems are intermittent. Just as a tech lugs a heavy piece of equipment to a site and gets close to the problem, it goes away, and he has to wait for it to show up again, hopefully today, maybe tomorrow. So it’s a wasted truck roll with nothing resolved. That’s one of the big advantages to having a software-based analyzer that remotely detects the noise. A tech can analyze the data at his computer before leaving the office. While he’s in the field he can check the noise levels on his phone or tablet from any location where he has internet access. So even if the noise is happening at another location he can still check it before he goes on that call and he’ll have a picture of what’s happening before he gets there.
Question: What about checking for leakage, wouldn’t that find the source?
Answer: Checking for leakage is a good way to find sources of ingress, but it is not 100 percent effective. In the case of very small leaks or ingress points, a lower level forward path signal may not leak out, but an external signal source (for example, a nearby CB or ham radio signal or electric heater) may produce a strong enough signal that ingress results. So in some cases, a leakage meter alone may not find all the ingress points.
Question: Is any method “100% effective” for finding the ingress problem?
Answer: Software with the ability to scan the return spectrum and display the signals provides an excellent method for identifying and finding ingress. The best software will provide a display of the return spectrum and display the noise under the carrier with 100% accuracy. Unfortunately not all software-based analyzers have this capability. With software like this, providers cut down on time and resources in the field while they’re proactively maintaining the stability of their cable plant. Imagine how easy it would be for an installer to pull out his tablet or smartphone to check for noise under the carrier before hooking the subscriber to the tap. With access to subscribers' homes very limited, operators must take advantage when access is given and the best time is during the installation.
Interested in more on this topic? We have an excellent paper written by Brady Volpe from the Volpe Firm on identifying ingress in the return path. Download your copy here, compliments of ZCorum.
Dennis “Buddy” Bertram, Vice President of Technology
A veteran of the IT and cable industries, Dennis “Buddy” Bertram has been with ZCorum fifteen years. He joined ZCorum in 2001 as a network engineer and now serves as the Vice President of Technology. Buddy currently heads up ZCorum’s engineering department and oversees a team of network engineers that designs networks for ZCorum’s affiliates.
Prior to joining ZCorum, Buddy learned the cable business at Cablevision in Pennsylvania, where he served in nearly every department of the cable company, gaining firsthand knowledge of how cable companies operate. Buddy and his wife have been married 18 years and they are avid motorcycle enthusiasts and spend a lot of time on the open road.
About the Author: Marsha Hemmerich
Leave a comment:
Never miss a post.
Enter your email to subscribe:
- Ask an Expert
- Hot Topics
- ask a broadband expert
- Customer Service
- Industry Perspectives
- proactive network maintenance
- Codeword Errors
- DOCSIS 3.1
- IPv6 migration
- PreEqualization Analyzer
- correlation groups
- network virtualization
- Carrier Grade NAT
- DDoS Attacks
- DOCSIS pre-equalization
- Distributed Denial of Service Attacks
- Fidelity Communications
- IPv4 Conservation
- IPv6 Transition Plan
- Purchase IPv4 Addresses
- Upstream Analyzer
- VoIP revenue
- case study
- cloud-based VoIP
- commercial VoIP
- commercial VoIP revenue
- correctable codeword errors
- customer service
- customer service tip
- free download
- net neutrality
- network function virtualization
- return path
- scott helms
- technical paper
- uncorrectable codeword errors