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 let's 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 controlled 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.