The FTW xDSL simulation tool

Content:

Introduction
System Requirements
Installing the Simulation Tool
Running the Simulation Tool using the Graphical User Interface
Simulation Examples
Using the Tool
Input Parameters:

General Simulation Parameters ex.param
List of Modem's and Disturber's Time and Frequency Plans ex.tfplan
List of Linecode Definitions ex.lclist
List of Cables ex.clist
Traffic and Topology Definition ex.tt

Simulation Output
Extended Calculations:

Calculating the SNR
Getting Bitrates and Margins

Graphical Output
Discussion/Conclusion
References
Revision History
License
Disclaimer
Contact

Description of all Program Files and Functions (document FileDescriptions.html)

Introduction

Welcome to the documentation of the FTW xDSL simulation tool. This is the version 3.2 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 ADSL, 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 Full Service Access Network (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. In the end of 1998 initiatives were taken by FSAN 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. The first version (1.0) of this tool (then called the FSAN simulator) was the result of that effort.

Since beginning of year 2000 FTW (Forschungszentrum Telekommunikation Wien) in Austria has taken over the responsibilities for the tool and its development. FTW now release bug fixes and acts as a coordinator for future simulator developments. A web site for the simulator, now called "The FTW xDSL simulator", can be found at: http://www.xdsl.ftw.at/xdslsimu. FTW's broader interest in all xDSL technologies is now seen from the better support for other xDSL technologies besides VDSL, for example, ADSL and SDSL.

But please note that any future extensions to the simulator will partly depend on user feedback, so please send in comments and contribute to the simulator and its examples.

System Requirements

The simulation software is written in Matlab code. This matlab code can either be executed with Matlab or with Octave.

Matlab

We lately tested with Matlab 6.5 and 7.0, but there is nothing special about the code that should stop it from running in any matlab version from 5 and forward. At the moment there might also be some dependencies on the signal processing toolbox

Octave

From version 2.1.50 of Octave we can run the simulator with Octave. You also need to have octave-forge installed. (We currently use Octave 2.1.71 and Octave forge 2005.06.13 for our testing).

Installing the simulation tool

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

tar -zxf xDSLsimu_3.2.tgz

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

Running the simulation tool using the Graphical User Interface

For VDSL simulations a Graphical User Interface (GUI) is available which allows the user to define and respectively change the most important simulation parameters quickly and easily. Users which are not familiar with the tool can get a first impression about the tool using the GUI. However the GUI does not provide access to all of the simulation parameters. For more sophisticated simulations and for an exhaustive usage of the capabilities of the simulation tool the input simulation parameters should be using text-based MATLAB simulation scripts (see chapter Using the tool).

To run this tool on unix:

Change the directory to the src directory and start Matlab

cd xDSLsimu3.2/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 to show a first example of a VDSL simulation using the Graphical User Interface.

Simulation Examples

There are a number of simulation examples found in the src\examples directory that can help to understand how to set up and run experiments using the xDSL simulation tool. Simulation files related to SDSL performance evaluation can also be found in the src\examples directory . In the companion document Examples.html and ExamplesSDSL.html all examples are described in more detail.

Using the tool

When not using the Graphical User Interface the input to the simulation is typically a text file with straight forward Matlab code.
A large number of input parameters are easily changeable to allow a large variation of scenarios to be simulated. These parameters include network traffic and topology, spectrum allocation plans, line code dependent parameters, transmit power spectral densities (PSD), and noise related parameters (background noise as well as crosstalk noise). 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.

In general a simulation run is outlined as:

An initiation phase where the experiment is described using a structure ex which contains all the information (input parameters) needed to run a simulation
The evaluation phase of the experiment based on the input parameters
Presentation of the result

Input Parameters

All the information (input parameters) needed for evaluating a simulation result must be contained in the structure ex, i.e., for preparing a simulation run the user has to set up the structure ex accordingly. Using the text based parameter setup we can access all the parameters in the simulation. The ex struct consists of the following five parts (each of them is again organized as a structure):

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

Below we discuss each part individually.

General Simulation Parameters ex.param :

The general simulation 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 ex.param structure we have the following variables:

ex.param.frequency.fastrecalc: Switch variable which determines if calculations should use an optimized frequency axis which is slightly (1-2%) less accurate but can be up to 20 times faster. Set to 1 if fast calculations should be used, otherwise a slow but more accurate calculation is done.
ex.param.frequency.min: Lower boundary of frequency axis (Hz) used for the evaluation.
ex.param.frequency.max: Upper boundary of frequency axis (Hz) used for the evaluation.
ex.param.frequency.granularity: Granularity (Hz) in the frequency axis if fastrecalc is not used.
ex.param.frequency.f: Frequency axis used for evaluation (derived from the settings of the preceding parameters)
ex.param.backgroundNoise: Background noise level to be used (dBm/Hz).
ex.param.XTlevel.NEXT: Reference near end crosstalk level at 1 MHz (dB)
ex.param.XTlevel.FEXT: Reference far end crosstalk level at 1 MHz (dB)
ex.param.XTlevel.thirdCXT: Reference crosstalk level for third circuit crosstalk at 1 MHz (dB)
ex.param.Zterm: Reference (loop terminating) impedance for attenuation calculation (Ohms)
ex.param.modemlist: List of modems to be evaluated in the simulation run. For each modem type (xDSL service) to be evaluated the modem's name must be contained in the list as a string. For example to evaluate VDSL as well as ADSL Modems of the given scenario a setting like ex.param.modemlist=['VDSL'; 'ADSL']; is needed. If ex.param.modemlist contains a modem name (service name) which does not exist in the selected scenario an error occurs.
ex.param.HAMBandName: Name of HAM band plan to be used as a string. The HAM bands are defined as PSD mask templates and must be contained in the experiment's list of time/frequency plans ex.tfplist.
ex.param.NoiseModel: Predefined FSAN noise model to be used for the evaluation. The variable must contain the name of the considered noise model as a string. If set to 'Calculate' the real noise caused by the traffic on the scenario is evaluated in the simulation run. Predefined noise models are defined as PSD mask templates and must be contained in the experiment's list of time/frequency plans ex.tfplist.
ex.param.xDSLlist: A structured list with elements containing fields name and used . This list maps the generic VDSL (or other xDSL) name into a specific name. For example the setting ex.param.xDSLlist(1).name = 'VDSL' and ex.param.xDSLlist(1).used='VDSL-TDD-sym1:1'leads to the use of the time/frequency plan (tfplan) of 'VDSL-TDD-sym1:1' when the generic name 'VDSL' appears in the simulation parameters.

List of modem's and disturber's time and frequency plans ex.tfplist :

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

% initiate ex.tfplist by fetching a HAM band definition
[ex.tfplist, ex.param.HAMBandName] = itu_tfplanHAM([]);
ex.tfplist = etsi_tfplansLegacy(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:

ex.tfplist.name: Contains the modem names as strings, e.g. 'ETSI-HDSL-2B1Q-2p','ETSI-ADSL-FDDoverPOTS', and 'ETSI-VDSL-Template-E1-Pex-P2-M2'.
ex.tfplist.PSD.downstream: PSD mask definition strings for downstream, that is, any function/vector is possible. This also includes out of band PSD.
ex.tfplist.PSD.upstream: PSD mask definition strings for upstream, that is, any function/vector is possible. This also includes out of band PSD.
ex.tfplist.PSD.active.downstream: Vector containing minimum and maximum active frequencies for 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.
ex.tfplist.PSD.active.upstream: Vector containing minimum and maximum active frequencies for upstream. By active we mean the part that should be used for capacity calculations thus excluding any out of band energy from the PSD definition.
ex.tfplist.PSD.UPBO.method: Connected to the tfplan is a upstream power back off (UPBO) method. The name of the UPBO method is contained in this variable as a string. The reference-based UPBO method standardized in VDSL is called 'RefRef'. There are a number of older methods also defined like: reference length 'RefLen', reference FEXT 'RefFEXT', reference Noise 'RefNoise', and reference frequency 'RefFreq'. If no UPBO is wanted a 'None' is selected.

ex.tfplist.PSD.UPBO.param.refa: For UPBO method 'RefRef' the alpha parameter vector (one parameter per upstream band) should be given. These parameters will depend on the assumed noise environment.

ex.tfplist.PSD.UPBO.param.refb: For UPBO method 'RefRef' the beta parameter vector (one parameter per upstream band) should be given. These parameters will depend on the assumed noise environment.
ex.tfplist.PSD.UPBO.param.len: UPBO parameter length (m); needed for UPBO methods 'RefLen' and 'RefFEXT'.
ex.tfplist.PSD.UPBO.param.freq: UPBO parameter frequency (Hz) ; needed for UPBO method 'RefFreq'.
ex.tfplist.PSD.UPBO.param.maxlen: For UPBO method 'RefFreq' a maximum length can also be given.
ex.tfplist.PSD.UPBO.band: For all PBO methods the fequency bands where UPBO should be performed is given with this matrix. Each row represents an upstream band with a start and end frequecies. For example, for plan 997 we define it to be [3000 5100; 7050 12000]*1e3.
ex.tfplist.PSD.HAM.active: Defines if HAM band should be active or not (1 is active).
ex.tfplist.timeDivision.upand ex.tfplist.timeDivision.down: Relative time contingent allocated for upstream respectively downstream in time division duplex methods. For example, in case of symmetric TDD these variables should be set to 0.5 each. For frequency division methods both should be set to 1).
ex.tfplist.timeDivision.sync: Flag indicating if the time division is synchronous or not. (1 is synchronous)
ex.tfplist.lcname: The name (as a string) of the line code definition to be used 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.UPBO.method='None'; % Power back-off method
tmp_tfplan.PSD.UPBO.param.freq=2e6; % PBO parameter length(m)
tmp_tfplan.PSD.UPBO.param.len=0;  % PBO parameter frequency(Hz)
tmp_tfplan.PSD.UPBO.param.maxlen=500; % PBO parameter maxlength(m)
tmp_tfplan.lcname='ETSI-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);

As is can be seen from the example, adding a specific tfplan to a an existing tfplist can be most conveniently done by using the function insertList.

List of linecode definitions ex.lclist:

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 directory src\xdsldefs, for example (lcDefADSLDMT.m,lcDefVDSLDMT.m, lcDefVDSLSCM.m, lcDefSDSL_sym.m, lcDefSDSL_asym.m, ...).

ex.lclist = setupLClist;

The elements in the linecode list consist of the following four fields:

ex.lclist.name: The name of the line code definition as a string.
ex.lclist.param: A set of parameters needed for performance calculations.
ex.lclist.calcRate: This variable must contain the name of a function (as a string) to call for calculating the resulting bit rate (or margin in case of SDSL simulations) of a specific modem (xDSL service). The function's input arguments are the time/frequency plan of the specific modem , the experiment result (result struct created by evalExperiment.m), the linecode definitions of the specific modem, and the used frequency vector. The function specified by ex.lclist.calcRate is typically called by the function calcXDSLresult after execution of evalExperiment .
ex.lclist.lcPrint: The function (as a string) which could be called to print out the parameters used in an experiment. Its argument is lc (the linecode structure to print).

The default linecode structure, set up by calling the routine setupLClist is as follows:

ex.lclist.name= 'VDSL-theo'
ex.lclist.param.signal_margin=  0.0    % [dB]
ex.lclist.param.xtalk_margin=   6.0    % [dB]
ex.lclist.param.refSNR=         9.8    % [dB]
ex.lclist.param.codingGain=     3.5    % [dB]
ex.lclist.param.SNRloss=        0.0    % [dB]
ex.lclist.param.efficiencyLoss= 0.1    % [dB]
ex.lclist.param.SNRmax=        60.0    % [dB]
ex.lclist.param.PxDown=        11.5    % [dBm]
ex.lclist.param.PxUp=          11.5    % [dBm]
ex.lclist.calcRate= 'calcResultTheo'
ex.lclist.lcPrint=  'lcPrintTheo'

List of cables ex.clist:

This list must contain all cable types used in the experiment scenario. A list of cables used for VDSL modelling is set up by calling

ex.clist = etsi_cablesVDSL([]);

The list of cables ex.clist consists of the following fields:

ex.clist.name: The name of the cable as a string. This name is used to identify a cable in the loop topology definition.
ex.clist.model: The name of the cable model (as a string) which is used to compute the cable's secondary line parameters (as attenuation, characteristic impedance, A,B,C,D parameters, ...) from their primary electric parameters (defined in ex.clist.param). Different models are needed because primary cable parameters are given according to different measurement methods.
ex.clist.param: This is again organized as a struct which contains multiple fields for the cables primary parameters, depending on the definition format. Below an example of a cable definition is given

cable.name='BT_dwug';
cable.model='BT';
cable.param.r0c=179;
cable.param.r0s=0;
cable.param.ac=35.89e-3;
cable.param.as=0;
cable.param.l0=0.695e-3;
cable.param.loo=585e-6;
cable.param.b=1.2;
cable.param.fm=1e6;
cable.param.coo=55e-9;
cable.param.c0=1e-9;
cable.param.ce=0.1;
cable.param.g0=0.5e-9;
cable.param.ge=1.033;
clist=insertList(clist,cable);

As is can be seen from the example adding a specific cable to an existing clist can be most conveniently done by using the function insertList.

Traffic and topology definition ex.tt

The scenario used for the simulation run is described in the structure ex.tt (topology and traffic). When using a GUI all available scenarios can be stored in a traffic/topology list (typically gui.ttlist). Default scenarios are defined in src\xdsldefs, for example (fsan_loopsVDSL.m, etsi_loopsSDSL.m, ansi_loopsVDSL.m). For example the command

gui.ttlist = etsi_loopsVDSL([]);

would set up a list of scenarios (with respect to traffic and topology) which are defined within the function etsi_loopsVDSL.
For running a simulation for a specific scenario from this list the command

ex.tt = getList(gui.ttlist,scenario);

will set the ex.tt struct properly by using the function getList, assuming that the variable scenario contains the name (as a string) of the scenario to be considered in the simulation run.

Each traffic and topology structure consist of three fields:

ex.tt.name: The name of the scenario as a string.
ex.tt.topology: A list of lists (note that this is a change since version 2.3) where each inner list defines; (distance [meters], cable name, node name, line name or comment)
ex.tt.traffic: A list of lists (note that this is a change since version 2.3) where each inner list defines; (from node [referring to topology], to node [referring 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  'DTAG_40' 'N1' ''},...   % Distance, Cable, Node name, Line name
        {500  'DTAG_40' 'N2' ''},...
        {500  'DTAG_40' 'N3' ''},...
        {1500 'DTAG_40' 'C'  ''},...
        {500  'DTAG_40' 'N4' ''}...
        };
    tt.traffic={...
        {1 2 'VDSL' 3},...            % From node, to node, tfplan, no modems
        {1, 2, 'NP-ADSL', 4},...
        {1, 3, 'VDSL', 4},...
        {1, 4, 'NP-ISDN-2B1Q', 3},...
        {1, 4, 'NP-ADSL', 1},...
        {1, 5, 'NP-HDSL-1', 3},...
        {5, 6, 'VDSL', 3},...
        {5, 6, 'NP-ADSL', 4}...
        };
    ex.tt=tt;                             % Define the experiment tt structure
    gui.ttlist=insertList(gui.ttlist,tt); % Insert into list (used for GUI)

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' ''},...
    {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->'}...
    };

Simulation Output

The 'core' of the simulation tool is the routine evalExperiment. It computes the basic results from the given input parameters (contained in the structure ex) in terms of signals and noises at each node for the considered services. These results are stored in the result structure:

    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.param.modemlist. There are three substructures: Modem, NT, and LT.

Modem: tells the name, LT_Node number, and NT_Node number of the analyzed modem.
NT: gives the signal and the noise environment at the customer end.
LT: gives the signal and 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, which are not in the list of investigated services (ex.param.modemlist).

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, however but the downstream VDSL transmitter(s) can be switched off depending on the VDSL duplex method . 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.

Extended Calculations

Calculating the SNR

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

To Be Written

Getting bitrates and margins

By calling calcXDSLresult with the result structure result we get the bit rates and margins for each modem, e.g.,

[Rate_LT, Rate_NT, Margin_LT, Margin_NT]=calcXDSLresult(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 NT or LT 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 (time/frequency) plan,whereby the function input parameters are as follows:

tfplan tfplan struct for tfplan to be plotted
type type of frequency axis as a string ('log' or 'linear')
fax struct for frequency range to be displayed (fax.min, fax. max boundaries of displayed f-axis axis in Hz

plotTTstructure (tt, inScale);

Plots the TT (time and topology) structure, whereby the function input parameters are as follows:

tt tt struct of scenario to be plotted
inScale flag for indicating if the graph should be plotted in scale or not (1 = in scale).

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

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

Plots the resulting transmission curves,

ex experiment input parameter structure
result basic simulation output computed by evalExperiment.m
modemno number of the modem for which the result will be plotted ( to entry in ex.param.modemlist)
ftype type of frequency axis as a string ('log' or 'linear')
fax struct for frequency range to be displayed (fax.min, fax. max boundaries of displayed f-axis axis in Hz

Discussion/Conclusion

To Be written

References

FSAN - Full Service Access Network Initiative web page, VDSL initiative.

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.

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

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
2001-06-29 Version 2.2 (Now called xDSLsimu) Released
2002-03-18 Version 2.3 Released
2002-08-01 Version 2.3.2 Released
2003-12-23 Version 3.0 beta 1 Released (private)
2005-07-15 Version 3.1 beta 1 Released (private)
2007-01-18 Version 3.1 beta 2 Released (private)
2008-03-10 Version 3.1 Released (no change from beta 2)
2008-05-?? Version 3.2 Released

License

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; version 2 of the License.

When referring to this simulator (The FTW 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

Happy simulation, wish the main authors:

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

FTW
Donau-City-Strasse 1/3
AT-1220 Wien
Austria

Daniel Bengtsson (Daniel.Bengtsson@teliasonera.com)

TeliaSonera AB
Johan Willins Gata 6
SE-41664 Göteborg
Sweden