Puma 4000 Series

Application Note

Puma Application Note PMA51A1

HDB3 Code Encoding
HDB3 is a modified version of the AMI code which produces marks of alternating polarity with a duty cycle of 50% for every bitslot that contains a logic 1 and no marks for the bitslots that contain a logic 0. An example of the AMI coding is shown below. 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1

It can be seen that if there is a prolonged steam of logic 0s without any logic 1s there will be no marks transmitted and therefore the clock recovery circuit at the receiving end could lose synchronisation with the transmitter clock and therefore bit slips will occur. To overcome this problem the HDB3 coding replaces groups of 4 zeros with either 1 or 2 marks ensuring that there is never more than 3 spaces between the marks and therefore maintaining the clock synchronisation. To enable the decoded to distinguish between normal marks and marks that have been introduced to replace groups of 4 zeros a violation is introduced on the last mark. These violations would produce a DC shift in the signal when it is fed down a long transmission line so the HDB3 encoding inverts the polarity of each violation to ensure that there is no DC build up. The same data stream is shown below with HDB3 encoding. 1 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1

The above example clearly shows how the violations alternate in polarity and the HDB3 coding inserts either 1 or 2 marks depending on the polarity of the last mark and violation. At point A the mark was positive and assuming the last violation was negative, a mark is introduced at point B to cause a HDB3 violation indicating the presence of 4 consecutive zeros. The same mark is introduced at point D however as the last mark and last violation are both positive it is necessary to introduce another mark at point C so that there is a violation and t is the opposite polarity to the last violation. These are the 2 types of violation that can be introduced to replace a group of 4 consecutive zeros and maintain the clock recovery synchronisation. The pattern shown at points C through to F are a good example of how an all zeros signal would appear when HDB3 encoded.

January 2002

page 1 of 3

Puma 4000 Series

Application Note

Code errors
In an AMI signal a code error would simply be 2 consecutive marks of the same polarity or violation regardless of the number of spaces between them however this is not true in a HDB3 signal because either 2 or 3 spaces between these marks could indicate that they were a HDB3 violation and therefore not a code error. When code errors are generated in a real system either a mark is incorrectly interpreted as a space or a space as a mark, this is shown below with the code errors indicated with E. 1 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1

There is an equal possibility of a space being incorrectly detected as a positive mark or a negative mark and both of these are shown on the diagram. It can be seen that the way the code is corrupted also changes the data being sent, a logic 1 becomes a logic 0 or a logic 0 a logic 1. If this type of error was to occur on the HDB3 violation it could just change the data and not produce a code violation, see the example below. 1 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1

In this example the incorrectly detected mark has changed the data only so that the last group of 4 zeros has been as 0001. This may produce a code error later if another group of 4 0's occurs or it might not. When introducing code violations in a piece of test equipment it is important to mimic the real world conditions as much as possible. One method commonly used in producing code errors is to simply invert the signal however this does not produce a real representation of how a real error would occur and it can produce a DC shift or low frequency components in the signal when fixed rate errors are introduced. The following diagram shows how the inversion would appear. 1 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0

The problem with this type of error generation is that it is not at all representative of the real telecom system and the inversion shown is not always detected by the exchange equipment. When the above pattern is detected there are several ways it can be interpreted :1. There is 1 code error because the HDB3 violations do not alternate. 2. There are 2 errors because there are 2 violations after the HDB3 violation 3. There are no code errors. Number 1 and 2 are valid interpretations of the HDB3 coding and number 3 is not technically correct however because a lot of equipment just checks for the HDB3 violation and not the alternating polarity of the HDB3 violation a lot of line interface chips would not detect the code error.

January 2002

page 2 of 3

Puma 4000 Series

Application Note

Test Equipment
When generating code errors with test equipment it is important to generate a pattern that not only represents the way code errors would occur in a real telecom system but also to generate them in such a way that the exchange equipment is guaranteed to detect them. This is important because code error generation is used to check the way the exchange equipment detects the errors and the sets the alarms. The simple inversion method is not really suitable as several of the line interface chips will not record code errors when 2 consecutive HDB3 violations are the same polarity as shown above. The engineer installing exchange equipment will want to know that the code error detection on the equipment is working correctly and this will normally indicate that a code error has been received, regardless of the number of code errors. If the equipment uses one of the chip types that do not report code errors for multiple HDB3 violations of the same polarity it might be considered faulty if the test pattern being used has a high content of 4x0s such as a PRBS pattern. To ensure that the equipment being tested detects the errors it is sometimes necessary to introduce a bit error so that the code error can be seen by all of the equipment. The problem with this technique is that the detector may see more than 1 code error for each error injected, depending on how it interprets the errors.

January 2002

page 3 of 3