ASSET3g Technical Reference Guide

ASSET3g Technical Reference Guide

Version 5.0.2

© Copyright 2005 AIRCOM International Ltd All rights reserved

ADVANTAGE, AIRCOM, ARRAY WIZARD, ASSET3g, CONNECT, DATASAFE, ENTERPRISE, NEPTUNE, OPTIMA, QUALITA, RANOPT, TARGET and WEBWIZARD are recognised trademarks of AIRCOM International.

Microsoft Word, Microsoft Office, Windows®, Windows 95™, Windows 98™, Windows NT®, Windows XP® and MS-DOS™ are trademarks of the Microsoft Corporation.

Other product names are trademarks of their respective companies.

This documentation is protected by copyright and contains proprietary and confidential information. No part of the contents of this documentation may be disclosed, used or reproduced in any form, or by any means, without the prior written consent of AIRCOM International.

Although AIRCOM International has collated this documentation to reflect the features and capabilities supported in the software products, the company makes no warranty or representation, either expressed or implied, about this documentation, its quality or fitness for particular customer purpose. Users are solely responsible for the proper use of ENTERPRISE software and the application of the results obtained.

An electronic version of this document exists on our website.

This User Reference Guide finalised on 11 May 2005.

Refer to the Online Help for more information.

This User Reference Guide prepared by:

AIRCOM International Ltd Grosvenor House 65-71 London Road Redhill Surrey RH1 1LQ ENGLAND

Telephone: +44 (0) 1737 775700 Support Hotline: +44 (0) 1737 775777 Fax: +44 (0) 1737 775770 Web: http://www.aircom.co.uk

Can You Improve Our User Assistance?

Do the Help and User Reference Guides Help You? AIRCOM is always working to improve the online Help and User Reference Guides for our products, so that your job is easier to do.

Even if you would not normally do so, please take a look at the Help or User Reference Guide next time you are unsure of how to do something and if you have any comments or questions that could help us improve them, please email us on: [email protected].

We highly value your comments, suggestions, and criticisms. If you did not find the user assistance you were looking for, needed more assistance than the online help or user reference guides provided, or have any suggestions for future improvements to our information, we want to know.

Specifically, consider:

• Is the information accurate and complete?

• Is the information helpful – does it answer your question about the program ?

• Are there any words that you would like to be put into the index ?

♦ ♦ ♦

ASSET3g Technical Reference Guide Page i Version 5.0.2

Contents Appendix A 2g and 2.5g Algorithms

Interference Table Algorithm 5 Interference and Connection Array Calculations 6

Worst Connection Array Calculation Method 7 Average Connection Array Calculation Method 8 Worst Interferer Array Calculation Method 8 Total Interference Array Calculation Method 9 Table of Default C/I BER Conversion Values 9

Frequency Hopping Algorithms 10 Synthesised Hopping Algorithm 12

Non-Frequency Hopping Algorithms 12 Automatic Frequency Planning (ILSA) 13

The Cost Function of the ILSA Algorithm 14 MAIO Planning Cost Function 14 GPRS and HSCSD Capacity Calculations 15

TRX Requirement - Circuit Switched Traffic and HSCSD 15 TRX Requirement - Circuit Switched, HSCSD and GPRS Traffic 15 Grade of Service and Data Rate 16 Channel Occupation Table 17

FCC Calculations 18 Frequency Calculations 20

Appendix B UMTS Algorithms Notation for UMTS 23 List of Principal Symbols for UMTS 24 UMTS Basic Formulae 26 UMTS Uplink Noise Rise 27 UMTS Uplink Load 27 UMTS Frequency Re-Use Efficiency 27 UMTS Air Interface and User Bitrates 27 UMTS Shadow Fade Modelling 28 UMTS Power Control Error Modelling 29 UMTS Service Activity Modelling 29 UMTS Activity Factor Calculation For Packet Services (Web Model) 30 UMTS Transmit/Receive Diversity Modelling 31 UMTS Terminal Speed Modelling 31 UMTS Overview of a Snapshot 32

UMTS Initialisation of Terminals 32 Initialisation of System Powers and Resource Usage in UMTS 32

Page ii ASSET3g Technical Reference Guide Version 5.0.2

UMTS Iterations 33 Gathering of Results in UMTS 34

UMTS Scenario Prioritisation 34 UMTS Connection Evaluation 35

Production of a Candidate Active Set in UMTS 35 Uplink Evaluation for UMTS 36 Downlink Evaluation for UMTS 38

UMTS Blocking Probability 39 Calculation of Blocking Probability in the Blocking Report for UMTS 39 Blocking Probability and Failure Rate for UMTS 40 UMTS Coverage Probability Array in the Map View 41

Appendix C CDMA2000 Algorithms CDMA2000 Notation 44 List of Principal Symbols for CDMA2000 44 CDMA2000 Basic Formulae 46 CDMA2000 Uplink Noise Rise 47 CDMA2000 Uplink Load 47 CDMA2000 Frequency Re-Use Efficiency 47 CDMA2000 Air Interface and User Bitrates 47 CDMA2000 Shadow Fade Modelling 48 CDMA2000 Power Control Error Modelling 49 CDMA2000 Service Activity Modelling 49 CDMA2000 Activity Factor Calculation For Packet Services (Web Model) 50 CDMA2000 Transmit/Receive Diversity Modelling 51 CDMA2000 Terminal Speed Modelling 51 PN Code Assignment Algorithm for CDMA2000 51

Difficulty Factor for CDMA2000 51 Best PN Code to Assign for CDMA2000 52 Quality Factor for CDMA2000 52

CDMA2000 Overview of a Snapshot 53 CDMA2000 Initialisation of Terminals 53 Initialisation of System Powers and Resource Usage in CDMA2000 53 CDMA2000 Iterations 54 Gathering Of Results in CDMA2000 55

CDMA2000 Scenario Prioritisation 55 CDMA2000 Connection Evaluation 56

Production of a Candidate Active Set in CDMA2000 56 CDMA2000 Uplink Evaluation 57 CDMA2000 Downlink Evaluation 59

Calculation of Equivalent Control Overhead Factors for CDMA2000 60 Uplink RC1 - RC2 61 Uplink RC3 - RC6 When Using a Supplemental Bearer 62 Uplink RC3 - RC6 When Not Using a Supplemental Bearer 63 Downlink RC1 - RC2 64 Downlink RC3 - RC10 65

ASSET3g Technical Reference Guide Page iii Version 5.0.2

CDMA2000 Blocking Probability 66 Calculation of Blocking Probability in the Blocking Report for CDMA2000 66 CDMA2000 Blocking Probability and Failure Rate 66 CDMA2000 Coverage Probability Array in the Map View Window 67

Appendix D HDR Algorithms69 HDR Notation 69 List of Principal Symbols for HDR 70 HDR Basic Formulae 71 HDR Uplink Noise Rise 72 HDR Uplink Load 72 HDR Frequency Re-Use Efficiency 72 HDR Air Interface and User Bitrates 73 HDR Shadow Fade Modelling 73 HDR Power Control Error Modelling 74 HDR Service Activity Modelling 74 HDR Transmit/Receive Diversity Modelling 74 HDR Terminal Speed Modelling 75 Overview of a HDR Snapshot 75

HDR Initialisation of Terminals 76 HDR Initialisation of System Powers 76 HDR Iterations 76 Gathering of Results for HDR 78

Scenario Prioritisation for HDR 78 HDR Connection Evaluation 78

HDR Downlink Evaluation 79 HDR Uplink Evaluation 79

Calculation of Uplink Equivalent Control Overhead Factor for HDR 81 HDR Coverage Probability and Blocking 82

HDR Coverage Probability Array in the Map View Window 82 HDR Blocking Probability and Failure Rate 82

About the HDR Quality of Service Algorithm 83 HDR Outline 84 IP Packet Transmission Time for HDR 84 IP Packet Queueing Delay for HDR 85 Throughput for HDR 87

Appendix E Packet Quality of Service Algorithms Simulation Inputs for QoS Analysis 90

Preliminary Tests 90 Traffic Generator for QoS Analysis 90

Matching Generated Traffic to Monte Carlo's Mean Number of Served Users 91 WWW Traffic Model 92 Packet Model 93 About the Code Schemes for GPRS 94 QoS Profiles for GPRS 94

Page iv ASSET3g Technical Reference Guide Version 5.0.2

Time Simulator for QoS Analysis 97 Results of QoS Analysis 99

References 103

Appendix F ASSET3g File Formats Simulation Array File Formats 105

3ga File Format 106 Live Traffic File Formats for 2g Networks 108

NMS File Format 108 GSM File Format 108 TPS File Format 109

Live Traffic File Formats for 3g Networks 109 About the *.tpc File Format 109 About the Bearer Traffic File Formats (*.cbc / *.cbd) 110

Index

ASSET3g Technical Reference Guide Page 5 Version 5.0.2

2g and 2.5g Algorithms

This chapter describes the following topics:

In This Section Interference Table Algorithm Interference and Connection Array Calculations Frequency Hopping Algorithms Non-Frequency Hopping Algorithms Automatic Frequency Planning (ILSA) MAIO Planning Cost Function GPRS and HSCSD Capacity Calculations FCC Calculations Frequency Calculations

Interference Table Algorithm The Interference Table stores the following four values for any pair of sub-cells A and B. These relate to the region where A is the best server.

Field Name Description Co-channel Traffic The amount of traffic served by cell A that would be affected by interference if A

and B were to be assigned the same carrier.

Co-channel Area The area served by cell A that would be affected by interference if A and B were to be assigned the same carrier.

Adjacent Channel Traffic The amount of traffic served by cell A that would be affected by interference if A and B were to be assigned adjacent carriers.

Adjacent Channel Area The area served by cell A that would be affected by interference if A and B were to be assigned adjacent carriers.

The values for area are obtained by averaging the probability of interference over the region where A is the best server. The average is taken over all pixels in the appropriate coverage array.

For traffic, the value to be averaged is the probability of interference x the traffic (in mE) at that pixel. Thus it is necessary to have a traffic raster available to make this calculation.

A P P E N D I X A

Page 6 ASSET3g Technical Reference Guide Version 5.0.2

The probability of interference at a given pixel is calculated using a standard statistical technique based on a C/I signal threshold value and a standard deviation. The assumption is that a difference in signal level between server and interferer exactly equal to the threshold value would give rise to a 50% chance of co-channel interference. For more information on how these values can be specified, see About the Interference Table Needed for ILSA.

By default, a -18dB offset is used for the adjacent channel interference, relative to the co-channel interference. This means that if, for example, the co-channel C/I threshold value is set at 9dB, a signal difference of -9dB between server and adjacent channel interferer would give rise to a 50% chance of adjacent channel interference. The C/A offset can be modified in the Array Settings dialog box.

All signal differences are converted into probabilities of interference. This graph displays the spread of probabilities for both C/I and C/A based on the default Interference Weights. Here, the C/I signal threshold value is 9 dB, using a standard deviation of 7.78dB.

C/I and C/A weights curve

Note : An example of an Interference Table can be found, along with a description of its File Format, in the Appendix of the ENTERPRISE User Reference Guide.

Interference and Connection Array Calculations This table shows the different interference analyses that are possible:

Field Name Description Worst Connection C/Ic Determines the co-channel C/I levels for all of the possible interfering

frequencies that may be used by the MS-BTS connection.

Each pixel presents the worst C/Ic level and frequency.

Worst Connection C/Ia Determines the adjacent channel C/I levels for all of the possible interfering frequencies that may be used by the MS-BTS connection.

Each pixel presents the worst C/Ia level and frequency.

Worst Connection C/(Ic+Ia) Determines the combined co-channel/adjacent channel C/I levels for all of the possible interfering frequencies that may be used by the MS-BTS connection.

Each pixel presents the worst C/I level and frequency.


Average Interference C/Ic Sums the co-channel C/I levels for all possible interfering frequencies and presents the average C/Ic level.

Average Interference C/Ia Sums the adjacent channel C/I levels for all possible interfering frequencies and presents the average C/Ia level.

Average Interference C/(Ic_Ia) Sums the combined co-channel and adjacent C/I levels for all possible interfering frequencies and presents the average C/(Ic_Ia) level.

Worst Interference C/Ic For non-frequency hopping networks sums all of the co-channel C/I levels for an interfering frequency.

Each pixel presents the total C/I level, server and interfering sub-cells and interfering frequency.

Worst Interference C/Ia For non-frequency hopping networks sums all of the adjacent channel C/I levels for an interfering frequency.

Each pixel presents the total C/I level, server and interfering sub-cells and interfering frequency.

Note : The worst connection and the worst interferer calculations are the same in the case of a non-frequency hopping network.

Worst Connection Array Calculation Method In the Worst Connection Array calculation, the connection refers to the carrier(s) corresponding to a single call:

• In the case of hopping frequencies, it corresponds to the entire group of hopping frequencies

• In the case of non-hopping frequencies, it corresponds to a single frequency

The Worst Connection Array calculates the C/I per connection, summing over all interferers, and then selects the connection with the lowest C/I.

The algorithm for this is as follows:

Where:

For each non-hopping carrier fi in the serving sub-cell, C/I(fi) is calculated.

For the hopping frequency group in the serving sub-cell, a single C/I(FH) is calculated.


Average Connection Array Calculation Method The Average Connection Array calculates the C/I per connection, summing over all interferers, and then calculates the average of those.

The algorithm for this is as follows:

(2)

Where:

is the averaged C/I for the hopping carriers.

is the number of hopping frequencies.

is the number of non-hopping frequencies.

is frequency Diversity Gain

is the fractional loading, calculated as follows:

, where is the number of hopping TRX

are the non-hopping frequencies

For each non-hopping carrier fri in the serving sub-cell, C/I(fri) is calculated.

For the hopping frequency group in the serving sub-cell, a single C/I(FH) is calculated.

Note : The denominator in the equation above can never be zero ( and cannot both be 0 at the same time). This is because ASSET3g does not allow you to set the total number of TRX allocated to a sub-cell to zero, if at least one carrier layer is allocated.

Worst Interferer Array Calculation Method The Worst Interferer Array calculates the C/I per frequency, summing over all interferers, and selects the frequency with the lowest C/I. It also finds the interferer that causes the most interference on that frequency.

Note : This array does not take into account fractional loading.

The most interfered frequency and its corresponding C/I are calculated as follows:

If , then

If , then


Where:

For each (non-hopping) carrier f1 in the serving sub-cell, C/I(f1) is calculated.

The worst interferer is calculated as follows:

Total Interference Array Calculation Method The Total Interference Array calculates the C/I per frequency, summing over all interferers, and then sums the C/I for each frequency at the serving cell.

Note : This array does not take into account fractional loading.

The total interference is calculated as follows:

Where:

For each (non-hopping) carrier fi in the serving sub-cell, C/I(fi) is calculated.

Table of Default C/I BER Conversion Values This table shows the Default C/I BER Conversion Values in ASSET3g:

C/I (dB) Bit Error Rate -10 0.5000000000

-9 0.4880000000

-8 0.4650000000

-7 0.4300000000

-6 0.3880000000

-5 0.3500000000

-4 0.3200000000

-3 0.3000000000

-2 0.2700000000

-1 0.2500000000

0 0.2200000000

1 0.2000000000

2 0.1700000000

3 0.1500000000

4 0.1200000000

5 0.1000000000

6 0.0900000000

7 0.0780000000

8 0.0660000000

9 0.0550000000


10 0.0450000000

11 0.0370000000

12 0.0300000000

13 0.0260000000

14 0.0200000000

15 0.0150000000

16 0.0120000000

17 0.0080000000

18 0.0060000000

19 0.0040000000

20 0.0020000000

21 0.0007000000

22 0.0001000000

23 0.0000070000

24 0.0000004000

25 0.0000000100

26 0.0000000001

27-45 0.0000000000

Frequency Hopping Algorithms The algorithms used for frequency hopping cells are as follows:

1 is used if , α is used if , 0 is used otherwise

Where: C/I(i) = C/I ratio for frequency i

SSC(i) = Signal strength from frequency i for serving cell

i,j = A particular frequency

N = Number of interfering cells

n = Number of frequencies in serving cell

m = Number of frequencies in interfering cell K


SIC(K,i) = Signal strength from frequency i for interfering cell K

K = Interfering cell

L(K,j) = Load in interfering cell K on frequency j

V(K,j) = DTX factor in interfering cell K on frequency j

f (i) = Fractional loading for frequency i for interfering cell

α = Adjacent interference factor

Each C/I(i) is converted to a Bit Error Rate, BER(i)

This graph shows the relationship between the Probability of Bit Error and the C/I:

BERAV(serving cell) is calculated as the average BER(i) for all frequencies in the cell:

Where:

x Number of FH frequencies per TRX

mFH Number of FH frequencies/serving cell

nTRX Number of TRX/serving cell

BERAV(serving cell) is then converted back to dB to give C/I (FH)(serving cell).


Important : If frequency diversity gain GFDIV(m) is enabled, you also need to add a given gain figure to the hopping C/I. For more information on this, see Defining Frequency Hopping Gain.

Synthesised Hopping Algorithm For synthesised hopping carrier layers, fractional loading is calculated as follows:

Where:

is the number of TRX allocated to the hopping carrier layers

is the number of hopping carriers

Non-Frequency Hopping Algorithms The calculations for non-frequency hopping are as follows:

1 is used if , α is used if , 0 is used otherwise

P(i) = f(C/I(i))

P(i) is the Probability of interference, and is calculated from the cumulative normal distribution of combined standard deviation of serving and interfering cell models.

and

PTOT = Average of all P(i) in the cell


This picture shows an example conversion curve:

Example C/I/Probability Curve

Automatic Frequency Planning (ILSA) The frequency planner uses an Intelligent Local Search Algorithm (ILSA) to search for an optimum or zero cost plan using the latest ideas from Combinatorial Optimisation Theory.

The interference in the network is measured by the value in the Cost of Current Plan field. Typically, this decreases very rapidly during the early part of the process. Thereafter, the average rate of decrease will be less and decreases will be more sporadic. In fact the cost is often stationary for a while before undergoing another stage of rapid decrease.

ILSA pays special attention to areas of high cost within the network (analogous to areas of high interference), temporarily ignoring lower cost areas. This allows ILSA to make very rapid initial progress. For example, if ILSA is attempting to plan for a network requiring 60 carrier allocations, with 20 available carriers, and identifies a sub-set of 10 high cost carrier allocations, then the maximum number of new states that ILSA needs to consider has been reduced from 3.8*1025 to 6.1*1012.

The algorithm monitors its own progress and will behave differently depending on how quickly the cost is decreasing at a given time. This intelligent behaviour enables it to continue finding improvements over long periods of time.

At the heart of the algorithm is a random process, so if the algorithm is run twice for a given period of time on a particular network the end results may differ by a few percent. Thus it may be worth running the algorithm more than once.


The Cost Function of the ILSA Algorithm The principle behind the algorithm used in the frequency planning tool is that the effectiveness of any particular frequency plan is measured by a single number (the cost). The algorithm then tries to minimise the cost over the set of all possible frequency plans. The cost function measures how much interference there is in the network, and also allows for the different weights that you may have imposed.

For a given frequency plan the value of the cost function is given by the formula:

Where:

= The adjacent channel interference caused on allocation i by allocation j (Units: 200*mE or 20,000*km2)

= The co-channel interference caused on allocation i by allocation j (Units: 200*mE or 20,000*km2)

= The frequency allocated at allocation i

= Members of the set of all frequency allocations

= The retune cost associated with allocation i

= The fixed or forbidden carrier cost associated with allocation i

= The separation costs (from equipment, neighbours, exceptions or close separations) between

allocations i and j

= The handover count and intermodulation interference costs associated with allocation i

= The weighting factor applicable to carrier allocation i

MAIO Planning Cost Function The cost function for MAIO planning is an aggregate of C/I and C/A separation counts generated by per cell pair frequency combinations, based on MAIO step and offset values, and weighted by the interference matrix. It has the following form:

Where:

are sub-cells

and are traffic and area percentages


and are traffic and area associated with sub-cell c

and are interference matrix coefficients

is the C/I or C/A separation count for all TRX combinations on sub-cells

GPRS and HSCSD Capacity Calculations This sectiondescribes GPRS and HSCSD capacity calculations, as follows:

• TRX Requirement - Circuit Switched Traffic and HSCSD

• TRX Requirement -Circuit Switched, HSCSD and GPRS Traffic

• Grade of Service and Data Rate

• Channel Occupation Table

TRX Requirement - Circuit Switched Traffic and HSCSD

The number of TS required ( ) for the CS traffic load ( ) given specified two Grade of Services and a choice of Erlang table.

The number of TRX required is determined using the Channel to Transceiver Map by

increasing the number of TRX from 1 until the map’s is equal to or greater than

and is greater than or equal to .

TRX Requirement - Circuit Switched, HSCSD and GPRS Traffic For cells where GPRS is enabled, the number of TS required from the shared traffic

channels for the GPRS ( ) traffic load ( ) can be determined using the

average GPRS data rate per TS ( ):

The total number of TS required for CS and GPRS traffic ( ) can then be

determined using the average Circuit Switched TS requirement and the channel occupation efficiency (e) as follows:


Where:

is total shared traffic channels required

is average (long term) number of TS required for Circuit Switched traffic (= )

is average (long term) number of TS required for HSCSD traffic (= )

The channel occupation efficiency (e) is determined by first calculating

( ) without dividing by e and then using the result to look up e in the Channel Occupation table.

The number of TRX required and are determined using the channel to transceiver map by increasing the number of TRX from the result of the previous section until the number of available TS for traffic (NCS allocation) is equal to or

greater than .

Grade of Service and Data Rate

Circuit Switched Traffic

This section presents the calculation for the blocking for the current allocation of TRX for CS and for each HSCSD multi-slot type traffic (%). It has been assumed throughout that CS traffic and HSCSD traffic will take precedence over GPRS traffic and therefore the Grade of Service for CS and HSCSD will not be affected by the GPRS load.

Calculate the blocking for the CS traffic given the traffic load ( ) the current allocation of TRX using the selected Erlang table.

HSCSD Blocking

Blocking is calculated from Erlang B or C using the number of HSCSD TS currently allocated to the cell and the HSCSD load in timeslot Erlangs.

= HSCSD traffic load

=timeslots allocated to CS

= number of CS timeslots that may be allocated to HSCSD

Erl = Erlang B or C functions returning blocking given traffic and channels


Summary blocking is the average of the four separate blocking values weighted by the known distribution.

GPRS Data Rate

The GPRS data rate for the current allocation of TRX is determined by first calculating the number of TS required for CS and HSCSD. The remaining TS are available for GPRS. That is:

Where: e is the efficiency from the Channel Occupation table determined from N

is the number of TS from the Channel Carrier Map for the current allocation of TRX

Channel Occupation Table A table similar to that shown below is used to relate the number of timeslots available to the channel occupancy for GPRS capacity calculations.


The table is stored in the database and you can edit the occupancy values.

Example of Channel Occupation Table, for Illustrative Purposes Only

FCC Calculations This section describes the algorithms used to calculate the data provided in the FCC report.

Antenna Height AAT

The Antenna Height AAT is calculated in metres.

The calculation is:

Antenna height + Site ground height + Radial average terrain elevation

The Radial average terrain elevation is the average ground height mapped along a radial of between 3 km and 16 km from the site. If the mapping data prevent this then it will not be calculated and this will be flagged in the FCC report.

Note : Feature height data and clutter heights are ignored in the calculation.

The best available resolution of the map data is used for this calculation. If the best map data is 1000 m resolution then you will receive a warning noting that the map data is of insufficient resolution for the FCC form.


Used Antenna Height

The Used Antenna Height AAT (metre) is subject to some minimum values according to the FCC category and, the ERP. Category ERP (if necessary) Minimum 32dBu Served N/A Minimum of 30 metres

32dBu Unserved ERP>=10 W

ERP<=10 W

Minimum of 30 metres

Minimum of 3 metres

Gulf of Mexico N/A Minimum of 8 metres

Note : You will receive a warning if the Average Radial distance exceeds 40.2 km (79.1 km for Gulf of Mexico cells).

Transmitting ERP Watts

The transmitting ERP for a cardinal radial is the radiated power in Watts taking into account the antenna gain for the azimuth, the down tilt and the base station powers/losses.

Note : You will receive a warning if the ERP exceeds 500W.

Used ERPS

This is the value of the transmitting ERP which is used in the calculations, it is the Transmitting ERP subject to certain minima.

Used ERP is the maximum of:

• 0.1 W

• Maximum ERP/500

• Transmitting ERP for the radial

Area within the Service Area Boundary

This will be calculated by finding the distance to the SAB for each degree by linear interpolation of distance as a function of angle, hence dividing the area into triangular sectors, joining at the site. The total area is then calculated by adding up the areas of each of the triangles.

Heron's Formula for calculation of area of scalene triangle:

A = SQR(S (S-a) (S-b) (S-c))

SQR - Square Root

a, b, c – sides of the triangle

S – half the perimeter of triangle, that is (a+b+c)/2


Distance to Service Area Boundary

The distance to the SAB is calculated as shown here: For: The distance to the SAB is: 32dBu Served

and

32 dBu Unserved

D = 2.531 x Used Antenna Height(m) ^ 0.34 x Used ERP for Radial in Watts ^ 0.17

Subject to a minimum distance of 5.4 km

Gulf of Mexico D = 6.895 x Used Antenna Height(m) ^ 0.30 x Used ERP for Radial (W) ^ 0.15

There is no minimum distance for this SAB

Frequency Calculations Two frequency calculations are used when you create a Frequency Plan report.

Effective Frequency Re-use

The effective frequency re-use is an approximate indication of the quality of the hopping network.

It can be calculated for each subcell and also the average of these calculated to give a figure for the network as a whole.

Where:

REFF is the Effective Frequency Re-use for a subcell

NF is the total number of carriers available to hopping TRX on the subcell (note: this is not the MA list length)

NTRX is the number of hopping TRX on the subcell

Frequency Load

The average frequency load is another approximate indication of the quality of the hopping network.

It can be calculated for each subcell and also the average of these calculated to give a figure for the network as a whole.

Where:

LFREQ is the Frequency Load of a subcell


LFRACTION is the Fractional Load of a subcell

LHW is the Hardware Load of a subcell

NTRX is the number of hopping TRX on the subcell

NMA is the MA list length (i.e. all carriers assigned to hopping carrier layers on the subcell)

E is the traffic that could be carried by the timeslots of hopping TRX on the subcell, at

a user specified Grade of Service (GoS), i.e.

NCSTS is the total number of timeslots installed – this value is derived from the Carrier to Timeslot map using NTRX.



UMTS Algorithms This chapter describes the following topics:

In This Section Notation for UMTS List of Principal Symbols for UMTS UMTS Basic Formulae UMTS Uplink Noise Rise UMTS Uplink Load UMTS Frequency Re-Use Efficiency UMTS Air Interface and User Bitrates UMTS Shadow Fade Modelling UMTS Power Control Error Modelling UMTS Service Activity Modelling UMTS Activity Factor Calculation For Packet Services (Web Model) UMTS Transmit/Receive Diversity Modelling UMTS Terminal Speed Modelling UMTS Overview of a Snapshot UMTS Scenario Prioritisation UMTS Connection Evaluation UMTS Blocking Probability

Notation for UMTS This list describes the notation symbols used in this section:

• A Greek subscript always indexes a carrier

• indicates a sum over all carriers

• An uppercase Roman subscript always indexes a cell

• indicates a sum over all cells

• A lowercase Roman subscript always indexes a terminal

• indicates a sum over all terminals

A P P E N D I X B


• indicates a sum over all terminals in cell J

• Up and down arrows indicate if a quantity is uplink or downlink

• All quantities are in standard SI units, never in dB

As an example. The quantity represents the for the uplink between terminal j and cell K using carrier α.

List of Principal Symbols for UMTS This table describes the list of principal symbols for UMTS:

Symbol Description

, Uplink (downlink) adjacent carrier inteference ratio. Gives fractional power leakage from

carrier β to carrier α. ( )

Uplink

Downlink

Pilot

Uplink (downlink) processing gain

Cell antenna gain

Terminal antenna gain

Mast head amplifier gain

Boltzmann constant

Mast head amplifier (downlink) insertion loss

Uplink (downlink) linkloss between cell and terminal

Pathloss between cell and terminal

Antenna masking loss

Cable (feeder) loss

Terminal body loss

Thermal noise at terminal

Thermal noise at cell


Terminal TX power

Cell pilot channel TX power

Cell common channel TX power

Cell synchronisation channel TX power

Downlink traffic channel TX power

Total output TX power of cell

Total received power at terminal

Total received power at cell

Pilot SIR

Temperature

Chip rate

Uplink (downlink) service activity factor

Uplink (downlink) bearer control-overhead factor

Cell orthogonality factor

Terminal noise figure

Base station noise figure

Mast head amplifier noise figure

Cable (feeder) noise figure ( = )


UMTS Basic Formulae The following formulae give the basic relations between link powers and noise. Handover gains, power control headroom, and power rise gain have been ignored.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)


UMTS Uplink Noise Rise Uplink noise rise (on a cell) is the total received power divided by the background noise. The noise rise on carrier α of cell J is given by:

(12)

This is expressed in dB in the Cell Uplink Report.

UMTS Uplink Load Uplink load (on a cell) is the total received power coming from all terminals divided by the total received power. The cell load on carrier α of cell J is given by

(13)

This is expressed as a percentage in the Cell Uplink Report.

UMTS Frequency Re-Use Efficiency Frequency re-use efficiency (on a cell) is the total received power coming from in-cell terminals divided by the total received power coming from all terminals. The frequency re-use efficiency on carrier α of cell J is given by

(14)

This is expressed as a percentage in the Cell Uplink Report.

UMTS Air Interface and User Bitrates For a UMTS network, the Air Interface Bitrate is used in the calculation of processing

gain. The processing gain ( , ) is calculated by dividing the system chiprate by the air interface bitrate.

The User Bitrate is used purely to calculate traffic (data throughput) on a cell.


UMTS Shadow Fade Modelling This section describes the shadow fade modelling that is used for UMTS.

Shadow fading is modelled in the simulator by applying random offsets to the pathlosses experienced by each of the terminals in a snapshot. Shadow fades are log-normally distributed, and you may specify the standard deviation of shadow fading for indoor and outdoor terminals in each clutter type. In reality, the fades between a terminal and the cells that cover it will exhibit a degree of correlation. In particular, a terminal is likely to have similar fades to cells that are located on the same site.

In order to model this in the simulator, you must specify two parameters in the Monte Carlo Wizard:

• The normalised inter-site correlation coefficient ( ). This is the correlation between fades from a terminal to cells on different sites.

• The normalised intra-site correlation coefficient ( ). This is the correlation between fades from a terminal to cells on the same site.

These two parameters must satisfy the constraints .

For each terminal in a snapshot, a set of correlated fades to cells is generated using the following procedure.

Note : All the random numbers mentioned below are independent and normally distributed with zero mean and unit variance.

1 Generate a random number X

2 For each site I, generate a random number

3 For each cell J, generate a random number

4 The fade (in dB) to cell J on site I is then set to:

(15)

where is the standard deviation of the shadow fading at the pixel (in dB).

The above procedure is performed whenever a terminal is initialised at the beginning of a snapshot. Fades for different terminals are uncorrelated, even if the terminals are located in the same pixel.


UMTS Power Control Error Modelling This section describes the power control error modelling for a UMTS network.

The simulator does not explicitly model the power control process, but it allows the simulation results to exhibit certain features one would associate with imperfect power control.

The standard deviation of power control error parameter controls the distribution of achieved values for successfully served terminals. If the standard deviation is set to

zero, the value for each successfully served terminal is achieved perfectly (ignoring quantisation and any lower limit on the link power). In a real system this is not the case since imperfect power control produces a (log-normal) distribution of achieved values at a cell.

The simulator models imperfect power control by including a log-normal error on the uplink and downlink transmit powers of successfully served terminals. The errors on the uplink and downlink are uncorrelated, and are applied after all other handover gains and margins have been considered. Terminals are never considered as having failed to make a connection if the resulting error makes them transmit at too high or too low a power.

UMTS Service Activity Modelling The UMTS service activity affects three areas of the simulation.

Consumption of Resources

A successfully served circuit switched service will consume the same number of resources regardless of the service activity factor. The number of resources in this case depends only on the bearer used.

A successfully served packet switched service will consume a partial number of resources depending on the service activity factor. For example, if a PS service is served using a bearer that requires 2 resources and the activity factor is 1%, then 0.02 resources will be consumed.

Calculation of Throughput

The throughput of a successfully served service is calculated by multiplying the data rate of the bearer used, by the service activity factor.

Calculation of Interference

Equations

( ) trafficJj

jjj

syncJ

commonJ

pilotJ

totalJ PPPPP ααααα βα∑ ↓↓ +++++=

(9)


(10)

(11)

all have a dependence on or .

UMTS Activity Factor Calculation For Packet Services (Web Model)

Using the same notation as given in the WWW traffic model, the activity factor formula is:

Where:

= Average packet time period (s)

= Size of a Packet (bytes)

= the Max Bit Rate the particular service supports (bit/s)

= Average session time period (s)

= Number of packet calls per session

= Reading time between packet calls (s)

= Number of packets within a packet call

= Inter arrival time between packets in a packet call (s)

= Retransmission factor (%)


UMTS Transmit/Receive Diversity Modelling You can indicate if a cell has an antenna system providing transmit or receive diversity by ticking the appropriate check boxes in the Site Database. Transmit

(receive) diversity on a cell effectively reduces the requirement on the downlink (uplink). When defining a service, you must specify two requirements for the downlink (uplink). One requirement is used on cells with transmit (receive) diversity and the other is used on cells without transmit (receive) diversity.

UMTS Terminal Speed Modelling Handover gains are speed-dependent, and so each terminal in the simulation is given a random speed. For each terminal type and clutter type, you must specify four

parameters that determine the speed distribution. These are the mean speed ( ),

the standard deviation of the speed distribution ( ), the minimum speed ( )

and the maximum speed ( ). A random speed is then given by:

(16)

where is a random number taken from a normal distribution of zero mean and unit variance.


UMTS Overview of a Snapshot This section gives an overview of a UMTS snapshot:

The aim of a snapshot is to produce a plausible picture of the network at a particular instant in time. This picture will typically consist of a set of successfully served terminals and their states, that is the link powers and handover state, and a set of unserved terminals and their reasons for failure. Many snapshots must be performed and the results from them averaged in order to produce an overall picture of network behaviour. A snapshot involves the stages outlined in the following diagram:

Initialisation of Terminals

Initialisation of System Powers and Resource Usage

Perform Iterations Until Convergence Achieved

Gathering of Results

UMTS Initialisation of Terminals The first stage of a snapshot involves creating a geographical distribution of terminals attempting to connect to the network. Each pixel is allocated a random, Poisson-distributed, number of terminals, according to the mean number of terminals specified for the pixel in the terminal-density array. Also during this initialisation stage, each terminal is given a set of random log-normal fades, one for each cell that covers it, that is it has a pathloss to it. A random “power control error” is chosen for the uplink and downlink. A terminal will use the same random values (fading, power control error, speed) for the duration of its existence in a snapshot.

After all the terminals have been created, they are given a random ordering which sets the sequence in which they will be considered during an iteration.

Initialisation of System Powers and Resource Usage in UMTS Before commencing the iterative process, the system is placed in a known state, namely the state of an unloaded network. This is simply done by setting all link powers to zero, and making all resources available at the cells.


UMTS Iterations An iteration involves sequentially evaluating the terminals (precisely once) to see if they can make a connection to the network. After each terminal is evaluated, the noise in the network (at cells and terminals) is updated before moving on to evaluate the next terminal.

A terminal may connect to the network in a variety of different ways (connection scenarios). For example a terminal may have several different cells or carriers that it may use. Each of the connection scenarios for a terminal is evaluated in turn until one that allows a successful connection is found. If no scenario can produce a successful connection to the network, the link powers for the terminal are set to zero, and the reasons for failure of the first scenario are recorded.

Terminals which fail to make a connection in an iteration are not removed from the simulation, since success or failure in an iteration does not necessarily ensure the same result in a subsequent iteration. In fact, the state (succeeded/failed) of a terminal is determined purely by its state in the final iteration of a snapshot when convergence has been achieved.

The following diagram illustrates how a snapshot converges with successive iterations. Each histogram shows the distribution of achieved uplink values for successfully served terminals. All terminals are running a service with an uplink requirement of 6 dB.

65<4 Eb/No 65<4 Eb/No

65<4 Eb/No 65<4 Eb/No

End ofIteration 1

End ofIteration 3

End ofIteration 5

End ofIteration 7

After the first iteration, the majority of “served” terminals fail to meet their requirement. This is because terminals evaluated at the beginning of the first iteration see little or no interference and so have their TX powers set to low values. By the end of the first iteration, the noise in the system will have increased due to interference from the newly served terminals. Hence terminals evaluated at the beginning of the first iteration will no longer attain their desired by the end of the first iteration. In fact, only the last terminal served is guaranteed to achieve its desired.


Successive iterations produce increasingly accurate pictures of network noise, and a larger proportion of the terminals meet their requirement. By the seventh iteration in the example above, practically all the served terminals meet their requirement, and the system noise no longer changes significantly between iterations. The iterations have converged to produce a plausible picture of served and failed terminals in the network. Any remaining distribution in the achieved values of served terminals is largely due to quantisation of link powers, or from specifying a non-zero power control error standard deviation.

Convergence Criteria for UMTS

A good practical measure of convergence is to examine how the total uplink interference from terminals (summed over all cells) changes between iterations. This is considerably faster than measuring the distribution of achieved values.

If the percentage change in total uplink interference changes by an amount smaller than the threshold that you have specified then the iterations are deemed to have converged. The default threshold is a 1% change in the interference between iterations. You also sets the maximum number of iterations that may be performed in any one snapshot (default = 10).

Gathering of Results in UMTS The final stage of a snapshot involves gathering results from the current snapshot and combining them with the results from previous snapshots, so that average values for the geographic output arrays and Excel reports may be calculated. The information gathered includes cell information such as resource and power usage, information about the states of successfully served terminals, and the reasons for failure of terminals which failed to be served.

UMTS Scenario Prioritisation A UMTS Connection Scenario consists of the following pieces of information.

• Carrier

• Carrier load status (overloaded/underloaded). If any covering cell uses the above carrier and exceeds its “load balance threshold”, then the carrier load status is set to overloaded. Otherwise the carrier load status is set to underloaded.

• Primary cell

• of primary cell

• UL bearer

• DL bearer


The rules for prioritising scenarios during connection evaluation are (in order of decreasing importance):

• Underloaded (before overloaded) carriers

• Higher (before lower) priority carriers (with respect to service)

• Higher (before lower)

• Higher (before lower) priority DL bearers (with respect to service-carrier)

• Higher (before lower) priority UL bearers (with respect to service-carrier)

UMTS Connection Evaluation There are three stages to evaluating a UMTS connection scenario to see if a terminal may be served.

• Production of a candidate active set for the terminal

• Uplink evaluation

• Downlink evaluation

Production of a Candidate Active Set in UMTS In order for a cell to be in the candidate active set of a terminal, it must have an

adequate number of primary or handover resources available, and the pilot or SIR for the cell must also be of an acceptable level. It is necessary to produce a candidate active set before the uplink and downlink can be evaluated. A candidate active set is produced by the following steps:

Check primary resource availability & pilot SIR level forcandidate primary cell.

Check handover resource availability & pilot oc IE levels forcandidate handover cells.

The connection scenario being examined sets the candidate primary cell. This cell is checked to see if it has a sufficient number of primary resources available, and to see if it provides an adequate pilot SIR level at the terminal. If these conditions are met, the cell is flagged as the primary cell of the candidate active set.

The remaining covering cells are evaluated to see if they can be handover cells. Cells with a low downlink linkloss are checked before cells with a higher downlink linkloss. A handover cell must have a sufficient number of handover resources available, and provide an level that is within the handover margin of the level of the primary cell. Each cell that satisfies these requirements is flagged as a handover cell of the candidate active set unless the active set size limit specified by the primary cell has been reached.


Uplink Evaluation for UMTS This is the process of determining the terminal transmit power required to meet the uplink requirement. It is necessary to consider several effects here, such as handover gains, power control headroom, and noise rise limits on cells. The uplink evaluation carries out the following procedure:

Calculate required terminal power to meet ob NE for eachcell in candidate active set.

Temporarily set terminal power to the lowest possible powerthat will achieve a satisfactory ob NE value.

Calculate difference between two best ob NE values achievedon cells in the candidate active set.

Calculate handover gains, power rise, andpower control headroom.

See if terminal has sufficient power to make link.

Check terminal power does not break noise rise limit on anycells.

Apply log-normal error to uplink power, ensuring that all cellnoise-rise and terminal power limits are not broken.

For each cell in the candidate active set, the terminal transmit power required to meet the uplink is calculated. This lowest of these values is then quantised according to the quantisation level specified for the terminal. We call the resulting power. The terminal transmit power is temporarily set to, and the two best values on cells in the candidate active set are calculated. The difference between these two values (in dB), together with the terminal speed, allows the following quantities to be determined from the tables that you supply in the Services dialog box


Terminal Power Reduction

The terminal power reduction ( ) is a gain that reduces the required transmit power of the terminal. It is equivalent to a reduction in the uplink requirement.

Average Power Rise

The Average Power Rise ( risepowerP ) effect is due to fast power control. Fast power control can compensate for fading in a channel and keep the received power (from a terminal) fairly constant in the cell providing the power control. However this compensation for fades causes peaks in the terminal transmission power. This results in a rise in the average interference experienced in other cells. This is modelled in the simulator by adding an average transmit power rise to the terminal transmit power when calculating the uplink interference caused in other cells. When calculating the interference a terminal causes to its own cell, the average power rise is not added.

Power Control Headroom

The Power Control Headroom ( pchH ) is also called shadow fade margin. This is an overhead on the transmit power a terminal requires to make the uplink. It is a function of terminal speed, and the overhead is largest for slow moving terminals. The overhead ensures that the uplink power control is able to compensate for deep fades at a cell border.

Soft Handover Gain against Average Power Rise

The Soft Handover Gain against Average Power Rise (risepowerG ) reduces the average

power rise for soft handover cells. For non-handover cells, risepowerG = 1.

Soft Handover Gain against Power Control Headroom

The Soft Handover Gain against Power Control Headroom (pchG ) reduces the power

control headroom when a terminal is in soft handover.

After all the above quantities have been calculated, the terminal is checked to see if it has sufficient power to make the uplink. The actual transmit power of the terminal ( ) is given by

(17)

The uplink requirement can be satisfied if

(18)

where is the maximum possible transmit power of the terminal.


The terminal is also checked to see if it will break the noise rise limit on any of the covering cells. When calculating the interference, the terminal power is taken as . When calculating the interference produced on other cells, the terminal power is

taken as . If the terminal cannot meet the uplink

requirement without breaking a noise rise limit, then the terminal fails to be served. If the uplink can be successfully achieved, is finally given a random (log-normal) adjustment to model the effect of imperfect power control.

Downlink Evaluation for UMTS This is the process of determining the cell transmit powers required to meet the downlink requirement at the terminal. It is necessary to consider the effect of maximal ratio combining when there are multiple links. The downlink evaluation carries out the following procedure.

Calculate difference between two best oc IE values fromcells in the candidate active set.

Read downlink ob NE target reduction.

Calculate the lowest cell TX power (T ) that will achieve asatisfactory ob NE value.

Set TX powers for cells in candidate active set to T .

Calculate total achieved ob NE at terminal assuming maximalratio combining of links.

Increase/Decrease T if total achieved ob NE at terminal istoo low/high.

Iterateuntil

Eb/Noachieved

or notchangingbetweeniterations

Apply log-normal error to all downlink powers, ensuring thatall downlink power limits and cell power limits are not broken.


The difference between the two best values of cells in the candidate active set is calculated. This figure, together with the terminal speed, determines the downlink target reduction in soft handover. This is found by linear interpolation of the values that you supply in the Services dialog box.

The downlink powers for cells in the candidate active set are calculated iteratively. The iterative procedure involves setting all downlink powers to the same (non-zero) value . The total achieved is then calculated by summing the values for individual downlinks. If the total achieved is too low (high) by a factor of , then is increased (decreased) by a factor of . This process continues until ceases to change between iterations, or the downlink requirement is achieved.

Note : Individual downlink powers are kept within the limits that you supply throughout the iterative procedure outlined above, so cells will never be allowed to transmit more power than they have available.

If the downlink requirement can not be achieved, then the terminal fails to be served, and all downlink powers are set to zero.

UMTS Blocking Probability This section describes the following:

• Calculation of Blocking Probability in the Blocking Report

• Blocking Probability and Failure Rate

• Coverage Probability Array in the Map View Window

Calculation of Blocking Probability in the Blocking Report for UMTS The blocking probabilities for cells (shown in the blocking report) cannot be found by simply averaging the blocking probabilities at pixels in the Map View window for the following reasons:

• Pixels with high traffic should have more influence on cell blocking probability than pixels with low traffic.

• Pixels in coverage holes should not influence cell blocking probability, even if they contain high traffic.

• A service may use some bearers more frequently than others. Frequently used bearers should have more influence on the blocking probability than infrequently used bearers.

• Several cells may serve the traffic at a pixel.


A measure of blocking probability that is sensibly weighted is needed with respect to these factors. Such a measure can be found by selective passive-scanning at the end of a snapshot. This is different to the usual (global) passive-scanning that the user selects in the simulation wizard. Global passive-scanning tests all pixels and allows all scenarios to be evaluated, whereas selective passive-scanning only tests a subset of pixels and scenarios at the end of each snapshot. To determine which pixels and scenarios to check, the successfully served terminals are taken from the previous snapshot and used to check for blocking at the end of the current snapshot. Each terminal is placed at the location it had in the previous snapshot, and checked to see if it can connect to the cell that previously served it, using the previous UL and DL bearer. This automatically ensures that the cell blocking probability is correctly weighted, since the most likely terminal locations and connection scenarios are checked.

Blocking Probability and Failure Rate for UMTS The blocking probability measured in the tool is more similar to a Lost Call Held blocking probability than a Lost Call Cleared (Erlang-B) blocking probability. This is a consequence of the way the simulator works. The simulator simply tries to serve as much of the offered traffic as possible. The following formulae show how these probabilities are related in a simple situation.

Note : These formulae are not used to explicitly calculate blocking probabilities in the tool, since the probabilities in the tool are all found by sampling snapshots.

Take a system with fixed capacity , and Poisson traffic with arrival rate users per second and mean holding time seconds. The mean offered traffic is .

The probability that exactly C users are offered. (19)

The probability that more than C users are offered.

(20)

The probability that less than C users are offered.

(21)

Lost Call Cleared: In an LCC system, blocked users do not try again.

(22)

Lost Call Held: In an LCH system, blocked users persistently retry until connected.

(23)

It is easy to show that . The two probabilities are most similar to each other for low blocking probabilities.

Note : The “Failure Rate” ( ) in the failure report is the proportion of offered terminals that fail.


(24)

This is NOT a blocking probability and it should never be treated as one. The failure rate can be an order of magnitude lower than both the LCC and LCH blocking probabilities.

UMTS Coverage Probability Array in the Map View The meaning of “coverage probability” shown in the Map View is dependent on whether the (global) passive-scan terminal is being used to test every pixel at the end of a snapshot.

When running a simulation with passive-scan disabled, the coverage probability in the Map View is determined by the connection attempts made by the randomly scattered terminals. It gives the proportion of offered terminals at the pixel that were successfully served. This is not related to the blocking probability at the pixel. In fact it is more like the complement of the “failure rate” given in the reports. For example, a cell with a coverage probability of 20% at most pixels would give a failure rate of about 80% in the report.

When running a simulation with passive-scan enabled, the coverage probability at each pixel in the Map View is determined largely by the connection attempts of passive-scan terminals at the end of the snapshot. In this case, the coverage probability is simply the complement of the blocking probability at the pixel that is, the two probabilities sum to 1.

To summarise, if want to see blocking (and its causes) in the Map View, then the passive-scan should be enabled. If you would only like to view the reports, then the passive-scan terminal may be disabled.

Note : The blocking probability report is always calculated using the selective passive-scanning technique, which is totally independent of the global passive-scanning used for the Map View.



CDMA2000 Algorithms This chapter describes the following topics:

In This Section CDMA2000 Notation List of Principal Symbols for CDMA2000 CDMA2000 Basic Formulae CDMA2000 Uplink Noise Rise CDMA2000 Uplink Load CDMA2000 Frequency Re-Use Efficiency CDMA2000 Air Interface and User Bitrates CDMA2000 Shadow Fade Modelling CDMA2000 Power Control Error Modelling CDMA2000 Service Activity Modelling CDMA2000 Activity Factor Calculation For Packet Services (Web Model) CDMA2000 Transmit/Receive Diversity Modelling CDMA2000 Terminal Speed Modelling PN Code Assignment Algorithm for CDMA2000 CDMA2000 Overview of a Snapshot CDMA2000 Scenario Prioritisation CDMA2000 Connection Evaluation Calculation of Equivalent Control Overhead Factors for CDMA2000 CDMA2000 Blocking Probability

A P P E N D I X C


CDMA2000 Notation This list describes the notation symbols used in this section:

• A Greek subscript always indexes a carrier.

indicates a sum over all carriers.

• An uppercase Roman subscript always indexes a sector.

indicates a sum over all sectors .

• A lowercase Roman subscript always indexes a terminal.

indicates a sum over all terminals.

indicates a sum over all terminals in sector J.

• Up and down arrows indicate if a quantity is uplink or downlink.

• All quantities are in standard SI units, never in dB.

As an example. The quantity represents the for the uplink between terminal j and sector K using carrier α.

List of Principal Symbols for CDMA2000 The following table describes the list of principal symbols for CDMA2000: Symbol Description

, Uplink (downlink) adjacent carrier interference ratio. Gives fractional power leakage from

carrier β to carrier α. ( )

Uplink

Downlink

Pilot

, Uplink (downlink) processing gain

Sector antenna gain



Boltzmann constant


Mast head amplifier (downlink) insertion loss

, Uplink (downlink) linkloss between sector and terminal

Pathloss between sector and terminal


Cable (feeder) loss

TX combiner loss (downlink)

RX splitter loss (uplink)

Terminal body loss


Thermal noise at sector

Excess noise at sector

Terminal TX power

Downlink broadcast channel TX power

Downlink common-assignment channel TX power

Downlink common-control channel TX power

Downlink common-power-control channel TX power

Downlink dedicated-control channel TX power

Sector pilot channel TX power

Sector paging channel TX power (summed over all paging channels)

Downlink quick-paging channel TX power

Sector synchronisation channel TX power

Downlink traffic channel TX power

Total output TX power of sector


Total received power at sector

Temperature


Chip rate

, Uplink (downlink) service activity factor

, Uplink (downlink) bearer control-overhead factor




Cable (feeder) noise figure ( = )

CDMA2000 Basic Formulae The following formulae give the basic relations between link powers and noise. Handoff gains, power control headroom, and power rise gain have been ignored.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)


(10)

CDMA2000 Uplink Noise Rise Uplink noise rise (on a sector) is the total received power divided by the background noise. The noise rise on carrier α of sector J is given by

(11)

This is expressed in dB in the Sector Uplink Report.

CDMA2000 Uplink Load Uplink load (on a sector) is the total received power coming from all terminals divided by the total received power. The sector load on carrier α of sector J is given by:

(12)

This is expressed as a percentage in the Sector Uplink Report.

CDMA2000 Frequency Re-Use Efficiency Frequency re-use efficiency (on a sector) is the total received power coming from in-sector terminals divided by the total received power coming from all terminals. The frequency re-use efficiency on carrier α of sector J is given by:

(13)

This is expressed as a percentage in the Sector Uplink Report.

CDMA2000 Air Interface and User Bitrates The Air Interface Bitrate is used in the calculation of processing gain. The processing

gain ( , ) is calculated by dividing the system chiprate by the air interface bitrate.

The User Bitrate is used purely to calculate traffic (data throughput) on a sector.


CDMA2000 Shadow Fade Modelling This section describes the shadow fade modelling that is used for CDMA2000.

Shadow fading is modelled in the simulator by applying random offsets to the pathlosses experienced by each of the terminals in a snapshot. Shadow fades are log-normally distributed, and you may specify the standard deviation of shadow fading for indoor and outdoor terminals in each clutter type. In reality, the fades between a terminal and the sectors that cover it will exhibit a degree of correlation. In particular, a terminal is likely to have similar fades to sectors that are located on the same site. In order to model this in the simulator, you must two parameters in the Monte Carlo wizard:

• The normalised inter-site correlation coefficient ( ). This is the correlation between fades from a terminal to sectors on different sites.

• The normalised intra-site correlation coefficient ( ). This is the correlation between fades from a terminal to sectors on the same site.

These two parameters must satisfy the constraints .

For each terminal in a snapshot, a set of correlated fades to sectors is generated using the following procedure:

Note : All the random numbers mentioned are independent and normally distributed with zero mean and unit variance.

1 Generate a random number .

2 For each site , generate a random number .

3 For each sector , generate a random number .

4 The fade (in dB) to sector on site is then set to

(14)

where is the standard deviation of the shadow fading at the pixel (in dB).

This procedure is performed whenever a terminal is initialised at the beginning of a snapshot. Fades for different terminals are uncorrelated, even if the terminals are located in the same pixel.


CDMA2000 Power Control Error Modelling This section describes the power control error modelling for a CDMA2000 network:

The simulator does not explicitly model the power control process, but it allows the simulation results to exhibit certain features one would associate with imperfect power control.

The standard deviation of power control error parameter controls the distribution of

achieved values for successfully served terminals. If the standard deviation is

set to zero, the values for each successfully served terminal are achieved perfectly (ignoring quantisation and any lower limit on the link power). In a real system this is not the case since imperfect power control produces a (log-normal)

distribution of achieved values at a sector.

The simulator models imperfect power control by including a log-normal error on the uplink and downlink transmit powers of successfully served terminals. The errors on the uplink and downlink are uncorrelated, and are applied after all other handoff gains and margins have been considered. Terminals are never considered as having failed to make a connection if the resulting error makes them transmit at too high or too low a power.

CDMA2000 Service Activity Modelling The CDMA2000 service activity affects three areas of the simulation.

Consumption of Resources

A successfully served circuit switched service will consume the same number of resources regardless of the service activity factor. The number of resources in this case depends only on the bearer used.

A successfully served packet switched service will consume a partial number of resources depending on the service activity factor. For example, if a PS service is served using a bearer that requires 2 resources and the activity factor is 1%, then 0.02 resources will be consumed.

Calculation of Throughput

The throughput of a successfully served service is calculated by multiplying the data rate of the bearer used, by the service activity factor.

Calculation of Interference

Equations:

(9)


(10)

and

(11)

all have a dependence on or .

CDMA2000 Activity Factor Calculation For Packet Services (Web Model)

Using the same notation as given in the WWW traffic model, the activity factor formula is:

Where:

= Average packet time period (s)

= Size of a Packet (bytes)

= the Max Bit Rate the particular service supports (bit/s)

= Average session time period (s)

= Number of packet calls per session

= Reading time between packet calls (s)

= Number of packets within a packet call

= Inter arrival time between packets in a packet call (s)

= Retransmission factor (%)


CDMA2000 Transmit/Receive Diversity Modelling You can indicate if a sector has an antenna system providing transmit or receive diversity by selecting the appropriate check boxes in the Site Database. Transmit

(receive) diversity on a sector effectively reduces the requirement on the

downlink (uplink). When defining a service, you must specify two

requirements for the downlink (uplink). One requirement is used on sectors with transmit (receive) diversity and the other is used on sectors without transmit (receive) diversity.

CDMA2000 Terminal Speed Modelling Handoff gains are speed dependent, and so each terminal in the simulation is given a random speed. For each terminal type and clutter type, you specify four parameters that determine the speed distribution. These are:

• The mean speed ( )

• The standard deviation of the speed distribution ( )

• The minimum speed ( )

• The maximum speed ( ).

A random speed is then given by:

(15)


PN Code Assignment Algorithm for CDMA2000 The PN code assignment algorithm is a two-stage process.

1 Find the most difficult sector to assign a PN code.

2 Find the best PN code to assign and then assign it to the sector.

The PN code calculation continues until all sectors have been assigned a PN code.

Difficulty Factor for CDMA2000 The difficulty factor, DF, for a sector is calculated as:

Where:

A is the number of adjacent sectors

is the number of adjacent sectors with codes assigned


N is the number of nearby sectors

is the number of nearby sectors with codes assigned

Nbr is the number of first and second order neighbours

s the number of first and second order neighbours with codes assigned

If the minimum code re-use distance is not selected in the parameters page then N and NA are set to zero, the same applies to first and second order neighbours.

Best PN Code to Assign for CDMA2000 Once the most difficult sector has been found, the best PN code, that is the code with the lowest penalty, needs to be found and assigned to that sector.

The following penalty values can be given to a PN code:

• 2.1e+78 if the code is not unique with respect to the neighbouring sectors.

• -10,000,000 if the code does not clash with neighbouring, nearby or interfering sectors.

• 100,000 + max interfering power, if the code clashes with nearby or interfering sectors.

Quality Factor for CDMA2000 Once the PN codes are assigned, a measure of quality is calculated. The quality does not change if sectors within the reuse distance have the same code applied. This information can be seen in the sectors within the minimum re-use distance column in the report. Instead, the quality is a measure of signal to noise ratio and best server area.

On a particular pixel, the strongest power is determined for every supported carrier in turn. The best signal to interference ratio (SIR) is found for each of these strongest carriers via the equation:

SIR = covering sector power / (interference + covering sector power)

Interference is the noise contribution from overlapping carriers on sectors with the same PN code as the best carrier. A running total of SIR for all carriers on the sector is kept along with the number of pixels on which the sector’s carriers were the best server. Quality is calculated as SIR/best server area *100 for each sector.


CDMA2000 Overview of a Snapshot This section gives an overview of a CDMA2000 snapshot:

The aim of a snapshot is to produce a plausible picture of the network at a particular instant in time. This picture will typically consist of a set of successfully served terminals and their states, that is the link powers and handoff state, and a set of unserved terminals and their reasons for failure. Many snapshots must be performed and the results from them averaged in order to produce an overall picture of network behaviour. A snapshot involves the stages outlined in the following diagram:


Initialisation of System Powers and Resource Usage



CDMA2000 Initialisation of Terminals The first stage of a snapshot involves creating a geographical distribution of terminals attempting to connect to the network. Each pixel is allocated a random, Poisson-distributed, number of terminals, according to the mean number of terminals specified for the pixel in the terminal-density array. Also during this initialisation stage, each terminal is given a set of random log-normal fades, one for each sector that covers it, that is it has a pathloss to it. A random Power Control Error is chosen for the uplink and downlink. A terminal will use the same random values (fading, power control error, activity flags and speed) for the duration of its existence in a snapshot.


Initialisation of System Powers and Resource Usage in CDMA2000 Before commencing the iterative process, the system is placed in a known state, namely the state of an unloaded network. This is simply done by setting all link powers to zero, and making all resources available at the sectors.


CDMA2000 Iterations An iteration involves sequentially evaluating the terminals (precisely once) to see if they can make a connection to the network. After each terminal is evaluated, the noise in the network (at sectors and terminals) is updated before moving on to evaluate the next terminal.

A terminal may connect to the network in a variety of different ways (connection scenarios). For example a terminal may have several different sectors or carriers that it may use. Each of the connection scenarios for a terminal is evaluated in turn until one that allows a successful connection is found. If no scenario can produce a successful connection to the network, the link powers for the terminal are set to zero, and the reasons for failure of the first scenario are recorded.

Terminals that fail to make a connection in an iteration are not removed from the simulation, since success or failure in an iteration does not necessarily ensure the same result in a subsequent iteration. In fact, the state (succeeded/failed) of a terminal is determined purely by its state in the final iteration of a snapshot when convergence has been achieved.

The following diagram illustrates how a snapshot converges with successive

iterations. Each histogram shows the distribution of achieved uplink values for successfully served terminals. All terminals are running a service with an uplink requirement of 6 dB.

65<4 Eb/No 65<4 Eb/No

65<4 Eb/No 65<4 Eb/No

End ofIteration 1

End ofIteration 3

End ofIteration 5

End ofIteration 7

After the first iteration, the majority of “served” terminals fail to meet their requirement. This is because terminals evaluated at the beginning of the first iteration see little or no interference and so have their TX powers set to low values. By the end of the first iteration, the noise in the system will have increased due to interference from the newly served terminals. Hence terminals evaluated at the beginning of the first iteration will no longer attain their desired by the end of the first iteration. In fact, only the last terminal served is guaranteed to achieve its desired .


Successive iterations produce increasingly accurate pictures of network noise, and a larger proportion of the terminals meet their requirement. By the seventh iteration in the example above, practically all the served terminals meet their requirement, and the system noise no longer changes significantly between iterations. The iterations have converged to produce a plausible picture of served and failed terminals in the network. Any remaining distribution in the achieved values of served terminals is largely due to quantisation of link powers, or from specifying a non-zero power control error standard deviation.

Convergence Criteria for CDMA2000

A good practical measure of convergence is to examine how the total uplink interference from terminals (summed over all sectors) changes between iterations.

This is considerably faster than measuring the distribution of achieved values described above.

If the percentage change in total uplink interference changes by an amount smaller than the threshold that you specify then the iterations are deemed to have converged. The default threshold is a 1% change in the interference between iterations. You should also set the maximum number of iterations that may be performed in any one snapshot (default = 10).

Gathering Of Results in CDMA2000 The final stage of a snapshot involves gathering results from the current snapshot and combining them with the results from previous snapshots, so that average values for the geographic output arrays and Excel reports may be calculated. The information gathered includes sector information such as resource and power usage, information about the states of successfully served terminals, and the reasons for failure of terminals that failed to be served.

CDMA2000 Scenario Prioritisation A CDMA2000 Connection Scenario consists of the following pieces of information:

• Carrier

• Primary sector

• of primary sector

• UL bearer

• DL bearer

• UL radio configuration (CDMA2000 only),

• DL radio configuration (CDMA2000 only)

• Required (HDR only)



• Higher (before lower) priority Downlink radio configurations (with respect to service)


• Higher (before lower) (CDMA2000 only)

• Higher (before lower) required (HDR only)

• Higher (before lower) priority DL bearers (with respect to service-carrier)

• Higher (before lower) priority UL bearers (with respect to service-carrier)

CDMA2000 Connection Evaluation There are three stages to evaluating a CDMA2000 connection scenario to see if a terminal may be served.

• Production of a candidate active set for the terminal



Production of a Candidate Active Set in CDMA2000 In order for a sector to be in the candidate active set of a terminal, it must have an

adequate number of primary or handoff resources available, and the pilot for the sector must also be of an acceptable level. It is necessary to produce a candidate active set before the uplink and downlink can be evaluated. A candidate active set is produced by the following steps:

Check primary resource availability & pilot oc IE level forcandidate primary sector.

Check handoff resource availability & pilot oc IE levels forcandidate handoff sectors.

The connection scenario being examined sets the candidate primary sector. This sector is checked to see if it has a sufficient number of primary resources available, and to

see if it provides an adequate level at the terminal. If these conditions are met, the sector is flagged as the primary sector of the candidate active set.


Each of the remaining sectors that have a pathloss to the terminal are evaluated to see if they can be handoff sectors. Sectors with low downlink linkloss are checked before sectors with a higher downlink linkloss. A handoff sector must have a sufficient

number of handoff resources available, and provide an level that is above the T_DROP level specified on the primary sector. Each sector that satisfies these requirements is flagged as a handoff sector of the candidate active set unless the active set size limit specified by the primary sector has been reached.

CDMA2000 Uplink Evaluation This is the process of determining the terminal transmit power required to meet the

uplink requirement. It is necessary to consider several effects here, such as handoff gains, power control headroom, and noise rise limits on sectors. The uplink evaluation carries out the followingprocedure:

Calculate required terminal power to meet tb NE for each cell in candidate active set.

Temporarily set terminal power to the lowest possible power that will achieve a satisfactory tb NE value.

Calculate difference between two best tb NE values achieved on cells in the candidate active set.

Calculate soft handoff TX power reduction.

See if terminal has sufficient power to make link.

Check terminal power does not break noise rise limit on any cells.

Apply log-normal error to uplink power, ensuring that all cell noise-rise and terminal power limits are not broken.


For each sector in the candidate active set, the terminal transmit power required to

meet the uplink is calculated. This lowest of these values is then quantised according to the quantisation level specified for the terminal. We call the resulting power . The terminal transmit power is temporarily set to , and the two best

values on sectors in the candidate active set are calculated. The difference between these two values (in dB), together with the terminal speed, allows the

terminal power reduction ( ) to be determined from the tables that you set in the Services dialog box.

The terminal power reduction ( ) is a gain that reduces the required

transmit power of the terminal. It is equivalent to a reduction in the uplink requirement.

After the terminal power reduction has been calculated, the terminal is checked to see if it has sufficient power to make the uplink. The actual transmit power of the terminal ( ) is given by:

(16)

The uplink requirement can be satisfied if

(17)


The terminal is also checked to see if it will break the noise rise limit on any of the covering sectors. When calculating the interference, the terminal power is taken as

. If the terminal cannot meet the uplink requirement without breaking a noise rise limit, then the terminal fails to be served. If the uplink can be successfully achieved, is finally given a random (log-normal) adjustment to model the effect of imperfect power control.


CDMA2000 Downlink Evaluation This is the process of determining the sector transmit powers required to meet the

downlink requirement at the terminal. It is necessary to consider the effect of maximal ratio combining when there are multiple links. The downlink evaluation follows the following procedure:

Calculate difference between two best tb NE values from cells in the candidate active set.

Read downlink tb NE target reduction.

Calculate the lowest cell TX power (T ) that will achieve a satisfactory tb NE value.

Set TX powers for cells in candidate active set to T .

Calculate total achieved tb NE at terminal assuming maximal ratio combining of links.

Increase/Decrease T if total achieved tb NE at terminal is too low/high.

Iterate until

Eb/No achieved

or not changing between iterations

Apply log-normal error to all downlink powers, ensuring that all downlink power limits and cell

power limits are not broken.


The difference between the two best values of sectors in the candidate active set is calculated. This figure, together with the terminal speed, determines the

downlink target reduction in soft handoff. This is found by linear interpolation of the values that you supply in the Services dialog box.

The downlink powers for sectors in the candidate active set are calculated iteratively. The iterative procedure involves setting all downlink powers to the same (non-zero)

value . The total achieved is then calculated by summing the values

for individual downlinks. If the total achieved is too low (high) by a factor of , then is increased (decreased) by a factor of . This process continues until

ceases to change between iterations, or the downlink requirement is achieved.

Note : Individual downlink powers are kept within the limits that you supply throughout the iterative procedure, so sectors will never be allowed to transmit more power than they have available.

If the downlink requirement can not be achieved, then the terminal fails to be served, and all downlink powers are set to zero.

Calculation of Equivalent Control Overhead Factors for CDMA2000

This section describes the following topics:

• Uplink RC1 – RC2

• Uplink RC3 – RC6 When Using a Supplemental Bearer

• Uplink RC3 – RC6 When Not Using a Supplemental Bearer

• Downlink RC1 – RC2

• Downlink RC3 – RC10


Uplink RC1 - RC2 The activity factor gives the proportion of time that the service is active. During an inactive period, the terminal maintains an uplink using an 1/8th rate bearer (called here the inactive bearer). The following diagram represent the powers transmitted in

the active and inactive periods. and are the fundamental channel powers in the active and inactive periods.

F2

Active FundamentalBearer

Inactive FundamentalBearer

α(ActivePeriod)

(InactivePeriod)

F1

1−α

The average uplink power is given by

which can be rewritten as

The ratio of transmit powers for the active and inactive fundamental bearers

is given by the ratio of their ( ) requirements and processing gains as follows:

Hard-coded look-up tables give and . The ratio of transmit powers

for the active and inactive fundamental bearers is given by the ratio of their

( ) requirements and processing gains as follows:

So in equations (1) and (10), the factor is given by:


Uplink RC3 - RC6 When Using a Supplemental Bearer The activity factor gives the proportion of time that the service is active. During an inactive period, the terminal maintains an uplink using an 1/8th rate bearer (called here the inactive bearer). The following diagram represent the powers transmitted

during active and inactive periods. is the supplemental channel powers in the

active period. and are the fundamental channel powers in the active and inactive periods and is the uplink pilot power.

α(ActivePeriod)

1-α

(InactivePeriod)



Active Fundamental Bearer

F2

F1

PilotP

Active Supplemental BearerS1

The average uplink power is given by:

Which can be rewritten as:

Hard-coded look-up tables give , .



Uplink RC3 - RC6 When Not Using a Supplemental Bearer The activity factor gives the proportion of time that the service is active. During an inactive period, the terminal maintains an uplink using an 1/8th rate bearer (called here the inactive bearer). The following diagram represent the powers transmitted


active period. and are the fundamental channel powers in the active and inactive periods and is the uplink pilot power:

α(ActivePeriod)

1-α

(InactivePeriod)




F2

F1

PilotP


which can be rewritten as:

Hard-coded look-up tables give and .



Downlink RC1 - RC2 The activity factor gives the proportion of time that the service is active. During an inactive period, the terminal maintains a downlink using an 1/8th rate bearer (called here the inactive bearer). The followingdiagram represent the powers transmitted in

the active and inactive periods. and are the fundamental channel powers in the active and inactive periods.

F2


Inactive Fundamental Bearer

α(Active Period)

1-α(Inactive Period)

F1

The average downlink power is given by:


The ratio of transmit powers for the active and inactive fundamental bearers

is given by the ratio of their ( ) requirements and processing gains as follows:



Downlink RC3 - RC10 The activity factor gives the proportion of time that the service is active. During an inactive period, the terminal maintains a downlink using an 1/8th rate bearer (called here the inactive bearer). The followingdiagram represent the powers transmitted


active period. and are the fundamental channel powers in the active and inactive periods periods.

α(Active Period)

1-α(Inactive Period)

Active Fundamental Bearer Inactive Fundamental Bearer

Active Supplemental Bearer

F2

S1

F1



The ratio of fundamental powers to the power of the active supplemental bearer

and is given by the ratio of their ( ) requirements and processing gains as follows:



CDMA2000 Blocking Probability This section describes the following:

• Calculation of Blocking Probability in the Blocking Report

• Blocking Probability and Failure Rate

• Coverage Probability Array in the Map View Window

Calculation of Blocking Probability in the Blocking Report for CDMA2000 The blocking probabilities for cells (shown in the blocking report) cannot be found by simply averaging the blocking probabilities at pixels in the Map View window for the following reasons:

• Pixels with high traffic should have more influence on cell blocking probability than pixels with low traffic.

• Pixels in coverage holes should not influence cell blocking probability, even if they contain high traffic.

• A service may use some bearers more frequently than others. Frequently used bearers should have more influence on the blocking probability than infrequently used bearers.

• Several cells may serve the traffic at a pixel.

We need a measure of blocking probability that is sensibly weighted with respect to all the above factors. We can find such a measure by selective passive-scanning at the end of a snapshot. This is different to the usual (global) passive-scanning that the user selects in the simulation wizard. Global passive-scanning tests all pixels and allows all scenarios to be evaluated, whereas selective passive-scanning only tests a subset of pixels and scenarios at the end of each snapshot. To determine which pixels and scenarios to check, we take the successfully served terminals from the previous snapshot and use them to check for blocking at the end of the current snapshot. Each terminal is placed at the location it had in the previous snapshot, and checked to see if it can connect to the cell that previously served it, using the previous UL and DL bearer. This automatically ensures that the cell blocking probability is correctly weighted, since the most likely terminal locations and connection scenarios are checked.

CDMA2000 Blocking Probability and Failure Rate The blocking probability measured in the tool is more similar to a Lost Call Held blocking probability than a Lost Call Cleared (Erlang-B) blocking probability. This is a consequence of the way the simulator works. The simulator simply tries to serve as much of the offered traffic as possible. The following formulae show how these probabilities are related in a simple situation.

Note : These formulae are not used to explicitly calculate blocking probabilities in the tool, since the probabilities in the tool are all found by sampling snapshots.


Take a system with fixed capacity , and Poisson traffic with arrival rate users per second and mean holding time seconds. The mean offered traffic is .

The probability that exactly C users are offered. (18)

The probability that more than C users are offered.

(19)

The probability that less than C users are offered.

(20)


(21)


(22)


Note : The “Failure Rate” ( ) in the failure report is the proportion of offered terminals that fail.

(23)

This is NOT a blocking probability and it should never be treated as one. The failure rate can be an order of magnitude lower than both the LCC and LCH blocking probabilities.

CDMA2000 Coverage Probability Array in the Map View Window The meaning of “coverage probability” shown in the Map View window is dependent on whether the (global) passive-scan terminal is being used to test every pixel at the end of a snapshot.

When running a simulation with passive-scan disabled, the coverage probability in the Map View window is determined by the connection attempts made by the randomly scattered terminals. It simply gives the proportion of offered terminals at the pixel that were successfully served. This is not simply related to the blocking probability at the pixel. In fact it is more like the complement of the “failure rate” given in the reports. For example, a cell with a coverage probability of 20% at most pixels would give a failure rate of about 80% in the report.


When running a simulation with passive-scan enabled, the coverage probability at each pixel in the Map View window is determined largely by the connection attempts of passive-scan terminals at the end of the snapshot. In this case, the coverage probability is simply the complement of the blocking probability at the pixel that is, the two probabilities sum to 1.

To summarise, if you are interested in seeing blocking (and its causes) in the Map View window, then the passive-scan should be enabled. If you are only interested in reports, then the passive-scan terminal may be disabled.

Note : The blocking probability report is always calculated using the selective passive-scanning technique, which is totally independent of the global passive-scanning used for the Map View window.


HDR Algorithms This chapter describes the following topics:

In This Section HDR Notation List of Principal Symbols for HDR HDR Basic Formulae HDR Uplink Noise Rise HDR Uplink Load HDR Frequency Re-Use Efficiency HDR Air Interface and User Bitrates HDR Shadow Fade Modelling HDR Power Control Error Modelling HDR Service Activity Modelling HDR Transmit/Receive Diversity Modelling HDR Terminal Speed Modelling Overview of a HDR Snapshot Scenario Prioritisation for HDR HDR Connection Evaluation Calculation of Uplink Equivalent Control Overhead Factor for HDR HDR Coverage Probability and Blocking About the HDR Quality of Service Algorithm

HDR Notation This list describes the notation symbols used in this section:

• A Greek subscript always indexes a carrier.

indicates a sum over all carriers.

• An uppercase Roman subscript always indexes a cell.

indicates a sum over all cells.

• A lower case Roman subscript always indexes a terminal.

A P P E N D I X D


indicates a sum over all terminals.

indicates a sum over all terminals in cell J.

• Up and down arrows indicate if a quantity is uplink or downlink.

• All quantities are in standard SI units, never in dB.

As an example, the quantity represents the for the uplink between terminal j and cell K using carrier α.

List of Principal Symbols for HDR The following table describes the list of principal symbols for CDMA2000: Symbol Description

, Uplink (downlink) adjacent carrier interference ration. Gives fractional power leakage from carrier β to

carrier α ( ).

Uplink

Pilot

Uplink processing gain

Cell antenna gain



Boltzmann constant

Mast head amplifier (downlink) insertion loss.

, Uplink (downlink) linkloss between cell and terminal

Pathloss between cell and terminal


Cable (feeder) loss

TX combiner loss (downlink)

RX splitter loss (uplink)

Terminal body loss



Thermal noise at cell

Excess noise at cell

Terminal TX power

Cell rated power


Total received power at cell

Temperature

Chip rate

Uplink service activity factor

Uplink equivalent control-overhead factor




Cable (feeder) noise figure ( = ).

HDR Basic Formulae The following formulae give the basic relations between link powers and noise. Handoff gains, power control headroom, and power rise gain have been ignored:

(1)

(2)

(3)

(4)


(5)

(6)

(7)

(8)

HDR Uplink Noise Rise Uplink noise rise (on a cell) is the total received power divided by the background noise. The noise rise on carrier α of cell J is given by:

(9)

This is expressed in dB in the Cell Uplink report.

HDR Uplink Load Uplink load (on a cell) is the total received power coming from all terminals divided by the total received power. The cell load on carrier α of cell J is given by:

(10)

This is expressed as a percentage in the Cell Uplink report.

HDR Frequency Re-Use Efficiency Frequency re-use efficiency (on a cell) is the total received power coming from in-cell terminals divided by the total received power coming from all terminals. The frequency re-use efficiency on carrier α of cell J is given by:

(11)

This expressed as a percentage in the Cell Uplink report.


HDR Air Interface and User Bitrates The Air Interface Bitrate of an uplink bearer is used in the calculation of the uplink

processing gain. The uplink processing gain ( ) is calculated by dividing the system chiprate by the air interface bitrate of the uplink bearer.

The User Bitrate of the uplink bearer is used purely to calculate traffic (data throughput) on a cell.

HDR Shadow Fade Modelling Shadow fading is modelled in the simulator by applying random offsets to the pathlosses experienced by each of the terminals in a snapshot. Shadow fades are log-normally distributed, and you may specify they standard deviation of shadow fading for indoor and outdoor terminals in each clutter type. In reality, the fade between a terminal is likely to have similar fades to cells that are located on the same site. In order to model this in the simulator, you should specify two parameters in the Monte Carlo wizard:

• The normalised inter-site correlation coefficient ( ). This is the correlation between fades from a terminal to cells on different sites.

• The normalised intra-site correlation coefficient ( ). This is the correlation between fades from a terminal to cells on the same site.

The two parameters must satisfy the constraints .

For each terminal in a snapshot, a set of correlated fades to cells is generated using the following procedure:

Note : All the random numbers mentioned in the following procedure are independent and normally distributed with zero mean and unit variance.

1 Generate a random number X.

2 For each cell site I, generate a random number .

3 For each cell J, generate a random number

4 The fade (in dB) to cell J on site I is then set to:

(12)

where is the standard deviation of the shadow fading in the pixel (in dB).

This procedure is performed whenever a terminal is initialised at the beginning of a snapshot. Fades for different terminals are uncorrelated, even if the terminals are located in the same pixel.


HDR Power Control Error Modelling The simulator does not explicitly model the power control process, but it allows the simulation results to exhibit certain features one would associate with imperfect power control.

The standar deviation of power control error parameter controls the distribution of

achieved values for successfully served terminals. If the standard deviation is

set ot zero, the values for each successfully served terminal are achieved perfectly (ignoring quantisation and any lower limit on the link power). In a real system this is not the case values since imperfect power control produces a (log-

normal) distribution of achieved values at a cell.

The simulator models imperfect power control by including a log-normal error on the uplink and transmit powers of successfully served terminals. The errors on the uplink are applied after all other handoff gains have been considered. Terminals are never considered as having failed to make a connection if the resulting error makes them transmit at too high or too low a power.

HDR Service Activity Modelling Service activity affects calculation of uplink interference. Equations 10 and 11 have a

dependence on the uplink activity factor .

HDR Transmit/Receive Diversity Modelling You can indicate if a cell has an antenna system providing transmit/receive diversity by selecting the appropriate check boxes on the Antennas tab of the Site Templates and Site Database dialog boxes.

Receive diversity reduces the requirement on the uplink. When defining an

uplink bearer, you should specify two requirements. One requirement is used on cells with receive diversity and the other is used on cells without receive diversity. Transmit diversity is not modelled in a HDR simulation, since downlink traffic powers are not calculated.


HDR Terminal Speed Modelling Handoff gains are speed dependent and so each terminal in the simulation is given a random speed. For each terminal type and clutter type, you must specify four parameters that determine the speed distribution. These are:

• the mean speed ( )

• the standard deviation of the speed distribution ( )

• the minimum speed ( )

• the maximum speed ( )

A random speed is the given by:

(13)


Overview of a HDR Snapshot The aim of a snapshot is to produce a plausible picture of the network at a particular instant in time. This picture will typically consist of a set of successfully served terminals and their state, that is the link powers and handoff state, and a set of unserved terminals and their reasons for failure. Many snapshots must be performed and the results from them averaged in order to produce an overall picture of network behaviour.

A snapshot involves the following stages:


Initialisation of System Power




HDR Initialisation of Terminals The first stage of a snapshot involves creating a geographical distribution of terminals attempting to connect to the network. Each pixel is allocated a random, Poission-distributed, number of terminals, according to the mean number of terminals specified for the pixel in the terminal-density array. Also during this initialisation stage, each terminal is given a set of random log-normal fades, one for each cell that covers it, that is it has a pathloss to it. A random power control error is chosen for the uplink. A terminal will use the same random values (fading, power control error, speed) for the duration of its existence in a snapshot.


HDR Initialisation of System Powers Before commencing the iterative process, they system is placed in a known state, namely the state of an unloaded network. This is simply done by setting all link powers to zero.

HDR Iterations An iteration involves sequentially evaluating the terminals (precisely once) to see if they can make a connection to the network. After each terminal is evaluated, the noise in the network is updated before moving on to evaluate the next terminal.

A terminal may connect to the network in a variety of different ways (connection scenarios). For example, a terminal may have several different cells or carriers that it may use. Each of the connection scenarios for a terminal is evaluated in turn until one that allows a successful connection if found. If no scenario can produce a successful connection to the network, the link powers for the terminal are set to zero and the reasons for failure of the first scenario are recorded.

Terminals which fail to make a connection in an iteration are not removed from the simulation, since success or failure in an iteration does not necessarily ensure the same result in a subsequent iteration. In fact, the state (succeeded/failed) of a terminal is determined purely by its state in the final iteration of a snapshot when convergence has been achieved.


The following diagram illustrates how a snapshot converges with successive

iterations. Each histogram shows the distribution achieved uplink values for successfully served terminals. All terminals are running a service with an uplink

requirement of 6 dB.

After the first iteration, the majority of served terminals fail to meet their requirement. This is because terminals evaluated at the beginning of the first iteration see little or no interference and so have their TX powers set to low values. By the end of the first iteration, the noise in the system will have increased due to interference from the newly served terminals. Hance terminals evaluated at the beginning of the

first iteration will no longer attain their desired by the end of the first iteration. In fact, only the last terminal served is guaranteed to achieve its desired

.

Successive iterations produce increasingly accurate pictures of network noise and a

larger proportion of the terminals meet their requirement. By the seventh

iteration practically all the served terminals meet their requirement and the system noise no longer changes significantly between iterations. The iteration have converged to produce a plausible picture of served and failed terminals in the network. Any remaining distribution in the achieved F values of served terminals is largely due to quantisation of link powers or from specifying a non-zero power control error standard deviation.


Convergence Criteria for HDR

A good practical measure of convergence is to examine how the total uplink interference from terminals (summed over all cells) changes between iterations. This

is considerably faster than measuring the distribution of achieved values as previously described.

If the percentage change in total uplink interference changes by an amount smaller than the threshold that you have specified, then the iterations are deemed to have converged. The default threshold is a 1% change in the interference between iterations. You must set the maximum number of iterations that may be performed in any one snapshot (default = 10).

Gathering of Results for HDR The final stage of a snapshot involves gathering results from the current snapshot and combining them with the results from previous snapshots, so that average values for the geographic output arrays and Excel reports may be calculated. The information gathered includes cell information such as resource and power usage, information about the states of successfully served terminals and the reasons for failure of terminals which failed to be served.

Scenario Prioritisation for HDR A connection scenario consists of the following pieces of information:

• Carrier

• Primary cell

• Uplink bearer

• Required



• Higher (before lower) required

• Higher (before lower) priority uplink bearers (with respect to service-carrier)

HDR Connection Evaluation There are two stages to evaluating a connection scenario to see if a terminal may be served:




HDR Downlink Evaluation

In order to be served, the cell must provide an adequate level for the terminal.

The level determines the downlink bitrate that can be achieved by the

terminal. The mapping between and the downlink bitrate must be specified in

the HDR Downlink Parameters dialog box. If the level for the terminal is lower than all the values specified in the table then the terminal will fail to be served.

HDR Uplink Evaluation The following diagram shows the process of determining the terminal transmit power

required to meet the uplink requirement:


For each cell in the candidate active set, the terminal transmit power required to meet

the uplink is calculated. The lowest of these values is then quantised according to the quantisation level specified for the terminal. We call the resulting power . The terminal transmit power is temporarily set to and the two best

values on cells in the candidate active set are calculated. The difference between these two values (in dB), together with the terminal speed, allows the

terminal power reduction ( ) to be determined from the supplied information in the Services dialog box.

The terminal power reduction ( ) is a gain that reduces the required

transmit power of the terminal. It is equivalent to a reduction in the uplink requirement.

After the terminal power reduction has been calculated, the terminal is checked to see if it has sufficient power to make the uplink. The actual transmit power of the terminal ( ) is given by:

(14)

The uplink requirement can be satisfied if:

(15)


The terminal is also checked to see if it will break the noise rise limit on any of the covering cells. When calculating the interference, the terminal power is taken as .

If the terminal cannot meet the uplink requirement without breaking a noise rise limit, then the terminal fails to be served. If the uplink can be successfully achieved is finally given a random (log-normal) adjustment to model the effect of imperfect power control.


Calculation of Uplink Equivalent Control Overhead Factor for HDR

The following diagram represents the powers transmitted during active and inactive periods:

The activity factor gives the proportion of time that the service is active. During an inactive period, the terminal is assumed the transmit no power.

There is an uplink pilot channel whose strength is related to the uplink traffic channel power.

T is the traffic channel power in the active period. P is the uplink pilot power in the active period.


This can be written in the form:

where is the control overhead factor. The term is the effective activity factor that appears in the calculation of uplink noise (equation 8). See equation 8.

In dBm, P can be calculated from T using the following formula:

a P_dBm = T_dBm – dataOffsetNom_dB – dB – dataOffsetRate_dB

DataOffsetRate_dB depends on the air interface bitrate of the bearer:

b 9600 dataOffsetRate_dB = dataOffset9k6dB – 3.75

c 19200 dataOffsetRate_dB = dataOffset9k2dB – 6.75

d 38400 dataOffsetRate_dB = dataOffset38k4dB – 9.75

e 76800 dataOffsetRate_dB = dataOffset76k8dB – 13.25

f 53600 dataOffsetRate_dB = dataOffset53k6dB – 18.50


The tool provides default values of dataOffsetNom_dB and dataOffsetRate_dB that make (P_dBm = T_dBm) for all bearers.

HDR Coverage Probability and Blocking This chapter describes the following algorithms:

HDR Coverage Probability Array in the Map View Window The meaning of coverage probability shown in the Map View window is dependent on whether the (global) passive scan terminal is being used to test every pixel at the end of a snapshot.

When running a simulation with passive-scan enabled, the coverage probability at each pixel in the Map View window is determined largely by the connection attempts of passive-scan terminals at the end of the snapshot. In this case, the coverage probability is simply the complement of the blocking probability at the pixel, that is the two probabilities sum to 1.

When running a simulation with passive-scan disabled, the coverage probability in the Map View window is determined by the connection attempts made by the randomly scattered terminals. It simply gives the proportion of offered terminals at the pixel that were successfully served. This is not simply related to a blocking probability. Instead, it complements the failure rate.

To summarise, if you want to view the blocking probability and its causes in the Map View window, the passive-scan should be enabled. However, if you would prefer to view the report in Excel only then the passive-scan terminal should be disabled.

HDR Blocking Probability and Failure Rate The blocking probability evaluated in the tool is more similar to a Lost Call Held blocking probability than a Lost Call Cleared (Erlang-B) blocking probability. This is a consequence of the way the simulator works. The simulator simply tries to serve as much of the offered traffic as possible. The following formulae show how these probabilities are related in a simple situation.

Note : These formulae are not used to explicitly calculate blocking probabilities in the tool, since probabilities in the tool are all found by sampling snapshots.

Take a system with fixed capacity , and poisson traffic with arrival rate users per second and mean holding time second. The mean offered traffic is .

(16)

(17)

(18)



(19)


(20)


The Failure Rate ( ) is the proportion of offered terminals that fail.

(21)

This is not a blocking probability and it should never be treated as one. The failure rate can be an order of magnitude lower than both the LCC and LCH blocking probabilities.

About the HDR Quality of Service Algorithm This chapter describes the HDR Packet Quality of Service (QoS) algorithm used in ASSET3g and explains the packet QoS reports generated by Monte Carlo simulations.

The following QoS figures are calculated:

• Mean Internet Protocol (IP) packet arrival rate

• Mean IP packet transmission time

• Mean IP packet delays caused by queuing at the packet scheduler

• Mean total IP packet transmission delay

• Mean gross user throughput

• Mean gross sector throughput

• Mean net sector throughput

• Mean percentage of packets timed out.

This chapter includes:

• HDR outline

• IP packet transmission time

• IP packet queueing delay

• Throughput


HDR Outline The HDR forward link is a time division multiple access (TDMA) link with 16 slots per frame. There are 600 time-slots per second so each time slot is approximately 1.66ms and the frame-length is 26.66ms. Each slot is divided into two with a pilot burst in the first half and a physical layer packet in the second half.

The link layer forms physical-layer packets from the original data packet. To do this the data is encoded (using turbo codes), block interleaved and repeated. The coding-rate and repetition-rate depend on the data-rate. The output is a number of symbols.

Physical layer packets are spread across a number of time slots, spaced out at four-slot intervals. The number of slots reserved for transmission is dependent on the HDR downlink parameter. For example, four slots would be reserved for a data-rate of 307.2kbps. If the first slot used was slot N, then the reserved slots would be N+4, N+8 and N+12.

There is a probability that an acknowledgement (ACK) will be received before all the reserved slots are transmitted. If this occurs, the remaining reserved slots are released and made available for other packet calls. The probability of an ACK being received increases with each slot transmitted.

There is also a probability that the physical layer packet will not have been successfully transmitted even when all the reserved slots are used. In this case the physical layer packet is re-transmitted, reserving the same number of slots as previously. The probability that the entire physical layer packet is not successfully received is defined by the packet erasure rate (PER).

IP Packet Transmission Time for HDR HDR QoS outputs are generated for each sector, on both a per service and per carrier basis. At the end of each snapshot in the Monte Carlo simulator, a list of connected terminals (internal to the simulator) is used as input to the HDR QoS calculation.

Each terminal is assigned an HDR downlink parameter from the terminal’s Ior/Ioc. This value of Ior/Ioc is used to calculate the terminal’s achievable Eb/Nt, defined as:

Eb/Nt = Ior/Ioc (dB) +10 log10(traffic chips per bit).

The Eb/Nt is then used to select the packet erasure rate from the HDR downlink parameter. The IP packet transmission time depends on the number of physical layer packets required to transmit the IP packet and the number of slots across which these physical layer packets are spread.

Determining the number of slots used for transmission is a two-stage process

• The number of physical layer packets required to transmit the IP packet is calculated using:

No. physical layer packets = IP packet size /available bits per physical layer packet.


• The number of slots used for each physical layer packet is determined. This depends on the number of reserved slots and the probability of receiving an acknowledgement, which is calculated for each reserved slot. The probability that an ACK will be received for a particular slot, p(ack)n, is:

where

m – gradient of the curve Eb/Nt vs (1-PER)

N – maximum number of reserved slots.

A uniformly distributed random number is drawn. If this is greater than p(ack) then the physical layer packet is said to be successfully transmitted. If the random number drawn is less that the probability of receiving an acknowledgement in the last reserved slot then the entire physical layer packet is retransmitted.

The average IP packet transmission time, , can then be calculated using:

where

Slots- sum of all the slots used for transmission.

IP Packet Queueing Delay for HDR It is assumed that the packet scheduler maintains a queue for each sector under its control. All the packets awaiting transmission are stored in the queue in order of arrival, that is the oldest packet is at the front.

The average length of each scheduler queue, and hence the average queuing delay, W, can be estimated using Erlang’s delayed call formula, from “Queueing Modelling Fundamentals”, Ng Chee Hock, John Wiley and Sons, pp. 113 – 117:

Where the symbols have the following meanings:

• m – maximum number of servers

• - average arrival rate (no. connected terminals/IP packet inter-arrival time)

• -average departure rate (1/average transmission time)*m

•

• Hence the queueing delay depends on the IP packet arrival rate, departure rate and the number of servers.


Each frame of 16 time-slots is sub-divided into sub-frames of four slots to account for the physical layer packets being spaced four slots apart. Therefore there is a maximum limit of four servers available. If only one service is running on a carrier then all four servers are available, if two services are running then two servers are available and if four services are running then one server is available to each service. This imposes a limit of four services per carrier.

A means of limiting queue length is needed to prevent the queue from tending to infinity. You can set a limit on either the average queue length or the average waiting time for a packet in the queue.

The number of items in the queue, Nq, is given by:

where the probability of delay, P(d) is defined as

and Po is

The number of servers available to a service on a carrier will vary depending on the number of services on that carrier. By using the above equations and the relation:

the following polynomials are obtained

m=1

m=2

m=4

Where W is the maximum permitted waiting time in the queue. These equations are solved for the maximum arrival rate which can be handled, , without exceeding the maximum waiting time.


The percentage of traffic blocked, %Tblocked, is

where is the actual arrival rate.

Throughput for HDR

Mean gross user throughput, , is the average physical layer packet throughput per user and is calculated using:

where

- number of available bits per physical layer packet

- number of physical layer packets per user

- average IP packet transmit time.

The mean gross sector throughput, , is the average maximum throughput that could be achieved considering the available signal quality.

where

- average number of slots required for transmission.

Mean net sector throughput, , is the actual throughput that is handled by the sector and is calculated by:

where

- percentage of packets timed out

- size of the IP packet in bits.



Packet Quality of Service Algorithms

This chapter details the Packet Quality of Service algorithms used in ASSET3g, and therefore explains the Packet Quality of Service Reports generated by the QoS analysis.

The packet QoS analysis feature is a downlink cell level simulation, with 10 ms (single radio frame) resolution. It is a trace-driven queuing simulation, the packet transmission delays through a cell are modelled by a queuing system, which has a time-series of packet traffic offered to it. It is based on the www traffic model and multiple, prioritised services can be specified.

The simulation is run for a calculated period of time, then the results are presented on the summary page of the QoS Analysis wizard as a spread sheet and graphs. The results can be saved as an Excel workbook containing graphs and spreadsheets, or the raw the raw data saved in text or comma separated variable (csv) format. The graphs include the cumulative delay distributions of the packet services on each cell, enabling you to view percentile delays.

The Excel workbook contains the following data per service, per carrier and, per cell:

• Mean and standard deviations of the queuing delays

• 95th percentile delay

• Confidence interval half width

• Mean transmission time

• Mean retransmission delay

• Total transmission delay ( mean queuing delay+mean transmission time+mean retransmission delay

Graphs for each cell and carrier giving the cumulative queuing delay probability distributions

In This Section Simulation Inputs for QoS Analysis Traffic Generator for QoS Analysis

A P P E N D I X E


Simulation Inputs for QoS Analysis Most of the packet QoS analysis parameters are input when you configure the network design, ready for the Monte Carlo simulation. The site/cell, carrier, terminal type and service type parameters are configured at this stage, and the QoS analysis uses these parameters later to deduce:

• The number of queues to model

• The parameters of the traffic streams to generate, and the

• Priorities of the service types, during before the time simulation

You then need to run at least two snapshots of the Monte Carlo simulation, although 100 snapshots or more isareare recommended to produce statistically valid inputs to the QoS analysis. The Monte Carlo simulation calculates the mean blocking probability for each packet service type, on each carrier, on each cell in the simulation in the simulation and the mean number of terminals connected to each cell, per carrier, per service, and per bitrate. The mean blocking probability and mean number of terminals are thenis are then used as inputs to the QoS analysis.

Preliminary Tests Some conclusions can be deduced from the input data without running the simulation at all. These are:

• 100% blocking on any service will result in delays building up to infinity

• Zero traffic on all services will result in zero delays

• Zero blocking on all services will result in zero delays

These results are immediately updated on the summary page of the QoS Analysis dialog box.

Traffic Generator for QoS Analysis This section describes the following:

• Matching Generated Traffic to Monte Carlo’s Mean Number of Served Users

• WWW Traffic Model

• Packet Model

• About the Code Schemes for GPRS

• QoS Profiles for GPRS


Matching Generated Traffic to Monte Carlo's Mean Number of Served Users The Monte Carlo simulator calculates the number of users which can be served for each service, by each cell and carrier in every snapshot. The mean is then calculated over the total number of snapshots run in the simulation. This figure is the starting point for the QoS analysis; it provides the mean number of users for each packet service in each cell and carrier in the simulation. The traffic generator generates a time series of packet sessions for each service in a cell and carrier, which matches the mean number of users over time, as shown in the following diagram:

The red line represents the mean number of users input from the Monte Carlo simulation. The orange blocks represent the number of users varying over time. The blue blocks represent the holding times of the packet sessions produced by the traffic generator.

Little’s theorem gives us the relation between the arrival rate of packet sessions, the mean number of users in the cell and their mean session holding time. Let

λ = mean session arrival rate

T = mean session holding time

= mean number of users in the cell

Little’s result says that:

TN .λ=


The traffic generator therefore generates sessions with mean arrival rate calculated from the mean number of users in the cell, and the mean session holding time, which is determined using the WWW traffic model.

WWW Traffic Model The WWW traffic model is used to generate the activity of each packet session. The following diagram shows a typical WWW browsing (packet service) session, which consists of a sequence of packet calls. The user initiates a packet call when downloading a WWW document and during a packet call, several packets may be generated. After the document has completely arrived, the user requires reading time to study the information.

The following diagram shows packets from a source, which may be at either end of the link, but not both ends simultaneously.

The model requires the generation of six random variables:

• Session arrival process - The arrival of session set-ups to the network is modelled as a Poisson process. For each service there is a separate process.

• Number of packet calls per session, Npc - A geometrically distributed, that is a discrete representation of the exponential distribution random variable is used, with a mean number of packet calls of 5.

• Reading time between packet calls, Dpc - A geometrically distributed, that is a discrete representation of the exponential distribution, random variable is used, with a mean reading time of 4 to 12 s.

• Number of packets per packet call, Nd - A geometrically distributed, that is a discrete representation of the exponential distribution, random variable is used, with a mean number of packets of 25.


• Size of packet, Sd – A Poisson distributed random variable is used, with a mean size of 480 Bytes.

• Inter arrival time between packets, Dd - A geometrically distributed, that is a ( that is, a discrete representation of the exponential distribution) random variable is used.

The session holding time is modelled implicitly by the number of events during the session.

Using the WWW traffic model, the mean holding time of a packet session is given by:

( ) ( ) ddpcpcpc DNNDNT 11 −+−=

Packet Model The traffic generator uses the session arrival and WWW models to produce a list of packets for each service type, for each cell, for each carrier, lasting the duration of the simulation. Each packet is stamped with its arrival time at the cell, and also keeps a record of when it gets transmitted (its departure time), and its randomly generated size. The packet service type lists are then merged and sorted in arrival time order, to produce a single list of packets offered to the cell carrier:

In the diagram, the data contained in the packet boxes is the arrival time, the departure time and the packet size. Initially, the packet’s departure time is set to be the same as its arrival time. The departure time is updated each time step the packet is queued, until it is successfully transmitted.

A histogram of the generated traffic is displayed for each service on each cell and carrier in the graphs tab of the QoS Analysis dialog box.


About the Code Schemes for GPRS The peak throughput and block size in GPRS is determined by the coding scheme and, in EGPRS, by the coding and modulation scheme, as shown in the following table: System Scheme Link Adaption

Family Modulation Peak Rate per Slot

(kb/s) Blocks Per 20 ms

RLC Block Size (bits)

GPRS CS - 1 GMSK 9.05 1 181

CS - 2 13.4 268

CS - 3 15.6 312

CS - 4 21.4 428

EGPRS MCS - 1 C GMSK 8.8 176

MCS - 2 B 11.2 224

MCS - 3 A 14.8 296

MCS - 4 C 17.6 352

MCS - 5 B 8 - PSK 22.4 1 448

MCS - 6 A 29.6 592

MCS - 7 B 44.8 2 896

MCS - 8 A 54.5 1090

MCS - 9 A 59.2 1184

In order to calculate the block size, the coding scheme allocated to each connection needs to be input from the Monte Carlo simulation (a mean number of MS connections per coding scheme, per bearer, per service type, per sub-cell array will be required as input).

The block size can be inferred directly from the GPRS coding schemes, however, the following mapping is used to calculate the block size for the first transmission attempt for the link adaptation families:

• A – 592 bits

• B – 448 bits

• C – 352 bits

There are no default BLER versus C/I curves for MCS – 7, 8 and 9. In the retransmission model, the lower bitrates of the link adaptation families are used.

QoS Profiles for GPRS GPRS defines several different QoS Profiles which consist of four components:

• Precedence class

• Delay class

• Reliability class

• Throughput class


Precedence Class

Traffic is given a precedence of 1 (premium), 2 (standard) or 3 (best effort), with a precedence of 1 being highest. This precedence is similar to the service type priorities set in the QoS Analysis wizard in ASSET3g, however the number of priorities needs to be restricted to three and different service types can have equal priorities. The precedence class is used to prioritise the queues. For more information, see Simulation Model on page 97.

Delay Class

GPRS has four different traffic classes. The following table shows that parameters that specifies their QoS requirements: Traffic Class Medium Application Data Rate (kbit/s) One-way Delay

Conversational Audio Telephony 4-25 <150ms

Data Telnet <8 <250ms

Streaming Audio Streaming (HQ) 32-128 <10s

Video On-way 32-384 <10

Data FTP - <10s

Interactive Audio Voice messaging 4-13 <1s

Data Web browsing - <4s/page

For background traffic, only bit integrity is required.

3g service types have traffic classes and are used in the packet service types dialog box in 3g to set default www parameters and delay targets. In the ASSET3g QoS Analysis the achieved 95th percentile delay per service type, per carrier, per cell is compared with the target 95th percentile delay.

Traffic class is used to prioritise the queues. For more information, see Simulation Model on page 97.

Reliability Class

Applications can request different reliability classes, depending on their ability to handle corrupt and duplicated blocks. The following table shows the reliability classes that can be selected:

Reliability Class Lost Block Probability

1 10

2 10

3 10


Reliability is only considered in terms of the retransmission delay formula used in ASSET3g. This uses the block error rate (BLER) to analytically calculate the retransmission delay for packet services. A different approach is proposed for GPRS. The BLER can be calculated using the Average Data Throughput per Timeslot vs Average Connection C/I curves. The formula is:

where:

Throughput(C/I) = throughput in kb/s read off the throughput per timeslot graph for the C/I achieved by the link

tePerSlotPeakDataRa = peak rate per slot for the given coding scheme (the asymptote of the throughput per timeslot graph

BLER(C/I) = block error rate for the C/I achieved by the link

The mean BLER over all the connections made per service type, per sub-cell is required as an input from the Monte Carlo simulation, and is reported in the QoS Analysis spreadsheet. Block errors also have implications for the retransmission model. For more information, see Mean Retransmission Delay on page 102.

Throughput Class

Applications can request different mean and peak throughputs, in order to request the desired throughput for bursty IP traffic. Peak throughput applies to short intervals where the transfer rate is at a maximum. Mean throughput describes the data transfer rate over an extended period of time, which could involve many idle periods.

Peak throughput class Peak throughput (kb/s) Mean throughput class Mean throughput (bytes per hour)

1 8 1 100

2 16 2 200

3 32 3 500

4 64 4 1 000

5 128 5 2 000

6 256 6 5 000

7 512*

8 1024* 17 20 000 000

9 2048* 18 50 000 000

*Data rate only reachable with UMTS or EDGE

31 Best Effort

In GPRS, the peak throughput is determined by the peak data rate per slot achievable by the coding scheme, and the number of timeslots for which the MS is enabled. The peak throughput is calculated as follows:

fSlotsMaxNumberOrameBlocksPerFtePerSlotPeakDataRahputPeakThroug **=


The coding scheme is identified by the bearer allocated to the connection during the Monte Carlo simulation and the maximum number of timeslots enabled on the MS will be a parameter set on the terminal type. It is therefore possible to do a preliminary check prior to running the GPRS QoS analysis to determine the peak throughput achievable for each service type on each sub-cell. The peak throughput is reported in the QoS Analysis spreadsheet.

The mean throughput is logged as successful transmissions are made from the queue in the QoS analysis, and are reported in the QoS Analysis spreadsheet.

Time Simulator for QoS Analysis This section describes the following:

• System Model

• Simulation Model

System Model

The call admission manager monitors the system's available capacity and accommodates new packet transmission requests, at the same time ensuring the QoS of existing connections. This may be situated at the BSC in a 2g network or the RNC in a 3g network.

The steps of a connection admission procedure are:

• A new packet transmission request is received by the call admission manager

• The capacity of the destination cell is monitored

• The system either accepts or blocks the new connection

• If the QoS of an existing connection is degraded, it is dropped

Simulation Model

The simulation models the connection admission procedure by making the following assumptions:

• The call admission manager monitors the cell capacity in every radio frame, that is every 10ms

• The cell capacity for each service type is generated using the blocking probability input from the Monte Carlo simulation

• The blocking decision is prioritised to accept new connections in the priority order of their services

• The dropping of existing connections is not modelled

The cell capacity for each service is determined in each frame by generating a uniformly distributed random number for each packet held in a queue. If the random number is greater than the blocking probability, the packet starts transmission in that frame. If the random number is less than of equal to the blocking probability, the packet is delayed in the queue until the next frame.


If the packet call mode is selected instead of the packet mode, connection admission decisions are taken on a packet call, instead of an individual packet basis.

The service prioritisation is modelled in the simulator. All the packets awaiting transmission through a cell are stored in a set of queues, one for each service type. A diagram of the queuing model which would be used for three packet services being transmitted through a cell is shown here:

The rule is then applied that if admissions for each service are considered in priority order, and that if any higher priority packets remain queued, no lower priority packets are admitted.

By the end of the simulation, the simulator will have produced a list of transmitted packets, each stamped with its arrival and departure times from the cell.

A histogram of the queue length throughout the simulation is displayed for each service on each cell and carrier in the graphs tab of the QoS Analysis dialog box.

About the Packet QoS Session Timeout Calculation for CDMA2000

The main limitation on capacity on CDMA systems is the forward link PA power available. The simulator provides us with data on the total available transmit power on the sector carrier (minus noise contributions) and the average transmit power required per sector, service , carrier or bearer for each user.


When a terminal is connected and active, and there is no data to transmit, it uses a fundamental and supplemental channel. For example, in between packets it uses a 1/8th rate fundamental channel. This means that a terminal is still consuming transmit power between packet calls. The session timeout parameter was added to prevent all the available power being consumed by terminals transmitting at 1/8th rate, which would mean that no packet data could be transmitted. The session timeout parameter is employed to kill any sessions which have been active for longer than the session timeout, thus freeing up transmit power and allowing packets or packet calls to be transmitted.

Results of QoS Analysis This section describes the following:

• Confidence Interval Half Width

• Simulation Duration

• Delay and Cumulative Delay Probability Distributions

• Mean and Standard Deviations of the Queuing Delays

• 95th Percentile Delay

• Mean Transmission Time

• Mean Retransmission Delay

Confidence Interval Half Width

The performance measure of the simulation is the mean delay of the first service on the cell. An estimate of the length of time for which a queue simulation should be run has been obtained by setting up a simulation for an M/M/1 queue, for which analytical results for the mean delay can be obtained, and experimentally determining how long the simulation should be run to obtain results of a given accuracy. To get an accuracy of 10% at a 95% confidence level, the following procedure has been recommended:

1 Set the basic run length to ensure at least 1000 2000 packet admission requests are made to the cell for each service.

2 Repeat the run (replicate) 5 times and calculate the confidence interval half width H5.

3 If the confidence interval is less than 10% of the mean delay, , the desired accuracy has been obtained.

The confidence interval half width H5 is calculated by repeating runs, using a different random number stream for each run (3). Suppose we make k runs (replications), each generating m sample values of the packet delay, Y.


Let Y1, Y2, Y3,…, Yk be the mean values of the k runs. The mean values are independent, since a different random number stream was used for each run and, for a sufficiently large m, it will be approximately normally distributed. The confidence interval half width Hi is then calculated from the sample mean , and variance σ

2

.

∑=

=k

i

i

kY

Y1

( )( )∑

= −−

=k

i

i

kYY

1

22

1σ

mH i

σ.2=

Simulation Duration

This is calculated for each cell and carrier. The value depends on the parameters that you have set for the services supported by that cell, and carrier, and the mean number of users of those services input from the Monte Carlo simulation. Using the same notation as the www traffic model section, plus the following definitions:

reqN = required number of packets

reqS = number of sessions required to generate reqN packets

reqT = time until the reqS session arrives

D = recommended simulation duration

Each session contains dpc NN . packets, so

dpc

reqreq NN

NS

.=

(1)

The session arrivals are modelled as a Poisson process, and so the expected time until

the reqS session arrives is:

λreq

req

ST =

(2)

Substituting Little's law and equation (1) and (2),

NNNTN

Tdpc

reqreq ..

.=


Adding the duration of the reqS session itself, the simulation duration is:

TNNN

ND

dpc

req .1.. ⎟

⎟⎠

⎞⎜⎜⎝

⎛+=

Delay and Cumulative Delay Probability Distributions

Graphs of the delay probabilities and the cumulative delay probabilities are produced for each service, on each cell and carrier. The delay probability graphs are the most easily understood. It will be apparent that the highest priority service should have a delay distribution, which peaks before the next highest priority service, and so on. However, the cumulative delay probability graphs are more useful, because you can read any percentile delay from them.

The data for these graphs will be collected by maintaining counts during the simulation. For example, when a packet which has been queued for 4 frames is finally transmitted, the count in the 4 frame bin will be incremented. If there are N bins, each bin represents a delay of F frames, and c is the count in a bin at the end of the simulation, their state can be represented by the following table:

Bin Delay Count

0 0.F C0

1 1.F C1

2 2.F C2

... ... ...

N n.F Cn

... ... ...

N N.F CN

Total number of packets transmitted during the simulation:

∑=

=N

iicTP

0 Delay probability of n.F frames:

TPc

nP n=)(

Cumulative delay probability of n.F frames:

TP

cnCP

n

ii∑

== 0)(


Mean and Standard Deviations of the Queuing Delays

The following are the mean and standard deviations of the queuing delays:

Mean delay ∑=

=N

nnPnFD

0)(..

Standard deviation ( )∑

=

−=N

nnPDnF

0

2 )(..σ

95th Percentile Delay

The 95th percentile is calculated from the cumulative delay graph, and compared with the target 95th percentile delay, that you originally set in the Packet Service dialog box. If the delay calculated from the graph is greater than the target, a ‘QoS target failed’ message is generated, listing the services which have failed on a particular cell and carrier. If the delay is less than the target, a ‘QoS target achieved’ message is displayed in the QoS Analysis summary page.

Mean Transmission Time

This is calculated using a running mean of the transmission time of each packet transmitted by the simulation. The packet transmission time is calculated from the mean packet size Sd (Bytes), (a Poisson distributed random variable, with the mean

size set in the Packet Service dialog box), and the service bitrate b (kbs-1) ).

Transmission time:

bST d

trans .1000.8

=

Mean Retransmission Delay

Error detection and correction across the air interface is handled by the Radio Link Control (RLC) sublayer, and is described in UMTS Standard TS 25.301. Packets are segmented by the RLC into equal sized blocks for transmission across the air interface. The block size and bearer rate determine the number of blocks which are transmitted per radio frame. The RLC then transmits the blocks, detects dropped or corrupted blocks and guarantees their delivery by retransmission. The retransmission protocol can be configured to provide different levels of QoS. The retransmission protocol which is modelled in the calculation of the retransmission delay is Stop-and-Wait ARQ (Automatic Repeat reQuest). This has the following features:

• One block is received and handled at a time

• The receiver acknowledges each correctly received block

• If a block is corrupted, the receiver discards it and sends no acknowledgement

• The sender uses a timer to determine whether or not to retransmit


• The sender keeps a copy of each transmitted block until its acknowledgement has been received

• Finally, the blocks are put back into order and reassembled into packets by the RLC at the receiver

In order to calculate the average retransmission delay, the block error rate (BLER) at which the system will operate is required as an input. A typical value of 10% is set as

the default. You also need to set the re-transmission timeout in units of radio frames. The BLER can then be used to calculate the increase in traffic through the link caused by retransmission, and the mean or median retransmission delay:

( ) seconds..delay sionretransmis Mean ⎟⎟⎠

⎞⎜⎜⎝

⎛+

−= 1

1010

BLERBLER

rtτ

References The following are documents that have been referred to throughout this chapter:

• “Selection procedures for the choice of radio transmission technologies of the UMTS” TR 101 112 v3.2.0, p.34

• “Quality of Service for Multimedia CDMA”, N. Dimitriou, R. Tafazolli, G. Sfikas, IEEE Communications Magazine, July 2000

• “Simulating Computer Systems”, M.H. MacDougall, MIT Press, p.114

• “Introduction to Mathematical Statistics”, R.V. Hogg and A.T. Craig, Collier-Macmillan Ltd, p.193



ASSET3g File Formats

This chapter describes the following topics:

In This Section Simulation Array File Formats Live Traffic File Formats for 2g Networks Live Traffic File Formats for 3g Networks

Simulation Array File Formats There are two types of simulation array file:

• 3gr File - This is a proprietary file which contains a complete dump of the simulation.

(the proprietary file's format is not disclosed in this manual)

• 3ga File - This file format is described in this topic.

Note : these formats are also applicable to 2g Monte Carlo simulations.

The advantages and disadvantages of the files are shown below:

3gr Files Advantages Disadvantages The fact that the file contains everything from the simulation means you can load the file on a PC anywhere and run it, evenif it is from a completely different database

Because the file contains everything it is large

Can be loaded and saved from the Array Manager You can only have one 3gr file loaded at any one time

A P P E N D I X F


3ga Files Advantages Disadvantages Small file size Cannot be used to rerun the simulator

Simple, published file format Only takes a copy of the information, which is useful for comparison purposes

Can copy to clipboard by right-clicking on a display and from the menu that appears clicking Archive, in the Map View window

Clicking Archive does not save the file, it just puts in memory, but when it is in memory, you can save it using the Array Manager

Contains information about an individual display, for example, Reasons for Failure

You can have multiple files loaded simultaneously

Can be loaded and saved from the Array Manager

3ga File Format The following sections give information on the 3g archived array format (*.3ga):

• File Header

• Array Instance Body

Note : this format is also applicable to 2g Monte Carlo simulations.

File Header

This table describes the header of the 3g archived array format (*.3ga):

Size Type Description Comments 4 Bytes int Magic Number should be 0x02121975

4 Bytes int Version Number Currently 4202

4 Bytes int Archive Name Length inc NULL terminator

char[ ] Archive Name User Visible Name

4 Bytes int Network Type Enumeration of one of the following:

NETWORK_UNKNOWN 0x00000000 NETWORK_UMTS 0x00000001 NETWORK_IS95 0x00000002 NETWORK_HDR 0x00000004 NETWORK_ALLTECHS 0xFFFFFFFF

4 Bytes int Region xMin

4 Bytes int Region xMax

4 Bytes int Region yMin

4 Bytes int Region yMax

4 Bytes int Resolution

4 Bytes int Memory Usage Mb

4 Bytes int Unique Name String Length inc NULL terminator

char[ ] Unique String GUID

4 Bytes time_t Date / Time

4 Bytes int User Name String Length inc NULL terminator


char[ ] User Name String

4 Bytes int Comment String Length inc NULL terminator

char[ ] Comment String

4 Bytes int Insertion String List Len

4 Bytes int Insertion String Len } Section Repeated

char[ ] Insertion String } for each

4 Bytes int Insertion String2 Len (inc NULL Terminator)

} Insertion

char[ ] Insertion String2 } String

4 Bytes Int Current Provisions

4 Bytes int Reserved1

4 Bytes int Opaque Data Block Length

Opaque Data Block Reserved for future. Size specified above

4 Bytes int Array Instance Count (must be >= 1)


Array Instance Body

This table describes the array instance body of the 3g archived array format (*.3ga):

Size

Type Description Comments

4 Bytes int Magic Number should be 0x21081970

4 Bytes time_t Date / Time

4 Bytes int Generic Name String Length inc NULL terminator

char[ ] Generic Name String

4 Bytes int Instance Number

4 Bytes int Carrier/Service Name Str Len inc NULL terminator

char[ ] Carrier/Service Name String

4 Bytes int Data Array Type currently 0 = float

4 Bytes int Data Array Num Elements

TYPE[ ] Data Array Type specified above

int[ ] Index Array

4 Bytes int String Array Num Elements

4 Bytes int String Length inc NULL terminator

char[ ] String

4 Bytes int Legend Colours Array Length

COLOREF Category Colour } Repeated

Int CategoryString Length } for each


Char[ ] Category String } category

4 Bytes int Thresholds Array Length

int[ ] Threshold For enumeration renderers only

4 Bytes int Reserved1

4 Bytes int Opaque Data Block Length

Opaque Data Block Reserved for future. Size specified above


Live Traffic File Formats for 2g Networks You can import measured traffic from a text file and use live rather than estimated traffic in traffic spreading. For GPRS and HSCSD, live traffic is the total traffic caused by any GPRS (or HSCSD) terminal types on sub-cells. Live HSCSD traffic is measured and distributed in Erlangs.

The live traffic file formats supported are:

Format File Type Contains NMS 2000 *.nms Live NMS2000 traffic information

Can contain circuit-switched, HSCSD and GPRS traffic

Uses LAC and GSMID

GSM *.gts Live GSM traffic Can contain circuit-switched, HSCSD and GPRS traffic

Uses LAC, GSMID and Cell Layer Name

General Purpose *.tps GSM, Analog or TETRA traffic Can contain circuit-switched, HSCSD and GPRS traffic

Uses CellID and Cell Layer Name

NMS File Format The NMS file format is as shown here:

LAC white-space GSMID white-space CSTraffic white-space HSCSDTraffic white-space GPRSTraffic

If there is no data for the CSTraffic or HSCSDTraffic or GPRSTraffic then the column must contain a - (hyphen).

GSM File Format The GSM file format is as shown here:

LAC white-space GSMID white-space Cell Layer Name white-space CSTraffic white-space HSCSDTraffic white-space GPRSTraffic

If there is no data for the CSTraffic or HSCSDTraffic or GPRSTraffic then the column must contain a - (hyphen).


TPS File Format The TPS file format is a general purpose format which can contain GSM, EGPRS, TETRA or AMPS live traffic. This file starts with this header:

# AIRCOM V1.0 Live Traffic File

And contains data in this format: CELLID white-space Cell Layer Name white-space CSTraffic white-space HSCSDTraffic white-space GPRSTraffic white-space EGPRSTraffic

The HSCSD Traffic, GPRS Traffic and EGPRS columns may be left blank unless there is data in a later column else they must contain a - (hyphen). This is done so as to support TETRA and AMPS network live traffic data loading.

Live Traffic File Formats for 3g Networks There are three live traffic import files that can be used when creating a Traffic Raster:

• *.tpc

• *.cbc

• *.cbd

About the *.tpc File Format The file defines the number of terminals to spread for each cell. This file format is an extension of the ENTERPRISE general purpose live traffic import file (*.tps).

The file format is as follows:

The first line is the header and the second line contains the word 'cell' (or 'sector' if the traffic to be spread is CDMA2000 traffic), followed by the word 'Terminals'.

The remaining lines then contain the traffic data to be spread.

The formats for each technology type are:

UMTS

UMTS Cell Name (white-space) UMTS Traffic (Terminals)

CDMA 2000

CDMA 2000 Sector Name (white-space) CDMA 2000 Traffic (Terminals)

HDR

UMTS Cell Name (white-space) UMTS Traffic (Terminals)

TD-SCDMA

CDMA 2000 Sector Name (white-space) TD-SCDMA Traffic (Terminals)


In all technologies the units of traffic will be Terminals.

Example *.tpc Live Traffic File

An example *.tpc file is shown here:

Traffic Per Cell File V1

Terminals

4.0

5.0

6.0

4.0

5.0

6.0

About the Bearer Traffic File Formats (*.cbc / *.cbd) The bearer file format consists of two files which both share the same filename but differ in file extension. The first extension is a *.cbc (cell bearer configuration) file which defines what is contained in the *.cbd (cell bearer data) file.

When you choose to select a bearer traffic file, you browse for the *.cbc file only. The *.cbd file is automatically loaded and a check is made to ensure that it exist. The file format is case insensitive and a version header check is performed for both formats.

The *.cbc file chooses between one of two naming methods (String/Number):

• String refers to matching by UMTS Cell Identity "NodeB1A"

• Number refers to the combination of RNC ID and UMTS Cell ID from the network combined with a ":" delimiter. For example "1234:4567".

The *.cbc file is necessary to provide a lookup table to map between the name of the bearer from the network and with the planning tool.

There is an indication of number of bearers that exist in the lookup table:

Cell Bearer Configuration File V1

Naming Method String

Bearers 5

Network-bearer1 Bearer1





The *.cbd file consists of a table of bearer traffic values for each cell.


If five bearers are defined in the *.cbc file, then there should be five bearer data columns in the *.cbd file. If the number of bearer data columns do not match the number specified in the *.cbc file, then an error dialog aborts the import process. For example:

Error The number of bearers specified in the *.cbc file (X) does not match the number of bearer data columns in the *.cbd file.

Cell Bearer Data File V1

Cell net-bearer1 net-bearer2 net-bearer3 net-bearer4 net-bearer5

NodeB1a 1.3 1.3 1.3 1.3 1.3

NodeB1b 2.4 2.4 2.4 2.4 2.4

NodeB1c 3.5 3.5 3.5 3.5 3.5

NodeB2a 4.6 4.6 4.6 4.6 4.6

NodeB2b 5.7 5.7 5.7 5.7 5.7

NodeB2c 6.8 6.8 6.8 6.8 6.8

NodeB3a 7.9 7.9 7.9 7.9 7.9

NodeB3b 9.0 9.0 9.0 9.0 9.0

NodeB3c 10.1 10.1 10.1 10.1 10.1

A *.cbd file should contain only be one row per cell. If duplication is detected during import then a warning message is given in the message log. For example: “CellXXX: Skipping duplicate bearer traffic data.”

Whilst the traffic wizard is processing the *.cbd file, as multiple network bearers can map to the same tool bearer, the application should generate a total for each tool bearer.

If the import detects that values are missing, then a value of 0.00 Erlangs should be assumed. A warning message should be added to the message log in those cases. For example: “CellXXX: BearerXXX traffic not specified. Defaulting to 0.0”

If there are no data values for the bearers, then 0 should be assumed - but a warning message in the message log indicates that this has occurred. For example: “CellXXX: BearerXXX traffic not specified. Defaulting to 0.”

The cell matching criteria will vary according to the Naming Method specified in the *.cbc file.

If no match occurs between the Cell ID and that in the database, a warning message is displayed in the message log stating that. For example: “CellXXX: Failed to import traffic. Cell does not exist.” (ID as appropriate to naming method)

As there can be up to 15,000 cells contained in the *.cbd file, a progress bar with an Abort button appears if the processing contains more than XXXX cells. XXXX is determined during testing to appear after 2 seconds.

The *.cbc file format allows a '-' instead of a Bearer ID to mean just ignore that column.


ASSET3g Technical Reference Guide Page i Version 5.0.2

Index

A Algorithms

CDMA2000 • 43 FCC calculations • 18 Frequency hopping • 10 Frequency Re-use and Load • 20 GPRS and HSCSD capacity • 15 HDR • 69 ILSA cost function • 13, 14 Interference arrays • 6 Interference Tables • 5 MAIO planning cost function • 14 Non-Frequency hopping • 12 Packet QoS • 89 UMTS • 23

C CDMA2000

algorithms • 43

F File formats

live traffic for 2g • 108 live traffic for 3g • 109 Simulation arrays • 105

G GPRS

algorithms • 5 GSM

algorithms • 5

H HDR

algorithms • 69 HSCSD

algorithms • 5

M Monte Carlo, algorithm • 23, 32, 34, 35, 39

P Packet Switched QoS algorithms • 89

Q QoS

algorithms • 89

S Snapshots

algorithm • 32

T TETRA

algorithms • 5 The main limitation on • 98

U UMTS

algorithms • 23

Page ii ASSET3g Technical Reference Guide Version 5.0.2

ASSET3g Technical Reference Guide

Documents

user reference

account fractional

candidate

channel occupation

circuit switched

ber conversion

hopping frequency

assigned adjacent