Category Archives: Troubleshooting DOCSIS

Advanced Troubleshooting in a DOCSIS 3.0 Plant

DOCSIS 3.0 Advanced Troubleshooting

If you missed the SCTE Cable-Tec 2011, I am making available my presentation and white paper on Advanced Troubleshooting in a DOCSIS 3.0 Plant. Each speaker had only 20 minutes to cover topics that could easily last hours, so the presentations are understandably brief. Below you will find my presentation in “Slideshare” for online viewing as well as a fully downloadable PowerPoint version. The PowerPoint version also has reader notes attached at the bottom of each slide which you may find useful. In addition, the animations work a little better in the downloadable version.

DOCSIS 3.0 | Impaired Service

DOCSIS 3.0 Impaired Service

“Impaired Service” in which case one or more bonded upstream channels are impacted by upstream RF impairments while other bonded channels are not. Since subscriber data is striped (that is broken into pieces and spread across each upstream channel and then re-assembled by the CMTS), some of the data will be lost or have errors while other data will not. Subscribers will most likely notice an impaired condition as upstream data rates slow down due to TCP/IP transmissions and/or VoIP, gaming, teleconferencing and other real-time applications will be noticeably impacted.

DOCSIS 3.0 | Partial Service

DOCSIS 3.0 Partial Service

Partial Service is a new term encountered in the DOCSIS 3.0 MULPI specification and realized in field deployments of DOCSIS 3.0 cable modems using upstream bonding. This was a topic that I touched on in this years SCTE Cable-Tec Expo, but will explore in greater detail in this article. Partial service can be considered a feature because the cable modem will stay online even when one or more upstream transmit channels goes offline.

Cable Modems Stuck? | init(r1), init(r2)…

Cable Modems Stuck in init(r1) init(r2)

Many of us have been there before – one or more cable modems stuck in one of numerous “init()” conditions – how do we interpret these messages and what do we do? A recent reader wrote in and had just this problem.  DOCSIS cable modems going offline and getting stuck in “R1″ or “R2″  condition, also known

Hacking DOCSIS Cable Modems

Hacking DOCSIS Cable Modems

Fundamental Precautions You Should Take to Secure Your Network

DOCSIS security wholes are a serious problem, even if you are a major MSO (Multiple System Operator). Recently a reader contacted me and said that theft of service, especially uncapping cable modems via hacking, was still impacting his network. Not surprisingly, one vendor’s CMTS was able to ward off the hacker’s while another vendor’s CMTS was unable to prevent the uncapping and subsequent theft of service. I will protect the vendor’s identities because I believe that the CMTS is the first line of defense. Vendors have put into place very effective, CMTS specific techniques, such as Cisco’s TFTP-Enforce which prohibits a cable modem from registering and coming on line if there is no matching TFTP traffic through the CMTS preceding the registration attempt. But often individual techniques are “hacked” (such as in the TFTP-Enforce bypass method found on hacker sites). What this indicates is that any reliance on a single point or method of hack-proofing your network WILL NOT WORK. You must implement a layered approach consisting of a number of CMTS, DHCP, TFTP and potentially SNMP and Kerbos related methods. The later would apply for MTAs and set top boxes. For now we will just focus on cable modems and the realm of CMTSs and DHCP/TFTP servers. Here are is the bare minimum of what you should be doing:

Speeding Upstream – Part II

This article will focus more specifically on DOCSIS 3.0 issues that will occur as you are deploying DOCSIS 3.0 or post -deployment.

Speeding Upstream – Part I

The first part of this article (in CT’s March 2009 issue) discussed downstream potential issues, while this one focuses on the potential issues associated with upstream deployments. In particular, this article covers the critical upstream areas that one should be aware of when getting ready to deploy or already deploying DOCSIS 3.0.

DOCSIS and Cable Modems – How it works :: Station Maintenance

DOCSIS Station Maintenance

While the UCD provides the language of the DOCSIS network, the Station Maintenance messaging is the proverbial “heartbeat” of the DOCSIS network. A station maintenance session consists of a Range Request sent from a cable and a Range Response sent by the CMTS. The CMTS analyzes the signal quality of the Range Request message and sends back any necessary RF adjustments in the Range Response message. This “handshake” between every cable modem and the CMTS must occur once every 30 seconds as dictated by the DOCSIS specification.

Troubleshooting DOCSIS – VoIP Impairments > Delay & Jitter

In this blog I will address delay and jitter as they pertain to VoIP in a DOCSIS network.  Delay, jitter and packet loss are the three primary impairment in a VoIP network, but packet loss was addressed in my Troubleshooting DOCSIS – VoIP Impairments > Packet Loss blog. After packet loss, delay is the second

Troubleshooting DOCSIS – VoIP Impairments > Packet Loss

In this blog I am going to focus on VoIP packet loss, which is just one of the three (3) primary types of VoIP impairments that are present in a DOCSIS network. I will cover many RF and IP terms in this blog that I have not discussed in my previous tutorials, not to worry! This terminology is all fodder for future blogs. :-)

To review, the three fundamental impairments which impact call quality of VoIP communications are as follows:

* Packet Loss – The complete or partial loss of a packet containing actual voice payload.

* Delay – The time a packet takes to traverse the space between the source and destination of a voice call. The space is comprised of both the physical distance the data must travel in addition to the active network routing and switching elements, which contribute additional delay.

* Jitter – The variance of inter-packet arrival time from one transmitted packet to the next sequential packet.

bradyvolpe.com is Stephen Fry proof thanks to caching by WP Super Cache