Since its inception, the DOCSIS 3.0 specification has supported upstream channel bonding. Most CMTS vendors have not supported this in their firmware until the past year. In most cases the firmware that is available is still in beta testing in cable operator labs to ensure cable modems and networks can support it – why? The bonding of two, three or four upstream channels in an RF DOCSIS network creates a lot of challenges such as finding enough RF spectrum, resolving overloading return path lasers, isolation issues and much more. Some of these items have been addressed in the Speeding Upstream Articles written by John Downey and me.
The focus of this article will be on the mechanics of upstream channel bonding and how it works more from a DOCSIS protocol perspective. Much more detailed information can be found in the DOCSIS 3.0 MULPIv3.0 document located in the Library, but this will provide a high level overview for the layman who is curious about the basics. First lets understand that it is the cable modem that is doing the channel bonding, remember in the upstream the cable modem transmits data to the CMTS. Per DOCSIS 3.0, the CM can bond from two to four channels in the upstream as coordinated by the CMTS. The CM is always controled by the CMTS.
Upstream channel bonding has a lot in common with downstream channel bonding. Like downstream channel bonding, upstream bonding consists of two or more channels active as an Upstream Bonding Group (UBG). In order to enable multiple upstream channels in a cable modem, a special mode is turned on in the cable called Multiple Transmit Channel mode (MTC mode). This is the basic distinction of whether the cable modem is functioning in DOCSIS 2.0 mode or DOCSIS 3.0 mode. Once in DOCSIS 3.0 mode, all of the power level variations described in Figure 3 of Speeding Upstream Part II are in effect.
At a very basic level, the CMTS assigns each upstream channel with a service flow. The Best Effort service flow is a just one of many “SID Clusters” that assigns this type of service flow to each channel in the bonding group. Queuing in the cable modem buffers data and then bandwidth REQs on any upstream from the CM allow the CMTS to load balance the CM by sending back MAP Grants to any upstream channel. Why would load balancing be necessary? For one the CMTS is managing many cable modems, some of which could be legacy DOCSIS 1.x/2.0 modems using only one of the available channels in the bonding group. Further, there could be impairments on some upstream channels seen by some modems. Higher levels of service flows will be established for QoS by the CMTS, this will be another SID Cluster and spread across the bonding group so that load balancing can also occur for that particular QoS service flow to achieve the best possible performance in the case of traffic or impairments.
A channel in a bonding group may become unusable due to say upstream impairments. In this case, if the CMTS becomes aware of the outage, it will stop providing opportunities for CMs to transmit on that channel (i.e. MAP grants). If the CM becomes aware, it will stop sending REQs for data. Both the CM and CMTS will continue to do Initial Ranging (i.e. the cable modem will continue to establish communication with the CMTS) until the channel become available. So basically, if an UBG channel becomes unavailable, the DOCSIS 3.0 network will continue to work with the remaining upstream bonded channels until the down channel is brought back up. Its smart enough to know not to transmit any data on the down channel.
So upstream channel bonding can be pretty straight forward. If you dig deeper you will find that a host of advanced features are supported similar to DOCSIS 2.0 such as Dynamic Channel Change, fragmentation, concatenation, etc. Of course these are beyond the scope of this blog and I encourage you to read the spec if you are interested in this level of detail.
If you are in need of consulting / design services, go to The Volpe Firm, Inc. You can also contact us through our online web portal or call directly at:
Ph:+1-404-424-8202.
About the Author:
Brady Volpe is the author of many industry articles and papers and owner The Volpe Firm, Inc. He has over 20 years of broadband cable and telecommunications industry experience specializing in DOCSIS, EPON, VoIP, video, IPTV, RF, and fiber optic transport.
Tiamoro
December 1, 2011I think at the end of the 2nd to last paragraph:
“Its smart enough to know not to transmit any channel on the down channel.”
You mean to say:
“Its smart enough to know not to transmit any data on the down channel.”
Brady
December 1, 2011Hi Tiamoro,
Indeed you are correct. I will make the correction. Thanks for catching it and bringing it to my attention.
-Brady
Kent
January 16, 2012Great Blogs!
Brady,
Are there any differences in the actual combining network structure when it comes to DOCSIS 3.0. I was told recently that each bonded US frequency will need to go to a separate upstream port?
So as an example, where once there was a direct connection from the last combining output to an upstream port, now a 2-way split would be required for two bonded upstreams to two upstream ports?
Would you have any examples of such schematics?
I know that there are a lot of variables, but lets just keep the example simple and assume that the DS’s are tied to the US’s.
Thanks,
Kent
Brady
January 16, 2012Hi Kent,
You were told correctly. Each upstream that is not a logical upstream will go to a separate physical upstream port on the CMTS. This is one of many topics that I lecture about in my seminars. There is a lot of re-configuration that must occur in the headend when downstream and especially upstream channel bonding occur. I’ll be posting my SCTE Cable-Tec Expo proceedings shorting, which contains a pretty intense headend configuration.
-Brady
Kent
January 18, 2012I look forward to that.
Thanks for your reply.
Kent
Ravi
February 6, 2012Excellent Blog, a source of very rich information about the DOCSIS.
Have one query though, when we talk about validating a DOCSIS environment, what all areas should we focus on?
Brady
February 7, 2012Hi Ravi,
Validating a DOCSIS environment or often I refer to this as ensuring the network is “DOCSIS Compliant” focuses on three areas: 1) the physical (PHY) layer, 2) the DOCSIS (MAC) layer and 3) the Internet Protocol (IP) layer, which is really layers 3-7 in the OSI model or everything above the MAC (layer 2).
From a DOCSIS compliance standpoint, we really focus on Layers 1-3 which ensure that the physical plant will support DOCSIS MAC and IP communications can occur. This PHY requirement can be found in all DOCSIS Specifications. Much of it boils down to the point that ensures the downstream and upstream will support a 10e-8 bit error rate (BER). Of course to achieve this level of BER many RF factors are taken into account. I cover much of this in my articles, which are also tied back into the DOCSIS specifications. MAC layer communications are also defined by the DOCSIS specifications and ensure that the CMTS and CMs operate properly. Finally, the IP network must be provisioned properly to support the amount of traffic (capacity) to and from the DOCSIS network. The IP network must also support the relevant servers necessary to enable provisioning of DOCSIS modems and other devices such as MTAs, settop boxes, etc.
I hope this answers your question, if not please ask more.
-Brady
Ravi
February 7, 2012Thanks Brady. You answered it well.
One more query,
Why do we have only QPSK or 16 QAM for upstream when we are using 64 or 256 QAM for downstream.
Can you also point me to an article/link which explains each field in CM configuration file….
Brady
February 8, 2012Hi Ravi,
DOCSIS 2.0 and 3.0 did add additional modulations to the upstream. You will now find 8-PSK, 32-QAM, 64-QAM and 128-QAM with Trellis Code Modulation (TCM). 8-PSK, 32-QAM and 128-QAM w/TCM are rarely used because they do not offer substantial data increases over the standard modulation of 16- and 64-QAM.
A lot of plants have migrated to 16-QAM successfully and are in the process of determining if the RF plant can support 64-QAM. There are a number of factors to look at including noise, group delay, micro-reflections, laser clipping, etc.
Keep in mind that 16-QAM only need 18 dB MER while 64-QAM needs 24 dB MER. So the plant must be in a lot better shape.
-Brady
Ravi
February 8, 2012Thanks for answering my previous query.
Wanted to understand the reason behind having QPSK or 16QAM only for Upstream while we have 64 or 256 QAM for Downstream channels.
Also it would be great iof you could point me to an article which explains all the fields of a CM configuration file.
I need to understand significance of fileds like MIC, QoS, CVC data etc..
Brady
February 8, 2012I don’t have a good reference other than DOCSIS specification itself. Section D of the DOCSIS 3.0 MULPI Specification, which starts on page 596 of the document, has a very detailed explanation of every section of the configuration file. This is really the place to start in order to understand configuration files.
The CVC pertains to secure downloads of firmware to cable modems. To understand this, you will want to read the BPI specification, starting on section 9.1, page 77.
Sorry that I don’t have primers on these yet. I’ve guess you’ve given me a number of topics to write on, however I’m deep into a downstream and upstream bonding impairment research that I hope to get a few articles out on soon.
-Brady
Ravi
February 8, 2012Thank You so much Brady for your valuable time and as usual spot on resoponse