ASSET3g Technical Reference Guide

ASSET3g
Technical Reference Guide
Version 5.0.3
© 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 05 September 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:
docs@aircom.co.uk.
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 ?
♦ ♦ ♦
Contents
Appendix A 2g and 2.5g Algorithms
Interference Table Algorithm 6
Interference and Connection Array Calculations 7
Worst Connection Array Calculation Method 8
Average Connection Array Calculation Method 8
Worst Interferer Array Calculation Method 9
Total Interference Array Calculation Method 9
Table of Default C/I BER Conversion Values 10
Frequency Hopping Algorithms 11
Synthesised Hopping Algorithm 13
Non-Frequency Hopping Algorithms 13
Automatic Frequency Planning (ILSA) 14
The Cost Function of the ILSA Algorithm 15
MAIO Planning Cost Function 16
GPRS and HSCSD Capacity Calculations 16
TRX Requirement - Circuit Switched Traffic and HSCSD 16
TRX Requirement - Circuit Switched, HSCSD and GPRS Traffic 17
Grade of Service and Data Rate 18
Channel Occupation Table 19
FCC Calculations 20
Frequency Calculations 22
Appendix B UMTS Algorithms

Notation for UMTS 24
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
ASSET3g Technical Reference Guide Page i

Version 5.0.3
UMTS Iterations 33
Gathering of Results in UMTS 34
UMTS Scenario Prioritisation 35
UMTS Connection Evaluation 35
Production of a Candidate Active Set in UMTS 36
UMTS Uplink Evaluation 37
UMTS Downlink Evaluation 39
UMTS Blocking Probability 40
Calculation of Blocking Probability in the Blocking Report for UMTS 40
Blocking Probability and Failure Rate for UMTS 41
UMTS Coverage Probability Array in the Map View 42
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 48
CDMA2000 Shadow Fade Modelling 48
CDMA2000 Power Control Error Modelling 48
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
Page ii ASSET3g Technical Reference Guide

Version 5.0.3
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 Algorithms

HDR Notation 70
List of Principal Symbols for HDR 70
HDR Basic Formulae 72
HDR Uplink Noise Rise 72
HDR Uplink Load 73
HDR Frequency Re-Use Efficiency 73
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 75
HDR Terminal Speed Modelling 75
Overview of a HDR Snapshot 76
HDR Initialisation of Terminals 76
HDR Initialisation of System Powers 76
HDR Iterations 77
Gathering of Results for HDR 78
Scenario Prioritisation for HDR 79
HDR Connection Evaluation 79
HDR Uplink Evaluation 80
HDR Downlink Evaluation 81
Calculation of Uplink Equivalent Control Overhead Factor for HDR 82
HDR Coverage Probability and Blocking 83
HDR Coverage Probability Array in the Map View Window 83
HDR Blocking Probability and Failure Rate 83
About the HDR Quality of Service Algorithm 84
HDR Outline 85
IP Packet Transmission Time for HDR 85
IP Packet Queueing Delay for HDR 86
Throughput for HDR 88
ASSET3g Technical Reference Guide Page iii

Version 5.0.3
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 95
Time Simulator for QoS Analysis 98
Results of QoS Analysis 100
References 104
Index
Page iv ASSET3g Technical Reference Guide

Version 5.0.3
APPENDIX A
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
ASSET3g Technical Reference Guide Page 5

Version 5.0.3
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. There must be a traffic raster in memory to make this calculation.
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
Page 6 ASSET3g Technical Reference Guide

Version 5.0.3
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.

Version 5.0.3
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.

Version 5.0.3
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.

Version 5.0.3
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

Version 5.0.3
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)

Version 5.0.3
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.

Version 5.0.3
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

Version 5.0.3
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.

Version 5.0.3
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

Version 5.0.3
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 .

Version 5.0.3
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 .

Version 5.0.3
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.

Version 5.0.3
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

Version 5.0.3
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 Minimum of 30 metres
ERP<=10 W 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

Version 5.0.3
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 D = 2.531 x Used Antenna Height(m) ^ 0.34 x Used ERP for
Radial in Watts ^ 0.17
and
Subject to a minimum distance of 5.4 km
32 dBu Unserved
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

Version 5.0.3
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.

Version 5.0.3
APPENDIX B
UMTS Algorithms
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

Version 5.0.3
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
• 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

Version 5.0.3
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 ( = )

Version 5.0.3
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)

Version 5.0.3
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.

Version 5.0.3
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.

Version 5.0.3
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
Pαtotal
J = + Pαpilot
J + Pαcommon
J + Pαsync
J ( )
+ ∑ α ↓j + β ↓j Pαtraffic
Jj
j
(9)

Version 5.0.3
(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 (%)

Version 5.0.3
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.

Version 5.0.3
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.

Version 5.0.3
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.
End of End of
Iteration 1 Iteration 3
<4 5 6 Eb/No <4 5 6 Eb/No
End of End of
<4 5 6 Eb/No <4 5 6 Eb/No
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.

Version 5.0.3
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.

Version 5.0.3
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

Version 5.0.3
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 for

candidate primary cell.
Check handover resource availability & pilot E c I o levels for

candidate 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.

Version 5.0.3
UMTS 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 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 Eb N o for each

cell in candidate active set.
Temporarily set terminal power to the lowest possible power

that will achieve a satisfactory Eb N o value.
Calculate difference between two best Eb N o values achieved

on cells in the candidate active set.
Calculate handover gains, power rise, and

power control headroom.
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 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

Version 5.0.3
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

power rise
The Average Power Rise ( P ) 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

pch
The Power Control Headroom ( H ) 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

power rise
The Soft Handover Gain against Average Power Rise ( G ) reduces the average
power rise
power rise for soft handover cells. For non-handover cells, G = 1.
Soft Handover Gain against Power Control Headroom

pch
The Soft Handover Gain against Power Control Headroom ( G ) 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.

Version 5.0.3
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.
UMTS Downlink Evaluation

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 E c I o values from

cells in the candidate active set.
Read downlink Eb N o target reduction.
Calculate the lowest cell TX power ( T ) that will achieve a

satisfactory Eb N o value.
Set TX powers for cells in candidate active set to T.
Iterate
until Calculate total achieved Eb N o at terminal assuming maximal
Eb/No
achieved ratio combining of links.
or not
changing
between
iterations
Increase/Decrease T if total achieved Eb N o at terminal is
too low/high.
Apply log-normal error to all downlink powers, ensuring that

all downlink power limits and cell power limits are not broken.

Version 5.0.3
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.

Version 5.0.3
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 .
(19)
The probability that exactly C users are offered.
(20)
The probability that more than C users are offered.

(21)
The probability that less than C users are offered.
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.

Version 5.0.3
(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.

Version 5.0.3
APPENDIX C
CDMA2000 Algorithms
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

Version 5.0.3
CDMA2000 Notation
• 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

Version 5.0.3
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

Version 5.0.3
Chip rate
Uplink (downlink) service activity factor

,
Uplink (downlink) bearer control-overhead factor
,
Cable (feeder) noise figure ( = )
CDMA2000 Basic Formulae

Handoff gains, power control headroom, and power rise gain have been ignored.
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

Version 5.0.3
(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.

Version 5.0.3
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.
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:

between fades from a terminal to sectors on different sites.

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
CDMA2000 Power Control Error Modelling

This section describes the power control error modelling for a CDMA2000 network:

Version 5.0.3
power control.
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.
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)

Version 5.0.3
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 (%)

Version 5.0.3
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)
where is a random number taken from a normal distribution of zero mean and
unit variance.
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

Version 5.0.3
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.

Version 5.0.3
CDMA2000 Overview of a Snapshot
This section gives an overview of a CDMA2000 snapshot:
terminals and their states, that is the link powers and handoff state, and a set of
behaviour. A snapshot involves the stages outlined in the following diagram:
Initialisation of System Powers and Resource Usage
CDMA2000 Initialisation of Terminals

attempting to connect to the network. Each pixel is allocated a random, Poisson-
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,
powers to zero, and making all resources available at the sectors.

Version 5.0.3
CDMA2000 Iterations
in the network (at sectors and terminals) is updated before moving on to evaluate the
next terminal.
scenarios). For example a terminal may have several different sectors or carriers that it
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
Terminals that fail to make a connection in an iteration are not removed from the
has been achieved.
iterations. Each histogram shows the distribution of achieved uplink values
for successfully served terminals. All terminals are running a service with an uplink
End of End of
<4 5 6 Eb/No <4 5 6 Eb/No
End of End of
<4 5 6 Eb/No <4 5 6 Eb/No
After the first iteration, the majority of “served” terminals fail to meet their
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 .

Version 5.0.3
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
Convergence Criteria for CDMA2000

interference from terminals (summed over all sectors) changes between iterations.
This is considerably faster than measuring the distribution of achieved values
described above.
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

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)


Version 5.0.3
• 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 Ec I o level for

candidate primary sector.
Check handoff resource availability & pilot Ec I o levels for

candidate 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.

Version 5.0.3
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 Eb N t for each

sector in candidate active set.

that will achieve a satisfactory Eb N t value.
Calculate difference between two best Eb N t values achieved

on sectors in the candidate active set.
Calculate soft handoff TX power reduction.
sectors.
Apply log-normal error to uplink power, ensuring that all sector


Version 5.0.3
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.

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)

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.

Version 5.0.3
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 E b Nt values from

sectors in the candidate active set.
Read downlink Eb N t target reduction.
Calculate the lowest cell TX power ( T ) that will achieve a

satisfactory Eb N t value.
Set TX powers for cells in candidate active set to T .
Iterate
until Calculate total achieved Eb N t at terminal assuming maximal
Eb/Nt
achieved ratio combining of links.
or not
changing
between
iterations
Increase/Decrease T if total achieved Eb N t at terminal is
too low/high.
Apply log-normal error to all downlink powers, ensuring that

all downlink power limits and sector 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.

Version 5.0.3
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

Version 5.0.3
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.
F1 Active Fundamental
Bearer
Inactive Fundamental F2
Bearer
α 1−α
(Active (Inactive
Period) Period)
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:

Version 5.0.3
Uplink RC3 - RC6 When Using a Supplemental Bearer
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.
S1 Active Supplemental Bearer
F1 Active Fundamental Bearer

Inactive Fundamental
F2
Bearer
Active Fundamental
Bearer
P Pilot
1α
α
(Active (Inactive
-
Period) Period)
The average uplink power is given by:
Which can be rewritten as:
Hard-coded look-up tables give , .


Version 5.0.3
Uplink RC3 - RC6 When Not Using a Supplemental Bearer
here the inactive bearer). The following diagram represent the powers transmitted
inactive periods and is the uplink pilot power:
F1 Active Fundamental Bearer

Inactive Fundamental
F2
Bearer
Active Fundamental
Bearer
P Pilot
1α
α
(Active (Inactive
-
Period) Period)
which can be rewritten as:
Hard-coded look-up tables give and .

Version 5.0.3
Downlink RC1 - RC2
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.
F1
Active Fundamental Bearer
Inactive Fundamental Bearer F2
α 1-α
(Active Period) (Inactive Period)
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:

Version 5.0.3
Downlink RC3 - RC10
inactive period, the terminal maintains a downlink using an 1/8th rate bearer (called
here the inactive bearer). The followingdiagram represent the powers transmitted
inactive periods periods.
S1 Active Supplemental Bearer
F1 Active Fundamental Bearer F2

Inactive Fundamental Bearer
α 1-α
(Active Period) (Inactive Period)
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:

Version 5.0.3
CDMA2000 Blocking Probability
• 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
tool, since the probabilities in the tool are all found by sampling snapshots.

Version 5.0.3
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 .
(18)
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)
(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
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.
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.

Version 5.0.3
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,
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.

Version 5.0.3
APPENDIX D
HDR Algorithms
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

Version 5.0.3
HDR Notation
• 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.
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.

Version 5.0.3
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 ( = ).

Version 5.0.3
HDR Basic Formulae
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.

Version 5.0.3
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

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:

between fades from a terminal to cells on different sites.

between fades from a terminal to cells on the same site.
The two parameters must satisfy the constraints .

Version 5.0.3
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
HDR Power Control Error Modelling

power control.
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.
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 .

Version 5.0.3
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)
where is a random number taken from a normal distribution of zero mean and
unit variance.

Version 5.0.3
Overview of a HDR Snapshot
terminals and their state, that is the link powers and handoff state, and a set of
behaviour.
A snapshot involves the following stages:
Initialisation of System Power
HDR Initialisation of Terminals

attempting to connect to the network. Each pixel is allocated a random, Poission-
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,
powers to zero.

Version 5.0.3
HDR Iterations
in the network is updated before moving on to evaluate the next terminal.
scenarios). For example, a terminal may have several different cells or carriers that it
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
Terminals which fail to make a connection in an iteration are not removed from the
has been achieved.
iterations. Each histogram shows the distribution achieved uplink values for
successfully served terminals. All terminals are running a service with an uplink

Version 5.0.3
After the first iteration, the majority of served terminals fail to meet their
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
Convergence Criteria for HDR

interference from terminals (summed over all cells) changes between iterations. This
is considerably faster than measuring the distribution of achieved values as
previously described.
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

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.

Version 5.0.3
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:

Version 5.0.3
HDR Uplink Evaluation
The following diagram shows the process of determining the terminal transmit power
required to meet the uplink requirement:
Calculate required terminal power to meet Eb N t for each

cell in candidate active set.

that will achieve a satisfactory Eb N t value.
Calculate difference between two best Eb N t values achieved

on cells in the candidate active set.
Calculate soft(er) handoff TX power reduction.
cells.
Apply log-normal error to uplink power, ensuring that all cell

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.

requirement.

Version 5.0.3
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)

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

Version 5.0.3
Calculation of Uplink Equivalent Control Overhead
Factor for HDR
The following diagram represents the powers transmitted during active and inactive
periods:
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:
P_dBm = T_dBm – dataOffsetNom_dB – dB – dataOffsetRate_dB
DataOffsetRate_dB depends on the air interface bitrate of the bearer:
9600 dataOffsetRate_dB = dataOffset9k6dB – 3.75
The tool provides default values of dataOffsetNom_dB and dataOffsetRate_dB that
make (P_dBm = T_dBm) for all bearers.

Version 5.0.3
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.
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 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
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)

Version 5.0.3
(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
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

Version 5.0.3
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.

Version 5.0.3
• 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.

Version 5.0.3
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.

Version 5.0.3
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.

Version 5.0.3
APPENDIX E
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
References

Version 5.0.3
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

• 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

Version 5.0.3
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:
N = λ .T

Version 5.0.3
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.

Version 5.0.3
• 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:
T = (N pc − 1)D pc + N pc ( N d − 1)Dd
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.

Version 5.0.3
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 Modulation Peak Rate per Slot Blocks Per RLC Block
Family (kb/s) 20 ms 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.

Version 5.0.3
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 98.
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 98.

Version 5.0.3
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
PeakDataRatePerSlot = 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 103.
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*

Version 5.0.3
8 1024* 17 20 000 000
9 2048* 18 50 000 000
*Data rate only reachable 31 Best Effort
with UMTS or EDGE
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:
PeakThroug hput = PeakDataRa tePerSlot * BlocksPerF rame * MaxNumberO fSlots
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.

Version 5.0.3
Time Simulator for QoS Analysis
• 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.

Version 5.0.3
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.

Version 5.0.3
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

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

Version 5.0.3
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
, and variance σ .
2
interval half width Hi is then calculated from the sample mean
k
Yi
Y =∑
i =1 k
σ =∑
2
k
(Yi −Y )
2
i =1 (k − 1)
2.σ
Hi =
m
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:
N req
= required number of packets
S req N req
= number of sessions required to generate packets
Treq S req
= time until the session arrives
D = recommended simulation duration
N pc .N d
Each session contains packets, so
N req
S req =
N pc .N d
(1)
The session arrivals are modelled as a Poisson process, and so the expected time until
S req
the session arrives is:
S req
Treq =
λ (2)

Version 5.0.3
Substituting Little's law and equation (1) and (2),
N req .T
Treq =
N pc .N d .N
S req
Adding the duration of the session itself, the simulation duration is:
⎛ N req ⎞
D=⎜ + 1⎟.T
⎜ N . N .N ⎟
⎝ pc d ⎠
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
TP = ∑ ci
i =0
Delay probability of n.F frames:

cn
P ( n) =
TP

Version 5.0.3
Cumulative delay probability of n.F frames:
n
∑c i
CP (n) = i =0
TP
Mean and Standard Deviations of the Queuing Delays

The following are the mean and standard deviations of the queuing delays:
N
D = F .∑ n.P (n)
Mean delay n =0
∑ (F .n − D ) .P(n)
N
σ=
2
n =0
Standard deviation
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:
8.S d
Ttrans =
1000.b
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)..

Version 5.0.3
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:
⎛ BLER ⎞
Mean retransmis sion delay = 0.01.⎜⎜τ rt + 1⎟⎟seconds
⎝ (1 − BLER ) ⎠
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

Version 5.0.3
S
Snapshots
algorithm • 32
Index T
TETRA
algorithms • 5
The main limitation on • 100
U
A
UMTS
Algorithms algorithms • 23
CDMA2000 • 43
FCC calculations • 20
Frequency hopping • 11
Frequency Re-use and Load • 22
GPRS and HSCSD capacity • 16
HDR • 69
ILSA cost function • 14, 15
Interference arrays • 7
Interference Tables • 6
MAIO planning cost function • 16
Non-Frequency hopping • 13
Packet QoS • 89
UMTS • 23
C
CDMA2000
algorithms • 43
G
GPRS
algorithms • 5
GSM
algorithms • 5
H
HDR
algorithms • 69
HSCSD
algorithms • 5
M
Monte Carlo, algorithm • 23, 32, 35, 40
P
Packet Switched QoS algorithms • 89
Q
QoS
algorithms • 89
ASSET3g Technical Reference Guide Page i

Version 5.0.3
Page ii ASSET3g Technical Reference Guide
Version 5.0.3

ASSET3g Technical Reference Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ASSET3g Technical Reference Guide

Hochgeladen von

Copyright:

Verfügbare Formate

ASSET3g

Technical Reference Guide

AIRCOM International Ltd

Telephone: +44 (0) 1737 775700

Do the Help and User Reference Guides Help You?

Appendix B UMTS Algorithms

ASSET3g Technical Reference Guide Page i

Appendix C CDMA2000 Algorithms

Page ii ASSET3g Technical Reference Guide

Appendix D HDR Algorithms

ASSET3g Technical Reference Guide Page iii

Page iv ASSET3g Technical Reference Guide

2g and 2.5g Algorithms

This chapter describes the following topics:

ASSET3g Technical Reference Guide Page 5

C/I and C/A weights curve

Page 6 ASSET3g Technical Reference Guide

Interference and Connection Array Calculations

ASSET3g Technical Reference Guide Page 7

Average Connection Array Calculation Method

is the averaged C/I for the hopping carriers.

is frequency Diversity Gain

is the fractional loading, calculated as follows:

, where is the number of hopping TRX

are the non-hopping frequencies

Page 8 ASSET3g Technical Reference Guide

Worst Interferer Array Calculation Method

Total Interference Array Calculation Method

ASSET3g Technical Reference Guide Page 9

Page 10 ASSET3g Technical Reference Guide

Frequency Hopping Algorithms

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

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

ASSET3g Technical Reference Guide Page 11

Page 12 ASSET3g Technical Reference Guide

is the number of TRX allocated to the hopping carrier layers

Non-Frequency Hopping Algorithms

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

ASSET3g Technical Reference Guide Page 13

Example C/I/Probability Curve

Automatic Frequency Planning (ILSA)

Page 14 ASSET3g Technical Reference Guide

= 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 weighting factor applicable to carrier allocation i

ASSET3g Technical Reference Guide Page 15

and are traffic and area percentages

and are traffic and area associated with sub-cell c

and are interference matrix coefficients

GPRS and HSCSD Capacity Calculations

TRX Requirement - Circuit Switched Traffic and HSCSD

Page 16 ASSET3g Technical Reference Guide

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

ASSET3g Technical Reference Guide Page 17

Circuit Switched Traffic

= HSCSD traffic load

= number of CS timeslots that may be allocated to HSCSD

Page 18 ASSET3g Technical Reference Guide

Channel Occupation Table

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