Line Coding Errors

Line Coding Errors (Updated 11-Feb-00)

The dial-up telephone network is based upon your analog telephone's signal being converted to a 64kbps digital stream by a codec. This 64kbps stream (called a DS0) becomes a channel routed by switches, and combined with other channels on carrier-based transmission systems. In the US, 24 DS0 channels are combined (T1 carrier).

One of the limitations of the original design of these systems was that no more than 7 consecutive zeros be transmitted on a T1 carrier. This means that a zero value (8 zero bits) is an illegal value for a T1. The T1 data is generated by a time-slot processor which receives 8000 8-bit inputs per second from each of 24 DS0 channels. If a zero value results in any 8-bits of the output, it is changed to a different value - determined by the line coding.

There are 2 standard line codings: AMI and B8ZS. The older AMI changes an 8 zero-bit sample to 00000010. [The use of AMI coding anywhere in the call path will result in a slight reduction in 56k performance as there is no way to distinguish between the 8-zero bit pattern - 00000000 and 00000010.] B8ZS takes advantage of the bi-polar nature of T1 carrier signals (each 1 is of opposite DC polarity to previous and next 1) to provide a code to represent 0 without affecting the ability to decode all 256 possible values for each 8-bit sample. (B8ZS uses the binary code 11011000 with bi-polar violations to represent a zero value.)

When the T1 signal is received at the next switching or destination point, a time-slot processor generates the 24 DS0 channels. Software settings determine the line coding used by each processor. When the line coding settings match on each pair of processors, the resulting signal passed to the customer will be "good". However, if there is a line coding mismatch in the call path, the result can be highly troublesome for 56k modems.

A line coding mismatch can occur anywhere in the digital network, from the curb (SLC) to your phone company (switches and carrier trunking) to a CLEC (independent phone company) to your ISP. It is not uncommon for line coding errors to result from improper mis-match of the settings for AMI/B8ZS somewhere in the chain! Line coding errors may go undetected by the phone company or its customers, and test equipment and techniques commonly used to check and troubleshoot these systems may fail to indicate any problem!

If there is a line coding error somewhere in a 56k-modem's call path, the result can be a high bit error rate with a serious hit in throughput. The difference in the sent and received values for any particular 8-bit PCM sample can be extremely large in magnitude.

It is important to remember that it is not just what the customer transmits, but what is also transmitted on the adjacent time-slots (channels) during any given frame. Here is an example of what can happen if there is a B8ZS to AMI mismatch*:

For instance, time-slot 1 and 2 have the following data:

time-slot 1 | time-slot 2
00111100    |00000011

or

time-slot 1 | time-slot 2
60          | 3 decimal

In this example, a zero octet is transmitted, but it is split between 2 time-slots, or DS0 channels, time-slot 1 and time-slot 2. The data, due to the B8ZS line transmitter will be converted to the following:

time-slot 1 | time-slot 2
00111111   | 01100011

Notice that time-slot 1’s data was changed from 00111100 to 00111111. Also, notice that time-slot 2’s data was changed from 00000011 to 01100011.

If this were a binary representation of a decimal number, instead of receiving a decimal 60 on time-slot 1, we would have received a decimal 63. On time-slot 2, the customer would receive a decimal 99 instead of a decimal 3.

128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 decimal weighting
   0 | 0   | 0   | 0   | 0 | 0 | 1 | 1 = decimal 3

But, we received:

128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 decimal weighting
   0 | 1   | 1   | 0   | 0 | 0 | 1 | 1 = decimal 99

THIS IS A HUGE ERROR FOR PCM MODEMS: Received = 99       Should have received = 3 !!! (Modems not operating with PCM - ie, 28.8k - will not be as affected as a different sampling rate & decoding method is used.)

Problems due to line coding mismatch may be intermittent or change with time of day: this is because traffic on adjacent time slots will have an effect on the errors in your call's time slot.

This is a REAL problem - The default coding for many transmission vendors - including Lucent - is AMI. There can be a mismatch anywhere in the chain of multiplexors, switching points, SLC or remote office trunks, or ISP equipment. Many large phone companies - including RBOCs - do not routinely do BERT (bit-error-rate-testing) on their trunks. Even if they do test, it may not detect a line coding mis-match!

STANDARD TESTING WILL NOT DETECT LINE CODING MIS-MATCH: There is a standard (CCITT 0.152) that defines the 2047 pseudorandom test pattern that is used to test DS0's. The 108 BERT test will never produce more than 7 consecutive zeros. This means that, when run on a single DS0, with adjacent channels idle, the BERT test will not detect any problem! However, if 2 adjacent channels are tested at the same time, the zeros density will be high enough for both channels to report errors.

Line coding can result in time-of-day related problems - Undetected line coding mis-matches won't always cause problems: if adjacent channels are idle - as in off-peak times - there will be little or no consequence to the mis-match; however, during peak times when adjacent channels are in use, the resulting mis-coded zeros can cause severely reduced throughput, a high rate of modem retrains, and random disconnections.

________________

* - Much of the information in this page is based upon studies and tests conducted by P. Herrald of Time-Warner Telecom.