How traditional framers work

The traditional framers specified in the 2B1Q-based ISDN and HDSL standards are based on a few key principles:

• The framer operates on the quat stream, not on a bit stream. Whether the interface between the bitpump and the framer is serial or parallel in a particular physical implementation, it needs to be logically viewed as a parallel interface in which each quat is indivisible.
• Each frame consists of a fixed number of quats beginning with a prescribed quat sequence called the sync word.
• The sync word is not scrambled and is thus always directly recognisable in the signal waveform transmitted on the line regardless of any state. Furthermore, the sync word normally consists of only +3 and -3 symbols so that it remains unaffected when the bitpump transmitter operates in the 2-level mode.
• The conversion of the quat stream to a bit stream is the responsibility of the framer. The framer determines which bit positions in the frame carry payload data and in which order they are filled.
• Payload bits are scrambled and the scrambler is implemented in the framer so that it skips the sync word (and possibly some other bits/quats depending on the specific standard).

In the Tx direction the framer simply emits the frame structure (block of quats) prescribed by the respective standard. The Rx deframer locks onto the frame sync word with the usual HUNT-PRESYNC-SYNC state machine and then extracts the rest of the frame. Having the sync word unscrambled while everything else is scrambled makes frame sync very robust and reliable; the likelihood of a false sync is very low even if someone with control of the payload data tries to fool the framer deliberately.

Link good criterion

2-wire transmission systems like ISDN, HDSL and SDSL have one important additional feature relative to the traditional 4-wire systems like T1 and DDS: the activation state machine. In those traditional 4-wire systems the Rx and Tx directions of the circuit were essentially independent and so were the receiver and the transmitter in a terminal unit. The transmitter would always be operating as long as the link was enabled at the local management interface, and the receiver would always keep doing its best to recover the incoming signal. If the Rx signal was bad, the terminal would indicate this condition to its local management interface and perhaps also in some control bit positions in the Tx frame overhead, but it would never take an action that could be called tearing the link down. If the link is bad, tearing it down would not help it heal, would it?

The situation is different with 2-wire transmission. Having data-bearing signals travel in both directions on the same pair requires a much tighter coupling between the receiver and transmitter sections of the terminal unit, and they are no longer independent. The terminal is also no longer stateless and an activation sequence is required before 2-way data transmission can work.

To make the long story short, an HDSL/SDSL terminal unit (HTU or STU) needs to implement an activation state machine, and one of its features is tearing down (deactivating) a bad link. If the activation sequence brings the link up but it subsequently goes bad, the only way to repair it and make it work again may be to tear it down completely and repeat the activation sequence. (Thus with 2-wire transmission tearing the link down can sometimes make it better, paradox notwithstanding.)

In addition to the decisive power to intervene and tear the link down if need be, the terminal unit needs one additional capability in order to implement this function: a criterion is needed for determining whether the link is good or not. Surprisingly enough, this criterion can sometimes be very non-trivial.

The basic problem is that the bitpump by itself is not always capable of detecting when the link has gone south. As it always does its best effort to extract the signal from the noise, given absolutely any electrical signal waveform on input it will produce some Rx quat output; whether this quat output is valid or garbage is another matter. The bitpump's far end level meter (FELM) will normally detect a LOS (loss of signal) condition and its noise level meter (NLM) may give an indication that garbage is being received, but neither of these checks is completely fool-proof. (Calibration is one problem in particular.)

In the standard HDSL application the framer provides the perfect solution. Valid HDSL signal is distinguished from garbage by the frame sync word appearing where it should, and the presence or absence of frame sync is the only criterion one really needs. This criterion is so good in fact that the HDSL spec explicitly specifies it as the only criterion to be used by the activation state machine for whether the link is good or not! Brooktree's HDSL firmware heeds the word of the spec and indeed looks only at the LOSW (loss of sync word) flag of the framer and ignores the bitpump's LOS and NMR indications when operating in the HDSL mode.

However, when one implements an unframed SDSL flavor, some other criterion must be used. With Flavor A the success or failure of cell delineation may replace HDSL LOSW (i.e., one would treat I.432 like a framer), but what about Flavor B?

For Flavor B Conexant's ZipWire Software User Guide recommends adding a check for valid HDLC link to the LOS and NMR (noise margin reading) checks implemented in their example application code. Doing so would not be terribly difficult in an integrated non-modular soapbox SDSL router which breaks the OSI layer separation, but is a little bit of a problem for a modular solution in which the PHY is a separate physical device (DSU) from the router or other higher level terminal which terminates the HDLC bit stream (OSI Layer 2). It certainly would have been cleaner with the HDSL framer.

An additional nifty feature of the traditional frame formats is that each frame carries a few bits of CRC (CRC-6 in HDSL and CRC-12 in ISDN) computed over the previous frame. The frame receiver can then recompute and verify this CRC, and although there isn't much it can do when an error is detected (the bits from the errored frame still contribute to the reconstructed payload bit stream), the framer-level CRC allows a DSU-type terminal unit to get an estimate of the bit error rate on the line without knowing anything about the format of the payload data.

Tip/ring reversal

A quirk of the 2B1Q line code is that it's sensitive to the reversal of the wire pair polarity. (Contrast with AMI and its derivatives used on T1, E1 and DDS lines which is polarity-insensitive.) If the wire pair is reversed, the sign bit of each received quat will be inverted while the magnitude bit remains unchanged.

It goes without saying that all robust telecom systems are built so that even though a correct polarity is defined nominally, everything always works fine whether the line is wired with the correct or reversed polarity. Sure, that line tester on your telco technician's tool belt has an LED which lights green when the polarity is correct or red when it's reversed, but have you ever seen a phone, a modem or any other device that fails to work when that LED is red?

How is then tip/ring reversal handled for SDSL? Well, in ISDN and HDSL the framer once again comes to the rescue: the frame sync word consists of a defined sequence of +3 and -3 symbols without scrambling and the framer can easily detect it both true and inverted. If frame lock is achieved with the sync word inverted, one knows that tip and ring are reversed and can set a control bit in the right register (either in the bitpump or in the framer) to invert the sign bit of all received quats. But what if there is no traditional framer?

Brooktree's solution for using the bitpump by itself uses the following trick. They use the internal startup sequence source which consists of continuous scrambled 1s and they also make use of a special feature of the bitpump's receive symbol detector/descrambler section called the BER meter. The so-called BER meter is actually nothing more than a counter which counts the number of 0s in the descrambled Rx bit stream; if the far end transmitter is sending continuous scrambled 1s, any 0s on the Rx end after descrambling have to be bit errors, hence the name BER meter.

When the bitpump control library has automatic tip/ring detection enabled, it adds the following step to the activation sequence: as soon as it is detected that the far end has switched from 2-level to 4-level transmission and the local bitpump is slicing those 4-level symbols correctly, the BER meter is run over a short interval. Since the far end is assumed to be transmitting 4-level scrambled 1s at this stage, if the tip/ring polarity is correct, there should be very few bit errors counted by the BER meter (ideally 0), whereas reversed polarity should produce lots of errors since the descrambler would be spewing garbage instead of constant 1s. The code compares the BER meter reading against a threshold and if there are too many bit errors, it declares tip and ring to be reversed and tells the bitpump to invert the sign bit of all received quats going forward.

It should be obvious that the above check is very crude and that very often when one sees Tip/Ring Reversal detected in the TDEBUG output, the reality is that tip and ring are actually fine, but the startup sequence has failed and the bitpump is receiving garbage. (At least that has been our frequent experience in the lab.) However, in the absence of a traditional framer with the traditional Barker code sync word, such crude checks are pretty much the only way to handle tip/ring reversal.