CM SDSL data rates

The possible data rates on a CM SDSL line using widely deployed equipment are 160, 208, 320, 416, 784, 1040 and 1568 kbps. All of these were served with a Bt8970 bitpump. Examination of later firmware images reveals added support for 2320 kbps, so they must have switched to RS8973 at some point. Observe the interesting numerical relation among these data rates: with the exception of 1040 kbps and the later-added 2320 kbps, they come in pairs of two rates related by a factor of two: 160 & 320, 208 & 416, 784 & 1568. This page explains a technical problem that is likely the reason behind these odd-looking data rates.

None of these numbers are nice round multiples of 64 kbps, yet there is nothing on the line but vanilla Flavor B, so these odd data rates are the transfer rates of actual user's payload. This means that when you buy an SDSL line that's sold as 384 kbps, you are probably in fact getting 416 kbps for no extra cost! (Let's just hope that it isn't 320 kbps, as that would be a ripoff.) It is possible, however, for the lower rounded rate (or any other rate for that matter) to be in force on the ATM or Frame Relay PVC between the DSLAM and the ISP's backhaul router.

Reverse engineering of CPE firmware has revealed buried vestigial support for 392 kbps in addition to the data rates listed above. However, it is not supported on commonly deployed CM hardware and the vestigial support in the firmware is apparently for some kind of prototype hardware. It appears that CM had experimented with 392 kbps initially, but then quickly dropped this rate in favor of 416 kbps.

CM SDSL startup sequence

When an SDSL line is provisioned but there is no CPE connected yet, the DSLAM sits there and waits patiently for CPE to connect. It can wait indefinitely and never gives up. Exactly the same behavior is specified by the HDSL standards if one replaces DSLAM with HTU-C and CPE with HTU-R, and is implemented by the standard BT software for the bitpump. The signal transmitted on the line by the HTU-C while it waits for an HTU-R to connect is called the HTU-C startup sequence and consists of a pseudorandom stream of +3 and -3 symbols. This sequence is called 2-level scrambled ones.

CM has made an extension to this sequence. While waiting indefinitely for an HTU-R to connect, the CM HTU-C periodically interrupts the 2-level scrambled ones transmission to send a pulse train encoding the data rate it wants to connect at. CM CPE has no user-configurable speed setting because it decodes these pulses and autodetermines the data rate from them. Generic Flavor B CPE OTOH would require manual configuration of the data rate.

CM's implementation of this hack resides in their modified versions of the standard bitpump library functions _HtucControlProcess() and _HturControlProcess(). We have reverse-engineered CM's code implementing their startup sequence (both HTU-C and HTU-R roles) and written a document for it. It also seems likely that Conexant's AutoBaud (which is not implemented by CM) was inspired by CM's hack.

CPE support for CM's special startup sequence is not necessary, but it is very helpful. Our first generation code was mostly unmodified ZipWire and did not implement any pre-activation; we would connect to the CM DSLAM in the HTU-R role by setting the correct data rate manually. However, our current SDCORE implements CM pre-activation in both STU-C and STU-R roles, and it is much more convenient.

SDSL configuration on the DSLAM

On the DSLAM side the settings pertaining to the SDSL physical layer on each port are contained in the cmHDSLModemTable MIB group. The configurable objects in that table are DataRate, MinRate and CPECode.

The DataRate setting is self-explanatory. If different settings are given for DataRate and MinRate, rate-adaptive functionality is enabled whereby the data rate is somehow adjusted automatically according to line conditions. The documentation is too shallow on exactly how that works; it is particularly unclear what criteria are used to judge the line conditions — it is possible that CMCP is needed for this function to work. Needless to say, this function shouldn't be enabled unless the CPE decodes the speed code pulses and switches its bitpump symbol rate automatically based on that information.

The CPECode object is vaguely documented and appears to be some kind of bit-masked word, although no bit settings are known because the documentation simply instructs the operator to set it to 0. It appears that whatever bit masks are defined for this word allow one to alter some of the details of CM's SDSL flavor: perhaps flip the quat orientation or disable the special startup sequence extension, but again we don't know for sure because no bit definitions are given.

Given that CM's flavor of SDSL is so simple and so well understood, it is better for our open source CPE to implement it as is rather than ask ISPs to change the CPECode setting for us.