FSAN

The FSAN xDSL simulation tool

Introduction

Welcome to the documentation of the FSAN xDSL simulation tool. This is the second public release of the simulation tool. With this simulator we hope that you will be able to simulate different xDSL technologies in relatively complex setup but still with relative ease.

The evaluation of technologies like SDSL and VDSL is a complicated and lengthy task. This is especially true for scenarios where the SNR is different at both ends of the lines and in topologies with different cable models including bridge taps, and where power boost and power back-off are to be applied. When so many parameters can be varied, it is important to have a common understanding of the simulation environment.

Within the FSAN VDSL group in the end of 1998 initiatives were taken to create and promote the use of a common simulation tool. This tool was to include things like various noise models, the FSAN noise combination method, power back-off methods, power boost, etc. The tool should also be able to evaluate the impact of VDSL on existing services (in particular ADSL, which is FEXT limited). It was agreed that Telia would take the responsibility of the implementation of the simulation tool in close cooperation with the other members of the FSAN group. This package is the result of this effort.

Within the FSAN VDSL group there has been a lot of ground-breaking work done, for example, by defining noise models, researching an appropriate noise combination method, and defining network topologies together with various disturbers describing potential real world scenarios. These methods can of course be used in this simulator. That is, one of the objective of this simulation tool was to concentrate the FSAN results into one simulation package to facilitate evaluation of VDSL proposals and scenarios. Later the scope of the simulator has been expanded to include evaluation of any xDSL method.

Extension in the future will partly depend on user feedback, so please send in comments and contribute to the simulator and its examples.

Please note that this is probably the last version of the simulator to be using FSAN in its name. In the future FTW (Forschungszentrum Telekommunikation Wien, Austria) will serve as support for the tool and will release bug fixes and function as coordinator for the simulator future developments. A web site for the simulator can be found at: http://www.xdsl.ftw.at/xdslsimu. Already in this version of the simulator FTWs broader interest in all xDSL technolgies is shown with a much better support for other xDSL technologies besides VDSL, for example, ADSL and SDSL.

Installing and starting the simulation tool

The simulation software is written in Matlab (version 5 or later without any extra toolboxes).

Installing the tool

The installation is done by unpacking the tool. All the Matlab code is then found in the fsansimu/src directory. To unpack this on unix you would do:

gzip -cd fsansimu_2.0.tar.gz | tar -xvf -

On a PC you could use WinZip to unpack the tool.

Running the tool

To run this tool on unix:

Change the directory to the src directory and start Matlab
cd fsansimu/src
matlab

To run on PC:

Start Matlab
Select menu File->Set path and set it to the src directory
Type/run "startup"

This actually sets up paths and change directory into "examples/GUI_VDSL" where uiMain is run.

More examples

There is a number of simulations examples found in the examples directory that can help to understand how to set up and run experiments using the xDSL simulation tool. In the companion document Examples.html the examples are described in more detail.

Using the tool

The input to the simulation is typically a text-file with straight forward Matlab code. However, for VDSL simulations a graphical user interface (GUI) has been developed.

A large number of input parameters are easily changeable to allow a large variaton of scenarios to be simulated. These parameters include network topology, spectrum allocation plan, line code dependent parameters, and transmit power spectral densities (PSD). The next section contains a description of the input parameters. Following that we describe the output of the simulations. From this output one can then calculate things like capacity and margin.

The simulation is outlined as

An initiation phase where the experiment is described using a structure ex containing five parts

param - general simulation parameters
tfplist - list of modem and disturbers time and frequency plans.
lclist - list of line code definitions
clist - list of cable definitions
tt - the selected traffic and topology definition

The evaluation of the experiment
Presentation of the result

Input Parameters

Using the text based parameter setup we can access all the parameters in the simulation. Below we discuss each parameter group individually.

Param

The global parameters are found in the structure ex.param. A default setup is done in setupParam.m by making a call like

ex.param = setupParam;

In the param structure we have the following variables

frequency
backgroundNoise: Background noise level (dBm/Hz).
XTlevel
Zterm: Reference impedance for attenuation calculation
modemlist: List of modem types to test
HAMBandName: Name of HAM band plan to use
FSANNoiseModel: FSAN noise model to use (or 'Calculate')
xDSLlist: A structured list with elements containing 'name' and 'used' fields. This list maps the generic VDSL (or other xDSL) name into a specific VDSL e.g. 'VDSL-TDD-sym1:1'.

TFPlist

A list of all time and frequency plans must be set up. This is simply done by using the definitions in the xdsldefs directory, for example:

% initiate ex.tfplist by fetching a HAM band definition
[ex.tfplist, ex.param.HAMBandName] = itu_tfplanHAM([]);
ex.tfplist = fsan_tfplansMISC(ex.tfplist); % Get plans for alien noise
ex.tfplist = etsi_tfplansVDSL(ex.tfplist); % Get some VDSL plans

Each entry in this list is a time and frequency plan (tfplan) containing the following fields:

name

The modem name

(VDSL modem must start with VDSL and ADSL modem with ADSL)

PSD

downstream

upstream

PSD mask definition string, that is, any function/vector is possible. This also includes out of band PSD.

active

upstream

downstream

Vector containing minimum and maximum active frequencies for upstream respectively downstream. By active we mean the part that should be used for capacity calculations thus excluding any out of band energy from the PSD definition.

PBO

method

Connected to the tfplan is a power back off (PBO) method. Currently there are four methods defined: reference length 'RefLen', reference FEXT 'RefFEXT', reference Noise 'RefNoise' and reference frequency 'RefFreq'. If no PBO is wanted a 'None' is selected.

param

len

PBO parameter length(m); for RefLen or RefFEXT.

freq

PBO parameter frequency(Hz); for RefFreq.

maxlen

For the RefFreq method a maximum length can also be given.

HAM

active

Defines if HAM band should be active (1 is active).

timeDivision

up

down

For time division duplex methods a time division can be given for up and down stream, respectively (for frequency division methods this is given as 1 and 1).

sync

Flag indicating if the time division is synchronous or not. (1 is synchronous)

lcname

The name (string) of the line code definition to use for the plan. This will the be found in ex.lclist (described below).

Thus, to add our own VDSL modem (cf. userDefinitionsExample1.m) we do something like:

% Add our own VDSL definition
tmp_tfplan=getList(ex.tfplist,ex.param.HAMBandName); % initiate tmp_tfplan
tmp_tfplan.name='VDSL-XXX';
tmp_tfplan.PSD.downstream ='calcPSD([.3e6 -160 .3e6 -60 3.5e6 -60 3.5e6 -160],''Linear'')';
tmp_tfplan.PSD.upstream ='calcPSD([3.5e6 -160 3.5e6 -60 10e6 -60 10e6 -160],''Linear'')';
tmp_tfplan.timeDivision.up=1; % Time used in up resp. down link
tmp_tfplan.timeDivision.down=1;
tmp_tfplan.timeDivision.sync=1;
tmp_tfplan.PSD.PBO.method='None'; % Power back-off method
tmp_tfplan.PSD.PBO.param.freq=2e6; % PBO parameter length(m)
tmp_tfplan.PSD.PBO.param.len=0; % PBO parameter frequency(Hz)
tmp_tfplan.PSD.PBO.param.maxlen=500; % PBO parameter maxlength(m)
tmp_tfplan.lcname='VDSL-theo';
tmp_tfplan.PSD.active.upstream=[0.3e6 10e6];
tmp_tfplan.PSD.active.downstream=[0.3e6 10e6];
tmp_tfplan.PSD.HAM.active=1;
ex.tfplist=insertList(ex.tfplist,tmp_tfplan);

LCList/ Line code definitions

New in version 2 of this simulator is the possibility to define line code dependent features. Default line code structure is defined by calling setupLClist.m. Many others are defined in xdsldefs, for example (fsan_alien_lcdefs.m, etsi_lcdefs.m).

ex.lclist = setupLClist;

The elements in the lclist consist of the following four fields:

name

The name of the line code definition.

param

A set of parameters needed for bit-rate calculations, the default values are shown below.

calcRate

The function (as a string) to call when calculating the bit rate. Its arguments are the tfplan used, the result (the experiment result), the lc to use, and the used frequency vector.

lcPrint

The function (as a string) to call to print out the parameters used in an experiment. Its argument is lc (the lc structure to print).

For example, by calling the setup routine setupLClist.m the following structure is set up:

name: 'VDSL-theo'
param: [1x1 struct]
signal_margin: 0
xtalk_margin: 6
refSNR: 9.8000
codingGain: 4.2000
SNRloss: 0
efficiencyLoss: 0.1000
SNRMax: 48
Px: 11.5000
calcRate: 'calcResultTheo'
lcPrint: 'lcPrintTheo'

TT/Scenario

The scenario is described in the structure tt (topology and traffic). When using a GUI all available scenarios can be stored in a ttlist (typically gui.ttlist). Default scenarios are defined in xdsldefs, for example (fsan_loops.m, etsi_loops.m, ansi_loops.m)

gui.ttlist = fsan_loops([]);

Each tt structure consist of three fields:

name

The name of the scenario.

topology

A vector of cell arrays where each cell array defines

{distance (meters), cable name, node name, line name or comment}

traffic

A vector of cell arrays where each cell array defines

{from node (referring to topology), to node (refering to topology), tfplan, number of modems}

Thus, to use our own scenario we write, for example (cf. userDefinitionsExample1.m)

% Use our own scenario
tt.name='My own Scenario';
tt.topology=[
    {0 '' 'CO' ''};
    {500 'DTAG04' 'N1' ''};            % Distance, Cable, Node name, Line name
    {500 'DTAG04' 'N2' ''};
    {500 'DTAG04' 'N3' ''};
    {1500 'DTAG04' 'C' ''};
    {500 'DTAG04' 'N4' ''};
    ];
tt.traffic=[
    {1 2 'VDSL' 3};                     % From node, to node, tfplan, no modems
    {1 2 'ADSL' 4};
    {1 3 'VDSL' 4};
    {1 4 'ISDN-2B1Q' 3};
    {1 4 'ADSL' 1};
    {1 5 'HDSL-1' 3};
    {5 6 'VDSL' 3};
    {5 6 'ADSL' 4};
    ];
ex.tt=tt;                               % Define the experiment tt structure
gui.ttlist=insertList(gui.ttlist,tt);   % Insert into list (used for GUI)

Bridge taps

To define a bridge-tap information about it is added to the definition of a node. The new fields are the length of the bridge-tap, the cable used, a name for the tap, and a name for the cable (typically used to describe the bridge tap length).

For example, if we would like to define the ANSI T1E1.4 VDSL loop4 short we write (the bridge tap extensions are in green):

tt.topology=[

    {0  '' 'CO' '' 0 '' '' ''};

    {1000*0.3048 'ANSI_TP1' 'Node' '1000 ft ANSI_TP1->' 300*0.3048 'ANSI_TP2' 'BT' '300 ft ANSI_TP2->'};

    {150*0.3048  'ANSI_TP2' 'Node' '150 ft ANSI_TP2->'  150*0.3048 'ANSI_TP2' 'BT' '150 ft ANSI_TP2->'};

    {150*0.3048  'ANSI_TP2' 'NT1'  '150 ft ANSI_TP2->'  0 '' '' ''};

];

Output

The basic result from evalExperiment.m is a result structure consisting of an array with a set of vectors:

result(i).Modem.Name
result(i).Modem.LT_Node
result(i).Modem.NT_Node
result(i).NT.Rx_signal
result(i).NT.Tx_signal
result(i).NT.Tot_noise.up
result(i).NT.Tot_noise.down
result(i).NT.Alien_noise
result(i).LT.Rx_signal
result(i).LT.Tx_signal
result(i).LT.Tot_noise.up
result(i).LT.Tot_noise.down
result(i).LT.Alien_noise

for each modem i matching the modems in ex.modemlist. There are three substructures: Modem, NT, and LT.

Modem: tells the name, LT_Node number, and NT_Node number of the analysed modem.
NT: gives the noise environment at the customer end.
LT: gives the noise environment at the exchange end.

For both the NT and the LT side there are four different sub structures Rx_signal, Tx_signal, Tot_noise, and Alien_noise.

Rx_signal: contains the received signal as a function of frequency (ex.param.frequency.f)
Tx_signal: contains the Transmitted signal from this side as a function of frequency (ex.param.frequency.f)
Alien_noise: contains the crosstalk noise from all systems except VDSL as a function of frequency (ex.param.frequency.f)

Note! there is no background noise in the Alien_noise

Tot_noise: Contains the total noise (Alien+self+background noise) and it is divided into two parts: up and down. The difference between the two is that for Tot_noise.up the upstream VDSL transmitter(s) is(are) always on but depening on the VDSL duplex the downstream VDSL transmitter(s) can be switched of. For Tot_noise.down it is the other way round. This means that Tot_noise.up=Tot_noise.down if the duplex is FDD but not if the duplex is TDD.

Calculating the SNR

To calculate the SNR for a certain side of a certain modem we do:

To Be Written

Getting bitrates and margines

By calling calcFSANresult with this result structure we get the bit rates for each modem, e.g.,

[Rate_LT, Rate_NT, Margin_LT, Margin_NT]=calcFSANresult(ex,result);

Here the Rate_LT and Rate_NT are the rates at the LT and NT respectively, while Margin_LT and Margin_NT gives the actual margin at either side.

Graphical Output

Two plot routines have been provided to display parts of the ex-structure, the time-frequency plan plot and the topology and traffic information plot:

plotTFplan(tfplan, ftype, fax)

Plots the PSD mask for a certain TF plan

plotTTstructure (tt, inScale)

Plots the TT structure

There is also a function to display transmission curves (signal and noise curves) from the evaluation results:

plotResult(ex, result, modemno, side, ftype, fax)

Plot the resulting transmission curves

Discussion/Conclusion

To Be written

References

FSAN - Full Service Access Network Initiative web page, VDSL initiative. (Sorry for the broken links)

FSAN VDSL working group VDSL scenarios for vendor simulations, 1998.

Heron et.al. Proposal for crosstalk combination method, T1E1.4/98-328 Plano TX, USA, 1998.

Heron et.al. Generator-based noise models for VDSL, T1E1.4/99-122 Costa Mesa, CA. ,March 8-12, 1999.

ITU Amateur and Amateur-satellite service Frequency Allocations Table - HF Bands.

ETSI Technical Specification TS 101 270-1 V1.1.1 (1998-04), Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements.

Very-high-speed Digital Subscriber Lines - System Requirements Draft Technical Document (T1E1.4/98-043R6).

Nordström, T., D. Bengtsson, "Simulating xDSL", to appear, 2000.

Revision History

1999/03/31 Version 1 Released
1999/11/18 Version 2 beta 3 released to FSAN for test
2000/05/05 Version 2 beta 4 released to people on the fsansimu e-mail list
2000/09/17 Version 2 Released

Licence

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version.

When referring to this simulator (The FSAN xDSL simulator) no files in the xdslcomm and xdsldefs directories should be changed. When referring to simulations done with this simulator the main simulations files must be made available upon request to anyone asking for them. That is, anyone should be able replicate any simulations referring to this simulator by putting the main files into their simulator and redo the experiments for themselves.

Disclaimer

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details (in file COPYING, or http://www.opensource.org/gpl-license.html)

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

The numerical assumptions in this tool are based on assumptions in published ETSI and ANSI standards, and the few measurements that have been performed. Due to the random and large variations in behaviour of these networks, it cannot be guaranteed that these assumptions are realistic for real access networks.

Contact

In the future FTW will serve as support for the tool and will release bugfixes and function as coordinator for the simulator future developments.

A web site for the simulator can be found at: http://www.xdsl.ftw.at/xdslsimu

Comments can be sent to:
xdslsimu@ftw.at (New address!)

Happy simulation, wishes the main authors:

Tomas Nordström (Tomas.Nordstrom@FTW.at)

FTW

Maderstrasse 1/9

AT-1030 Wien

Austria

Daniel Bengtsson (Daniel.J.Bengtsson@Telia.se)

Telia Research AB

Aurorum 6

SE-97775 Luleå

Sweden