DSL

Eric Schreiber Erasmus Student at the University of Edinburgh
Crosstalk in xDSL and Simulation of a TC-PAM SHDSL Transceiver

March 2001
Declaration of originality
I declare that this thesis is my original work except where stated.
......................................................
ii
Acknowledgements
I would like to thank Nedko Nedev for his valuable support and for providing source code in Matlab, Martin Luna for his spontaneous help with the Viterbi algorithm and Stephen McLaughlin for a sensible planning.
iii
Acronyms and abbreviations

ADSL ANFP ANSI APK BASK BER BT Byte CO CRC DSL DSP ETSI FDM FEC FEXT FIR HDSL HPF ISDN ISP ITU LPF Asymmetric Digital Subscriber Line Access Network Frequency Plan American National Standards Institute Amplitude Phase Keying Binary Amplitude Shift Keying Bit Error Rate British Telecom A group of eight bits Central Ofce Cyclic Redundancy Check Digital Subscriber Line Digital Signal Processing European Telecommunication Standards Institute Frequency Division Mulitplexing Forward Error Correction Far-End Crosstalk Finite Impulse Response High-bit-rate Digital Subscriber Line High Pass Filter Integrated Services Digital Network Internet Service Provider International Telecommunications Union Low Pass Filter
iv
Acronyms and abbreviations
Next OH PAM PLB PMD PMS-TC POTS PSD PSTN SER SHDSL SNR STM T1 TC-PAM TCM TDM UK xDSL XOR XTalk
Near-End Crosstalk Overhead (bits) Pulse Amplitude Modulation Payload Block Physical Media Dependent Physical Media - Specic Layer Plain Old Telephone Service Power Spectral Density Public Switched Telephone Network Symbol Erro Rate Single-pair high-speed Digital Subscriber Line Signal to Noise Ratio Synchronous Transfer Mode 1.544Mb/s symmetric Transmission Trellis Coded Pam Modulation Trellis Coded Modulation Time Division Multiplexing United Kingdom All kinds of DSL Exclusive Or Operation Crosstalk
Contents
Declaration of originality . . Acknowledgements . . . . . Acronyms and abbreviations Contents . . . . . . . . . . . List of gures . . . . . . . . List of tables . . . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii . iii . iv . vi . vii . viii 1 1 1 3 3 6 7 9 10 10 10 14 15 15 20 20 21 22 22 23 26 28 34 41 43 45 51 60 89 vi
Introduction 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Structure of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Digital Subscriber Line 2.1 An introduction . . . . . . . . . . . . . . 2.2 Crosstalk in DSL . . . . . . . . . . . . . 2.3 The ITU-T Draft G.991.2 for SHDSL [1] 2.4 Summary . . . . . . . . . . . . . . . . . Cross-Talk in Digital Subscriber Line 3.1 Introduction . . . . . . . . . . . . 3.2 PSDs: Equations and Results . . . 3.3 NEXT: Equations and Results . . 3.4 FEXT: Equations and Results . . . 3.5 Conclusions . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
The TC-PAM Transceiver 4.1 Introduction . . . . . . . . . . . . . 4.2 Programming considerations . . . . 4.3 Components of the simulation . . . 4.3.1 Structure . . . . . . . . . . 4.3.2 Framer and Deframer . . . . 4.3.3 Scrambler and Descrambler 4.3.4 TCM encoder . . . . . . . . 4.4 Results . . . . . . . . . . . . . . . . 4.5 Conclusions . . . . . . . . . . . . . Conclusions
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
A Crosstalk calculation in Matlab B SHDSL transceiver simulation in Matlab C SHDSL transceiver simulation in C++ References
List of gures
2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 ADSL Reference Model . . . . . . . . . . . . Frequency bands in ADSL . . . . . . . . . . . 16-PAM and 16 APK . . . . . . . . . . . . . . NEXT and FEXT model . . . . . . . . . . . . Simplied user plane protocol reference model PSDs of ADSL up- and downstream . . PSDs of various services except ADSL . NEXT of ADSL up- and downstream . NEXT of various services except ADSL FEXT of ADSL up- and downstream . . FEXT of various services except ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 6 7 8 17 17 18 18 19 19 20 23 24 26 27 28 29 31 32 33 33 34
SHDSL transceiver application model . . . . . . . . . . C++ Programming Scheme . . . . . . . . . . . . . . . . Structure of a frame . . . . . . . . . . . . . . . . . . . . Block diagram of the scrambler . . . . . . . . . . . . . . Block diagram of the descrambler . . . . . . . . . . . . Block Diagram of the TCM Encoder . . . . . . . . . . . Diagram of the convolutional encoder . . . . . . . . . . State transition diagram of the convolutional encoder . . Constructing the Trellis diagram . . . . . . . . . . . . . Introducing Hamming distance and weights in the trellis Trellis diagram after rejecting inferior nodes . . . . . . . Final shape of the trellis diagram . . . . . . . . . . . . .
vii
List of tables
4.1 4.2 4.3 4.4 4.5 SHDSL Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An example of convolutional encoding . . . . . . . . . . . . . . . . . . . . . . . . Input-Output characteristics of the convolutional encoder . . . . . . . . . . . . . . Mapping of bits to PAM levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results using parameters proposed by [1] (Pe = 0.001, 10 Frames, n = 3, i = 0, 4000 symbols, 11520 data bits, 12000 bits total) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Another way of mapping bits to PAM levels . . . . . . . . . . . . . . . . . . . . . Results obtained with the new mapper (Pe = 0.001, 20 Frames, n = 3, i = 0, 8000 symbols, 23040 data bits, 24000 bits total) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results obtained with the new mapper (Pe = 0.01, 20 Frames, n = 3, i = 0, 8000 symbols, 23040 data bits, 24000 bits total) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results obtained with a two-level-error impairment generator (Pe = 0.001, 20 Frames, n = 3, i = 0, 8000 symbols, 23040 data bits, 24000 bits total) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 30 31 35
4.6 4.7
36 38
39
4.8
40
4.9
41
viii
Chapter 1 Introduction
1.1 Overview
In a world with a growing need for efcient data transmission, DSL has proven to be a competitive technology. It combines the advantages of providing fast means of Internet access with the usage of an existent infrastructure known as the plain old telephone service (POTS). By employing processing power of modern DSP technology to implement efcient modulation methods and to overcome transmission impairment, high-speed data transmission rates of a multiple 1 of that required for a single voice signal become possible. Crosstalk noise induced from signals present in adjacent wires has to be understood in order that different transmission technologies do not interfere with each other. Different equations for crosstalk have been published by various authors. In a rst approach, crosstalk formulae have been evaluated and compared with each other and their consistency was investigated. In a further, more extensive approach, the Single-Pair High-Speed Digital Subscriber Line (SHDSL) Transceiver specied by the ITU-Draft [1] has been simulated. A rst attempt was made with Matlab before the simulation was completed in C++ due to performance considerations. The core of the transceiver is a Trellis Encoder/Decoder, which is capable of correcting errors caused by noise in the transmission lines. Noise has been simulated by selectively destroying a certain number of symbols produced by the transmitter. After decoding, the performance of the transceiver has been evaluated in respect of error correction capabilities and conclusions have been drawn.
1.2 Structure of this thesis

Fundamentally the project consists of two main parts: Investigation of crosstalk in various DSL systems and a simulation of a trellis encoded SHDSL transceiver specied by the ITU Draft [1]. After an introduction, background information to both parts will be provided in the second chapter i.e. functional principles of DSL and impairment caused by crosstalk. Further we will address the
1
Nearly 100 according to [2] (p.1)
CHAPTER 1. INTRODUCTION
ITU draft underlying the implementation of the simulated SHDSL transceiver. The

chapter investigates crosstalk equations provided by different resources. An approach to
the characteristic power spectral density (PSD) functions, and two sets of crosstalk models will be made. It is followed by a discussion of the results obtained from the Matlab programme. Chapter 4 describes the implementation of the trellis encoded SHDSL transceiver. A Matlab-based approach to the simulation will be compared with the nal implementation in C++. A successive description of the components of the transceiver will make up the core of this project. Using different levels of symbol error probabilities the performance of the transceiver will be tested and the results discussed. Matlab and C++ code used for the simulation can be found in the appendix.
Chapter 2 Digital Subscriber Line

2.1 An introduction
DSL is a new data transmission technology making high-speed transmission on existing telephone connections a reality. It offers an always-on service using the same copper wires as voice telephone service but bypasses the public switched telephone network (PSTN) used by the plain old telephone service (POTS) for data transmission. The telephone lines used by conventional voice signals are connected to a voice coder/decoder (codec) in the central ofce (CO) owned by the telephone company. The voice codec converts a voice signal with a maximum frequency of 4 kHz into a digital (modulalated) signal of 64 Kbps which will then be routed through the PSTN. In contrast to DSL, telephone calls operate over an end-to-end PSTN connection which means that a xed pathway through the network is established and remains until the connection is closed. Dial-up modems are converting digital data into an analogue representation of the signal which will then be transmitted like an ordinary telephone call. Due to the limitations set by the voice codec at the central ofce the theoretical bandwidth supported by the cable can by far not be exploited using this kind of transmission technology.
Central Office
voice
PSTN Switch
PSTN network
Figure 2.1 depicts the transmission method deployed by asymmetric DSL (ADSL). A DSL cus3
data
DSL - CPE
local loop
DSLAM
Internet Service Provider
Figure 2.1: ADSL Reference Model
CHAPTER 2. DIGITAL SUBSCRIBER LINE
tomer premise equipment (CPE) will be installed at the customers side multiplexing voice signals and data signals for transmission over the local loop. At the CO, a DSL access multiplexer (DSLAM) will then split off the voice signal and route it to the circuit switched infrastructure of the PSTN, whereas DSL data trafc will be routed over a backbone network to an internet service provider or corporate network. Figure 2.2 shows the frequency bands of ADSL. The lowest (POTS) band is carrying the voice signal from 300 to 3400 Hz. It is separated from the data signal by a LPF (splitter). ADSL allocates upstream transmission1 and downstream transmission2 to two different frequency bands, both far above the limit set by the voice codec. By processing signals at frequencies of up to more than 1 MHz, the DSLAM allows a much higher transmission rate to be achieved. Two-way transmission in the same band is possible as well, but restricted to a certain frequency due to crosstalk becoming more signicant at higher frequencies. This will be shown in more detail in chapter 3.
Power
POTS Band Lower Bit-rate Upstream Band
Higher Bit-rate Downstream Band
Frequency [kHz] 4 10 200 1100
Figure 2.2: Frequency bands in ADSL Symmetric DSLs such as HDSL do not support analogue POTS (voice) but transmit an equally high data rate upstream and downstream at rates up to 1.54 Mbps (2.048 Mbps for the European version). Like ADSL, HDSL uses a wide bandwidth exploiting even the band used for POTS in ADSL. Single-pair HDSL uses an echo-cancelled transmission method which means that the upand downstream bands are not separated as in ADSL but superimposed. They will be separated at the receiver using echo-cancellation. Although ISDN data trafc is routed through the PSTN switches (like a telephone call) and not
1 2
From the customer to the CO From the CO to the customer
through the DSLAM concentrator, ISDN is mostly referred to as a predecessor of XDSL services. It supports 128 Kbps symmetrical service and is employing two bearer channels at 64 Kbps each and a signalling channel (D-channel). In certain cases this 16Kbps-channel can be used for data transmission as well. ISDN works as a dial-up service and uses a bandwidth of 80 kHz. T1 is an always-on, point-to-point service where transmission lines are leased from the telephone company. 24 x 64 Kbps channels deliver a total of 1.54 Mbps of data (2.048 Mbps for the European E1-version). This service is usually used by larger companies or ISPs. T1 transmission uses a high transmitted signal power, which generates high levels of crosstalk at a wide range of frequencies. T1 lines thus, must be segregated into separate binder groups. To transmit data and voice signals over the local loop, various modulation methods are employed. The most common ones used in ADSL and HDSL are CAP (Carrierless Amplitude and Phase), DMT (Discrete Multitone) and 2B1Q (Two Binary, One Quaternary). We will not elaborate on these modulation schemes here since the modulation technique proposed for the SHDSL transceiver is PAM (Pulse Amplitude Modulation). A PAM signal is created by convolving a symbol sequence with a pulse shape as described by equation 2.1 ( [3], p.150)
many other pulse representations. In the SHDSL draft [1] the pulse shape is not specied and is presumably chosen by the vendor or determined by regional peculiarities. The sample symbol
signal levels. The most common kind of PAM uses only two levels and is called binary amplitude shift keying (BASK). In BASK, the symbol rate and bit rate are the same since one bit is converted into one symbol. The SHDSL PAM transceiver employs a 16-level alphabet mapping a word of 4 bits
into one symbol. As explained in detail in [4] (p.381-383 and p.391-395),
PAM is spectrally less efcient than other modulation schemes. Another way to achieve a better performance of Pe is by introducing phase modulation. In combination with PAM an improved distribution of signal states can be obtained as depicted in the constellation diagram (Figure 2.3). For 16-PAM, all signal levels lie on the real axis while for amplitude/phase keying (APK) they are arranged in circles in the complex plane. A received signal which is impaired by noise represents
) % 0(
time and its inverse
is the baud rate. The pulse shape can be a rectangular pulse or one of
represents a value from an alphabet with a nite number of elements or
is the sample symbol at time instant
and
% # ! & $" '

is the pulse shape function.
# 6 7( 3 1 542
(2.1)
is the symbol
a point somewhere in the complex plane. To decide which of the possible symbols (represented as dots in the diagram) has been transmitted there is clearly more decision space available for 16 APK since a complex dimension is added. Therefore a better Pe can be achieved with APK. However more complexity for transmitter and receiver is required as well.
Im
Im Re Re
Figure 2.3: 16-PAM and 16 APK
2.2
Crosstalk in DSL
Crosstalk is one of the main types of noise interference 3 and occurs when electromagnetic coupling causes an electrical signal to induce currents from one circuit into the other. In the XDSL environment crosstalk occurs primarily within wire pairs contained in a so-called binder group typically made up of 50 pairs. Crosstalk can be the main factor limiting the performance of XDSL services resulting in a certain number of destroyed symbols at the receiver. The performance obtained is generally stated in terms of symbol or bit error probability (BER). A higher transmitter power may improve the BER but will result in an increase of crosstalk interference to adjacent transmission lines. Telephone companies thus have released so-called PSD masks, imposing maximal transmitter power levels depending on the frequency. Given two or more pairs of wire in a binder group the amount of crosstalk interference depends mainly on bandwidth and power of the contributing signals. Since various XDSL services have different PSD functions, the induced crosstalk noise depends on the services used for transmission in adjacent pairs. Efforts have been made to investigate which services are spectrally compatible in a sense of low crosstalk noise induction. The policy pursued by BT for the UK [5] (Access Network Frequency Plan or ANFP) aims at maximising the capability of their copper network by minimising mutual interference. However,
3
There is also impulse noise and radio noise
for the reason of cable pairs not being adjacent for the whole range of the local loop, statements about their spectral compatibility cannot be made. Thus BT has no management policy allowing only certain services on adjacent wire pairs. All pairs in an access cable shall be allowed to support any of the transmission systems supported by the ANFP.
2-wire cable transmitter NEXT receiver receiver transmitter
2-wire cable
FEXT
Figure 2.4: NEXT and FEXT model As depicted in gure 2.4, there are two types of Crosstalk: Near-End (NEXT) and Far-End (FEXT) crosstalk. Given an active transmitter and receiver at one end of the cable, NEXT noise occurs when the signal from the transmitter is coupled back into the receiver. NEXT between two pairs of the same Transceiver can be avoided by using FDM or TDM, whereas this is not possible for NEXT between adjacent different pairs. Figure 2.2 illustrates how NEXT crosstalk on the same pair can be avoided by dividing upstream and downstream ADSL-transmission into two different channels (FDM). At higher frequencies, NEXT noise will increase, while the signal power will decrease due to attenuation in the cable. FEXT on the other hand, is due to noise coupled into the signal travelling to the far end of the transmission line from the source when transmitting in the same direction on both lines. Since the noise signal has to travel along the entire cable, it will be attenuated. For this reason FEXT is in general less signicant than NEXT. Requirements for high transmission rates, limited transmitter power, long distances of transmission and low BER cannot all be met at the same time. Should one factor be improved, concessions will have to be made to another.
2.3 The ITU-T Draft G.991.2 for SHDSL [1]

G.991.2 is a standard released by the International Telecommunication Union describing the interface between the telecommunications network and the customer installation in terms of their
interaction and electrical characteristics. SHDSL transceivers are designed primarily for duplex operation4 over mixed gauge two-wire twisted metallic pairs and are capable of supporting selected symmetric user data rates in the range of 192 Kbps to 2312 Kbps using a Trellis Coded Pulse Amplitude Modulation (TC-PAM) line code5 .
STU - R PMS - TC (Physical Media Specific TC - Layer)
STU - C
PMS - TC
PMD (Physical Media Dependent)
PMD
Physical Media
Figure 2.5: Simplied user plane protocol reference model Figure 2.5 shows the two lower layers of the user plane reference model. One SHDSL Transceiver Unit is located at the remote end (STU-R) and the other one at the Central Ofce (STU-C). Both are connected to each other over the local line or physical media. For the purpose of simulating the functionality of the SHDSL transceiver we have to elaborate on the functional characteristics of the Physical Media Dependent (PMD) and the Physical MediaSpecic Transmission Convergence (PMS-TC) layer6 . Information about activation processes may be ignored since the SHDSL transceiver shall be simulated in data transfer mode. The PMS-TC layer consists of the framer/deframer and the scrambler/descrambler modules. Frame synchronization is also addressed here but for the simulation this shall concern us only as far as synchronization bits will be inserted into the frames. The framer is the rst module implemented in the simulation. In a real transceiver it would be linked via interface to a protocol of a higher hierarchy e.g. STM. The framer divides incoming data into payload blocks which will then be used to construct the frames. The overhead bits of the frame contain information to assure a safe transmission. The purpose of scrambling data is to make an input data stream more random. Assuming an independent occurrence of ones and zeros in binary transmission, long sequences of the same symbol
Sending information continuously in both directions As stated in the scope and summary in the SHDSL ITU draft 6 Corresponding to chapters 6 and 7 respectively (SHDSL ITU-Draft)
5 4
are not desirable. According to [2], there are two types of scramblers: Synchronous scramblers and Self-synchronizing scramblers. The former generate a pseudorandom output sequence by multiplying (XOR) the binary data, using a predened polynomial. Self-synchronizing scramblers require less complexity of synchronization and use a simple lter polynomial and its inverse for descrambling and scrambling respectively. The latter will be used for the SHDSL transceiver. The PMD layer consists of 6 principal functions. Relevant for the simulation is only the coding/decoding 7. The coding/decoding module consists of 3 submodules all of which will be described in chapter 4.
2.4 Summary
In this chapter, background information on DSL has been provided and crosstalk, a main factor limiting DSLs performance has been addressed. A brief introduction into the structure of the SHDSL transceiver was given at the end. The main difference between the POTS, based on an end-to-end PSTN connection and DSL deploying a DSL Access Multiplexer allowing transmission at much higher frequencies was discussed. Having given a description of the frequency bands of ADSL, a variety of DSL services have been presented focusing on their properties in the frequency domain. In the crosstalk section, an explanation of its occurrence has been given before we elaborated on NEXT and FEXT, the two types of crosstalk interference. In the last section we had a closer look at the SHDSL ITU draft [1] focusing on the modules used later in the SHDSL transceiver simulation.
7 The others are: Symbol timing generation and recovery, modulation and demodulation, echo cancellation, line equalization and link startup
Chapter 3 Cross-Talk in Digital Subscriber Line

3.1 Introduction
In this chapter methods will be examined to quantify different types of crosstalk. The corresponding equations are implemented in Matlab to compare them and elaborate their accuracy. The following 3 sources have been investigated: Understanding DSL technology by T. Starr, M. Ciof and P. J. Silverman [2]

This book focusing on xDSL in US telecommunication networks provides crosstalk equations for a variety of transmission technologies including ADSL, ISDN, HDSL and ISDN Standard T1.413 by ANSI [6] T1.413 provides crosstalk models for the same types of DSL as [2] and as well a crosstalk description for T1 lines. Plots of the functions can be found here as well. Draft G.991.2 by ITU [1] This source has only be used for its equation for SHDSL crosstalk in this chapter. For other interferer functions it references to [6]
3.2 PSDs: Equations and Results

In order to evaluate a NEXT or a FEXT crosstalk PSD function, the PSD function of the interfering service has to be known. Since calculating NEXT and FEXT from a given interferer-PSD is a simple process, it makes sense to rst compare the various underlying PSD functions provided. Many of the stated equations provided by the three sources have been implemented in Matlab (see Appendix A). The only difference in those formulas is an additional scaling factor of 1000, allowing to draw the graphs in DBm.
10
CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE
11
ADSL upstream according to [2]
where
ADSL upstream according to [6]
(3.2)
where
In ADSL upstream, [2] was employing a slightly different model compared to [6]. Equation 3.1 is using a frequency dependent constant while equation 3.2 incorporates a high and a low-pass lter. In gure 3.1 (at the end of this chapter) we can see that the two resulting functions are quite similar. However equation 3.2 reaches a higher peak power and falls off at a slightly higher frequency. Looking at the lower frequencies it becomes obvious as well that equation 3.1 makes an approximation and forgoes the HPF (the function does not start at the origin). 3.2 is the only equation where no scaling (DBm) factor has been added for the Matlab implementation. If there was, the function would have been magnied by 30 DB resulting in a plot completely out of boundaries. The other equations also issued by [6] however, require this scaling factor to obtain a reasonable result. Consequently we note that source [6] lacks consistency.
D EC
c gG j TURmHG Y H1 i UmHHbE ! n n T R IIIc l 1 SH1 j UR i I ( H ( ! I T i Y d c I p PG !Ig
A 9 3 &5875 1 7 f t # R x t # 0x ! #r (( ! y A @ &5875 3 0)'% $ t 9 1
138 kHz
28 kHz
D EC
f 138 kHz 0
T UR )
A 875 9 63 1 5 A@9 31 % B&65875 420)('&$

#
3 a s h ph f d c Y x` vwrrFuF rqt r6i ge !15! H F i TUR ) # bHH a`Y
#
" ! h f g f !f f f4f h 4f t R k f gf f f4!fh f f # e t g T R i I ( 6 H1 4 G F

! !
(3.1)
V WX
# ! T RQIG F USHPH1 4
12
ADSL downstream according to [2]
where
ADSL downstream according to [6]

Equation: same as equation 3.2 Variables and lters:
gG j I TUmnHG Y H1 i R HHxE ! R n T IIIc l 6 ( ( j UR I ( !I ( ( i T c d x!I ( ( S ! c I
that we receive a wrong result if we use equation 3.3. Plugging in the factor in the equation results in practically the same plot for both equations as depicted in gure 3.1. Minor differences lie in the LPF and HPF. For the latter, the cut-off frequency is signicantly lower in equation 3.3. For ADSL up- and downstream we obtain two completely different graphs. This makes sense if we remember that ADSL employs FDM to transmit in two different frequency bands (Figure 2.2). ADSL upstream transmits only at relatively low frequencies while the bandwidth used by ADSL downstream is much wider. Since the two bands are overlapping we can assume that echocancellation has been deployed.
HDSL
For HDSL, the two sources ( [2] and [6]) provide the same equation 3.4. The last term could be
In ADSL downstream the main difference lies in the factor
. A graphic plot in Matlab has shown
D EC
(3.3)
A 875 9 &3 1 5 t # R H t 0x A @ 9 &575 3 1 0)'&$ % 7t TU!I ( ( R c # 0cSI ( (
fh f TURPH1 r i f t R I h 9 5 h r i h5 1 t # e T RQIG F USHPH1 4
#
! # ! y ffhff f g f h f f R fk g f h f f t e f g f t # T R I ( Y H1 S1 4 I F
13
identied as a LPF with a cut-off frequency at 196 kHz. Figure 3.2 shows the HDSL-function with the two most signicant lobes. The rst lobe begins to fall off at the cut-off frequency.
where
ISDN
For ISDN the two sources ( [2] and [6]) provide the same equation (3.5). The last term could be identied as a LPF with a cut-off frequency of 80 kHz. The constants used in this function are very similar to the ones employed for HDSL. Apparently the result in gure 3.2 is similar too. This time the lobes are much more narrow and the rst lobe begins to fall off at approximately 80 kHz.
T1
For T1 services [6] provides the equation 3.6. Here, we nd an additional factor with a sine in square. This factor is responsible for the exceptionally high values the function is showing at high frequencies (See gure 3.2).
where
t A
F B
A A 1 A R t A # ECi R t @ 9 F P1 DB @
h 9 5 5 1 h h
ff 1 t @ 9 7 r$ F 4 ( 1 ff t t @ 9 7 1 $
2 0 31
where
d # 31n ( )` ' %d $" HG S1 2 0 I ( & # ! A u ! U T R Q F T R 6 ( i USH1 4 f f @ ( F q 9 f 1 $ t 9 f7 1 4 ( # ! 1 ! ff t @ 9 7 1 $ f ff @ 3 9 7 f 7( F 1( $ t 9 f 7 1 1 f t @ 9 7 1 $

6 7
(3.4)
6 4 !r4 # 7!s5y

u
6 7
)` ' %d $" Hn S1 I ( & # ! F T RQ !r4 USHI Y 4
G DB t # F ECi R
#
8 9

(3.5)
(3.6)

=
14
SHDSL
For (symmetric) SHDSL there was only one source available ([1], p.93). Here, various PSD functions are provided dependent on the user data rate. Generally, the functions all have high values at low frequencies and fall off abruptly at certain values. Two different data rates have been chosen for the Matlab programme: 1536 Kbps and 2048 Kbps. The former reaches a low transmit power level at around 480 kHz and the latter at 620 kHz. The function representing the PSD of the minimumdata-rate-SHDSL of 192 Kbps (as used in the SHDSL transceiver simulation) would start to fall off at a frequency of less than 100 kHz.
3.3 NEXT: Equations and Results

Equation 3.7 provided by [2] calculates the NEXT crosstalk PSD from a given interferer PSD. The only difference to the formula used in [6] is the constant which in [6] becomes
This yields practically the same result. Characteristic for NEXT is its gain with frequency by a power of 1.5.
c u h p I ( F 9 1 ih
Figure 3.3 depicts the 4 NEXT graphs that can be obtained if equation 3.7 is applied to the ADSL PSD functions investigated before. The power level has dropped by a factor of almost
shape of the graphs of ADSL upstream have not changed signicantly but for ADSL downstream an increase of crosstalk at higher frequencies is apparent. Figure 3.4 shows NEXT PSD functions for the other services discussed in section 3.1. The most crosstalk interference is produced by T1 services. This explains, why T1 transmission lines have to be segregated into separate binder groups. SHDSL with high data rates produce signicant crosstalk noise as well. While [2] and [6] dont show graphs of PSD functions they provide a set of plots depicting NEXT and FEXT PSDs. To assure that the PSD and NEXT PSD plots are correct, a number of NEXT
3 I ( ( h
I(
Y Y
T R cc UH!n
. (3.7) . The
i g I ( h
F 4 #r
(#( y
d # 30 HI ( 2 I A f fh A f A
#
6 ( f t # F B 8 R
8
6 y
15
functions have been plotted using the same number of interferers as in [2]. This has been realised with an additional plot which is not shown here. The Matlab code provided in appendix A however is plotting this set of functions. The obtained result is practically the same as the one depicted in [2] (Figure 3.17 in [2]).
3.4 FEXT: Equations and Results

As explained in chapter 2, FEXT-noise is produced by a signal which has to travel over the transmission line. In the FEXT equation 3.8 this is expressed by the transfer function H(f) which in the programme is a sub-function implemented in C. This function has been implemented for a crosstalk model in an ADSL simulation earlier (see [7]). One of the arguments of this function - the line
Again the two functions differ only slightly in the constant. While [6] uses
term
. Thus the slopes are falling off slightly slower than in NEXT.
Figure 3.5 and 3.6 show the results obtained from equation 3.8 using the same PSD functions as for NEXT. This time the maximum power level has dropped to approximately interference is virtually no threat for other transmission lines.
3.5 Conclusions
Section 3.2 has shown that complex equations are used to describe power spectral density functions of different transmission services. Since two crosstalk equtions from [2] yielded a reasonable result only with an additional factor, equations from this source should not be used without verication. The obtained crosstalk functions may be used to create PSD masks for services in adjacent wire pairs. Theoretically, services can be chosen in such a way that mutual interference is minimal. Though this is technically feasible it might still fail for the reason that cables are not adjacent for their entire length. Another way to limit impairment is by releasing PSD masks - maximum allowed power levels dened for a number of frequency segments. Using the obtained crosstalk PSD
it p I (
t ` F I ( t
c # R x #r (#( y 8 F 9 1 t
a factor of
, as shown in equation 3.8. In FEXT the frequency dependency is given by the
t ( F I Y
length - has been set to 4 Km.
, [2] employs
t ( F I
t
(3.8)
. Such a low
16
functions we can adjust the transmitter power to make the resulting crosstalk lie within the limits of the PSD mask. Appart from minor differences the compared crosstalk models show a remarkable consistency. However, accuracy seems not to be the primery concern. Rather, there is a desire to obtain a rough shape of crosstalk PSDs in order to be able to state which services interfere most with each other. As we have seen, there is a number of mathematical ways to simulate the behaviour of crosstalk. However, one should be aware that these results are only a rough approximation. Various telecommunication companies and organisations have released instructions about how tests of transmission lines should be conducted in order to obtain line properties. Since transmission lines and their characteristics depend vastly on regional peculiarities theoretical crosstalk models should be used only as a supplementary guideline besides practical tests. In the range of 0 to about 1 MHz, all PSD functions except the one for T1 are decreasing in power with increasing frequency. Although there is a
most of the NEXT functions still show high interferences at lower and falling slopes at higher frequencies. This is helpful since signal power is attenuated more at higher frequencies. Signicant crosstalk power at high frequencies is a major impairment factor for the SNR. For this reason modulation schemes have been designed to have spectrums with low power at high frequencies. T1 is an exception producing high amounts of crosstalk in the entire spectrum. ADSL is employing FDM and has to be investigated separately as an ADSL up- and downstream service. While ADSL upstream is transmitting at a low data rate reserving a narrow band at a relatively low frequency, ADSL downstream uses a larger bandwidth in order to transmit at high data rates. Although the slopes of FEXT functions are falling off slightly slower than in NEXT the shape of the functions are very similar compared to their NEXT counterparts. The difference lies primarily in the power level which is much lower for FEXT. Even if we assume a maximum number of interferer the impairment caused by FEXT is virtually negligible.
u h
relationship between PSD and NEXT PSD,
17
Various PSDs of ADSL up and downstream 0 10 20 30 40 PSD (dBmscale) 50 60 70 80 90 100 110
upstream according to [starr] upstream according to ANSI downstream according to [starr] downstream according to ANSI
5 frequency
10 x 10
5
Figure 3.1: PSDs of ADSL up- and downstream

PSDs of various services except ADSL 0 10 20 30 40 PSD (dBmscale) 50 60 70 80 90 100 110 SHDSL 1536kbit/s SHDSL 2048kbit/s HDSL ISDN T1
5 frequency
10 x 10
5
Figure 3.2: PSDs of various services except ADSL
18
NEXT from ADSL up and downstream interferers (10) 80
90
100
PSD (dBmscale)
110
120
130
140
150
5 frequency
10 x 10
5
Figure 3.3: NEXT of ADSL up- and downstream

NEXT from various services except ADSL, 10 interferers 80
90
100 SHDSL 1536kbit/s SHDSL 2048kbit/s HDSL ISDN T1
PSD (dBmscale)
110
120
130
140
150
5 frequency
10 x 10
5
Figure 3.4: NEXT of various services except ADSL
19
FEXT from ADSL up and downstream interferers (10) 200
210
220
230 PSD (dBmscale)
240
250
260
270
280
290
300
5 frequency
10 x 10
5
Figure 3.5: FEXT of ADSL up- and downstream

FEXT from various services except ADSL, 10 interferers 200 SHDSL 1536kbit/s SHDSL 2048kbit/s HDSL ISDN T1
210
220
230 PSD (dBmscale)
240
250
260
270
280
290
300
5 frequency
10 x 10
5
Figure 3.6: FEXT of various services except ADSL
Chapter 4 The TC-PAM Transceiver

4.1 Introduction
As depicted in gure 4.1 the Trellis Encoded PAM transceiver dened by the ITU-T Draft G.991.2 [1] consists of 2 x 5 stages: The framer, scrambler, TCM encoder, precoder and the spectral shaper for the transmitter and the deframer, descrambler, TCM Decoder, precoder and spectral shaper for the receiver. The rst 3 stages for both directions (drawn solid in gure 4.1) will be implemented in this simulation.
Framer
f(n)
Scrambler
s(n)
TCM Encoder
x(m)
Precoder
y(m)
Spectral Shaper
y(t)
f(n) Deframer
Descrambler
s(n)
TCM Decoder
x(m)
Precoder
y(m)
Spectral Shaper
y(t)
Figure 4.1: SHDSL transceiver application model The output of the TCM encoder are TC-PAM symbols. Assuming certain values for the Symbol Error Rate (SER), symbols will be destroyed randomly and the performance of the 3 modules processing the destroyed symbols can be measured. Apparently it would be closer to reality and more sophisticated an approach to use the precoder and spectral shaper to produce a PSD function representing the transmitted output data which could be compared to crosstalk PSD functions obtained in chapter 3. This would be a more realistic approach to investigate the effects of noise to the system. Unfortunately, the coefcients of the precoder lter and its functionality itself have not been dened very clear in [1]. Therefore, a simulation and investigation of the 3 stages seems to be a feasible approach, yet allowing to assess the performance of the core modules. The transport capacity of the SHDSL transceiver is dened as follows:
I ` '# & G C C I ` ) 6 C & d ) Q Y & c 6 ( ` ! # &
20
& 1 !

2 !
CHAPTER 4. THE TC-PAM TRANSCEIVER

Thus the maximum data rate is: and the minimum data rate is:
21
4.2 Programming considerations

In a rst approach the SHDSL transceiver was implemented in Matlab. Fundamentally, a decision had to be made, about how a bitstream should be represented internally. At rst bits representing a data bitstream were contained in an unspecied Matlab Vector. Unfortunately in this case each single bit was internally occupying 52 bits! A boolean data type is difcult to handle in Matlab, however by using variables of type uint8 the ratio of the number of representing bits to that of memory occupying bits could be increased from to .
A much more efcient approach could be achieved by working with words instead of bits. This would mean that we could still use a 52 bit data type but we would access each internal bit of the word individually. This was possible for a model of an ADSL transceiver simulation results of which were published in [7]. There, it is possible to process a bitstream sequentially, transmitting frames one after the other as it is done in a real transceiver. In the SHDSL-simulation however, this approach would pose a problem since the modules scrambler and descrambler are processing bits from different frames at the same time. Hence, our approach is to process a bitstream entirely by each module before it is forwarded to the next one. Matlab provides a set of bit-manipulation functions to work on this (word-) level. A function calculating the cyclic redundancy check (CRC) was implemented successfully. Unfortunately the length of the message was restricted to 52 bits. Concatenating words to extend the message length would have made the function very complex. Moreover this problem would have occurred in other functions as well. The framer for instance has to set the rst 14 synchronization bits to one. Since the frame length depends on user input and is usually not a multiple of 52, these bits would be found most certainly at different locations in the words containing synchronization bits. Such complexity can be avoided by working with continuous bitstreams. Provided we use simple bit-vectors as described before, Matlab offers a convenient environment when bit manipulations are required. In the nal Matlab implementation, the data is rst represented by a continuous bitstream vector of type uint8. The le framer returns a matrix of the same type with each column vector containing one frame. The scrambler which follows is most easily applied to a continuous bitstream and thus the matrix is converted back into a vector before scram-
I ` ' & & ` ) 6
& 1 !
& 1 !
# hq
# d ) P1 ( Q d ) H1 ( 1 Q sht u

bling.
22
Having completed the modules framer/deframer, scrambler/descrambler and partially the encoder/ decoder1 the performance of the programme was found to be very poor. To transmit 2 frames at the minimal data rate (n=3, i=0), the programme took approximately 5 s with the descrambler taking longest with almost 2 s. Changing the data type to uint8 brought a slight improve of roughly 20%. This was still unacceptable. Consequently a second approach using C++ was attempted. Having reached the same level of model development in C++ as in Matlab a rough comparison was possible yielding an improvement factor of approximately 100: In the same time the Matlab simulation transmitted 2 frames, the C++-transceiver was processing 200 frames of the same size 2 . Though still being considerably more efcient than the Matlab version, the nal programme in C++ suffers in performance due to the time-consuming Viterbi algorithm of the convolutional decoder. The simulation in C++ will be explained in detail in the next chapter.
4.3 Components of the simulation

4.3.1 Structure
Figure 4.2 depicts the structure of the C++ programme. Lines with arrowheads refer to interfaces where user-data is forwarded from one le to the other. The dash-dotted lines describe subrelationships where a sub-function contained in one le is performing a subtask before returning a result to the invoking function in another le. It could be described as a help-function relationship. The bold, dashed relationship appears when a C++ class function (consisting of a dot-h interface and a dot-C implementation le) is called. The core of the class BitStream3 is a boolean vector. Various member-functions are dened to alter or extract a certain number of bits contained in the boolean vector. The purpose of this functions is to ease the handling of the BitStream and to out-source processes needed by more than one other function. To a certain extend the class BitStream provides a bit-working-environment similar to the one naturally available in Matlab. The main le shdsl.C creats a BitStream which will be processed by the subsequent modules. The
The submodules serial-to-parallel and parallel-to-serial converter and the Mapper and unmapper have been implemented, whereas the convolutional encoder does only bit-copying 2 Note that since the two programming environments are entirely different, we can not conclude that C++ is approximately 100 times faster than Matlab 3 From now on, instead of using the term bitstream we will use BitStream to refer to an object of the class BitStream. This is fundamentally the same but our BitStream consists of an additional set of member-functions.
1
23
format of the data remains BitStream until it is sent to the le Mapper.h which converts bits into symbols. Later they will be converted back by the le Unmapper.h. The class Viterbi is not as fundamental a data structure as BitStream but rather uses the quality of a C++ class to structure the rather complex Viterbi algorithm. Both pairs of class les are compiled into a dot.o le by the Makele, which nally compiles the whole programme into an executable le.
Scrambler.h Framer.h TCM_encoder.h TC.h
Mapper.h
Bitstream.h
BitStream.C
shdsl.C
ImpairGen.h Unmapper.h
TCM-decoder.h
TC_reverse.h
Deframer.h
Descrambler.h
Viterbi.h CRC.h Xor.h Makefile Viterbi.C
Figure 4.2: C++ Programming Scheme
4.3.2
Framer and Deframer
As depicted in gure 4.3, the frame consists of a series of synchronization bits followed by 4 overhead sections and 4 consecutive Payload Blocks (PLB). At the end of the frame, two stufng bits are added. Most of the overhead bits explained below are not essential for the simulation. They were implemented in order to have a complete frame to be processed. Overhead (OH) bits are required by the transceiver for different purposes and will be explained below.
Frame Synchronization Word
24
Sync O bits H
PLB 1
O H
PLB 2
O H
PLB 3
O H
PLB 4
Stuff bits
Figure 4.3: Structure of a frame The rst 14 bits in every frame enable the (real) SHDSL receiver to acquire frame alignment. For the simulation they have been set to one. Payload Blocks The size of one Payload Block is dened as k bits and is divided into 12 Sub-blocks of size

where
[bits]. Thus one Payload Block has a size of
If we divide the block size by the data rate as dened in chapter 4.1, we obtain a value for the time duration for one block:
In the C++ implementation the Payload Blocks are simply copied from the input-BitStream into the frame-BitStream. Embedded Operations Channel Bits There are 20 overhead bits used for the Embedded Operations Channel (EOC) providing a separate maintenance channel. These bits are used only in the real transceiver to maintain a network management database. They are disabled in this simulation and thus set to zero. Cyclic Redundancy Check code The cyclic redundancy check (CRC) is used for error detection and has to be generated for each frame. The generator polynomial is dened as
where
stands for the XOR - operation.
required in the theory [4].
The message polynomial M(x) shall consist of all bits in the frame except for the synchronization
In Matlab, as in C++, this message is rst constructed in the framer module before the message is

bits, stuff bits and, obviously, CRC bits. Thus, the message length is dened to be
6 1
Qc bE
In decimal notation the value of the polynomial becomes
which is a prime as
&
Q ! # ) d # n
1(
6 (
d )
Q Y
1(
) &
Q Y
1(
& '
` !#
Y
&

sent as an argument to the CRC sub-function.
25
One way4 to calculate the CRC bits is by rst bit-shifting M(x) by 6 - the order of P(x), and then divide M(x) by P(x). The remainder yields the required CRC bits. In the simulation, the bit-shift is done by simply extending M(x) by 6 zeros. Then, the programme follows the procedure of a binary division on a scratch-pad. Finally the subfunction returns the 6 CRC overhead bits to the invoking function (Framer.h or Deframer.h). Fixed Indicator Bits The 4 xed indicator OH-bits (fbits) are used for time-critical framing information and indicate anomalies. They are not used in the simulation and are thus set to one indicating a normal status. Stuff Indicator Bits and Stufng Bits In synchronous mode the two stuff indicator OH-bits (sbid 1 and 2) are spare bits and set to zero. There are only two stufng bits (stb1 and 2), which are chosen to be zero as well. Table 4.1 shows the structure of the frame. The length of the entire frame is
the 6 CRC bits are allocated to different locations by pairs. For other overhead bits the situation is similar. Apparently, the message created for the CRC has to be constructed entirely by itself.
Frame Bit # 1 - 14 15 - 16 17 - k + 16 Frame Bit # k + 17 - k + 20 k + 21 - k + 22 k + 23 k + 24 k + 25 - k + 26 k + 27 - 2k + 26 2k + 27 - 2k + 30 2k + 31 - 2k + 32 2k + 33 2k + 34 - 2k + 35 2k + 36
Name sw 1 - sw 14 fbit 1 and 2 b1 Name eoc 1 - 4 crc 1 and 2 fbit 3 sbid 1 eoc 5 and 6 b2 eoc 7 - 10 crc 3 and 4 fbit 4 eoc 11 - 12 sbid 2
Description Synchronization word (14 bits) 2 xed indicator bits Payload Block #1 (k bits) Description 4 EOC bits 2 CRC bits 1 xed indicator bit 1 stuff indicator bit 2 EOC bits Payload Block #2 (k bits) 4 EOC bits 2 CRC bits 1 xed indicator bit 2 EOC bits 1 stuff indicator bit
Another approach would be to implement a hardware CRC encoder in C++
Yc
Q bc
. Note that
26
2k + 37 - 3k + 36 3k + 37 - 3k + 40 3k + 41 - 3k + 42 3k + 43 - 3k + 46 3k + 47 - 4k + 46 4k + 47 - 4k + 48
b3 eoc 13 - 16 crc 5 and 6 eoc 17 - 20 b4 stb 1 and 2
Payload Block #3 (k bits) 4 EOC bits 2 CRC bits 4 EOC bits Payload Block #4 (k bits) 2 stufng bits
Table 4.1: SHDSL Frame Structure
4.3.3
Scrambler and Descrambler
The self-synchronizing scrambler implemented in the SHDSL transceiver multiplies (XOR) the input BitStream with a lter polynomial generating a more random Bitstream.
s(n)
f(n)
Tb
s(n-1)
Tb
Tb
s(n-5)
Tb
Tb
s(n-23)
Figure 4.4: Block diagram of the scrambler Figure 4.4 shows the scrambler as proposed by the SHDSL draft [1] (p.37). Since the synchronization and stuff bits do not have to be scrambled, there is a bypass allowing the input f(n) to be connected directly to the output s(n). All other bits will be scrambled by the lter, whose transfer function can be derived from the gure as follows:

Applying the z-Transform yields
# T
p T it
1 5!
&
T
n
!
&
u T
&
# T
" & d
# T
(4.1)

and we obtain the lter function
27
The descrambler has to inverse the process of the scrambler. [8] (p.773-775) suggests that this is achieved by a lter whose transfer function is simply the inverse of the lter. This process is called inverse ltering or deconvolution. For the inverse Filter we write:
and applying the inverse z-Transform yields

In the binary notation the minus signs become XOR-gates and we can redraw the descrambler as depicted in gure 4.5.
x(n)
Tb
x(n-1)
Tb
Tb
x(n-5)
y(n-1)
Figure 4.5: Block diagram of the descrambler The implementation of the scrambler and descrambler in Matlab and C++ starts with copying the bits from the input BitStream into a temporary, continuous BitStream. This is the simplest way to do it, since the scrambler convolves bits across the boundaries of the frames. The scrambling
# T
# T
it p T
1 !
(4.2) (4.3)
Tb Tb
x(n-23)
it p T i g T t u T it p T
&
it p T
! !
T ! ( # T
! # T
( !
u T
u T u T n
! (
&

! ( # T
! ( # T
u T
# T # T
! # T
& &
T
# T
# T # T # T
R
E4 6
28
process itself multiplies (XOR) the bits according to the scrambling function 4.1 and writes them into a second temporary BitStream. Finally the synchronization and stuff bits are added when the scrambled bits are copied into a third BitStream designed to hold the resulting scrambled bits. An equivalent, inverse procedure is employed for the descrambler.
4.3.4
TCM encoder
As depicted in gure 4.6 the TCM encoder consists of 3 submodules: A serial-to-parallel (SP) converter, a convolutional encoder and a Mapper. The SP converter takes 3 samples from the input stream and forwards each of them to one of the outputs X1, X2 or X3. Obviously, the bit rate at the output x(m) must be one third of the one at the input s(n). n is the number of bits after the framer (and scrambler) and m is the number of symbols. Unfortunately, n depends on the transmission rate and in general, is not a multiple of three. In the simulation this was taken into account and the input BitStream was extended (zero appendage) appropriately. The SP converter was implemented by copying the serial bits into three temporary BitStreams of length m.
X 3(m)
Y (m) 3
Scrambler
s(n)
Serial to Parallel
X 2(m)
Y (m) 2
Mapper
x(m)
X 1(m)
Convolutional Encoder
Y (m) 1 Y (m) 0
Figure 4.6: Block Diagram of the TCM Encoder BitStream X1 is then sent to the convolutional encoder which performs a process similar to the one used by the descrambler. However, two different characteristic polynomials are used here producing two output BitStreams Y0 and Y1. Finally, the submodule Mapper is converting each four bits into one symbol. Pulse amplitude
29
modulation (PAM) is employed here assigning one of 16 possible signal amplitudes to the input vector containing the 4 bits Y0, Y1, Y2 and Y3. After the transmission, the sequence of submodules will be executed in reverse order. The Mapper becomes an Unmapper, the convolutional encoder is replaced by the Trellis Decoder and the SP converter by a parallel-to-serial converter. Since there is only a slight difference between the submodules Mapper and Unmapper, they will be discussed in the same section at the end of this chapter. The convolutional decoder will be described in the next section before we elaborate on the heart of the transceiver, the error-correcting Trellis Decoder.
Convolutional Encoder
[1] (p.18) states, that the coefcients of the encoder are vendor specic and should be chosen in such a way that the performance requirements are satised. The number of memory-stages should not exceed 20. This is not restrictive since typical (convolutional) encoder polynomials are of smaller order. [9] (page 98, Table VI for R=1/2) for instance shows various polynomials of orders ranging from 1 to 7. Since the convolutional encoder entails a Trellis Decoder of much higher complexity, coefcients
Y0
X1
T0
T1
T2 Y1
Figure 4.7: Diagram of the convolutional encoder should be chosen carefully. A feasible approach is suggested and described in [4] (p.351-359). Figure 4.7 shows a block diagram of this simple 2-stage half-rate encoder. A sequence of bits enters the encoder at the input X1. After one delay the actual bit proceeds from T0 to T1, the rst memory stage. After each delay the bits are forwarded to the next stage. Y0 is the result of an XOR multiplication of T0 and T2 and Y0 respectively of T0 and T1. Table 4.2 gives an example of the process. The output sequence which is twice as long as at the input was obtained by arranging the Y0 - Y1 bits in pairs.
30
Input Output
1 11
0 01
1 01
1 10
0 00
Table 4.2: An example of convolutional encoding Using the same notation as for the descrambling lter, the convolutional encoder can also be described by the two functions
As in the les scrambler.h or descrambler.h, the simulation of the convolutional encoder employs the XOR sub-function to create the resulting bits. Two new BitStreams Y0 and Y1 are designed to store them.
Trellis Decoder
A good description of the Trellis Decoder employed in this simulation can be found in [4] (p.351359). However, it is necessary to derive and show the key ideas in this section in order to explain how the Trellis Decoder was implemented in C++. The Trellis Decoder was implemented by using a class construct. Different member functions help to structure the process to build the trellis, to employ the Viterbi algorithm and to nd the correct output sequence. From gure 4.7 we derive table 4.3 which shows the output of the encoder for every possible combination. Since the output bits (Y0 and Y1) are not only determined by the two memory stages (T1 and T2) but also by the bit arriving at the input (T0) there are
Based on this table we can derive the state transition diagram of the encoder as depicted in gure 4.8. The values inside the boxes are representing the four states of the encoder with the values T1 and T2. Each transition is labelled with the input value T0 (before the slash) and the two output values Y0 and Y1 (after the slash).
Using the transition diagram we are able to draw the Trellis Diagram. Figure 4.9 shows the rst
( ! # (
1 5! # (
# ( # (

# # (
entries in the table.
31
T0 0 0 0 0 1 1 1 1
T1 0 0 1 1 0 0 1 1
T2 0 1 0 1 0 1 0 1
Y0 0 1 0 1 1 0 1 0
Y1 0 0 1 1 1 1 0 0
Table 4.3: Input-Output characteristics of the convolutional encoder

1 / 11 1 / 10
10
0 / 00
00
0 / 01
1 / 01
11
1 / 00
0 / 10
01
0 / 11
Figure 4.8: State transition diagram of the convolutional encoder three stages5 of the decoding trellis. The four different states are given at the left side of the trellis. Since the encoder is empty at the beginning (lled with zeros) the initial state is 00 (denominated as A in the programme). From here, we can either reach state 10 (B) via transition 11 or remain in the same state by choosing the output 00. In the second stage, there are also paths leading to states 01 (C) and 11 (D) and in the third stage every state is reached by two different paths. The C++ class Viterbi uses a pointer approach to construct the trellis. Two pointers (next0 and next1) are leading to the two next nodes to the right in the trellis and a third one is used to maintain a link to the back. The algorithm starts with an activation process (member function startup) where the rst two stages make the trellis grow such that every state is reached by one path.
Using the rst three output pairs 11 - 01 - 01 from the example shown in the encoder we would choose the bold transitions in gure 4.9 to obtain the same output from the Trellis Decoder. However, if the bits are corrupted (e.g. if the
5 In the C++ programme, the term step is used to refer to the number of horizontal segments or stages in the trellis tree diagram (starting at zero). Care has to be taken not to confuse state with stage
i c
bit is received as a 0 instead of a 1 and we would receive
32
00
00 11
00 11 11 10
00
10 01 01 10
0 01 01
10 11
11 [11] [01]
00 [01]
Figure 4.9: Constructing the Trellis diagram the sequence 11 - 00 - 01) it becomes unclear which path to choose. Time to introduce the Viterbi algorithm: The Viterbi decoding algorithm is designed to choose the most likely path to a given node and rejecting all other possible paths on the grounds that their Hamming distance is larger and that they are, thus, less likely events than that represented by the shorter distance path. ( [4], p.355) The Hamming distance is determined for each transition as the number of bits of the transition-bits different from the received bit-pair. For each paths end-node a weight is calculated by adding up the Hamming distances of every transition of the path. Figure 4.10 shows the weights for the received sequence 11 - 00 - 01. After three stages, there are two different values obtained for each state. The rst value given (in brackets) represents the result from the upper (incoming) path. In Viterbi.h this is done by the member-function insert. At each of the four nal nodes, two transitions are added and 8 new nodes are created. To access them, 8 pointers called leaves have been deployed in the structure of the Trellis Decoder. For each of the new nodes, the Hamming distance and the weight are calculated and the state is determined. The next step and core of the Viterbi algorithm is to reject one of the two paths arriving at two equal states. 4 inferior nodes (with larger weight values), their transitions and eventually the paths leading there have to be deleted. This is done by the member function prune. In the example depicted in gure 4.10 the two paths leading to state A have both the same nal weight. In this situation it doesnt matter which path is chosen. As shown in gure 4.11 the choice made in this example, as in the programme, is to select the lower path. Ending up with 4 nal nodes we are ready to insert another received pit-pair. In the programme
33
00
[0]
00 11
[2]
00 11
[2] 11 [4] 10
00
[3,3]
10
[0] 01
[3,1] 01 01
01
[1] 10 [1] 10 11
[4,2]
11 [11] [00]
[6,2] 00 [01]
Figure 4.10: Introducing Hamming distance and weights in the trellis the insert member-function is called once more appending 8 new transitions and complete nodes to the trellis. Again, a call to the prune member-function follows making the right end of the trellis diagram again look like in gure 4.11. This iterative process is repeated for all received bit-pairs.
00
[0] 11
[3]
10
[0] 01
10 01 [1] 10 [1] 11
[1]
01
[2]
11 [11] [00]
[2] 00 [01]
Figure 4.11: Trellis diagram after rejecting inferior nodes The next task (executed by the member function nish) is to choose the node with the lowest weight from the 4 nal ones and delete all inferior nodes and their paths. If we apply this procedure to our trellis we receive a single path as depicted in gure 4.12.
34
The last step is easy: We determine for each transition if it is of type upward or downward. For upward we output the result zero and for downward one as shown in gure 4.12. The member-function result follows this procedure for the entire path and collects all output bits in the resulting vector X1.
00
[0]
1
10 [0] [1] 0
0
01 [1]
1
1
11 [11] [00] [01]
Figure 4.12: Final shape of the trellis diagram
Mapper
The purpose of this submodule is to map a possible combination of Y0, Y1, Y2 and Y3 into one of 16 possible PAM symbols. The mapping table as dened by [1], (p.19) is given in table 4.4. In the C++ programme the function Mapper is converting a vector containing 4 binary values into one PAM symbol (data type: oat) according to table 4.4. In the TCM decoder the function Unmapper does the reverse process converting a symbol back into a vector of hopefully the same 4 digits. Both functions are invoked repetitively for every symbol.
4.4 Results
To assess the performance of the SHDSL transceiver an impairment generator was implemented to destroy symbols randomly depending only on a selected symbol error probability. In a real transceiver, the amplitude of the PAM signal would be impaired by noise and some of the PAM symbols would be mistaken as symbols of close vicinity. In the simulation this was achieved by
35
0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0
0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
Table 4.4: Mapping of bits to PAM levels rendering symbols selectively. A symbol of value 5/16 for instance could be rendered to either 3/16 or 7/16. The probability of a symbol rendered to a a level which is two levels away is very small compared to a one-level-error. Nevertheless, this shall be investigated as well. Concerning bit and symbol error probability, [2] (p. 23) writes: DSLs are designed with a 6 DB SNR margin. This means that the DSL will provide
when the crosstalk signal power is 6 DB greater than the dened worst case crosstalk model. In many cases, the worst-case crosstalk model is a 50-pair binder group lled with 49 self crosstalkers. With pure Gaussian noise, a 6 DB SNR margin would result in a

BER. However, in
the real world, noise is often non-Gaussian. Thus, for typical conditions, the 6 DB margin provides assurance that DSLs usually operate at a BER of better than
and that DSLs will provide
reliable service even when the transmission environment is worse than normal. According to [4] (p.389) the relationship between symbol errors and bit errors is:
where M, the number of PAM-levels, is 16 in the SHDSL transceiver. Equation 4.4 implies that if we use the highest BER stated above we receive a SER of
. For the simulation this is
far too small if we want to obtain a quantitative result within a realistic time. Thus a SER of
i S I (
I(
3 I ( t
I( c
I(
2 #
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
t ! #
x(m) -15/16 -13/16 -11/16 -9/16 -7/16 -5/16 -3/16 -1/16 1/16 3/16 5/16 7/16 9/16 11/16 13/16 15/16
BER
(4.4)

and
36
latter value is where the decoder starts to work properly as we shall see. Care has to be taken when the SER is that high that it produces error clusters which prevent the decoder from correcting error occurrences one after the other. A SER of
located far enough away from each other in the Trellis diagram but large enough to obtain a reasonable amount of corrected bits. Considering table 4.4, we realise that the way bit-errors occur is very much dependent on the symbol error. Bit Y3 is wrong only if a symbol is rendered from 1/16 to -1/16 or vice versa. For Bit Y2 there are two similar occurrences when symbols change between 7/16 and 9/16 or between -7/16 and -9/16. Obviously, the bit representation of the symbols was implemented with a minimum number of zero-to-one transitions in mind. Remembering gure 4.6 we note that only bits Y0 and Y1 are sent to the trellis decoder but errors occurring in Y2 or Y3 remain unaffected. Therefore, most one-level-errors result in a change of bits Y0, Y1 or both. Table 4.5 shows the rst results obtained with transmission coefcients n = 3, i = 0 and Pe = 0.001, sending 10 frames, 4000 symbols or 11520 bits of user data (12000 including all framing bits). The programme was run 10 times with and without6 Trellis encoder and the results were averaged. The second column shows the number of destroyed symbols which should be close to the number of transmitted symbols times the symbol error probability Pe. The third and fourth columns show number of destroyd bits after the Trellis Decoder and the number of destoyed data bits after the last block (deframer) respectively. The last column contains the number of destroyed frames as reported by the function conducting the cyclic redundancy check (CRC) after transmission. To obtain a meaningful value there, we should strive for a high number of frames rather than a high bit rate. Thus the minimal bit rate (n = 3, i = 0) was used for all experiments.
Trellis Dec. no yes
# of destroyed symbols 4.1 4.3
# of destr. bits after framer 6.5 1417.9
Table 4.5: Results using parameters proposed by [1] (Pe = 0.001, 10 Frames, n = 3, i = 0, 4000 symbols, 11520 data bits, 12000 bits total)
It should be noted that the process of bit copying employed when the convolutional encoder / Trellis Decoder is disabled is not eligible to deduce a factor telling how many times better or worse the error correction module has performed. In the encoder, bit copying is done by simply copying each bit to either Y0 or Y1 alternating. In the decoder, either Y0 or Y1 (the one which contains the information) is copied back to X1. Thus if there is an error in the Y0 or Y1 bit which is not copied to X1 the error is corrected. Consequently, the choice no Trellis Decoder is performing slightly better than one might expect and should be used only as a lead.
6
i S I (
t g I (
has been used to investigate the performance of the error correcting Trellis Decoder. The
turned out to be small enough to produce errors
# of destr. data bits 11.2 1370.4
CRC 2.7 4.6
37
Clearly, this result will not get you to buy a Trellis Decoder. It shows, that if this submodule is not working properly the result is much worse than without using it. Having made sure that the Trellis Decoder is capable of correcting bits, the answer was not found unless its proper bit-correcting performance was investigated in more detail: The encoder was capable to correct single bit errors (with a Hamming distance of one) in either Y0 or Y1 very well. However, if Y0 and Y1 were corrupted at the same time producing a Hamming distance of two, the Trellis Decoder produced a cluster of errors! This happens when the Hamming distance of a node in the trellis diagram is small enough to get the algorithm choose a wrong path in the diagram. Every trellis segment in the diagram being part of this path would then produce an error. Consulting table 4.4 again we realise that 7 of 15 neighbourly symbols are having a Hamming distance (of the two least signicant bits) of two. This indicates that roughly each second symbol error produced a cluster of errors in the output BitStream leading to a poor performance overall. Unfortunately this is a consequence of our decision to choose a simple Trellis Decoder. Decoders employing more memory stages show a superior performance and should be able to correct errors occurring in pairs as well. On the other hand it is possible as well to choose the binary representation of the symbols in the mapper in such a way, that the Hamming distance between two adjacent PAM-levels is always one (in Y0 and Y1). This was attempted in table 4.6. The mapping of bits Y2 and Y3 is the same as before which means that there are still three PAM-level transitions allowing an error to slip through the decoder. Since a symbol can be altered forth and back there are 6 possible error occurrences that cannot be corrected. The total number of possible one-level-errors is

the number of PAM-levels7 . Thus we can expect an error correction capability of approximately
. In other words: The number of errors should decrease by roughly a factor of 5.33 as
they pass through the decoder. Again the simulation was run 10 times with the Trellis Decoder enabled, yielding an average of 7.7 symbol errors, 3.9 errors in data bits, 1.3 errors in the entire bitStream and 1.1 frame errors as reported by the CRC (see table 4.7). The rst conclusion we can draw: The encoder works, reducing 7.7 symbol errors to 1.3 bit errors. Even if we assume that one symbol error results in only one bit error8 we can say that an error reduction from 7.7 to 1.3 is good enough to satisfy the predicted factor of 5.33. In the second part of the table where no Trellis Decoder was used, the number of symbol errors is almost twice the number of bit errors after
It would be more accurately to subtract 2 and work with 30 due to the symbols , which can only change in one direction but the impairment generator does not take this into account 8 In fact there will be slightly more bit errors since some symbol errors result in two - correctable and uncorrectable bit errors.
7
6 1 1 7(
where 16 is
gn
t &i
38
0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0
0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0
Table 4.6: Another way of mapping bits to PAM levels decoding. This conrms the explanation of having a loss of half of the errors due to alternate bit-copying. Apparently the number of errors in the data BitStream has increased by a factor of 3 compared to the gure we obtain after the decoder. At rst this appears very strange since there are only bits taken away in the deframer and its functional reliability has been tested extensively. Where do the new errors came from? There is only one more module after the decoder: The descrambler. A test with only scrambler and descrambler activated has been made and the latter module turned out to be the culprit. Equation 4.3 describes the occurrence: There can be an error in either x[n], x[n-5] or in x[n-23], in any case the error will be copied into y[n]. If there is a single error in x[n] it will inict (after XORing it with other bits) 3 different bits of BitStream Y. An explanation of this occurrence can be found in [2] (p.286): However, a single input bit error into the descrambler can lead to a nite number of descrambler output bit errors. The multiplication number of bit errors is equal to the Hamming weight of the primitive polynomial, typically about 3 to 5 in practice. This slight loss in bit error rate is more than offset by the aversion of having to synchronise in most applications. Thus all DSLs to date use self-synchronizing scramblers [as in this simulation]. The CRC reports the number of faulty frames and has to be in a range between 0 and 20. In this experiment the values are the same or slightly below the gures in the
i c
2 #
1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1
x(m) -15/16 -13/16 -11/16 -9/16 -7/16 -5/16 -3/16 -1/16 1/16 3/16 5/16 7/16 9/16 11/16 13/16 15/16
column. At rst this

# # of destroyed symbols # of destr. bits after decoding With Trellis Decoder 4 3 0 2 0 0 1 0 0 3 1.3 Without Trellis Decoder 5 4 5 2 6 1 6 6 5 3 4.7 # of destr. data bits CRC
39
1 2 3 4 5 6 7 8 9 10 Av.
15 7 6 7 5 6 8 5 8 10 7.7
12 9 0 6 0 0 3 0 0 9 3.9
3 3 0 2 0 0 1 0 0 2 1.1
1 2 3 4 5 6 7 8 9 10 Av.
8 7 6 7 7 8 10 10 8 8 7.9
14 12 12 5 18 15 18 17 14 9 13.4
4 4 4 2 5 4 4 6 4 3 4.0
Table 4.7: Results obtained with the new mapper (Pe = 0.001, 20 Frames, n = 3, i = 0, 8000 symbols, 23040 data bits, 24000 bits total) seems odd since the CRC is computed after the descrambler. The reason is that the duplicated errors produced by the descrambler lie in close vicinity (maximum 23 delays away from each other) and are scarcely spread over a borderline of a frame. Therefore a cluster of 3 errors is inicting only one frame in most of the cases. A third simulation has been conducted with an error probability of 0.01. The results are shown in table 4.8. With the Trellis Decoder enabled the simulation yielded a very poor result for average numbers of error occurrences. However the values show that there were only a few cases where the decoder didnt work properly but was producing a huge number of errors. This suggests that the Trellis Decoder works only at low SER. A Pe of 0.01 is obviously in the transition zone. A clearly lower SER such as 0.001 has to be used to make sure that the output produces fewer errors.
40
# of destroyed symbols
# of destr. bits after decoding With Trellis Decoder 13 1620 1847 13 12 19 7 1142 19 4982 967.4 # of destr. bits after decoding Without Trellis Decoder 41 37 40 37 64 42 38 51 41 50 44.1
# of destr. data bits
CRC
1 2 3 4 5 6 7 8 9 10 Av. #
78 87 75 83 66 81 87 93 81 69 80.0 # of destroyed symbols
39 1584 1816 38 36 57 21 1116 54 4810 958.1 # of destr. data bits
9 10 13 9 10 13 5 10 11 18 11.1 CRC
1 2 3 4 5 6 7 8 9 10 Av.
83 87 71 70 104 73 68 89 75 82 80.2
111 104 110 108 180 122 105 146 117 141 124.4
18 18 16 15 18 18 16 18 19 18 17.4
Table 4.8: Results obtained with the new mapper (Pe = 0.01, 20 Frames, n = 3, i = 0, 8000 symbols, 23040 data bits, 24000 bits total) In the rst half of the table the results generated by the CRC are noticeably low even for bulk-error producers. This suggests that long, continuous error-sequences are generated when the Trellis Decoder follows a long (and wrong) path in the diagram inicting a couple of adjacent frames. A last simulation has been conducted using a different impairment generator. This time the symbol was altered by two levels. Thus the symbol 1/16 for instance can become 5/16 or -3/16. The result is shown in table 4.9. Again the Trellis Decoder produces huge amounts of errors. This is logical since 4 two-level-errors produce a change of bits Y0 and Y1 as can be seen in table 4.6. If we assume a (large) SER of
I( c
for one-level-errors, the probability for two-level-errors will
41
be very small. However even one single two-level-error producing a change of both least signicant bits (Y0 and Y1) generates a cluster of errors. Since the SER is very small this poses no real threat to our system which is allready allowing a certain amount of errors sliping through the decoder. However, aiming at operating a reliable transceiver, the probability of two-step-errors should be calculated and additional measures should be taken as the case may be. This may include a more sophisticated Trellis Decoder or an additional error correction schemes. Trellis Dec. yes no # of destr. symbols 4.1 4.0 # of destr. bits after decoding 2998.2 7.0 # of destr. data bits 2899.2 19.8 CRC 11.4 6.2
Table 4.9: Results obtained with a two-level-error impairment generator (Pe = 0.001, 20 Frames, n = 3, i = 0, 8000 symbols, 23040 data bits, 24000 bits total)
4.5
Conclusions
A rst approach in Matlab has turned out to be too inefcient due to our approach of representing data in vectors. The more efcient method of working with words was rejected because the modules of the SHDSL transceiver all have to access the information bitwise. The substantially better performance achieved with C++ was a compensation for the additional expenses required in the new environment. Hence, results could be produced within a reasonable execution time. Since the SHDSL draft [1] states that the Trellis Encoder/Decoder required by the transceiver is vendor specic a simple two-stage half-rate encoder has been chosen. Unfortunately the simulation has shown that the obtained Trellis Decoder is not capable of correcting errors with a Hamming distance of two. Thus a new mapping module has been introduced to remedy this problem. The results obtained with the new module were satisfying and proved that it is possible to employ one of the most simple Trellis Encoder/Decoder in the transceiver to transmit data reliably. However, it is known that by increasing the number of memory stages in the convolutional encoder the performance of the Trellis Decoder can be improved signicantly. Although this would make the code much more complex and probably reduce the speed of the simulation it would be a more realistic approach. As it has been shown in the third experiment (Table 4.7) the convolutional decoder duplicates the amount of errors by a factor of 3 (for a small Pe). According to [2], this is a property of self-synchronizing scramblers and can only be avoided by choosing a more complex scrambler.
Chapter 5 Conclusions
DSL, one of the most contemporary promising transmission technologies, is offering a variety of facets worth investigating. The main aspects of this project were to get understanding of DSL in general, to investigate crosstalk as a main impairment factor to transmission efciency and to simulate an SHDSL transceiver specied by the latest ITU Draft [1]. Chapter 3 has shown NEXT and FEXT crosstalk models for a set of services. Equations given by different sources for the same service proved to be consistent in general and their plots showed the characteristics described in theory. FEXT crosstalk clearly proved to be less signicant than NEXT. While practical tests to assess the properties of transmission lines are required to facilitate choosing the best transmission technology, theoretical crosstalk models can help to consider which services are spectrally compatible with each other and what interference one might expect from crosstalk. Yet, only pure crosstalk noise caused by one kind of interferer has been investigated. In a 49-pair binder group different crosstalk scenarios are conceivable. As proposed by [1] (p.83-84) this could be simulated by composing the different crosstalk models evaluated in this paper. Moreover, a comparison could be made between PSD functions obtained from evaluated crosstalk models with the most recently released PSD masks. Chapter 4 has elaborated on two approaches of the SHDSL transceiver. Matlab has proved to be too inefcient a tool to simulate a transceiver which processes data bitwise. A second approach employing C++ could remdy this deciency but resulted in a more extensive programme. Unlike Matlab, basic functions had to be implemented rst to facilitate handling with bitstreams. The effort was rewarded by a programme which runs aproximately 100 times faster. By employing a simple impairment generator to destroy a number of symbols, it was possible to assess the performance of the transceiver. The results have shown that it is possible to use a very simple convolutional encoder / Trellis Decoder in combination with a modied PAM-Mapper to obtain a transceiver reducing the number of errors by a factor of 5 to 6. Theory of Trellis Decoding suggests that improvements are possible by extending the length of the encoder and increasing the complexity of the Trellis Decoder. It would be an interesting and feasible task to extend the current encoder length to verify its performance with the PAM-Mapper suggested by the SHDSL Draft [1]. However, we should keep in mind that we cannot improve the error correction capabilities of 42
CHAPTER 5. CONCLUSIONS
43
the transceiver any further since there would still be the same number of bits slipping uncorrected through the Trellis Decoder. In this simulation, symbols were destroyed at two different, relatively large symbol error rates. It should be possible to achieve higher accurracy in assessing the qualities of the transceiver by using smaller SER-values and transmit more data (by using higher data rates or by sending more frames). A more challenging task would be to derive a more realistic SER by using crosstalk noise obtained in chapter 3 to destroy the symbols. This could be realised with an SNR approach where crosstalk models would be used to calculate a value for the noise power. Using realistic values for the signal power, the bit and symbol error probabilities for PAM could be calculated with the obtained SNR. Finally, by including impulse noise as an additional impairment factor, the simulation could be made yet more realistic.
Appendix A Crosstalk calculation in Matlab

File xtalk.m
function xtalk()
Nchannel = 256; f = 2156.25 + ((1:Nchannel)-1) * 4312.5; fmax = 2156.25 + (Nchannel-1) * 4312.5;
linetype = 2; linelength = 4.0;
CALCULATING PSDs
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% PSD of ADSL upstream interferer according to [starr] f0 = 270e3;
Kadsl(f<138e3) = 10(-3.8); Kadsl(f>=138e3) = 10.(-3.8 - (2.4 .* (f(f>=138e3) - 138e3)/43125));
PSDadsl_us(f==0) = Kadsl(f==0); PSDadsl_us((f==0)) = Kadsl((f==0)) .* ((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2);
% PSD of ADSL upstream interferer according to ANSI Standart T1.413 (ADSL) f0 = 276e3; Kadsl = 1000*0.0437; % Correction factor of 1000 for DBm scaling
alphal = 20.32; lpf2 = 1.0./(1.0 + (f((f==0)) / 138e3).alphal); alphah = 7.34; hpf2 = (f((f==0)).alphah + 4e3alphah) ./ (f((f==0)).alphah + 25.875e3alphah);
PSDadsl_us_ansi((f==0)) = Kadsl * (2/f0) .* ((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2 .* lpf2 .* h
% PSD of ADSL downstream interferer according to [starr] f0 = 2.208e6; Kadsl = 1000*0.1104;
44
APPENDIX A. CROSSTALK CALCULATION IN MATLAB
45
alpha = 8;
lpf2 = 1.0./(1.0 + (f((f==0)) / 1.104e6).alpha); hpf2 = 1.0./(1.0 + (20e3 ./ f((f==0)) ).alpha);
PSDadsl_ds(f==0) = 0; PSDadsl_ds((f==0)) = Kadsl*2/f0 * ((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2).*lpf2.*hpf2;
% PSD of ADSL downstream interferer according to ANSI Standart T1.413 (ADSL) f0 = 2.208e6; Kadsl = 1000* 0.1104; % Correction factor of 1000 for DBm scaling
alphal = 11.96; lpf2 = 1.0./(1.0 + (f((f==0)) / 1.104e6).alphal); alphah = 7.09; hpf2 = (f((f==0)).alphah + 4e3alphah) ./ (f((f==0)).alphah + 25.875e3alphah);
PSDadsl_ds_ansi((f==0)) = Kadsl * (2/f0) .* ((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2 .* lpf2 .* h
% PSD of 1544 SHDSL interferer according to ITU G.991.2 (SHDSL) N = 1; % number of interferer R = 1544e3; % Bit Rate in bit/s Kshdsl = 8.32; Order = 6; fsym = (R+8)/3; % symbol/s f3db = 0.9*fsym/2; fint = 4.77e5; % Frequency of intersection, its approx value derived from plot PBO = 0; % Power Backoff in dB
MOB(f<f3db) = 1.0 + 0.4 * (f3db-f(f<f3db)) / f3db; % MaskOffsetB(f) MOB(f>f3db) = 1.0;
PSDshdsl_a((f==0)) = 1000*10(-PBO/10) * Kshdsl/135 / fsym * ((sin(pi*f((f==0))/(N*fsym))./(pi*f((f PSDshdsl_a(f>fint) = 1000*0.5683e-4 * (f(f>fint)).(-1.5); PSDshdsl_a(f>1.1e6) = 0;
% PSD of 2048 SHDSL interferer according to ITU G.991.2 (SHDSL) N = 1; % number of interferer R = 2048e3; % Bit Rate in bit/s Kshdsl = 7.86; Order = 6; fsym = (R+8)/3; % symbol/s f3db = 1.0*fsym/2; fint = 6.33e5; % Frequency of intersection, its approx value derived from plot PBO = 0; % Power Backoff in dB
MOB(f<f3db) = 1.0 + 0.4 * (f3db-f(f<f3db)) / f3db; % MaskOffsetB(f) MOB(f>f3db) = 1.0;
46
PSDshdsl_b((f==0)) = 1000*10(-PBO/10) * Kshdsl/135 / fsym * ((sin(pi*f((f==0))/(N*fsym))./(pi*f((f PSDshdsl_b(f>fint) = 1000*0.5683e-4 * (f(f>fint)).(-1.5); PSDshdsl_b(f>1.1e6) = 0;
% PSD of HDSL interferer according to ANSI T1.413 (ADSL) and ITU G.991.2 (SHDSL) and [Starr] f0 = 392e3; % kHz f3db = 196e3; % kHz Vp = 2.7; % V R = 135; % Ohm Khdsl = 1000*5*Vp*Vp/(9*R); alpha = 8; % Correction factor of 1000 for DBm scaling
PSDhdsl(f==0) = Khdsl*(2/f0);
PSDhdsl((f==0)) = Khdsl*(2/f0).*((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2)./(1+((f((f==0))/f3db).
% PSD of ISDN (DSL) interferer according to ANSI T1.413 (ADSL) and ITU G.991.2 (SHDSL) and [Starr] f0 = 80e3; % kHz Vp = 2.5; % V R = 135; % Ohm Kisdn = 1000*5*Vp*Vp/(9*R); % Correction factor of 1000 for DBm scaling alpha = 4;
PSDisdn(f==0) = Kisdn*(2.0/f0);
PSDisdn((f==0)) = Kisdn*(2.0/f0).*((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2)./(1+((f((f==0))/f0).
% PSD of T1 interferer according to ANSI T1.413 (ADSL) and ITU G.991.2 (SHDSL) f0 = 1.544e6; % kHz Vp = 3.6; % V R = 100; % Ohm Kt1 = 1000*2*Vp*Vp/(R*f0); % Correction factor of 1000 for DBm scaling
lpf2 = 1.0./(1.0 + (f((f==0))/3.0e6).6); hpf2 = 1.0./(1.0 + (40e3 ./ f((f==0)) ) );
alpha = 6;
PSDt1(f==0) = 0;
PSDt1((f==0)) = Kt1 * ((sin(pi*f((f==0))/f0)./(pi*f((f==0))/f0)).2).*(sin(pi*f((f==0))./(2*f0) ))
Fig_PSD1 = figure; semilogy(f, PSDadsl_us,-, f, PSDadsl_us_ansi,--, f, PSDadsl_ds,-., f, PSDadsl_ds_ansi,+); axis([0 fmax 1e-11 1e0]); title(Various PSDs of ADSL up- and downstream); xlabel(frequency);ylabel(PSD (dBm-scale));
legend(upstream according to [starr],upstream according to ANSI,downstream according to [starr],do
47
Fig_PSD2 = figure; semilogy(f, PSDshdsl_a,-, f, PSDshdsl_b,--, f, PSDhdsl,-., f, PSDisdn,+, f, PSDt1,:) axis([0 fmax 1e-11 1e0]); title(PSDs of various services except ADSL); xlabel(frequency);ylabel(PSD (dBm-scale)); legend(SHDSL 1536kbit/s,SHDSL 2048kbit/s,HDSL,ISDN,T1);
CALCULATING NEXT
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
N = 10; % number of NEXT interferer, for SHDSL this figure should be included in the calulation of the ps
PSDnext_adsl_us = NEXTcalculation(PSDadsl_us,f,N); PSDnext_adsl_us_ansi = NEXTcalculation(PSDadsl_us_ansi,f,N); PSDnext_adsl_ds = NEXTcalculation(PSDadsl_ds,f,N); PSDnext_adsl_ds_ansi = NEXTcalculation(PSDadsl_ds_ansi,f,N); PSDnext_shdsl_a = NEXTcalculation(PSDshdsl_a,f,N); PSDnext_shdsl_b = NEXTcalculation(PSDshdsl_b,f,N); PSDnext_hdsl = NEXTcalculation(PSDhdsl,f,N); PSDnext_isdn = NEXTcalculation(PSDisdn,f,N); PSDnext_t1 = NEXTcalculation(PSDt1,f,N);
Fig_NEXT1 = figure;
semilogy(f, PSDnext_adsl_us,-, f, PSDnext_adsl_us_ansi,--, f, PSDnext_adsl_ds,-., f, PSDnext_adsl_d axis([0 fmax 1e-15 1e-8]); title(NEXT from ADSL up- and downstream interferer (10)); xlabel(frequency);ylabel(PSD (dBm-scale));
Fig_NEXT2 = figure;
semilogy(f, PSDnext_shdsl_a,-, f, PSDnext_shdsl_b,--, f, PSDnext_hdsl,-., f, PSDnext_isdn,+, f, P axis([0 fmax 1e-15 1e-8]); title(NEXT from various services except ADSL, 10 interferer); xlabel(frequency);ylabel(PSD (dBm-scale)); legend(SHDSL 1536kbit/s,SHDSL 2048kbit/s,HDSL,ISDN,T1);
% some more NEXT PSDs for comparison to the plots in the ANSI Standards a = NEXTcalculation(PSDisdn,f,24); b = NEXTcalculation(PSDhdsl,f,10); c = NEXTcalculation(PSDt1,f,24); d = NEXTcalculation(PSDadsl_us_ansi,f,10); e = NEXTcalculation(PSDadsl_ds_ansi,f,10);
Fig_NEXT3 = figure; semilogy(f, a,-, f, b,--, f, c,-., f, d,+, f, e,:) axis([0 fmax 1e-15 1e-8]); title(Some NEXT PSDs for comparison with NEXT PSDs in the ANSI Standards);
48
xlabel(frequency);ylabel(PSD (dBm-scale));
legend(ISDN 24 dist,HDSL 10 dist,T1 24 dist,ADSL ANSI upstream 10dist,ADSL ANSI dowstream 10 dis
CALCULATING FEXT
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
N= 10; % number of FEXT interferer, for SHDSL this figure should be included in the calulation of the psd
PSDfext_adsl_us = FEXTcalculation(PSDadsl_us, linetype, linelength,f,N); PSDfext_adsl_us_ansi = FEXTcalculation(PSDadsl_us_ansi, linetype, linelength,f,N); PSDfext_adsl_ds = FEXTcalculation(PSDadsl_ds, linetype, linelength,f,N); PSDfext_adsl_ds_ansi = FEXTcalculation(PSDadsl_ds_ansi, linetype, linelength,f,N); PSDfext_shdsl_a = FEXTcalculation(PSDshdsl_a, linetype, linelength,f,N); PSDfext_shdsl_b = FEXTcalculation(PSDshdsl_b, linetype, linelength,f,N);
PSDfext_hdsl = FEXTcalculation(PSDhdsl, linetype, linelength,f,N); PSDfext_isdn = FEXTcalculation(PSDisdn, linetype, linelength,f,N); PSDfext_t1 = FEXTcalculation(PSDt1, linetype, linelength,f,N);
Fig_FEXT1 = figure;
semilogy(f, PSDfext_adsl_us,-, f, PSDfext_adsl_us_ansi,--, f, PSDfext_adsl_ds,-., f, PSDfext_adsl_d axis([0 fmax 1e-30 1e-20]); title(FEXT from ADSL up- and downstream interferer (10)); xlabel(frequency);ylabel(PSD (dBm-scale));
Fig_FEXT2 = figure;
semilogy(f, PSDfext_shdsl_a,-, f, PSDfext_shdsl_b,--, f, PSDfext_hdsl,-., f, PSDfext_isdn,+, f, P axis([0 fmax 1e-30 1e-20]); title(FEXT from various services except ADSL, 10 interferer); xlabel(frequency);ylabel(PSD (dBm-scale)); legend(SHDSL 1536kbit/s,SHDSL 2048kbit/s,HDSL,ISDN,T1);
return
function[PSDnext] = NEXTcalculation(psd,f,N) % Calculates NEXT PSD from interferer PSD and Frequency % N is the number of interferer % remark: For calculating NEXT ANSI Standard uses the constant 8.818e-14 compared to 1e-13 in [starr]
PSDnext = psd .* ((N/49)0.6).*1e-13.*(f.1.5);
return
49
function[PSDfext] = FEXTcalculation(psd, linetype, linelength,f,N) % Calculates FEXT PSD from interferer PSD, and Frequency % N is the number of interferer % linetype and linelength to be used in transfer subfunction(mexsol) % remark: For calculating FEXT ANSI Standard uses the constant 8e-20 compared to 9e-20 in [starr]
PSDfext = psd .* transfer_fnmex(linetype,linelength,f).2 .* ((10/49)0.6) .*9e-20 .* linelength.*f.*f;
return
Appendix B SHDSL transceiver simulation in Matlab

Main le
function shdsl() % determine data rate
global n; n = 3; global i; i = 0;
% 3 <= n <= 36
% 0 <= i <= 7 and i = 0 or 1 for n = 36
Ruser = 64 * n + 8 * i; % user data rate in kbit/sec global totalFrames; totalFrames = 2; global Ks; Ks = i + 8 * n; % size of one subblock in bit global K; K = 12 * Ks; % size of one payloadblock in bit
global framelength; framelength = 4 * K + 48; % = 1200 for i=0 and n=3 TotalBitNumber = framelength * totalFrames
rand(state,sum(100 * clock)); % generate random data XTdata = uint8(fix(2*rand(1, totalFrames * 4 * K)));
XTFrames = framer(XTdata); % generate dataframes XTSFrames = scrambler(XTFrames); % generate scrambled data XTSymbols = TCM_encoder(XTSFrames); % generate symbols
XRSymbols = XTSymbols; % impairment generator can be inserted here
XRSFrames = TCM_decoder(XRSymbols); XRFrames = descrambler(XRSFrames); [XRdata, FrameError] = deframer(XRFrames);
Biterrorsum = sum(sum(xor(XTdata,XRdata))) FrameError return
50
APPENDIX B. SHDSL TRANSCEIVER SIMULATION IN MATLAB
51
framer.m
function[Frames] = framer(Data) % packing data into frames according to the SHDSL frame specification % returns a matrix with each column representing one frame
global K; % payload block (PLB) size global totalFrames;
fsync = uint8(ones(1,14)); % 14 frame synchronization bits eoc = uint8(zeros(1,20)); % 20 bits for disabled embeded operations channel fbit = uint8(ones(1,4)); % 4 fixed indicator bits (= 1 for normal operation) sbid = uint8(zeros(1,2)); % 2 stuff indicator bits (= 0 for synchronous mode operation) stb = uint8(zeros(1,2)); % stuffing bits. only two in synchronous mode
% packing "Data" into a matrix of which every column is containing % data of one payloadblock ("buffer" does not work with uint8 datatype) framepayload = uint8([]); for i= 1:4*totalFrames framepayload(:,i) = Data((i-1)*K+1:i*K); end
for l = 0:totalFrames-1
for i = 1:4 % create matrix containing payload of current frame PLB(:,i) = framepayload(:,4*l + i); end % create message including payload and specified bits for cyclic redundancy check % messagebits is a row-vector messagebits = [fbit(1:2) PLB(:,1) eoc(1:4) fbit(3) sbid(1) eoc(5:6) PLB(:,2) eoc(7:10)]; messagebits = [messagebits fbit(4) eoc(11:12) sbid(2) PLB(:,3) eoc(13:20) PLB(:,4)]; CRCbit = crc2(messagebits);
% create frame according to shdsl frame specifications this_frame = [fsync fbit(1:2) PLB(:,1) eoc(1:4) CRCbit(1:2) fbit(3) sbid(1) eoc(5:6)]; this_frame = [this_frame PLB(:,2) eoc(7:10) CRCbit(3:4) fbit(4) eoc(11:12) sbid(2)]; this_frame = [this_frame PLB(:,3) eoc(13:16) CRCbit(5:6) eoc(17:20) PLB(:,4) stb(1:2)];
Frames(:,l+1) = this_frame; % appends a column vector for each frame end
return
52
deframer.m
function[XRdata, Frame_Error] = deframer(Frames) % unpacks shdsl specified frames into a data vector % calculates and compares crc sum, counts number of impaired frames % expects a matrix with with each column representing one frame
global K; global totalFrames;
% Initialise XRdata = uint8([]); Frame_Error = 0;
for i = 1:totalFrames
this_frame = Frames(:,i);
% extract (old) crc bits crc_bits = [this_frame(K+21:K+22) this_frame(2*K+31:2*K+32) this_frame(3*K+41:3*K+42)];
% extract payload, return data PLB1 = this_frame(17:K+16); PLB2 = this_frame(K+27:2*K+26); PLB3 = this_frame(2*K+37:3*K+36); PLB4 = this_frame(3*K+47:4*K+46); XRdata = [XRdata PLB1 PLB2 PLB3 PLB4];
% extract overhead bits needed for crc eoc = [this_frame(K+17:K+20) this_frame(K+25:K+26) this_frame(2*K+27:2*K+30)]; eoc = [eoc this_frame(2*K+34:2*K+35) this_frame(3*K+37:3*K+40) this_frame(3*K+43:3*K+46)]; fbit = [this_frame(15:16) this_frame(K+23) this_frame(2*K+33)]; sbid = [this_frame(K+24) this_frame(2*K+36)];
% recalculate crc bits messagebits = [fbit(1:2) PLB1 eoc(1:4) fbit(3) sbid(1) eoc(5:6) PLB2 eoc(7:10)]; messagebits = [messagebits fbit(4) eoc(11:12) sbid(2) PLB3 eoc(13:20) PLB4]; crc_bits_new = crc2(messagebits);
if isequal(crc_bits, crc_bits_new) Frame_Error = Frame_Error + 1; end end
return
53
crc.m
function [crc_bits] = crc2(message) % Calculates the Cyclyc Redundancy Check Bits of a binary message (n-column-vector) % this function implements the polynomial binary division % message must have a length of at least 5 bit
poly = [1 0 0 0 0 1 1]; Lp= length(poly);
message = [message zeros(1,Lp-1)]; Lm = length(message);
current = message(1:Lp);
for i = Lp+1:Lm if current(1) == 1 current = xor(current,poly); current = [current(2:Lp) message(i)]; else current = [current(2:Lp) message(i)]; end
end
if current(1) == 1 current = xor(current,poly); end
crc_bits = current(2:Lp);
return
scrambler.m
function[Sframes] = scrambler(TXframes) % scrambels data according to the shdsl specification % scrambling function is y[n] = x[n]+y[n-5]+y[n-23] % expects a matrix with with each column representing one frame
global totalFrames; global framelength; SCframelength = framelength-16; % relevant frame length without sync and stuff bits
54
Sframes = uint8([]); bitstream = uint8([]); fsync = uint8([]); stbit = uint8([]);
for i = 1:totalFrames fsync = [fsync TXframes(1:14,i)]; % sync and stuff bits shall not be scrambled bitstream = [bitstream TXframes(15:framelength-2,i)]; % one-row vector stbit = [stbit TXframes(framelength-1:framelength,i)]; end
for i = 1:5 Sbitstream(i) = bitstream(i); end for i = 6:23 Sbitstream(i) = xor(bitstream(i), Sbitstream(i-5)); end % main scrambling for i=24:length(bitstream) Sbitstream(i) = xor(xor(bitstream(i), Sbitstream(i-5)), Sbitstream(i-23)); end
% repack into framestructure
for i=0:totalFrames-1 column = [fsync(:,i+1); Sbitstream(i*SCframelength+1:(i+1)*SCframelength); stbit(:,i+1)]; Sframes = [Sframes column]; end
return
descrambler.m
function[DSframes] = descrambler(RXframes) % descrambels data according to the shdsl specification % descrambling function is y[n] = x[n]-x[n-5]-x[n-23] % expects a matrix with with each column representing one frame
global totalFrames; global framelength; SCframelength = framelength - 16; % relevant frame length without sync and stuff bits
DSframes = uint8([]); bitstream = uint8([]); fsync = uint8([]);
55
stbit = uint8([]);
for i = 1:totalFrames fsync = [fsync RXframes(1:14,i)]; % synchronization and stuff bits must not be descrambled bitstream = [bitstream RXframes(15:framelength-2,i)]; % one-row vector stbit = [stbit RXframes(framelength-1:framelength,i)]; end
for i = 1:totalFrames bitstream = [bitstream RXframes(:,i)]; end for i = 1:5 DSbitstream(i) = bitstream(i); end for i = 6:23 DSbitstream(i) = xor(bitstream(i), bitstream(i-5)); end
t1 = clock; t1 = t1(6); % main descrambling: THIS NEEDS TIME !! for i=24:length(bitstream) DSbitstream(i) = xor(xor(bitstream(i), bitstream(i-5)), bitstream(i-23)); end
t2 = clock; t2 = t2(6); core_descrambling = t2 - t1
% repack into framestructure for i=0:totalFrames-1 column = [fsync(:,i+1); DSbitstream(i*SCframelength+1:(i+1)*SCframelength); stbit(:,i+1)]; DSframes = [DSframes,column]; end
return
TCM encoder.m
function[symbols] = TCM_encoder(frames) % encodes frames according to shdsl specification % is mapping 3 bits to one symbol % expects a matrix with each column representing one frame % returns a data vector (one element = one symbol)
global totalFrames; global framelength;
56
% concatenating frames to one continuous bitvector bitstream = uint8([]); for i = 1:totalFrames bitstream = [bitstream frames(:,i)]; end
% append zeros to bitstream to reach length of a multiple of 3 if rem(totalFrames*framelength,3) bitstream = [bitstream uint8(zeros(1,3-rem(totalFrames*framelength,3)))]; end
% packing bits into 3-row vector for further processing X = uint8([]); for i= 1:length(bitstream)/3 X(:,i) = bitstream(3*i-2:3*i); end
X1 = X(1,:); % extract X1 line for TC feeding Y0Y1 = TC(X1); % call trellis coder Y = [Y0Y1; X(2,:); X(3,:)]; % composing 4 bit broad matrix to feed mapper symbols = []; for i = 1:length(Y) symbols = [symbols mapper(Y(:,i))]; end
return
function[Y0Y1bits] = TC(X1bits) % trellis coder according to shdsl specification % returns 2-row matrix (Y0 and Y1) % each row of the matrix coresponds to one bit step % expects a row-vector
Y0Y1bits = []; for i = 1:length(X1bits) Y0 = X1bits(i); Y1 = X1bits(i); Y0Y1bits = [Y0Y1bits [Y0; Y1]]; end
return
57
function[symbol] = mapper(quad) % mapper according to the shdsl specification % mapps 4 input bits (binary vector) to one PAM symbol
quad = double(quad); symbol = 0;
for i = 1:4 % maps the "quad" to a number between 0 and 15 symbol = bitset(symbol,i,quad(i)); end
symbol = (2*(symbol+1)-17)/16; % final tranformation to PAM levels
return
TCM decoder.m
function[frames] = TCM_decoder(symbols)
% inverses process of TCM_encoder % is mapping one symbol to 3 bits % expects a data vector (one element = one symbol) % returns a matrix with each column representing one frame
global totalFrames; global framelength;
Y = uint8([]); for i = 1:length(symbols) Y(:,i) = unmapper(symbols(i)); end
X1 = TC_reverse(Y(1:2,:)); X = [X1; Y(3:4,:)];
bitstream = []; for i=1:length(X) bitstream = [bitstream X(:,i)]; end
if rem(totalFrames*framelength,3) bitstream = bitstream(1:end-(3-rem(totalFrames*framelength,3))); end
% pack bitstream into frames
58
frames = uint8([]); for i= 1:totalFrames frames(:,i) = bitstream((i-1)*framelength+1:i*framelength); end
return
function[X1bits] = TC_reverse(Y0Y1bits) % trellis decoder % returns a row vector % expects a 2-row matrix (Y0 and Y1)
X1bits = []; for i = 1:length(Y0Y1bits) X1 = Y0Y1bits(1,i); % here comes the real trellis decoder X1bits = [X1bits X1]; end
return
function[quad] = unmapper(symbol) % reverses process of mapper % mapps one symbol to 4 bits (binary vector)
% transforms PAM level to a number between 0 and 15 symbol = uint8((16*symbol+17)/2 -1);
quad = uint8([]); for i = 1:4 % transforms byte to a binary vector quad(i) = bitget(symbol,i); end
return
Appendix C SHDSL transceiver simulation in C++

Main le
#include <iostream.h> #include <math.h> #include <stdlib.h> #include <time.h>
#include "BitStream.h" #include "Framer.h" #include "Deframer.h" #include "Scrambler.h" #include "Descrambler.h" #include "TCM_encoder.h" #include "TCM_decoder.h" #include "Viterbi.h" #include "ImpairGen.h"
int main() {
cout << "Enter symbol error probability: " << float Pe; while (Pe < 0 || Pe >= 1) { cout << endl << "cmon: "; cin >> Pe; }
endl;
cout << "Enable Trellis en-/decoder ?" << char enableTrellis;
endl;
while (enableTrellis != y && enableTrellis != n) { cout << endl << "(y/n) "; cin >> enableTrellis; }
// notations for n, i, Ks, and K correspond to the ones used in the shdsl draft // values for n, i and totalFrames to be changed for testing const int n = 3; // 3 <= n <= 36
59
APPENDIX C. SHDSL TRANSCEIVER SIMULATION IN C++
60
const int i = 0; // 0 <= i <= 7 but restricted to 0 or 1 for n = 36 const int Ks = i + 8 * n; // size of one subblock in bit const int K = 12 * Ks; // size of one payloadblock(PLB) in bit
const int totalFrames = 20; const int dataBitLength = 4 * K * totalFrames; const int framelength = 4 * K + 48;
// create random data bitstream (to be sent to framer) BitStream XTStream(dataBitLength); XTStream.Randomize(77);
// initialise other bitstreams used within the programme BitStream XTFrames(totalFrames * framelength); // after framer BitStream XTScrambled(totalFrames * framelength); // after scrambler
BitStream XRScrambled(totalFrames * framelength); // after decoder BitStream XRFrames(totalFrames * framelength); // after descramber BitStream XRStream(dataBitLength); // after deframer
Framer(XTFrames, XTStream, totalFrames, framelength, K); // call subfunction Framer
Scrambler(XTScrambled, XTFrames, totalFrames, framelength); // call subf. Scrambler
// extend bitstream to a multiple of 3 (for TCM encoder) int Dlength = 3 - (XTScrambled.NumItems() % 3); // extend by Delta-length if (Dlength == 3) Dlength = 0; XTScrambled.Extend(Dlength); XRScrambled.Extend(Dlength);
int numOfSymb = XTFrames.NumItems() / 3; // determine the number of symbols
// initialise array symbols float *Symbols = new float[numOfSymb];
// call subf. TCM_encoder TCM_encoder(Symbols, XTScrambled, numOfSymb, enableTrellis);
// call impairment generator int numSymbolError = ImpairGen(Symbols, numOfSymb, Pe);
// call subf. TCM_decoder TCM_decoder(XRScrambled, Symbols, numOfSymb, enableTrellis);
// call subf. Descrambler Descrambler(XRFrames, XRScrambled, totalFrames, framelength);
61
// call subf. Deframer int FrameErrors = Deframer(XRStream, XRFrames, totalFrames, framelength, K);
int DataBitErrors = XRStream.Compare(XTStream); int BitErrors = XRScrambled.Compare(XTScrambled); cout << endl << numOfSymb << " symbols have been conveyed." << endl << numSymbolError << " symbols were destroyed." << endl << dataBitLength << " bits of user data have been transmitted." << endl << DataBitErrors << " of above data bits have changed during" << " transmission (including all stages)." << endl << XTScrambled.NumItems() << " bits have been transmitted (total)." << endl << BitErrors << " of above bits have changed comparing BitStreams" << " before TCM_encoder with after TCM_decoder." << endl << FrameErrors << " of " << totalFrames << " frames error-detected by CRC." << endl;
Class BitStream.h
#ifndef _BitStream_h_ #define _BitStream_h_
#include <iostream.h>
class BitStream { // consists of a boolean array and a number of member functions // allowing various kinds of manipulation of the elements of the array // see BitStream.C file for explanation of member functions
public: BitStream(int Size = 100); BitStream() { delete[] TheStream; }
void Randomize(int d); void ClearBit(int i); void ClearBits(int from, int to); void SetBit(int i); void SetBits(int from, int to); void DestroyBit(int i); void DestroyBits(int from, int to); bool GetBit(int i) const; void Xor(const BitStream & BS); void Xor(const BitStream & BS, int BSfrom, int BSto, int from, int to); int Compare(const BitStream &BS) const;
62
void Extend(int size); void Cut(int from, int to); void WriteBit(int location, bool bit); void WriteBits(const BitStream &BS, int BSstart, int BSend, int location); int CountBits() const; void ShowBits() const; int NumItems() const {return N;}
private: bool *TheStream; // The bit stream int N; // Number of Elements bool IsInRange(int i) const; // Check range };
#endif
BitStream.C
#include <iostream.h> #include <stdlib.h> #include <time.h> #include "BitStream.h"
BitStream::BitStream(int Size){ // Constructor: // intialises and sets all bits to zero TheStream = new bool[Size]; N = Size; ClearBits(0, N - 1); }
void BitStream::Randomize(int d){ // sets all bits randomly to zero or one srand48(time(NULL)); for (int i = 0; i <= N-1; i++) { if (drand48() < .5) TheStream[i] = 1; else TheStream[i] = 0; } }
void BitStream::ClearBit(int i){ // sets bit i to zero if(IsInRange(i))
63
TheStream[i] = 0; }
void BitStream::ClearBits(int from, int to){ // sets all bits between from and to to zero if (IsInRange(from) && IsInRange(to)) for (int i = from; i <= to; i++) TheStream[i] = 0; }
void BitStream::SetBit(int i){ // sets bit i to one if (IsInRange(i)) TheStream[i] = 1; }
void BitStream::SetBits(int from, int to){ // sets all bits between from and to to one if (IsInRange(from) && IsInRange(to)) for (int i = from; i <= to; i++) TheStream[i] = 1; }
void BitStream::DestroyBit(int i){ // sets bit i to zero if one or to one if zero if (IsInRange(i)) { if (TheStream[i]) { TheStream[i] = 0; return; } else TheStream[i] = 1; } }
void BitStream::DestroyBits(int from, int to){ // performs DestroyBit function to all bits from "from" to "to" if (IsInRange(from) && IsInRange(to)) for (int i = from; i <= to; i++) DestroyBit(i); }
bool BitStream::GetBit(int i) const{ // returns bit i as boolean value if (IsInRange(i)) return TheStream[i]; }
64
int BitStream::Compare(const BitStream &BA) const{ // compares the bits of two BitStreams of the same length // counts and returns the number of different bits // returns -1 if the Bitstreams are not equal in length int k = 0; if (BA.N == N) { for (int i = 0; i <= N-1; i++) if (BA.TheStream[i] != TheStream[i]) k ++; return k; } else { cerr << "Error Compare: BitStreams must be of the same length!" << endl; return -1; } }
void BitStream::Extend(int size){ // extends the BitStream by size bits // the appended bits are set to zero bool *TheStreamOld = TheStream; int NewSize = N + size; TheStream = new bool[NewSize]; for (int i = 0; i <= N - 1; i++) TheStream[i] = TheStreamOld[i]; for (int i = N; i <= NewSize-1; i++) TheStream[i] = 0; N = NewSize; delete [] TheStreamOld; }
void BitStream::Cut(int from, int to) { // randers BitStrea to one, consisting of only // the bits between from and to // expunges bits below from and above to bool *TheStreamOld = TheStream; int NewSize = to - from + 1; TheStream = new bool[NewSize]; for (int i = 0; i <= NewSize - 1; i++) TheStream[i] = TheStreamOld[from + i]; N = NewSize; delete [] TheStreamOld; }
void BitStream::Xor(const BitStream & BS) { // applies xor operation to the related Bitstream using Bitstream BS // which is sent as argument. both must be of the same length if (BS.N == N) {
65
for (int i = 0; i <= N - 1; i++) { if (TheStream[i] && !BS.TheStream[i] || !TheStream[i] && BS.TheStream[i]) SetBit(i); else ClearBit(i); } } else cerr << "Error: BitStreams must have same size for Xor." << endl; }
void BitStream::Xor(const BitStream & BS, int BSfrom, int BSto, int from, int to) { // applies xor operation on the Bitstream between from and to using the // bits of the Bitstream in the arguments between BSfrom and BSto
if ((BSto - BSfrom == to - from) && IsInRange(from) && IsInRange(to) && BS.IsInRange(from) && BS.IsInRa int length = to - from; for (int i = 0; i <= length; i++) {
if (TheStream[from + i] && !BS.TheStream[BSfrom + i] || !TheStream[from + i] && BS.TheStream[BSfrom SetBit(from + i); else ClearBit(from +i); } } else cerr << "Error XorBits." << endl; }
void BitStream::WriteBits(const BitStream &BS, int BSstart, int BSend, int location){ // takes bits from start to end of BitStream BS // and copies them into the related BitStream starting at location int lengthBS = BSend - BSstart + 1; if ((location + lengthBS <= N) && BS.IsInRange(BSstart) && BS.IsInRange(BSend)) { for (int i = location; i <= location + lengthBS - 1; i++) WriteBit(i, BS.GetBit(i - location + BSstart)); } else cerr << "Error: Exceeding Matrix sice. No bits have been written." << endl; }
void BitStream::WriteBit(int location, bool bit) { // writes boolean value "bit" into BitStream at "location" if (IsInRange(location)){ if (bit) TheStream[location] = 1; else TheStream[location] = 0; } }
66
int BitStream::CountBits() const{ // counts all bits set to 1 and returns value int k = 0; for (int i = 0; i <= N-1; i++) if (TheStream[i]) k++; return k; }
void BitStream::ShowBits() const{ // displays all bits cout << endl; for (int i = 0; i <= N-1; i++) { cout << TheStream[i] << " "; if (((i+1) % 40) == 0) cout << endl; } cout << endl; cout << "Number of elements: " << N << endl; cout << "Number of active bits: " << CountBits() << endl; }
bool BitStream::IsInRange(int i) const{ // check if i is in range of BitStream // returns 1 (true) if in range, otherwise 0 (false) if (i < 0 || i >= N) { cerr << "Bit " << i << " exceeds size " << endl; return 0; } return 1; }
Framer.h
#ifndef _Framer_h_ #define _Framer_h_
#include <iostream.h> #include "CRC.h"
void Framer(BitStream & Frames, BitStream & Stream, int totalFrames, int framelength, int K) { // packs data into frames according to the shdsl specification // stream of type BitStream is processed into a larger array of the same type returned // in Frames. both arguments are passed by reference
67
int messagelength = 4 * K + 26; // message length for crc
for (int i = 0; i <= totalFrames - 1; i++) {
BitStream Message(messagelength); // create message for crc
int pos = i * 4 * K; // position in the input (data-) stream int pos2 = i * framelength; // position in the output (frame-) stream
// a message consisting of the bits to be processed by the crc has to be // created for each frame Message.SetBits(0,1); // set fixed indicator bits (fbit) to one Message.WriteBits(Stream, pos + 0, pos + K - 1, 2); // first Payloadblock (PLB) Message.ClearBits(K + 2, K + 5); // eoc bits (disabled embeded oper. chanel) Message.SetBit(K + 6); // more fbit Message.ClearBits(K + 7, K + 9); // sbid (stuff indicator bits) and eoc bits Message.WriteBits(Stream, pos + K, pos + 2 * K - 1, K + 10); // PLB 2 Message.ClearBits(2 * K + 10, 2 * K + 13); // eoc bits Message.SetBit(2 * K + 14); // fbit Message.ClearBits(2 * K + 15, 2 * K + 17); // eoc bits and sbid Message.WriteBits(Stream, pos + 2 * K, pos + 3 * K - 1, 2 * K + 18); // PLB 3 Message.ClearBits(3 * K + 18, 3 * K + 25); // eoc bits Message.WriteBits(Stream, pos + 3 * K, pos + 4 * K - 1, 3 * K + 26); // PlB 4
BitStream CRC_bits = CRC(Message); // calculate crc bits
// now all the bits of the frame can be stored in BitStream Frames // since the structure of the message is similar to the one of the // corresponding frame, parts of Message can be copied into Frames Frames.SetBits(pos2, pos2 + 13); // 14 frame synchronization bits Frames.WriteBits(Message, 0, K + 5, pos2 + 14); Frames.WriteBits(CRC_bits, 0, 1, pos2 + K + 20); // insert 2 crc bits Frames.WriteBits(Message, K + 6, 2 * K + 13, pos2 + K + 22); Frames.WriteBits(CRC_bits, 2, 3, pos2 + 2 * K + 30); // insert 2 crc bits Frames.WriteBits(Message, 2 * K + 14, 3 * K + 21, pos2 + 2 * K + 32); Frames.WriteBits(CRC_bits, 4, 5, pos2 + 3 * K + 40); // insert 2 crc bits Frames.WriteBits(Message, 3 * K + 22, 4 * K + 25, pos2 + 3 * K + 42); Frames.ClearBits(pos2 + 4 * K + 46, pos2 + 4 * K + 47); // stuffing bits }
#endif
68
Deframer.h
#ifndef _Deframer_h_ #define _Deframer_h_
#include <iostream.h> #include "CRC.h"
int Deframer(BitStream & Stream, BitStream & Frames, int totalFrames, int framelength, int K) { // unpacks Frames and returns data as Stream (both of which are of type // BitStream and are passed by reference. // returns result of crc as number of detected frame errors
int messagelength = 4 * K + 26; // message length for crc int Frame_Error = 0;
for (int i = 0; i <= totalFrames - 1; i++) {
BitStream CRC_bits(6); // for storing extracted crc bits BitStream CRC_bits2(6); // for newly calculated crc bits
BitStream Message(messagelength); // create message for crc
int pos = i * 4 * K; // position in the output (data-) stream int pos2 = i * framelength; // position in the input (frame-) stream
// extract crc bits CRC_bits.WriteBits(Frames, pos2 + K + 20, pos2 + K + 21, 0); CRC_bits.WriteBits(Frames, pos2 + 2 * K + 30, pos2 + 2 * K + 31, 2); CRC_bits.WriteBits(Frames, pos2 + 3 * K + 40, pos2 + 3 * K + 41, 4);
// extract data bits Stream.WriteBits(Frames, pos2 + 16, pos2 + K + 15, pos); Stream.WriteBits(Frames, pos2 + K + 26, pos2 + 2 * K + 25, pos + K); Stream.WriteBits(Frames, pos2 + 2 * K + 36, pos2 + 3 * K + 35, pos + 2 * K); Stream.WriteBits(Frames, pos2 + 3 * K + 46, pos2 + 4 * K + 45, pos + 3 * K);
// create message for crc Message.WriteBits(Frames, pos2 + 14, pos2 + K + 19, 0); Message.WriteBits(Frames, pos2 + K + 22, pos2 + 2 * K + 29, K + 6); Message.WriteBits(Frames, pos2 + 2 * K + 32, pos2 + 3 * K + 39, 2 * K + 14); Message.WriteBits(Frames, pos2 + 3 * K + 42, pos2 + 4 * K + 45, 3 * K + 22);
CRC_bits2 = CRC(Message); // calculate crc bits
// a frame error occurs if one or more crc bits is/are corrupted if (CRC_bits.Compare(CRC_bits2) != 0) Frame_Error++;
69
} return Frame_Error; }
#endif
CRC.h
#ifndef _CRC_h_ #define _CRC_h_
BitStream CRC(BitStream & Message) {
// create generator polynomial (1 0 0 0 1 1) BitStream Poly(7); Poly.SetBit(0); Poly.SetBits(5,6); int Lp = 7;
// multiply (binary) message by the order of the polynomial Message.Extend(Lp - 1); int Lm = Message.NumItems();
// algorithm, implementing the division BitStream Current(7); Current.WriteBits(Message, 0, 6, 0);
for (int i = Lp; i <= Lm - 1; i++) { if (Current.GetBit(0)) { // if there is a bit at the input Current.Xor(Poly); // make the division Current.Cut(1, 6); // This 3 lines only shift the bits and Current.Extend(1); // take the next one from the input Current.WriteBit(6, Message.GetBit(i)); } else { Current.Cut(1, 6); // same as above 3 last lines Current.Extend(1); Current.WriteBit(6, Message.GetBit(i)); } } if (Current.GetBit(0)) Current.Xor(Poly); Current.Cut(1, 6);
70
return Current; }
#endif
Scrambler.h
#ifndef _Scrambler_h_ #define _Scrambler_h_
#include <iostream.h> #include "Xor.h"
bool Xor(bool a, bool b); // function declaration
void Scrambler (BitStream & Scrambled, BitStream & Frames, int totalFrames, int framelength) { // scrambles data according to the shdsl draft // processes input BitStream (Frames) into output BitStream (Scrambled)
// length without sync & stuff bits int Slength = framelength - 16;
BitStream Temp1(totalFrames * Slength); // initialising BitStreams BitStream Temp2(totalFrames * Slength);
// extract bits to be scrambled from BitStream Frames into temporary // BitStream (Temp1) for (int i = 0; i <= totalFrames - 1; i++) {
int pos = i * framelength; // position in the input (frame-) stream int pos2 = i * Slength; // position in the output (scrambled-) stream
Temp1.WriteBits(Frames, pos + 14, pos + framelength - 3, pos2); }
// scrambler according to function y[n]=x[n]+y[n-5]+y[n-23] // (binary xor - addition) Temp2.WriteBits(Temp1, 0, 4, 0); // first 5 bits are just copies for (int i = 5; i <= 22; i ++) Temp2.WriteBit(i, Xor(Temp1.GetBit(i),Temp2.GetBit(i-5))); for (int i = 23; i <= Temp2.NumItems() - 1; i++) Temp2.WriteBit(i, Xor(Xor(Temp2.GetBit(i-5), Temp2.GetBit(i-23)), Temp1.GetBit(i)));
// reassemble frame (adding fsync and stuff bits)
71
for (int i = 0; i <= totalFrames - 1; i++) { int pos = i * framelength; int pos2 = i * Slength;
Scrambled.SetBits(pos, pos + 13); // reset sync bits Scrambled.WriteBits(Temp2, pos2, pos2 + Slength - 1, pos + 14); // reset stuff bits: Scrambled.ClearBits(pos + framelength - 2, pos + framelength - 1); } }
#endif
Descrambler.h
#ifndef _Descrambler_h_ #define _Descrambler_h_
#include <iostream.h> #include "Xor.h"
bool Xor(bool a, bool b); // function declaration
void Descrambler(BitStream & Frames, BitStream & Scrambled, int totalFrames, int framelength) { // processes input BitStream (Scrambled) into output BitStream (Frames)
int Slength = framelength - 16; // shortenend length (no sync & stuff bits)
BitStream Temp1(totalFrames * Slength); BitStream Temp2(totalFrames * Slength);
// extract bits to be descrambled from BitStream Scrambled into temporary // BitStream (Temp1) for (int i = 0; i <= totalFrames - 1; i++) {
int pos = i * framelength; // position in the output (frame-) stream int pos2 = i * Slength; // position in the input (scrambled-) stream
Temp1.WriteBits(Scrambled, pos + 14, pos + framelength - 3, pos2); }
// scrambler according to function y[n]=x[n]-x[n-5]-x[n-23] // (binary xor - addition) Temp2.WriteBits(Temp1, 0, 4, 0); // first 5 bits are just copies for (int i = 5; i <= 22; i ++)
72
Temp2.WriteBit(i, Xor(Temp1.GetBit(i),Temp1.GetBit(i-5))); for (int i = 23; i <= Temp2.NumItems() - 1; i++) Temp2.WriteBit(i, Xor(Xor(Temp1.GetBit(i-5), Temp1.GetBit(i-23)), Temp1.GetBit(i)));
// reassemble frame (adding fsync and stuff bits) for (int i = 0; i <= totalFrames - 1; i++) { int pos = i * framelength; int pos2 = i * Slength;
Frames.SetBits(pos, pos + 13); // reset sync bits Frames.WriteBits(Temp2, pos2, pos2 + Slength - 1, pos + 14); // reset stuff bits Frames.ClearBits(pos + framelength - 2, pos + framelength - 1); }
#endif
Xor.h
#ifndef _Xor_h_ #define _Xor_h_
bool Xor(bool a, bool b) { // help function for scrambler // returns logical xor result of a and b if ((a && !b) || (!a && b)) return 1; else return 0; }
#endif
TCM encoder.h
#ifndef _TCM_encoder_h_ #define _TCM_encoder_h_
73
#include "Mapper.h" #include "Mapper2.h" #include "TC.h"
void TCM_encoder(float *Symbols, BitStream & Scrambled, int numOfSymb, char enableTrellis) { // encoder according to the shdsl draft consisting of // * a serial to parallel converter // * a convolutional ecoder // * a PAM mapper // processes input BitStream (Scrambled) into output array (symbols) // Scrambled must hold of 3 times as many elements (bits) as numOfSymb
// * serial to parallel converter // initialising temporary BitStreams BitStream X1(numOfSymb); BitStream X2(numOfSymb); BitStream X3(numOfSymb);
BitStream Y0(numOfSymb); BitStream Y1(numOfSymb);
// write 3 bits from BitStream Scrambled (serial) // into each of the 3 (parallel) BitStreams for (int i = 0; i <= numOfSymb - 1; i++) { X1.WriteBit(i, Scrambled.GetBit(3 * i)); X2.WriteBit(i, Scrambled.GetBit(3 * i + 1)); X3.WriteBit(i, Scrambled.GetBit(3 * i + 2)); }
// * call convolutional encoder TC(Y0, Y1, X1, numOfSymb, enableTrellis);
// * call PAM mapper once per 4 bits (= 1 symbol) for (int i = 0; i <= numOfSymb - 1; i++) { // extract the 4 bits and store them in temporary array bool *Y = new bool[4]; Y[0] = Y0.GetBit(i); Y[1] = Y1.GetBit(i); Y[2] = X2.GetBit(i); Y[3] = X3.GetBit(i); Symbols[i] = Mapper2(Y); // call subfunction } }
#endif
74
TC.h
#ifndef _TC_h_ #define _TC_h_
#include "Xor.h"
void TC(BitStream & Y0, BitStream & Y1, BitStream & X1, int length, char enableTrellis) { // trellis half-rate encoder (optional) // Y0[n] = X1[n] + X1[n-2] // Y1[n] = X1[n-1] + X1[n-2]
if (enableTrellis == n) { // if no encoder employed there is only bit copying i.e. // for (int i = 0; i <= length - 1; i++) { if ((i % 2) == 0) Y0.WriteBit(i, X1.GetBit(i)); else Y1.WriteBit(i, X1.GetBit(i)); } } else { // execute trellis encoder
// initialise first two values (for both Y0, Y1) Y0.WriteBit(0, X1.GetBit(0)); Y0.WriteBit(1, X1.GetBit(1)); Y1.WriteBit(0, X1.GetBit(0)); Y1.WriteBit(1, Xor(X1.GetBit(0), X1.GetBit(1)));
// encoding cycles for (int i = 2; i <= length - 1; i++) { Y0.WriteBit(i, Xor(X1.GetBit(i), X1.GetBit(i-2))); Y1.WriteBit(i, Xor(X1.GetBit(i), X1.GetBit(i-1))); } } }
#endif
75
Mapper.h
#ifndef _Mapper_h_ #define _Mapper_h_
float Mapper(bool *Y) { // mapper according to the shdsl specification // mapps 4 input bits to one PAM symbol // argument is a pointer to a boolean array of 4 elements
// first: mapping to a number between 0 and 15 int value = 0; for (int i = 0; i <= 3; i++) if (Y[i]) value |= 1 << i; // bitshift (only for type int possible)
// final transformation to PAM levels float Symbol = (2 * (float(value) + 1) - 17) / 16; return Symbol; }
#endif
Mapper2.h
#ifndef _Mapper2_h_ #define _Mapper2_h_
float Mapper2(bool *Y) { // self-made mapper for improved error-correction capability // mapps 4 input bits to one PAM symbol // argument is a pointer to a boolean array of 4 elements
// first: mapping to a number between 0 and 15 int value = 0;
if (!Y[3] && !Y[2] && !Y[1] && !Y[0]) value = 1; if (!Y[3] && !Y[2] && !Y[1] && Y[0]) value = 0; if (!Y[3] && !Y[2] && Y[1] && !Y[0]) value = 2; if (!Y[3] && !Y[2] && Y[1] && Y[0]) value = 3;
if (!Y[3] && Y[2] && !Y[1] && !Y[0]) value = 6; if (!Y[3] && Y[2] && !Y[1] && Y[0]) value = 7; if (!Y[3] && Y[2] && Y[1] && !Y[0]) value = 5;
76
if (!Y[3] && Y[2] && Y[1] && Y[0]) value = 4;
if (Y[3] && !Y[2] && !Y[1] && !Y[0]) value = 14; if (Y[3] && !Y[2] && !Y[1] && Y[0]) value = 15; if (Y[3] && !Y[2] && Y[1] && !Y[0]) value = 13; if (Y[3] && !Y[2] && Y[1] && Y[0]) value = 12;
if (Y[3] && Y[2] && !Y[1] && !Y[0]) value = 9; if (Y[3] && Y[2] && !Y[1] && Y[0]) value = 8; if (Y[3] && Y[2] && Y[1] && !Y[0]) value = 10; if (Y[3] && Y[2] && Y[1] && Y[0]) value = 11;
// final transformation to PAM levels float Symbol = (2 * (float(value) + 1) - 17) / 16; return Symbol; }
#endif
ImpairGen.h
#ifndef _ImpairGen_h_ #define _ImpairGen_h_
void DestroySymb(float *Symbols, int i); // function declaration
int ImpairGen(float *Symbols, int numOfSymb, float Pe) { // impairment generator // works only accurately for small symbolerrorprobabilities (Pe << 0.1) // returns number of destroyd symbols srand48(time(NULL)); bool randomvalue; int count = 0;
for (int i = 0; i <= numOfSymb - 1; i++) { float rndval = drand48(); if (rndval >= 1 - Pe) { DestroySymb(Symbols, i); count++; } } return count; }
77
void DestroySymb(float *Symbols, int i) { cout << "Symbol: number: " << i << " value: " << 16 * Symbols[i]; float rndval = drand48(); if ((rndval >= .5) && (Symbols[i] != (15.0 / 16.0))) { Symbols[i] += (2.0 / 16.0); cout << " } if ((rndval < .5) && (Symbols[i] != -(15.0 / 16.0))) { Symbols[i] -= (2.0 / 16.0); cout << " } cout << " to " << 16 * Symbols[i] << endl;; } changed downwards"; changed upwards";
#endif
TCM decoder.h
#ifndef _TCM_decoder_h_ #define _TCM_decoder_h_
#include <iostream.h> #include "TC_reverse.h" #include "Unmapper.h" #include "Unmapper2.h"
void TCM_decoder(BitStream & Scrambled, float *Symbols, int numOfSymb, char enableTrellis) { // decoder according to the shdsl draft // processes input array Symbols (of type float) into BitStream Scrambled // the number of bits in BitStream Scrambled must not necessarily be // a multiple of 3 // cutlength is the number of bits to be appended to Bitstream Scrambled to // make its length a multiple of 3
// initialising temporary BitStreams BitStream Y0(numOfSymb); BitStream Y1(numOfSymb); BitStream Y2(numOfSymb); BitStream Y3(numOfSymb); BitStream X1(numOfSymb);
// * unmapper // for each symbol: for (int i = 0; i <= numOfSymb - 1; i++) {
78
bool *Y = Unmapper2(Symbols[i]); // call PAM unmapper
Y0.WriteBit(i, Y[0]); // write 4 bits into temporay BitStreams Y1.WriteBit(i, Y[1]); Y2.WriteBit(i, Y[2]); Y3.WriteBit(i, Y[3]); }
// * call convolutional decoder TC_reverse(X1, Y0, Y1, numOfSymb, enableTrellis);
// * parallel to serial converter for (int i = 0; i <= numOfSymb - 1; i++) { Scrambled.WriteBit(3 * i, X1.GetBit(i)); Scrambled.WriteBit(3 * i + 1, Y2.GetBit(i)); Scrambled.WriteBit(3 * i + 2, Y3.GetBit(i)); } }
#endif
Unmapper.h
#ifndef _Unmapper_h_ #define _Unmapper_h_
bool *Unmapper(float Symbol) { // mapps one float value to 4 binary (boolean) digits // returns a pointer to a boolean array of 4 elements
bool *Y = new bool[4]; // create array & pointer // transform symbol to a number between 0 and 15 (of type float) Symbol = (16 * Symbol + 17) / 2 - 1; int value = int(Symbol); // type cast necessary because...
for (int i = 0; i <= 3; i++) { if ((1 << i) & value) // ...bitshift is only for type int possible Y[i] = 1; else Y[i] = 0; } return Y; // return pointer }
#endif
79
Unmapper2.h
#ifndef _Unmapper2_h_ #define _Unmapper2_h_
bool *Unmapper2(float Symbol) { // self-made unmapper // mapps one float value to 4 binary (boolean) digits // returns a pointer to a boolean array of 4 elements
bool *Y = new bool[4] = {0, 0, 0, 0}; // create array & pointer // transform symbol to a number between 0 and 15 (of type float) Symbol = (16 * Symbol + 17) / 2 - 1; int value = int(Symbol); // type cast necessary because...
if (value >= 8) Y[3] = 1; if ((value >= 4) && (value <= 11)) Y[2] = 1;
if (((value >= 2) && (value <= 5)) || ((value >= 10) && (value <= 13))) Y[1] = 1;
if (((value % 4) == 0) || ((value % 4) == 3)) Y[0] = 1;
return Y; // return pointer }
#endif
TC reverse.h
#ifndef _TC_reverse_h_ #define _TC_reverse_h_
#include "Viterbi.h"
void TC_reverse(BitStream & X1, BitStream & Y0, BitStream & Y1, int length, char enableTrellis) { // trellis decoder (optional)
if (enableTrellis == n) { // if no encoder employed there is only bit copying i.e. //
80
for (int i = 0; i <= length - 1; i++) { if ((i % 2) == 0) X1.WriteBit(i, Y0.GetBit(i)); else X1.WriteBit(i, Y1.GetBit(i)); } } else { // execute trellis decoder Viterbi Trellis; // create instance of class Viterbi
Trellis.startup(Y0.GetBit(0), Y1.GetBit(0)); Trellis.startup(Y0.GetBit(1), Y1.GetBit(1));
for (int i = 2; i <= length - 1; i++) Trellis.insert(Y0.GetBit(i), Y1.GetBit(i));
Trellis.finish();
bool *result = Trellis.result();
for (int i = 0; i <= length - 1; i++) X1.WriteBit(i,result[i]); } }
#endif
Class Viterbi.h
#ifndef _Viterbi_h_ #define _Viterbi_h_
class Viterbi { // this class implements the trellis decoder // decoding hal-rate encoder: // Y0[n] = X1[n] + X1[n-2] // Y1[n] = X1[n-1] + X1[n-2]
// see Viterbi.C file for explanation of member functions public: Viterbi(int weight = 0); void startup(bool Y0, bool Y1); void insert(bool Y0, bool Y1);
81
void finish(); bool * result(); void display();
private: enum state { A, B, C, D };// possible states of the trellis state diagram struct node { // one element of the trellis diagram int step; // numbers of steps to the right in the trellis diagram state stt; int weight; // weight used in the algorithm node *next0; // pointers to the next trellis elements node *next1; node *prev; // pointer to the previous (left) trellis element }; typedef node* node_ptr; node_ptr first; // initial pointer node_ptr leaves[8]; // pointers to the last 8 elements (right end) node_ptr forks[4]; // ponters to the leaves
void insert(node_ptr &p, bool Y0, bool Y1); void prune(); void delete_path(node_ptr &p); int *HammingD(bool Y0, bool Y1, int stt); void display(node_ptr &p); };
#endif
Viterbi.C
#include "Viterbi.h"
Viterbi::Viterbi(int weight) { // constructor first = new node; first->step = 0; first->stt = A; first->next0 = NULL; first->next1 = NULL; first->prev = 0; first->weight = weight; for (int i = 0; i <= 7; i++) leaves[i] = NULL; for (int i = 0; i <= 3; i++) forks[i] = NULL;
82
void Viterbi::startup(bool Y0, bool Y1) { // to be used for inserting the first two pairs of bits // this function is necessary since there is no pruning // for the first two steps insert(first, Y0, Y1); }
void Viterbi::insert(bool Y0, bool Y1) { // adds one step to the trellis diagram // calls recursive, private class member functions insert(first, Y0, Y1); prune(); }
void Viterbi::insert(node_ptr &p, bool Y0, bool Y1) { // this recursive function follows the pointers in the nodes // in the trellis diagram until it reaches its "leaves", // 4 nodes with 2 pointers to NULL // on each of the 8 pointers ends two new nodes are attached // and the new values, i.e. weight and state are determined if (p->next0 == NULL && p->next1 == NULL) { node_ptr q0 = new node; p->next0 = q0; q0->next0 = NULL; q0->next1 = NULL; q0->prev = p; q0->step = p->step + 1; node_ptr q1 = new node; p->next1 = q1; q1->next0 = NULL; q1->next1 = NULL; q1->prev = p; q1->step = p->step + 1; int *HD = HammingD(Y0, Y1, p->stt); q0->weight = p->weight + HD[0]; q1->weight = p->weight + HD[1]; switch (p->stt) { case A: q0->stt = A; q1->stt = B; leaves[0] = q0; leaves[2] = q1; forks[0] = p; break; case B: q0->stt = C;
83
q1->stt = D; leaves[4] = q0; leaves[6] = q1; forks[1] = p; break; case C: q0->stt = A; q1->stt = B; leaves[1] = q0; leaves[3] = q1; forks[2] = p; break; case D: q0->stt = C; q1->stt = D; leaves[5] = q0; leaves[7] = q1; forks[3] = p; break; }; } else { if (p->next0 != NULL) { insert(p->next0, Y0, Y1); } if (p->next1 != NULL) { insert(p->next1, Y0, Y1); } } } // recursive call // recursive call
void Viterbi::prune() { // recursive function evaluating the latest 8 calculated weights, // determining the "successful" leaves and deleting the "unsuc// cessful" ones. // in the sections labeled with a * , two pointers of the same node // are pointing to "unsuccessful leaves" both of which had to be // removed. in that case a subfunction is called to remove the whole // path if (leaves[0]->weight < leaves[1]->weight) { delete leaves[1]; leaves[1] = NULL; forks[2]->next0 = NULL; } else { delete leaves[0]; leaves[0] = NULL; forks[0]->next0 = NULL;
84
} if (leaves[2]->weight < leaves[3]->weight) { delete leaves[3]; leaves[3] = NULL; forks[2]->next1 = NULL; if (forks[2]->next0 == NULL) // * delete_path(forks[2]); } else { delete leaves[2]; leaves[2] = NULL; forks[0]->next1 = NULL; if (forks[0]->next0 == NULL) // * delete_path(forks[0]); } if (leaves[4]->weight < leaves[5]->weight) { delete leaves[5]; leaves[5] = NULL; forks[3]->next0 = NULL; } else { delete leaves[4]; leaves[4] = NULL; forks[1]->next0 = NULL; } if (leaves[6]->weight < leaves[7]->weight) { delete leaves[7]; leaves[7] = NULL; forks[3]->next1 = NULL; if (forks[3]->next0 == NULL) // * delete_path(forks[3]); } else { delete leaves[6]; leaves[6] = NULL; forks[1]->next1 = NULL; if (forks[1]->next0 == NULL) // * delete_path(forks[1]); } }
void Viterbi::finish() { // in the trellis diagram, determines the node (or leave) with // the least weight // for the other leaves, there is function called to remove // the "unsuccesfull paths". int max = 2147483647; // max unsigned value for integer node_ptr p = NULL;
85
for (int i = 0; i <= 7; i++) if (leaves[i] != NULL) if (leaves[i]->weight < max) { max = leaves[i]->weight; p = leaves[i]; // pointer to best leave } for (int i = 0; i <= 7; i++) if ((leaves[i] != NULL) && leaves[i] != p) { // call function to remove "unsuccessful" paths delete_path(leaves[i]); } }
bool * Viterbi::result() { // iterative (non-recursive) function returning the // result of the final (finished) "successful path" int length; // first, the number of steps has to be found for (int i = 0; i <= 7; i++) if (leaves[i] != NULL) length = leaves[i]->step; bool *result = new bool[length]; // create array to hold result
node_ptr i = first; while (!((i->next0 == NULL) && (i->next1 == NULL))) { // pointer "walking" through the trellis-path... if (i->next0 != 0) { // result = 0 if the path in the trellis goes upward result[i->step] = 0; i = i->next0; } if (i->next1 != 0) { // result = 1 if the path in the trellis goes downward result[i->step] = 1; i = i->next1; } } return result; }
void Viterbi::delete_path(node_ptr &p) { // recursive funcion removing nodes in the trellis diagram. // works its way to the left removing all nodes until // a fork is reached (i.e. until the pointer points to a node // belonging to another path ending in a successful leave. node_ptr d = p->prev; if (d->next0 == p) { d->next0 = NULL; }
86
if (d->next1 == p) { d->next1 = NULL; } if (d->next0 == NULL && d->next1 == NULL) delete_path(d); delete p; }
int * Viterbi::HammingD(bool Y0, bool Y1, int stt) { // help function for calculating the weights in the // trellis diagram // for a given state in the trellis diagram and two given bits // this function retuns the hamming distance as an array of two // int values representing the upper and lower transition starting // from tht state stecified in "stt" int *HD = new int[2]; HD[0] = 0; HD[1] = 0; if ((stt == A && Y0) || ((stt == B) && Y0)) { HD[0]++; } if ((stt == A && !Y0) || ((stt == B) && !Y0)) { HD[1]++; } if ((stt == C && Y0) || ((stt == D) && Y0)) { HD[1]++; } if ((stt == C && !Y0) || ((stt == D) && !Y0)) { HD[0]++; } if ((stt == A && Y1) || ((stt == C) && Y1)) { HD[0]++; } if ((stt == A && !Y1) || ((stt == C) && !Y1)){ HD[1]++; } if ((stt == B && Y1) || ((stt == D) && Y1)){ HD[1]++; } if ((stt == B && !Y1) || ((stt == D) && !Y1)) { HD[0]++;} return HD; }
void Viterbi::display() { // calls recursive function cout << "This is to display the ends (leaves): " << endl; display(first); }
void Viterbi::display(node_ptr &p) { // recursive function that shows the elements (nodes) of // the trellis diagram // this function is not needed for obtaining the result but // may help to clearify what is going on...
87
if (p->next0 != NULL) display(p->next0); if (p->next1 != NULL) display(p->next1); // if the following line is removed the funcion is showing ALL nodes if (p->next0 == NULL && p->next1 == 0) cout << "Weight: " << p->weight << " State: " << p->stt << " Step: " << p->step << endl; }
Makele
CC = g++
CFLAGS = -g CXXFLAGS = -g
all: shdsl
shdsl: shdsl.C BitStream.o Viterbi.o $(CC) -o $@ $(CCFLAGS) shdsl.C BitStream.o Viterbi.o
BitStream.o: BitStream.C BitStream.h $(CC) -c $(CFLAGS) BitStream.C
Viterbi.o: Viterbi.C Viterbi.h $(CC) -c $(CFLAGS) Viterbi.C
clean: rm -f *.o core shdsl
References
[1] ITU-T (International Telecommunication Union), Single-Pair High-Speed Digital Subscriber Line (SHDSL) Transceivers, Draft G.991.2, August 2000. [2] T. Starr, J. M. Ciof, P. J. Silverman, Understanding Digital Subscriber Line Technology, Prentice Hall PTR, 1999. [3] Edward A. Lee, David G. Messerschmitt, Digital Communication, Kluwer Academic Publishers, 1988. [4] I. A. Glover, P. M. Grant, Digital communications, Prentice Hall, 1998. [5] J. Wheat, UK - Access Network Frequency Plan user Guide, EMEA Ofce of the Chief Ofcer, Marconi, Technology Drive, Beeston, Notts, NG9 1LA, UK. [6] ANSI, Asymetric Digital Subscriber Line (ADSL) Metallic Interface, T1.413, 1998. [7] N. Nedev, S. McLaughlin, D. Laurenson, R. Daley, ATM over DSL under the Inuence of Impulse Noise, Dept. of Electrical Engineering, The University of Edinburgh, Edinburgh, EH9 3JL, UK. [8] R. Strum, Discrete Systems and Digital Signal Processing, Addison-Wesley Publishing Company, pp. 773775, 1989. [9] J. B. Cain, Punctured Convolutional Codes of Rate (n-1/n) and Simplieed Maximum Likelihood Decoding, IEEE Transaction on Information Theory, vol. IT-25, No.1, pp. 9798, January 1979.
88

DSL

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DSL

Hochgeladen von

Copyright:

Verfügbare Formate

Eric Schreiber Erasmus Student at the University of Edinburgh

Crosstalk in xDSL and Simulation of a TC-PAM SHDSL Transceiver

I declare that this thesis is my original work except where stated.

Acronyms and abbreviations

Acronyms and abbreviations

1.2 Structure of this thesis

Nearly 100 according to [2] (p.1)

chapter investigates crosstalk equations provided by different resources. An approach to

Chapter 2 Digital Subscriber Line

Internet Service Provider

Figure 2.1: ADSL Reference Model

CHAPTER 2. DIGITAL SUBSCRIBER LINE

POTS Band Lower Bit-rate Upstream Band

Higher Bit-rate Downstream Band

Frequency [kHz] 4 10 200 1100

From the customer to the CO From the CO to the customer

CHAPTER 2. DIGITAL SUBSCRIBER LINE

into one symbol. As explained in detail in [4] (p.381-383 and p.391-395),

time and its inverse

represents a value from an alphabet with a nite number of elements or

is the sample symbol at time instant

% # !  & $"    ' 

CHAPTER 2. DIGITAL SUBSCRIBER LINE

Figure 2.3: 16-PAM and 16 APK

There is also impulse noise and radio noise

CHAPTER 2. DIGITAL SUBSCRIBER LINE

2-wire cable transmitter NEXT receiver receiver transmitter

2.3 The ITU-T Draft G.991.2 for SHDSL [1]

CHAPTER 2. DIGITAL SUBSCRIBER LINE

STU - R PMS - TC (Physical Media Specific TC - Layer)

PMD (Physical Media Dependent)

CHAPTER 2. DIGITAL SUBSCRIBER LINE

Chapter 3 Cross-Talk in Digital Subscriber Line

3.2 PSDs: Equations and Results

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

ADSL upstream according to [2]

ADSL upstream according to [6]

c gG j TURmHG Y H1 i  UmHHbE ! n n T R IIIc l 1 SH1 j UR i I (  H ( ! I T i Y d c I  p PG !Ig  

A 9 3 &5875 1  7 f    t # R x t # 0x     !   #r ((  ! y A @ &5875 3 0)'% $ t 9 1

A 875 9 63 1 5 A@9 31 % B&65875 420)('&$

3 a s h ph f d c Y x` vwrrFuF rqt r6i ge !15! H F i TUR ) # bHH a`Y

    " !     h f g f !f f f4f h 4f t  R  k f gf f f4!fh f f # e t  g T R i I (  6 H1 4 G F

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

ADSL downstream according to [2]

ADSL downstream according to [6]

In ADSL downstream the main difference lies in the factor

. A graphic plot in Matlab has shown

A 875 9 &3 1 5   t # R H t  0x A @ 9 &575 3 1 0)'&$ % 7t TU!I ( ( R c # 0cSI ( (

fh f TURPH1 r i  f t  R I  h 9 5 h r i   h5 1 t # e T RQIG F USHPH1 4    

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

d # 31n ( )` ' %d $" HG S1 2 0 I ( &  # !   A    u ! U   T R Q F    T R 6 (  i  USH1  4  f f @ ( F q 9 f 1 $  t 9 f7 1  4     (  # ! 1 ! ff t @ 9 7 1 $ f ff @ 3 9 7 f 7( F 1( $  t 9 f 7 1   1 f t @ 9 7 1 $

)` ' %d $" Hn S1 I ( &  # ! F T RQ !r4  USHI Y 4

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

3.3 NEXT: Equations and Results

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

3.4 FEXT: Equations and Results

, as shown in equation 3.8. In FEXT the frequency dependency is given by the

length - has been set to 4 Km.

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

relationship between PSD and NEXT PSD,

CHAPTER 3. CROSS-TALK IN DIGITAL SUBSCRIBER LINE

Various PSDs of ADSL up and downstream 0 10 20 30 40 PSD (dBmscale) 50 60 70 80 90 100 110

% # ! & $" '

c gG j TURmHG Y H1 i UmHHbE ! n n T R IIIc l 1 SH1 j UR i I ( H ( ! I T i Y d c I p PG !Ig

A 9 3 &5875 1 7 f t # R x t # 0x ! #r (( ! y A @ &5875 3 0)'% $ t 9 1

3 a s h ph f d c Y x` vwrrFuF rqt r6i ge !15! H F i TUR ) # bHH a`Y

" ! h f g f !f f f4f h 4f t R k f gf f f4!fh f f # e t g T R i I ( 6 H1 4 G F

A 875 9 &3 1 5 t # R H t 0x A @ 9 &575 3 1 0)'&$ % 7t TU!I ( ( R c # 0cSI ( (

fh f TURPH1 r i f t R I h 9 5 h r i h5 1 t # e T RQIG F USHPH1 4

d # 31n ( )` ' %d $" HG S1 2 0 I ( & # ! A u ! U T R Q F T R 6 ( i USH1 4 f f @ ( F q 9 f 1 $ t 9 f7 1 4 ( # ! 1 ! ff t @ 9 7 1 $ f ff @ 3 9 7 f 7( F 1( $ t 9 f 7 1 1 f t @ 9 7 1 $

)` ' %d $" Hn S1 I ( & # ! F T RQ !r4 USHI Y 4

I ` ' & & ` ) 6