What is Autobaud

Completely unrelated to the common meaning of this term in the RS-232 world, Autobaud in the SDSL world is a message protocol for use on SDSL lines distinct from the 2B1Q bidirectional signal used in normal operation. Autobaud messages are half-duplex 20 bps transmissions generated by turning the bitpump's transmitter on or off for 50 ms to transmit a 1 or a 0, respectively. Each Autobaud message is 33 bits long and is transmitted in 1.65 s. These messages encode the data rate used on the line and some aspects of the SDSL flavor. The HTU-C transmits these messages while it's waiting for an HTU-R to connect, and the HTU-R is supposed to receive them, decode them, act on them, and send response messages back to the HTU-C. The end goal of the exercise is for the HTU-R to auto-configure itself.

In addition to the message protocol just described, Conexant/Mindspeed's Autobaud solution includes a line probe mechanism whereby the HTU-C and the HTU-R cooperate to somehow characterize the quality of the line between them (attenuation and noise level maybe?) and thus arrive at a figure of the maximum data rate that line can support.

Relevance

Despite Conexant's very pompous marketing back in the day, it appears that this particular pre-activation mechanism is not very widespread in the real world. In particular, it is not used by either of the two most dominant SDSL/2B1Q flavors (Copper Mountain and Nokia), and the author of these web pages is not aware of any major DSLAM brand that uses this pre-activation mechanism on the SDSL circuits it serves out.

Our interest in the details of the Autobaud pre-activation mechanism is thus mostly academic/sportive. We have reverse-engineered most of the protocol (everything except the line probe mechanism) and our SDCORE implementation running as HTU-C is able to link up with a 5890 router running as HTU-R, commanding the latter to any desired speed.

Technical details

Autobaud was developed by Conexant when they owned the HDSL/SDSL chip family (before it became Mindspeed), and like just about everything produced by this shithead company, the Autobaud spec is secret and proprietary.

Starting information

The basic piece of information that allowed us to even begin to understand the Autobaud pre-activation protocol is the description in section 7.2 of the M289xx kitchen sink software manual. This description gives a lot of valuable tidbits, but is nowhere near complete. We have also found a patent for Autobaud which contains some additional details.

Here is a summary of our starting information:

Each Autobaud message consists of 1 start bit (always a 1) followed by 32 bits of data (variable).
Each bit is transmitted in a 50 ms interval; the bitpump transmitter is on for a 1 and off for a 0.
The data bits are transmitted MSB first.
Each message consists of opcode, data and checksum fields.
The M289xx manual lists all defined message types and their opcodes.
The M289xx manual explains the general message transaction order, which is the same as that given in the patent plus an unlock message phase.
Two bytes in one of the messages encode some aspects of the SDSL flavor; the M289xx manual gives their bit definitions.

Our findings

We have used our usual reverse engineering techniques to figure out the rest of the protocol where the information from the M289xx manual and from the patent was insufficient, or where the two were in conflict. Our test setup consisted of a Hack-o-Rocket running against a Siemens 5890 router; the latter supports Autobaud by way of Mindspeed's new M28945 chip.

We have implemented the basic low-level routines for transmitting and detecting 32-bit Autobaud messages using the methods described in the patent (they now live in libpreact in our code tree), put the 5890 into a mode in which it acts as an SDSL/Autobaud HTU-C and sniffed the initial unlock message with our Hack-o-Rocket implementation (after a basic sanity check with a lineman's handset). We then reversed the roles and got the correct unlock response; by going back and forth several times we have figured out the entire protocol with the exception of the line probe mechanism. We now have the following details to supplement what's in the M289xx manual:

The opcode field which directly follows the start bit is only 4 bits wide; the opcodes given in the M289xx manual are correct.
The data field is indeed 20 bits wide as the M289xx manual says initially, not 16 as the rest of the manual section, the patent and common sense suggest.
The 4 bits between the opcode and the two normal data types seem to be reserved. They have been observed to be always zero except in the unlock message.
The checksum byte is at the end of the message and equals the XOR value of the 3 preceding bytes.
The unlock message with which the Autobaud process begins is 7FFF8000 hex in both directions (HTU-C to HTU-R and HTU-R to HTU-C). In physical terms it's a 50 ms pulse followed by a 50 ms pause and an 800 ms pulse.
The data rate value in the Select Rate message is transmitted as high byte followed by low byte.

This information is sufficient to implement a non-line-probing SDSL/Autobaud terminal, either an HTU-C which unilaterally commands the HTU-R to a certain data rate or an HTU-R implementation which gets the data rate from the HTU-C but cannot handle line probes. Error handling leaves a lot to be desired though.

Line probe mechanism

The simple methods we have used to reverse-engineer the basic message protocol are unfortunately insufficient for cracking the line probe part. If the HTU-C requests a line probe, the protocol requires the HTU-R to do some measurements on the HTU-C's probe signal and to report the results of these measurements in the line probe response message. Supporting this operation in our own Autobaud HTU-R implementation would require knowing exactly what to measure, how to measure it and how to encode the measurement results in the probe response message: that is more than one can figure out from sniffing messages sent by existing implementations.

Thus if there is a DSLAM out there whose SDSL flavor includes mandatory Autobaud (i.e., it won't drop into the standard HTU-C startup sequence until the Autobaud protocol does its thing) and whose Autobaud implementation always includes the line probe step, we are currently out of luck in terms of open source connectivity to that flavor. (But whether or not such a flavor exists is an unknown, fortunately we haven't run into one yet.)

If we ever run into an SDSL flavor of the kind just described and we have to recover the line probe response algorithm somehow, what will we do? Well, unless someone in Russia, China, North Korea, Iran or some other good country helps us recover the Autobaud source code from Mindspeed via some form of rubber hose cryptanalysis (FWIW, as far as we can tell they used to divulge it in source code form back in the Bt8970/RS8973 days before going to M289xx with its built-in 8051 core), our only option would be to disassemble the firmware for some existing RS8973-based (or Bt8970-based) CPE device that implements Autobaud. It would be very massive work though, so whoever wants it badly enough better be prepared to pay some very good consulting fees.

Autobaud flavor ID bytes

Bytes 1 and 2 of the Discovery message sent by an Autobaud HTU-C are supposed to encode some aspects of the SDSL flavor; the HTU-R is also expected to send this information in its response. The supposed bit definitions for these two bytes are listed in the M289xx manual.

Although at first SDSL flavor autoconfiguration seems like a laudable idea, there are a few problems:

The use or nonuse of Autobaud (as opposed to some other pre-activation scheme) is itself an aspect of the SDSL flavor, and it seems that very few real-life flavors are using it.
The information in the two bytes in question is nowhere near sufficient to configure a multiflavor STU, thus it is expected that any real-life implementation would still use extensive local configuration and the Autobaud flavor ID bytes would serve only as a confirmation at best.
The bit definitions attempting to capture each terminal's in-band management protocol capabilities are pathetic.
Given the general uselessness of these flavor ID bytes it is likely that some important implementations may have gotten them wrong and never bothered to fix them. In particular the 09 00 ID sent by the 5890 router we've been using to reverse-engineer the protocol seems bogus.

Autobaud Post

Mindspeed's blurbs about Autobaud mention there being some kind of optional post-activation part in addition to the pre-activation message protocol we have just been discussing, and that is a mystery. To the simple peasant mind of the hacker writing these web pages post-activation implies some kind of in-band protocol that somehow coexists with HDLC, ATM or whatever the SDSL flavor puts in the 2B1Q payload, and that is just very hard to believe. The following questions arise naturally:

Did Conexant specify an actual HDLC or ATM in-band protocol they wanted people to implement, or was their AutoBaud Post offering nothing more than a general idea of such a thing?
If there was an actual protocol put down on paper, has anyone actually implemented it?
There are many very different things that can go over the 2B1Q bit stream: HDLC, ATM, possibly others. How can one have any kind of general or flavor-neutral in-band post-activation protocol in that mess?

We don't know the answers to these questions.