Flavor A is what one gets when one applies the
I.432.1
standard ATM
cell stuffer/delineator (formally known as Transmission Convergence
)
to the bit stream coming out of a Bt8970 or RS8973
bitpump.
It is the most straightforward and non-innovative way to implement SDSL/ATM
and indeed it appears that most (all?) ATM flavors of SDSL/2B1Q
with the exception of
Nokia are nothing more than what we call Flavor A.
Before we go any further, it needs to be emphasized that when I.432.1 is
implemented directly over a raw
bitpump without an intermediate framer,
one must hunt for the cell delineation bit by bit, rather than octet by octet.
The octet-oriented mode is easier to implement, more robust and generally
considered more graceful; some common existing hardware implementations of
I.432.1 only support the octet-oriented mode.
However, octet-oriented I.432.1 cannot be implemented over a raw
bitpump because there are no octet boundaries in the signal stream, the largest
naturally delineated units are 2-bit quats.
With the above caveat out of the way, there are several different ways in which Flavor A may potentially be implemented. The first option to consider is that the standard I.432.1 cell stuffer/delineator may itself operate in one of three different basic modes: no scrambling, SSS and DSS. (These concepts and modes are not explained in detail here; you are expected to know ATM pretty well if you wish to hack at this level.) The use or nonuse of SSS has little impact on anything other than the cell delineator itself and its performance, but using DSS would have a larger impact on the bigger picture at the SDSL level. We thus begin our tackling of SDSL/2B1Q Flavor A by splitting it into the subflavors A-without-DSS and A-with-DSS.
Our experiments with
Netopia R7200 have
revealed that DSS-less Flavor A is implemented (at least by Netopia)
exactly how we thought it would be.
The configuration menu (at least on our unit with a fairly early firmware
version) includes the following named options: Generic
, Lucent
,
Nokia Fixed
, Nokia EOC Fast
, Paradyne
and
Nortel UE IMAS
.
Experiment has revealed that all of them except Nokia are Flavor A.
The Generic
and Lucent
profiles appear to be identical; SSS is
enabled and the list of presented data rate choices consists of
all possible data rates.
(We assume that the Lucent profile refers to the
Stinger, not the TNT.)
The Paradyne
profile is the same, but the list of allowed data rates
is restricted to 144, 272, 400, 528, 784, 1168, 1552 and 2320 kbps
(RS8973's preferred set).
The Nortel UE IMAS
profile disables SSS; the list of allowed data
rate choices is again all possible rates.
Here are the critical implementation aspects:
The just-listed key points combine to make a peculiar set of timing requirements. Each side's transmitter starts out sending scrambled 1s and then at some point switches to sending ATM idle cells with valid headers. The point at which this switchover is made is rather critical. The tip/ring reversal detection method relies upon the far end sending scrambled 1s until the bitpump control code is done with the activation process, i.e., you can't be sending ATM cells from the very start. (You might be able to get away with it if you make the idle cell payload all 1s, but it would be cumbersome, especially if SSS is used, and not worth the bother.)
Yet you can't be sending those scrambled 1s for too long either: if the
Flavor A terminal doesn't get cell delineation shortly after the bitpump
control code says it's up, it won't declare the link fully up and instead its
ASM (activation state machine) will proceed to link teardown (deactivation).
In my experiments I have configured my
Hack-o-Rocket as an HTU-C and established
manual sync-up with the Netopia R7200 acting as the HTU-R using
SDEBUG
without anything to transmit ATM cells; the link would stay up for 10 s
before the R7200 would kill it for not getting cell delineation.
Aside from these timing considerations though, it seems pretty simple and straightforward.
The bitpump's internal scrambler is always used in this flavor. SSS makes it harder to fool the cell delineator, but it isn't sufficient scrambling for good 2B1Q transmission performance.
I have yet to see a real world implementation of Flavor A with DSS. Maybe there is one out there, maybe not. (M289xx chipset support for Flavor A with all possible scrambling options including DSS doesn't count as a real world implementation; by the latter I mean a finished product, not just a chip.) It's interesting to ponder though since this is exactly the kind of application that DSS is designed for and should excel at.
DSS is a scrambling option presented in the I.432.1 spec as a possible alternative to SSS. Whereas SSS is designed only to make it harder to fool the cell delineator, DSS achieves a dual function: the same function as SSS plus scrambling for transmission performance. Using DSS would thus allow one to not use the bitpump's internal scrambler; furthermore, DSS is actually a better scrambler than the 23-bit 3-tap self-synchronising scrambler from the ISDN/HDSL/SDSL world. Here are its specific advantages:
It is not a self-synchronising scrambler and thus produces no error multiplication. The standard ISDN/HDSL/SDSL scrambler OTOH produces an error multiplication of 3, i.e., a single corrupted bit in the scrambled bit stream results in 3 bits being wrong at the descrambler output. (They will all be within a 23-bit window, so it isn't too terribly bad, but still.)
A 23rd order LFSR scrambler is good, but a 31st order one is even better. :-)
Of course nothing comes for free, and the price for the benefits of DSS is a much more complex transmission convergence block. Specifically, the I.432.1 receive cell delineator/extractor is much more complex with DSS than with SSS or no scrambling: in addition to HEC checking and cell delineation it must extract the distributed samples of the scrambler state, use them to synchronise the descrambler and maintain a complex state machine to recover from all possible errors.
Perhaps the difficulty of implementation is the reason why Flavor A with DSS is not used as commonly as it could have been. Dedicated chips like RS8228 which implement just I.432.1 transmission convergence and nothing else will normally support all possible modes including SSS and DSS (the ATM block in the M289xx kitchen sink chipset is purported to be identical to one section of the RS8228 octal device, hence it supports everything too), but for example the serial ATM interface in the ATM-enabled MPC8xx telecom PowerPC processors supports only SSS.
If someone did implement Flavor A with DSS, how would it work? Well, one reasonable way to do it would be to start the pump with the internal startup sequence source, use these internally-scrambled 1s with the BER meter to establish tip and ring, then switch the Tx bit stream to DSS, turning off the internal scrambler at the same time. Cell delineation and DSS descrambler synchronisation would then serve as the link up criterion.
It would also be possible to run DSS under the bitpump's internal scrambler (what one would get by taking the Flavor A with SSS configuration and reconfiguring the I.432.1 chip from SSS to DSS while changing nothing else), but let's hope that no one has done this, as it basically amounts to expending the full effort to implement DSS without reaping its benefits (replacement of the HDSL scrambler).
In addition to the I.432.1 scrambling option, the following options need to be considered with Flavor A:
Quat orientation: sign bit first or magnitude bit first. All flavors of A supported by our Netopia R7200 put the sign bit first.
Quat alignment: are ATM cells aligned on quat boundaries so that each cell neatly occupies 212 quats, or can the ATM cell boundary fall in the middle of a quat?
The best implementation strategy is probably the tried & trusted
be conservative in what you send and liberal in what you accept
:
have the Rx cell delineator hunt each and every bit, but have the Tx cell
stuffer align on quat boundaries.
Such an implementation will successfully receive cells from DSLAMs which
haven't bothered to align to QCLK, but will also work if the DSLAM or whatever
on the other end has implemented a quat-oriented cell delineator instead of
standard bit-oriented or octet-oriented.
But then Murphy's Law would have it and someone would find a Flavor A implementation which requires the cell boundary to fall in the middle of a quat... Such would result if someone had intended to do quat alignment, but got the QCLK polarity wrong and never bothered to fix it. So it might be prudent to design the I.432.1 block in the FPGA so that software can request Tx quat misalignment via a control bit.
The optional 01010101 HEC coset. It seems that most ATM implementations, including all SDSL/ATM implementations I've seen so far do use this HEC coset, but it is supposedly optional...