Return Path for cable modems | docsis.org

You are here

Return Path for cable modems

12 posts / 0 new
Last post
rheinra
Return Path for cable modems

We have been trying to figure out the best way to control our issues for cable modems. We have switched to the IBBS platform and are discovering issues in our system that we were not aware of. I wanted to get a little prospective on how others out there are using this system.

How are you sweeping your system and what parameters are being used to do so?

How you control your SNR and break up the plant to discover problem areas?

More questions will probably arise as responses start coming in

Thanks!

Capm
You mean you've never looked

You mean you've never looked at your return path with a spectrum analyzer? Few questions -
1) How many nodes do you have
2) What kind of gear is it?
3) What kind of meters are you using?
4) Do you have any return sweep equipment at all?
5) I'm assuming you *have* a spectrum analyzer ?- otherwise you'd have a hard time doing proofs - does it have a baseband video/monitor out?

We're on IBBS as well, its been a pretty good platform so far.

rheinra
We have a spectrum analyzer..

We have a spectrum analyzer... and it does have a baseband video/monitor out. I am just trying to find out if we are doing things right or if we have to change the way we are doing things. We have 16 nodes coming out our CMTS. Each node is coming off one port and 1000 modems total. We have the room for expansion so that is not my concern.

Plant Equipment:
node: Motorola - stargate
amps: Motorola - BTD 875
line extenders: Motorola - JLX
Taps: Motorola - SSP

We are using DSP860 meters and we use them to sweep our system. Right now when we sweep, the line tech is sweeping at 53 db US Power. I am thinking that is too high. I have talked to another person and he is saying it should be around 48. I am trying to get confirmation from different sources.

Also, we have no return path sweep equipment. We are using our meters and I have found out that the way we are using them causes a misrepresentation because of bursting. As I do know the basics, I am not as technical on the specifics.

We have just started using the IBBS platform and my concern for plant issues are growing. Now that we have this in place, I would like to know how others are using it for more of a proactive approach. Any information you can give me would be greatly appreciated.

rheinra
Frequency Range

Also, our return frequency for all our nodes are set at the same frequency. Does this cause interference when it comes to noise filtering back into the system. They are all set at 32.0 MHz.

Capm
Few more things

So your setup is fairly similar to ours.
Couple more questions,
So you don't have any breed of 9580 SSR, or 8310 RSA in your headend?
What kind of cmts are you running and how many of them?

rheinra
We do not have that equipment

We do not have that equipment.

We are running one CISCO UBR 7246 VXR for the whole plant. Like I said before around 1000 modems currently. We are experiencing big fluctuations in SNR and US power levels. Trying to maintain a constant level on each is a growing concern of mine.

thanks

Capm
How many cards do you have in

How many cards do you have in it and what are they? Sorry so little answer so many questions, but I wanted to be thorough in my reply and I want to get a feel for your network layout.
Also, how many transmitters are feeding your nodes? I assume you either have an amp in the headend feeding multiple lasers or do you have the light split?
Are the modems the only thing in your return? (Digital boxes, t-channel locals etc) What is your amp split (40/52 or 42/54 etc) What channel width and symbol rate is your return (ie, 1.6mhz qpsk, 3.2mhz 16qam, 6.4mhz 64qam etc) How deep are your cascades? (ie node +5, node +9 etc)

If you have not been monitoring your returns all this time, this will be an uphill battle for you for a while, there isn't an overnight fix, but hopefully we can get you to a point where your noise is better managed.

Capm
Also

You'll need one of these:
http://www.newegg.com/Product/Product.aspx?Item=N82E16889206072

Its going to be your new best friend. (leave the plastic cover on the screen)

wnycable
Divide and Conquer! And keep your Us modem levels between 45-50

Upstream noise:
First, balance not just the forward but the return path. I’ve brought levels up on the return path that I knew would create a service call. We called the customer and set up a call. If they were not home or unavailable, we left a message, made the change and corrected the problem. Most noise will come from the customer’s premises.
If you’re using optics for the return, be sure to not overload the optics. Clipping the optics is the fastest way to induce noise.
Check all your grounds.
Check for corroded connectors, any corroded connectors can cause problems.
Make sure all connections at your control are tight. Make sure, as far as you can to make all the connections inside the customers home tight.
Make sure the shielding is good on distribution lines.
Use good fittings.
Start at the lowest value tap and work your way to the amp and or node.
Divide the legs of the system and find out which one has more noise than the other. Knock them off one by one. Keep dividing and you will conquer.
Good luck.

rheinra
Not technical

I am not very technical. What is the best way to divide which node is producing the most noise into the system and is there any way to thwart one node noise from disrupting another node? We are running all nodes on the same frequency at 32 MHz. Should we split that up?

Thanks

mbowe
You said you have 16 nodes,

You said you have 16 nodes, and 16 upstream ports, 1 node per port? If this is the case then each node is fully isolated from the others - so noise in one node will not be affecting any other node. And you can re-use the same frequency in each node without any clashes.

If some nodes are larger or busier than others, then it can often make sense to rewire the combiners so that eg 2 nodes share 2 upstream ports. This results in less idle/wasted upstream capacity. But the downside is that noise in one node will affect the other node it is paired with. Plus you have to ensure that both nodes are using unique frequencies otherwise they will clash.

Either way I am not a big fan of hard-coding upstream frequencies. In my opinion you are better of configuring a spectrum group eg
"cable spectrum-group 1 band 20000000 42000000"
and then for each cable interface, add the command
"cable spectrum-group 1"
And remove any frequency settings for each upstream interface.

This way the CMTS will automatically choose a frequency in that band, and if noise is present the CMTS will automatically "hop" the upstream to a different frequency. Spectrum groups also automatically takes care of ensuring there are no frequency clashes should you ever rewire so eg 2 nodes share 2 upstreams.

With regards to identifying which upstreams are suffering noise problems, you can snmp poll stats from the CMTS and then use a graphing program like MRTG or cacti to plot these. And/or use an app like Nagios to generate alarms should SNR drop below an acceptable level. Once you have spotted an upstream that has noise, you would usually go into the headend and connect spec-an to the monitor port of that node's return laser.

A crude way to track down the source of the noise would be to go out to the node and start disconnecting legs and seeing if the noise goes away. When you find the leg with the noise go half way down the leg and disconnect again. Keep halving it until you have located the source of the noise.

Here are the snmp mibs for some useful upstream stats :

upstream_width = "1.3.6.1.2.1.10.127.1.1.2.1.3"
unerrored = "1.3.6.1.2.1.10.127.1.1.4.1.2"
correctable = "1.3.6.1.2.1.10.127.1.1.4.1.3"
uncorrectable = "1.3.6.1.2.1.10.127.1.1.4.1.4"
snr = "1.3.6.1.2.1.10.127.1.1.4.1.5"
upstream_modems_tot = "1.3.6.1.4.1.9.9.116.1.4.1.1.3"
upstream_modems_reg = "1.3.6.1.4.1.9.9.116.1.4.1.1.4"
utilisation = "1.3.6.1.4.1.9.9.116.1.4.1.1.7"

Hope that helps!

rheinra
Sounds Good

I am going to run this by our network guy and see what he thinks. Appreciate the Info!

Log in or register to post comments