FSAN

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

Introduction

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 there has been a lot of groundbreaking 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

Installing the simulation tool

gzip -cd xDSLsimu_2.3.2.tar.gz | tar -xvf -

Running the simulation tool using the Graphical User Interface

To run this tool on unix:

To run on PC:

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

Using the tool

In general a simulation run is outlined as

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

Input Parameters

• 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

General Simulation Parameters  ex.param :

ex.param = setupParam;

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.

Lower boundary of  frequency axis (Hz) used for the evaluation.

Upper boundary of  frequency axis (Hz) used for the evaluation.

Granularity (Hz) in the frequency axis if fastrecalc is not used.

Frequency axis used for evaluation (derived from the settings of the preceeding parameters)

Background noise level to be used (dBm/Hz).

Reference near end crosstalk level at 1 MHz (dB)

Reference far end crosstalk level at 1 MHz (dB)

Reference crosstalk level for third circuit crosstalk at 1 MHz (dB)

Reference (loop terminating)  impedance for attenuation calculation (Ohms)

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.

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 :

% 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

ex.tfplist.name

Contains the modem names as strings. The first 4 letters must indicate the type of the xDSL modem (i.e.VDSL, ADSL, ...) and should be followed by characters which give a more specific description of the tfplan (e.g. 'VDSL-TDD-sym1:1', 'ADSL-overISDN', 'SDSL-asym', ....)

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.PBO.method

Connected to the tfplan is a power back off (PBO) method. The name of the PBO method is contained in this variable as a string. 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.

ex.tfplist.PSD.PBO.param.len

PBO parameter length (m); needed for PBO methods 'RefLen' and 'RefFEXT'.

ex.tfplist.PSD.PBO.param.freq

PBO parameter frequency (Hz) ;  needed for PBO method  'RefFreq'.

ex.tfplist.PSD.PBO.param.maxlen

For PBO method 'RefFreq'  a maximum length can  also be given.

ex.tfplist.PSD.HAM.active

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

ex.tfplist.timeDivision.up and 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.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);

List of linecode definitions  ex.lclist:

ex.lclist = setupLClist;

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 fplan 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 calcFSANResult  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).

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=     4.2 dB
ex.lclist.param.SNRloss=        0.0 dB
ex.lclist.param.efficiencyLoss= 0.0 dB
ex.lclist.param.SNRmax=        48.0 dB
ex.lclist.param.Px=            11.5 dBm   (Transmit Power)
ex.lclist.calcRate= 'calcResultTheo'
ex.lclist.lcPrint= 'lcPrintTheo'

List of cables  ex.clist:

ex.clist = etsi_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 organised 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='DTAG_50';

cable.model='DTAG';
cable.param.Ka1=[4.2 0.7 10.3];
cable.param.Ka2=[11.9 14.1 7.7];
cable.param.Ka3=[0.92 0.52 0.68];
cable.param.Kb1=30.6;
cable.param.Kb2=1.62;
cable.param.Kz1=141;
cable.param.Kz2=3.4;
cable.param.Kz3=0.69;
cable.param.Kx1=0.038;
cable.param.Kx2=0.0082;
cable.param.Kx3=0.73;
ex.clist=insertList(ex.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

gui.ttlist  = fsan_loops([]);

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

Each traffic and topology structure consist of three fields:

ex.tt.name

The name of the scenario as a string.

ex.tt.topology

A vector of cell arrays where each cell array defines

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

ex.tt.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}

% 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)

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 '' '' ''};

    ];

Simulation Output

 
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

• Modem: tells the name, LT_Node number, and NT_Node number of the analysed 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.

• 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).

• 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 Be Written
 

Getting bitrates and margines

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

Graphical Output

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

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

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

References

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.

Revision History

Licence

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

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

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, wish the main authors:

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

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