Why not G.shdsl?

The big problem with G.shdsl is that no one makes a transceiver chip for it that meets our (FSF-like) criteria for freedom and openness. All known G.shdsl transceiver chips revolve around closed-source proprietary firmware.

Sure, the standard itself is free and open, but are you going to design and fab your own chip? Even if one were to take the cost of fabbing a chip out of the equation by using some existing programmable DSP/ADC/DAC platform, the level of expertise and effort required to design a DSL transceiver chip is very significant, far beyond the limits of our little project.

The only symmetric DSL transceiver chip that is fully open and documented at the register level without proprietary firmware is RS8973, but it only supports 2B1Q. Hence that's what we use for the sake of freedom, despite the shortcomings of 2B1Q.

Why Flavor B?

We have a very strong preference for using HDLC rather than ATM. While ATM is indeed dominant in the xDSL world, that is likely because the backhaul networks feeding the DSLAMs are predominantly ATM (whether one likes it or not), and apparently the DSLAM vendors felt that by extending ATM to the CPE they were standing out of the way for users to use the power of ATM. But our situation is different: we are not in the business of making DSLAMs, and our flavor of SDSL is intended for dry pair point-to-point applications where the terminal on each end is a classic WAN router. The latter traditionally use HDLC over V.35, hence it makes the most sense to carry it directly across the copper pair without assinine conversion to ATM and back.

While we could have accomplished the goal of carrying HDLC over a copper pair using some fancier scheme like Flavor HB, we couldn't justify the significant amount of extra effort; it would also be grossly unfair to burden potential users with the extra cost of the otherwise unnecessary FPGA part (rather expensive). As it is, Flavor B is the simplest and most native one for our VersaDSU, hence it only makes sense that it should be our preferred flavor.

Why our own variant of Flavor B?

Why invent our own variant of Flavor B then? Why not adopt an existing one like Copper Mountain or Lucent?

Well, it is basically a matter of perfectionism on our part:

Issues with the CM flavor

• We want full support for all data rates including 2.3 Mbps. Although our disassembly of CM's CPE firmware has revealed that CM's startup sequence does seem to have a code defined for 2320 kbps and we do support it in our SDCORE implementation, some may argue that this data rate is not truly part of the CM flavor as the real CopperEdge DSLAMs don't support it.
• Quat orientation: putting the sign bit first feels more right.
• Making our flavor clearly distinct from CM's allows us to distance ourselves from the ugliness of CMCP.

Issues with the Lucent flavor

• The Lucent flavor (at least as implemented on the XSB-2000 DSU) lacks any type of pre-activation, hence the correct data rate must be configured on the STU-R or else it won't work. That is a clear disadvantage compared to CM's flavor.
• Data inversion is plain dumb.

So we have invented our own variant of Flavor B with the following properties:

• Sign bit first;
• No data inversion;
• A pre-activation mechanism that accomplishes the same goal as CM's, but implemented differently.

The specification for our flavor can be found here.

There is no difficulty or extra cost associated with supporting both existing flavors as well as our own on our VersaDSU because it's only a matter of software/firmware configuration readily changeable by the user.