ASSET3g Technical Reference Guide

ASSET3g Technical Reference Guide Version 5.0.2

© Copyright 2005 AIRCOM International Ltd All rights reserved ADVANTAGE, AIRCOM, ARRAY WIZARD, ASSET3g, CONNECT, DATASAFE, ENTERPRISE, NEPTUNE, OPTIMA, QUALITA, RANOPT, TARGET and WEBWIZARD are recognised trademarks of AIRCOM International. Microsoft Word, Microsoft Office, Windows®, Windows 95™, Windows 98™, Windows NT®, Windows XP® and MS-DOS™ are trademarks of the Microsoft Corporation. Other product names are trademarks of their respective companies. This documentation is protected by copyright and contains proprietary and confidential information. No part of the contents of this documentation may be disclosed, used or reproduced in any form, or by any means, without the prior written consent of AIRCOM International. Although AIRCOM International has collated this documentation to reflect the features and capabilities supported in the software products, the company makes no warranty or representation, either expressed or implied, about this documentation, its quality or fitness for particular customer purpose. Users are solely responsible for the proper use of ENTERPRISE software and the application of the results obtained. An electronic version of this document exists on our website. This User Reference Guide finalised on 11 May 2005. Refer to the Online Help for more information. This User Reference Guide prepared by: AIRCOM International Ltd Grosvenor House 65-71 London Road Redhill Surrey RH1 1LQ ENGLAND Telephone: Support Hotline: Fax: Web:

+44 (0) 1737 775700 +44 (0) 1737 775777 +44 (0) 1737 775770 http://www.aircom.co.uk

Can You Improve Our User Assistance?

Do the Help and User Reference Guides Help You? AIRCOM is always working to improve the online Help and User Reference Guides for our products, so that your job is easier to do. Even if you would not normally do so, please take a look at the Help or User Reference Guide next time you are unsure of how to do something and if you have any comments or questions that could help us improve them, please email us on: [email protected]. We highly value your comments, suggestions, and criticisms. If you did not find the user assistance you were looking for, needed more assistance than the online help or user reference guides provided, or have any suggestions for future improvements to our information, we want to know. Specifically, consider: •

Is the information accurate and complete?

•

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

•

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

♦

♦

♦

Contents Appendix A 2g and 2.5g Algorithms Interference Table Algorithm

5

Interference and Connection Array Calculations

6

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

7 8 8 9 9

Frequency Hopping Algorithms

10

Synthesised Hopping Algorithm

12

Non-Frequency Hopping Algorithms

12

Automatic Frequency Planning (ILSA)

13

The Cost Function of the ILSA Algorithm

14

MAIO Planning Cost Function

14

GPRS and HSCSD Capacity Calculations

15

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

15 15 16 17

FCC Calculations

18

Frequency Calculations

20

Appendix B UMTS Algorithms Notation for UMTS

23

List of Principal Symbols for UMTS

24

UMTS Basic Formulae

26

UMTS Uplink Noise Rise

27

UMTS Uplink Load

27

UMTS Frequency Re-Use Efficiency

27

UMTS Air Interface and User Bitrates

27

UMTS Shadow Fade Modelling

28

UMTS Power Control Error Modelling

29

UMTS Service Activity Modelling

29

UMTS Activity Factor Calculation For Packet Services (Web Model)

30

UMTS Transmit/Receive Diversity Modelling

31

UMTS Terminal Speed Modelling

31

UMTS Overview of a Snapshot

32

UMTS Initialisation of Terminals Initialisation of System Powers and Resource Usage in UMTS ASSET3g Technical Reference Guide Version 5.0.2

32 32 Page i

UMTS Iterations Gathering of Results in UMTS

33 34

UMTS Scenario Prioritisation

34

UMTS Connection Evaluation

35

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

35 36 38

UMTS Blocking Probability

39

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

39 40 41

Appendix C CDMA2000 Algorithms CDMA2000 Notation

44

List of Principal Symbols for CDMA2000

44

CDMA2000 Basic Formulae

46

CDMA2000 Uplink Noise Rise

47

CDMA2000 Uplink Load

47

CDMA2000 Frequency Re-Use Efficiency

47

CDMA2000 Air Interface and User Bitrates

47

CDMA2000 Shadow Fade Modelling

48

CDMA2000 Power Control Error Modelling

49

CDMA2000 Service Activity Modelling

49

CDMA2000 Activity Factor Calculation For Packet Services (Web Model)

50

CDMA2000 Transmit/Receive Diversity Modelling

51

CDMA2000 Terminal Speed Modelling

51

PN Code Assignment Algorithm for CDMA2000

51

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

51 52 52

CDMA2000 Overview of a Snapshot

53

CDMA2000 Initialisation of Terminals Initialisation of System Powers and Resource Usage in CDMA2000 CDMA2000 Iterations Gathering Of Results in CDMA2000

CDMA2000 Scenario Prioritisation

55

CDMA2000 Connection Evaluation

56

Production of a Candidate Active Set in CDMA2000 CDMA2000 Uplink Evaluation CDMA2000 Downlink Evaluation

Calculation of Equivalent Control Overhead Factors for CDMA2000 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 Page ii

53 53 54 55


56 57 59

60 61 62 63 64 65

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

66 66 66 67

Appendix D HDR Algorithms69 HDR Notation

69

List of Principal Symbols for HDR

70

HDR Basic Formulae

71

HDR Uplink Noise Rise

72

HDR Uplink Load

72

HDR Frequency Re-Use Efficiency

72

HDR Air Interface and User Bitrates

73

HDR Shadow Fade Modelling

73

HDR Power Control Error Modelling

74

HDR Service Activity Modelling

74

HDR Transmit/Receive Diversity Modelling

74

HDR Terminal Speed Modelling

75

Overview of a HDR Snapshot

75

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

76 76 76 78

Scenario Prioritisation for HDR

78

HDR Connection Evaluation

78

HDR Downlink Evaluation HDR Uplink Evaluation

79 79

Calculation of Uplink Equivalent Control Overhead Factor for HDR

81

HDR Coverage Probability and Blocking

82

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

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

82 82

83 84 84 85 87

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

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 ASSET3g Technical Reference Guide Version 5.0.2

90 90

90 91 92 93 94 94 Page iii

Time Simulator for QoS Analysis Results of QoS Analysis

97 99

References

103

Appendix F ASSET3g File Formats Simulation Array File Formats

105

3ga File Format

106

Live Traffic File Formats for 2g Networks

108

NMS File Format GSM File Format TPS File Format

108 108 109

Live Traffic File Formats for 3g Networks

109

About the *.tpc File Format About the Bearer Traffic File Formats (*.cbc / *.cbd)

Index

Page iv


109 110

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

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

Description

Co-channel Traffic

The amount of traffic served by cell A that would be affected by interference if A and B were to be assigned the same carrier.

Co-channel Area

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

Adjacent Channel Traffic

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

Adjacent Channel Area

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

The values for area are obtained by averaging the probability of interference over the region where A is the best server. The average is taken over all pixels in the appropriate coverage array. For traffic, the value to be averaged is the probability of interference x the traffic (in mE) at that pixel. Thus it is necessary to have a traffic raster available to make this calculation.


Page 5

The probability of interference at a given pixel is calculated using a standard statistical technique based on a C/I signal threshold value and a standard deviation. The assumption is that a difference in signal level between server and interferer exactly equal to the threshold value would give rise to a 50% chance of co-channel interference. For more information on how these values can be specified, see About the Interference Table Needed for ILSA. By default, a -18dB offset is used for the adjacent channel interference, relative to the co-channel interference. This means that if, for example, the co-channel C/I threshold value is set at 9dB, a signal difference of -9dB between server and adjacent channel interferer would give rise to a 50% chance of adjacent channel interference. The C/A offset can be modified in the Array Settings dialog box. All signal differences are converted into probabilities of interference. This graph displays the spread of probabilities for both C/I and C/A based on the default Interference Weights. Here, the C/I signal threshold value is 9 dB, using a standard deviation of 7.78dB.

C/I and C/A weights curve

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

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

Description

Worst Connection C/Ic

Determines the co-channel C/I levels for all of the possible interfering frequencies that may be used by the MS-BTS connection. Each pixel presents the worst C/Ic level and frequency.

Worst Connection C/Ia

Determines the adjacent channel C/I levels for all of the possible interfering frequencies that may be used by the MS-BTS connection. Each pixel presents the worst C/Ia level and frequency.

Worst Connection C/(Ic+Ia)

Determines the combined co-channel/adjacent channel C/I levels for all of the possible interfering frequencies that may be used by the MS-BTS connection. Each pixel presents the worst C/I level and frequency.

Page 6


Average Interference C/Ic

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

Average Interference C/Ia

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

Average Interference C/(Ic_Ia)

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

Worst Interference C/Ic

For non-frequency hopping networks sums all of the co-channel C/I levels for an interfering frequency. Each pixel presents the total C/I level, server and interfering sub-cells and interfering frequency.

Worst Interference C/Ia

For non-frequency hopping networks sums all of the adjacent channel C/I levels for an interfering frequency. Each pixel presents the total C/I level, server and interfering sub-cells and interfering frequency.

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

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

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

•

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

The Worst Connection Array calculates the C/I per connection, summing over all interferers, and then selects the connection with the lowest C/I. The algorithm for this is as follows:

Where: For each non-hopping carrier fi in the serving sub-cell, C/I(fi) is calculated. For the hopping frequency group in the serving sub-cell, a single C/I(FH) is calculated.


Page 7

Average Connection Array Calculation Method The Average Connection Array calculates the C/I per connection, summing over all interferers, and then calculates the average of those. The algorithm for this is as follows:

(2) Where: is the averaged C/I for the hopping carriers. is the number of hopping frequencies. is the number of non-hopping frequencies. is frequency Diversity Gain is the fractional loading, calculated as follows:

, where

is the number of hopping TRX

are the non-hopping frequencies For each non-hopping carrier fri in the serving sub-cell, C/I(fri) is calculated. For the hopping frequency group in the serving sub-cell, a single C/I(FH) is calculated. Note : The denominator in the equation above can never be zero ( and cannot both be 0 at the same time). This is because ASSET3g does not allow you to set the total number of TRX allocated to a sub-cell to zero, if at least one carrier layer is allocated.

Worst Interferer Array Calculation Method The Worst Interferer Array calculates the C/I per frequency, summing over all interferers, and selects the frequency with the lowest C/I. It also finds the interferer that causes the most interference on that frequency. Note : This array does not take into account fractional loading. The most interfered frequency and its corresponding C/I are calculated as follows:

Page 8

If

, then

If

, then


Where: For each (non-hopping) carrier f1 in the serving sub-cell, C/I(f1) is calculated. The worst interferer is calculated as follows:

Total Interference Array Calculation Method The Total Interference Array calculates the C/I per frequency, summing over all interferers, and then sums the C/I for each frequency at the serving cell. Note : This array does not take into account fractional loading. The total interference is calculated as follows:

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

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

Bit Error Rate

-10

0.5000000000

-9

0.4880000000

-8

0.4650000000

-7

0.4300000000

-6

0.3880000000

-5

0.3500000000

-4

0.3200000000

-3

0.3000000000

-2

0.2700000000

-1

0.2500000000

0

0.2200000000

1

0.2000000000

2

0.1700000000

3

0.1500000000

4

0.1200000000

5

0.1000000000

6

0.0900000000

7

0.0780000000

8

0.0660000000

9

0.0550000000


Page 9

10

0.0450000000

11

0.0370000000

12

0.0300000000

13

0.0260000000

14

0.0200000000

15

0.0150000000

16

0.0120000000

17

0.0080000000

18

0.0060000000

19

0.0040000000

20

0.0020000000

21

0.0007000000

22

0.0001000000

23

0.0000070000

24

0.0000004000

25

0.0000000100

26

0.0000000001

27-45

0.0000000000

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

, α is used if

1 is used if

, 0 is used otherwise

Where:

Page 10

C/I(i)

=

C/I ratio for frequency i

SSC(i)

=

Signal strength from frequency i for serving cell

i,j

=

A particular frequency

N

=

Number of interfering cells

n

=

Number of frequencies in serving cell

m

=

Number of frequencies in interfering cell K


SIC(K,i)

=

Signal strength from frequency i for interfering cell K

K

=

Interfering cell

L(K,j)

=

Load in interfering cell K on frequency j

V(K,j)

=

DTX factor in interfering cell K on frequency j

f (i)

=

Fractional loading for frequency i for interfering cell

α

=

Adjacent interference factor

Each C/I(i) is converted to a Bit Error Rate, BER(i) This graph shows the relationship between the Probability of Bit Error and the C/I:

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

Where: x Number of FH frequencies per TRX mFH

Number of FH frequencies/serving cell

nTRX

Number of TRX/serving cell

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


Page 11

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

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

Where: is the number of TRX allocated to the hopping carrier layers is the number of hopping carriers

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

1 is used if

, α is used if

, 0 is used otherwise

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

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

Page 12


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.


Page 13

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

Where: =

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

=

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

=

The frequency allocated at allocation i

=

Members of the set of all frequency allocations

=

The retune cost associated with allocation i

=

The fixed or forbidden carrier cost associated with allocation i

=

The separation costs (from equipment, neighbours, exceptions or close separations) between allocations i and j

=

The handover count and intermodulation interference costs associated with allocation i

=

The weighting factor applicable to carrier allocation i

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

Where: are sub-cells

and

Page 14

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 subcells

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 ( Grade of Services and a choice of Erlang table.

) given specified two

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 and

is equal to or greater than

is greater than or equal to

.

TRX Requirement - Circuit Switched, HSCSD and GPRS Traffic For cells where GPRS is enabled, the number of TS required from the shared traffic channels for the GPRS ( average GPRS data rate per TS (

) traffic load (

) can be determined using the

):

The total number of TS required for CS and GPRS traffic (

) can then be

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


and the

Page 15

Where: is total shared traffic channels required is average (long term) number of TS required for Circuit Switched traffic (= is average (long term) number of TS required for HSCSD traffic (=

) )

The channel occupation efficiency (e) is determined by first calculating ( ) without dividing by e and then using the result to look up e in the Channel Occupation table. The number of TRX required and are determined using the channel to transceiver map by increasing the number of TRX from the result of the previous section until the number of available TS for traffic (NCS allocation) is equal to or greater than

.

Grade of Service and Data Rate Circuit Switched Traffic This section presents the calculation for the blocking for the current allocation of TRX for CS and for each HSCSD multi-slot type traffic (%). It has been assumed throughout that CS traffic and HSCSD traffic will take precedence over GPRS traffic and therefore the Grade of Service for CS and HSCSD will not be affected by the GPRS load. Calculate the blocking for the CS traffic given the traffic load ( current allocation of TRX using the selected Erlang table.

) the

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

Page 16


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

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

Where: e

is the efficiency from the Channel Occupation table determined from N is the number of TS from the Channel Carrier Map for the current allocation of TRX

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


Page 17

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

Example of Channel Occupation Table, for Illustrative Purposes Only

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

Antenna Height AAT The Antenna Height AAT is calculated in metres. The calculation is: Antenna height + Site ground height + Radial average terrain elevation The Radial average terrain elevation is the average ground height mapped along a radial of between 3 km and 16 km from the site. If the mapping data prevent this then it will not be calculated and this will be flagged in the FCC report. Note : Feature height data and clutter heights are ignored in the calculation. The best available resolution of the map data is used for this calculation. If the best map data is 1000 m resolution then you will receive a warning noting that the map data is of insufficient resolution for the FCC form.

Page 18


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

N/A

Minimum of 8 metres

Gulf of Mexico

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

Transmitting ERP Watts The transmitting ERP for a cardinal radial is the radiated power in Watts taking into account the antenna gain for the azimuth, the down tilt and the base station powers/losses. Note : You will receive a warning if the ERP exceeds 500W.

Used ERPS This is the value of the transmitting ERP which is used in the calculations, it is the Transmitting ERP subject to certain minima. Used ERP is the maximum of: •

0.1 W

•

Maximum ERP/500

•

Transmitting ERP for the radial

Area within the Service Area Boundary This will be calculated by finding the distance to the SAB for each degree by linear interpolation of distance as a function of angle, hence dividing the area into triangular sectors, joining at the site. The total area is then calculated by adding up the areas of each of the triangles. Heron's Formula for calculation of area of scalene triangle: A = SQR(S (S-a) (S-b) (S-c)) SQR - Square Root a, b, c – sides of the triangle S – half the perimeter of triangle, that is (a+b+c)/2


Page 19

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 32 dBu Unserved Gulf of Mexico

Subject to a minimum distance of 5.4 km D = 6.895 x Used Antenna Height(m) ^ 0.30 x Used ERP for Radial (W) ^ 0.15 There is no minimum distance for this SAB

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

Effective Frequency Re-use The effective frequency re-use is an approximate indication of the quality of the hopping network. It can be calculated for each subcell and also the average of these calculated to give a figure for the network as a whole.

Where: REFF is the Effective Frequency Re-use for a subcell NF is the total number of carriers available to hopping TRX on the subcell (note: this is not the MA list length) NTRX is the number of hopping TRX on the subcell

Frequency Load The average frequency load is another approximate indication of the quality of the hopping network. It can be calculated for each subcell and also the average of these calculated to give a figure for the network as a whole.

Where: LFREQ is the Frequency Load of a subcell Page 20


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.


Page 21

Page 22


APPENDIX B

UMTS Algorithms This chapter describes the following topics:

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

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

A Greek subscript always indexes a carrier

•

indicates a sum over all carriers

• • • •

An uppercase Roman subscript always indexes a cell indicates a sum over all cells A lowercase Roman subscript always indexes a terminal indicates a sum over all terminals


Page 23

•

indicates a sum over all terminals in cell J

•

Up and down arrows

•

All quantities are in standard SI units, never in dB

indicate if a quantity is uplink or downlink

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

for the uplink

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

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

,

carrier β to carrier α. (

)

Uplink Downlink Pilot Uplink (downlink) processing gain Cell antenna gain Terminal antenna gain Mast head amplifier gain Boltzmann constant Mast head amplifier (downlink) insertion loss Uplink (downlink) linkloss between cell and terminal Pathloss between cell and terminal Antenna masking loss Cable (feeder) loss Terminal body loss Thermal noise at terminal Thermal noise at cell

Page 24


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 ( =


)

Page 25

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)

Page 26


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 ( the air interface bitrate.

,

) is calculated by dividing the system chiprate by

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


Page 27

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

Page 28


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 = + Pαpilot + Pαcommon + Pαsync + ∑ α ↓j + β ↓j Pαtraffic J J J J Jj j


(9)

Page 29

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

Page 30


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 ( and the maximum speed (

), the minimum 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.


Page 31

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

Page 32


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 Iteration 1

<4

5

End of Iteration 3

6

Eb/No

<4

5

6

Eb/No

6

Eb/No

End of Iteration 7

End of Iteration 5

<4

5

6

Eb/No

<4

5

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.


Page 33

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

Convergence Criteria for UMTS A good practical measure of convergence is to examine how the total uplink interference from terminals (summed over all cells) changes between iterations. This is considerably faster than measuring the distribution of achieved values. If the percentage change in total uplink interference changes by an amount smaller than the threshold that you have specified then the iterations are deemed to have converged. The default threshold is a 1% change in the interference between iterations. You also sets the maximum number of iterations that may be performed in any one snapshot (default = 10).

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

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

Carrier

•

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

•

Primary cell

•

Page 34

of primary cell

•

UL bearer

•

DL bearer


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

Underloaded (before overloaded) carriers

•

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

•

Higher (before lower)

•

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

•

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

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

Production of a candidate active set for the terminal

•

Uplink evaluation

•

Downlink evaluation

Production of a Candidate Active Set in UMTS In order for a cell to be in the candidate active set of a terminal, it must have an or adequate number of primary or handover resources available, and the pilot 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.


Page 35

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

N o for each

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

Page 36


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 The Soft Handover Gain against Average Power Rise ( G

power rise

power rise for soft handover cells. For non-handover cells, G

) reduces the average

power rise

= 1.

Soft Handover Gain against Power Control Headroom The Soft Handover Gain against Power Control Headroom ( G control headroom when a terminal is in soft handover.

pch

) reduces the power

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.


Page 37

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

is finally given a random (logserved. If the uplink can be successfully achieved, normal) adjustment to model the effect of imperfect power control.

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

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

Iterate until Eb/No achieved or not changing between iterations

Calculate total achieved

T.

Eb N o at terminal assuming maximal

ratio combining of links.

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.

Page 38


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.


Page 39

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 second and mean holding time

, and Poisson traffic with arrival rate

users per

seconds. The mean offered traffic is

The probability that exactly C users are offered.

. (19) (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 to each other for low blocking probabilities. Note : The “Failure Rate” ( terminals that fail. Page 40

. The two probabilities are most similar

) in the failure report is the proportion of offered


(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 passivescanning technique, which is totally independent of the global passive-scanning used for the Map View.


Page 41

Page 42


APPENDIX C

CDMA2000 Algorithms This chapter describes the following topics:

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


Page 43

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

A Greek subscript always indexes a carrier. indicates a sum over all carriers.

•

An uppercase Roman subscript always indexes a sector. indicates a sum over all sectors

•

.

A lowercase Roman subscript always indexes a terminal. indicates a sum over all terminals. indicates a sum over all terminals in sector J.

•

Up and down arrows

•

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

indicate if a quantity is uplink or downlink.

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

for the uplink

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 Terminal antenna gain Mast head amplifier gain Boltzmann constant

Page 44


Mast head amplifier (downlink) insertion loss Uplink (downlink) linkloss between sector and terminal , Pathloss between sector and terminal Antenna masking loss Cable (feeder) loss TX combiner loss (downlink) RX splitter loss (uplink) Terminal body loss Thermal noise at terminal 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 terminal Total received power at sector Temperature


Page 45

Chip rate Uplink (downlink) service activity factor , Uplink (downlink) bearer control-overhead factor , Terminal noise figure Base station noise figure Mast head amplifier noise figure


)

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

(2)

(3)

(4)

(5)

(6)

(7) (8)

(9)

Page 46


(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 insector terminals divided by the total received power coming from all terminals. The frequency re-use efficiency on carrier α of sector J is given by: (13)

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

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

,

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

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


Page 47

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

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

•

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

These two parameters must satisfy the constraints

.

For each terminal in a snapshot, a set of correlated fades to sectors is generated using the following procedure: Note : All the random numbers mentioned are independent and normally distributed with zero mean and unit variance. 1

Generate a random number

2

For each site

3

For each sector

4

The fade (in dB) to sector

.

, generate a random number , generate a random number on site

. .

is then set to (14)

where

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

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

Page 48


CDMA2000 Power Control Error Modelling This section describes the power control error modelling for a CDMA2000 network: The simulator does not explicitly model the power control process, but it allows the simulation results to exhibit certain features one would associate with imperfect power control. The standard deviation of power control error parameter controls the distribution of achieved

values for successfully served terminals. If the standard deviation is

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

values at a sector.

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

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

Consumption of Resources A successfully served circuit switched service will consume the same number of resources regardless of the service activity factor. The number of resources in this case depends only on the bearer used. A successfully served packet switched service will consume a partial number of resources depending on the service activity factor. For example, if a PS service is served using a bearer that requires 2 resources and the activity factor is 1%, then 0.02 resources will be consumed.

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

Calculation of Interference Equations: (9)


Page 49

(10)

and (11)

all have a dependence on

or

.

CDMA2000 Activity Factor Calculation For Packet Services (Web Model) Using the same notation as given in the WWW traffic model, the activity factor formula is:

Where: = Average packet time period (s) = Size of a Packet (bytes) = the Max Bit Rate the particular service supports (bit/s) = Average session time period (s) = Number of packet calls per session = Reading time between packet calls (s) = Number of packets within a packet call = Inter arrival time between packets in a packet call (s) = Retransmission factor (%)

Page 50


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 requirement is used on sectors requirements for the downlink (uplink). One with transmit (receive) diversity and the other is used on sectors without transmit (receive) diversity.

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

The mean speed (

•

The standard deviation of the speed distribution (

•

The minimum speed (

)

•

The maximum speed (

).

) )

A random speed is then given by: (15)


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

Find the most difficult sector to assign a PN code.

2

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

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

Difficulty Factor for CDMA2000 The difficulty factor, DF, for a sector is calculated as: Where: A is the number of adjacent sectors is the number of adjacent sectors with codes assigned


Page 51

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.

Page 52


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

Initialisation of System Powers and Resource Usage



CDMA2000 Initialisation of Terminals The first stage of a snapshot involves creating a geographical distribution of terminals attempting to connect to the network. Each pixel is allocated a random, Poissondistributed, number of terminals, according to the mean number of terminals specified for the pixel in the terminal-density array. Also during this initialisation stage, each terminal is given a set of random log-normal fades, one for each sector that covers it, that is it has a pathloss to it. A random Power Control Error is chosen for the uplink and downlink. A terminal will use the same random values (fading, power control error, activity flags and speed) for the duration of its existence in a snapshot. 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 CDMA2000 Before commencing the iterative process, the system is placed in a known state, namely the state of an unloaded network. This is simply done by setting all link powers to zero, and making all resources available at the sectors.


Page 53

CDMA2000 Iterations An iteration involves sequentially evaluating the terminals (precisely once) to see if they can make a connection to the network. After each terminal is evaluated, the noise in the network (at sectors and terminals) is updated before moving on to evaluate the next terminal. A terminal may connect to the network in a variety of different ways (connection scenarios). For example a terminal may have several different sectors or carriers that it may use. Each of the connection scenarios for a terminal is evaluated in turn until one that allows a successful connection is found. If no scenario can produce a successful connection to the network, the link powers for the terminal are set to zero, and the reasons for failure of the first scenario are recorded. Terminals that fail to make a connection in an iteration are not removed from the simulation, since success or failure in an iteration does not necessarily ensure the same result in a subsequent iteration. In fact, the state (succeeded/failed) of a terminal is determined purely by its state in the final iteration of a snapshot when convergence has been achieved. The following diagram illustrates how a snapshot converges with successive iterations. Each histogram shows the distribution of achieved uplink values for successfully served terminals. All terminals are running a service with an uplink requirement of 6 dB. End of Iteration 1

<4

5

End of Iteration 3

6

Eb/No

<4

5

6

Eb/No

6

Eb/No

End of Iteration 7

End of Iteration 5

<4

5

6

Eb/No

<4

5

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 .

Page 54


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

Convergence Criteria for CDMA2000 A good practical measure of convergence is to examine how the total uplink interference from terminals (summed over all sectors) changes between iterations. This is considerably faster than measuring the distribution of achieved described above.

values

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

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

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

Carrier

•

Primary sector

•

of primary sector

•

UL bearer

•

DL bearer

•

UL radio configuration (CDMA2000 only),

•

DL radio configuration (CDMA2000 only)

•

Required


(HDR only)

Page 55


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

•


•

Higher (before lower)

•

Higher (before lower) required

•

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

•

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

(CDMA2000 only) (HDR only)

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

•

Uplink evaluation

•

Downlink evaluation

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 for adequate number of primary or handoff resources available, and the pilot 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.

Page 56


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 requirement. It is necessary to consider several effects here, such as uplink 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 cell in candidate active set.

Temporarily set terminal power to the lowest possible power that will achieve a satisfactory E b N t value.

Calculate difference between two best E b N t values achieved on cells in the candidate active set.

Calculate soft handoff TX power reduction.

See if terminal has sufficient power to make link.

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

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


Page 57

For each sector in the candidate active set, the terminal transmit power required to is calculated. This lowest of these values is then quantised meet the uplink 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 ( in the Services dialog box. The terminal power reduction (

) to be determined from the tables that you set ) is a gain that reduces the required

transmit power of the terminal. It is equivalent to a reduction in the uplink requirement. After the terminal power reduction has been calculated, the terminal is checked to see if it has sufficient power to make the uplink. The actual transmit power of the terminal (

) is given by: (16)

The uplink

requirement can be satisfied if (17)

where


The terminal is also checked to see if it will break the noise rise limit on any of the covering sectors. When calculating the interference, the terminal power is taken as . If the terminal cannot meet the uplink requirement without breaking a noise rise limit, then the terminal fails to be served. If the uplink can be successfully is finally given a random (log-normal) adjustment to model the effect achieved, of imperfect power control.

Page 58


CDMA2000 Downlink Evaluation This is the process of determining the sector transmit powers required to meet the requirement at the terminal. It is necessary to consider the effect of downlink maximal ratio combining when there are multiple links. The downlink evaluation follows the following procedure: Calculate difference between two best Eb N t values from cells 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 Eb/No achieved or not changing between iterations

Calculate total achieved Eb N t at terminal assuming maximal ratio combining of links.

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 cell power limits are not broken.


Page 59

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 target reduction in soft handoff. This is found by linear downlink interpolation of the values that you supply in the Services dialog box. The downlink powers for sectors in the candidate active set are calculated iteratively. The iterative procedure involves setting all downlink powers to the same (non-zero) value

. The total achieved

is then calculated by summing the

is too low (high) by a factor of

for individual downlinks. If the total achieved , then

is increased (decreased) by a factor of

values

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

Page 60

•

Uplink RC1 – RC2

•

Uplink RC3 – RC6 When Using a Supplemental Bearer

•

Uplink RC3 – RC6 When Not Using a Supplemental Bearer

•

Downlink RC1 – RC2

•

Downlink RC3 – RC10


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

F1

and

are the fundamental channel powers in the

Active Fundamental Bearer Inactive Fundamental Bearer

α (Active Period)

F2

1−α (Inactive 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 is given by the ratio of their

for the active and inactive fundamental bearers (


So in equations (1) and (10), the factor


is given by:

Page 61

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

is the supplemental channel powers in the

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

S1

Active Supplemental Bearer

F1


F2

Active Fundamental Bearer P

Pilot

1α (Inactive Period)

α (Active Period)

The average uplink power is given by:

Which can be rewritten as:

Hard-coded look-up tables give

,

.

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

Page 62


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

F1


are the fundamental channel powers in the active and is the uplink pilot power:


F2

Active Fundamental Bearer P

Pilot

1α (Inactive Period)

α (Active Period)


which can be rewritten as:

Hard-coded look-up tables give So in equations (1) and (10), the factor


and

. is given by:

Page 63

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

F1

and

are the fundamental channel powers in the


α (Active Period)

F2

1-α (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 (



Page 64

is given by:


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


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

Active Supplemental Bearer

F1

Active Fundamental Bearer

α (Active Period)

Inactive Fundamental Bearer

F2

1-α (Inactive Period)



The ratio of fundamental powers to the power of the active supplemental bearer and is given by the ratio of their ( processing gains as follows:



) requirements and

is given by:

Page 65

CDMA2000 Blocking Probability This section describes the following: •

Calculation of Blocking Probability in the Blocking Report

•

Blocking Probability and Failure Rate

•

Coverage Probability Array in the Map View Window

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

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

•

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

•

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

•

Several cells may serve the traffic at a pixel.

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

CDMA2000 Blocking Probability and Failure Rate The blocking probability measured in the tool is more similar to a Lost Call Held blocking probability than a Lost Call Cleared (Erlang-B) blocking probability. This is a consequence of the way the simulator works. The simulator simply tries to serve as much of the offered traffic as possible. The following formulae show how these probabilities are related in a simple situation. Note : These formulae are not used to explicitly calculate blocking probabilities in the tool, since the probabilities in the tool are all found by sampling snapshots.

Page 66


Take a system with fixed capacity second and mean holding time

, and Poisson traffic with arrival rate

users per

seconds. The mean offered traffic is

The probability that exactly C users are offered.

. (18) (19)

The probability that more than C users are offered. (20) The probability that less than C users are offered.

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


It is easy to show that to each other for low blocking probabilities. Note : The “Failure Rate” ( terminals that fail.


) in the failure report is the proportion of offered (23)

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

CDMA2000 Coverage Probability Array in the Map View Window The meaning of “coverage probability” shown in the Map View window is dependent on whether the (global) passive-scan terminal is being used to test every pixel at the end of a snapshot. When running a simulation with passive-scan disabled, the coverage probability in the Map View window is determined by the connection attempts made by the randomly scattered terminals. It simply gives the proportion of offered terminals at the pixel that were successfully served. This is not simply related to the blocking probability at the pixel. In fact it is more like the complement of the “failure rate” given in the reports. For example, a cell with a coverage probability of 20% at most pixels would give a failure rate of about 80% in the report.


Page 67

When running a simulation with passive-scan enabled, the coverage probability at each pixel in the Map View window is determined largely by the connection attempts of passive-scan terminals at the end of the snapshot. In this case, the coverage probability is simply the complement of the blocking probability at the pixel that is, the two probabilities sum to 1. To summarise, if you are interested in seeing blocking (and its causes) in the Map View window, then the passive-scan should be enabled. If you are only interested in reports, then the passive-scan terminal may be disabled. Note : The blocking probability report is always calculated using the selective passivescanning technique, which is totally independent of the global passive-scanning used for the Map View window.

Page 68


APPENDIX D

HDR Algorithms This chapter describes the following topics:

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

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

A Greek subscript always indexes a carrier. indicates a sum over all carriers.

•

An uppercase Roman subscript always indexes a cell. indicates a sum over all cells.

•

A lower case Roman subscript always indexes a terminal.


Page 69

indicates a sum over all terminals. indicates a sum over all terminals in cell J. •

Up and down arrows

•

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

indicate if a quantity is uplink or downlink.

As an example, the quantity terminal j and cell K using carrier α.

represents the

for the uplink between

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 Terminal antenna gain Mast head amplifier gain Boltzmann constant Mast head amplifier (downlink) insertion loss. Uplink (downlink) linkloss between cell and terminal , Pathloss between cell and terminal Antenna masking loss Cable (feeder) loss TX combiner loss (downlink) RX splitter loss (uplink) Terminal body loss

Page 70


Thermal noise at terminal Thermal noise at cell Excess noise at cell Terminal TX power Cell rated power Total received power at terminal Total received power at cell Temperature Chip rate Uplink service activity factor Uplink equivalent control-overhead factor Terminal noise figure Base station noise figure Mast head amplifier noise figure


).

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

(2)

(3)

(4)


Page 71

(5)

(6) (7)

(8)

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

This is expressed in dB in the Cell Uplink report.

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

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

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

This expressed as a percentage in the Cell Uplink report.

Page 72


HDR Air Interface and User Bitrates The Air Interface Bitrate of an uplink bearer is used in the calculation of the uplink processing gain. The uplink processing gain ( ) is calculated by dividing the system chiprate by the air interface bitrate of the uplink bearer. The User Bitrate of the uplink bearer is used purely to calculate traffic (data throughput) on a cell.

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

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

•

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

The two parameters must satisfy the constraints

.

For each terminal in a snapshot, a set of correlated fades to cells is generated using the following procedure: Note : All the random numbers mentioned in the following procedure are independent and normally distributed with zero mean and unit variance. 1

Generate a random number X.

2

For each cell site I, generate a random number

3

For each cell J, generate a random number

4

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

.

(12)

where

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

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


Page 73

HDR Power Control Error Modelling The simulator does not explicitly model the power control process, but it allows the simulation results to exhibit certain features one would associate with imperfect power control. The standar deviation of power control error parameter controls the distribution of achieved

values for successfully served terminals. If the standard deviation is

values for each successfully served terminal are achieved set ot zero, the 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 (lognormal) distribution of achieved

values at a cell.

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

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

.

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

requirement on the uplink. When defining an

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

Page 74


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

the mean speed (

•

the standard deviation of the speed distribution (

•

the minimum speed (

)

•

the maximum speed (

)

) )

A random speed is the given by: (13)


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

Initialisation of System Power




Page 75

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

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

HDR Iterations An iteration involves sequentially evaluating the terminals (precisely once) to see if they can make a connection to the network. After each terminal is evaluated, the noise in the network is updated before moving on to evaluate the next terminal. A terminal may connect to the network in a variety of different ways (connection scenarios). For example, a terminal may have several different cells or carriers that it may use. Each of the connection scenarios for a terminal is evaluated in turn until one that allows a successful connection if found. If no scenario can produce a successful connection to the network, the link powers for the terminal are set to zero and the reasons for failure of the first scenario are recorded. Terminals which fail to make a connection in an iteration are not removed from the simulation, since success or failure in an iteration does not necessarily ensure the same result in a subsequent iteration. In fact, the state (succeeded/failed) of a terminal is determined purely by its state in the final iteration of a snapshot when convergence has been achieved.

Page 76


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

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

requirement. By the seventh

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


Page 77

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

values as

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

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

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

Carrier

•

Primary cell

•

Uplink bearer

•

Required



•

Higher (before lower) required

•

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

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

Page 78

•

Downlink evaluation

•

Uplink evaluation


HDR Downlink Evaluation In order to be served, the cell must provide an adequate The

level for the terminal.

level determines the downlink bitrate that can be achieved by the

terminal. The mapping between

and the downlink bitrate must be specified in

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

HDR Uplink Evaluation The following diagram shows the process of determining the terminal transmit power required to meet the uplink


requirement:

Page 79

For each cell in the candidate active set, the terminal transmit power required to meet is calculated. The lowest of these values is then quantised the uplink according to the quantisation level specified for the terminal. We call the resulting power

. The terminal transmit power is temporarily set to

and the two best

values on cells in the candidate active set are calculated. The difference between these two values (in dB), together with the terminal speed, allows the terminal power reduction ( ) to be determined from the supplied information in the Services dialog box. The terminal power reduction (

) is a gain that reduces the required

transmit power of the terminal. It is equivalent to a reduction in the uplink requirement. After the terminal power reduction has been calculated, the terminal is checked to see if it has sufficient power to make the uplink. The actual transmit power of the terminal (

) is given by: (14)

The uplink

requirement can be satisfied if: (15)

where


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 requirement without breaking a noise If the terminal cannot meet the uplink 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.

Page 80


.

Calculation of Uplink Equivalent Control Overhead Factor for HDR The following diagram represents the powers transmitted during active and inactive periods:

gives the proportion of time that the service is active. During an The activity factor 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. The average uplink power is given by:

This can be written in the form:

where is the control overhead factor. The term is the effective activity factor that appears in the calculation of uplink noise (equation 8). See equation 8. In dBm, P can be calculated from T using the following formula: a P_dBm = T_dBm – dataOffsetNom_dB – dB – dataOffsetRate_dB DataOffsetRate_dB depends on the air interface bitrate of the bearer: b 9600

dataOffsetRate_dB = dataOffset9k6dB – 3.75

c 19200


d 38400


e 76800


f 53600



Page 81

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

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

HDR Coverage Probability Array in the Map View Window The meaning of coverage probability shown in the Map View window is dependent on whether the (global) passive scan terminal is being used to test every pixel at the end of a snapshot. When running a simulation with passive-scan enabled, the coverage probability at each pixel in the Map View window is determined largely by the connection attempts of passive-scan terminals at the end of the snapshot. In this case, the coverage probability is simply the complement of the blocking probability at the pixel, that is the two probabilities sum to 1. When running a simulation with passive-scan disabled, the coverage probability in the Map View window is determined by the connection attempts made by the randomly scattered terminals. It simply gives the proportion of offered terminals at the pixel that were successfully served. This is not simply related to a blocking probability. Instead, it complements the failure rate. To summarise, if you want to view the blocking probability and its causes in the Map View window, the passive-scan should be enabled. However, if you would prefer to view the report in Excel only then the passive-scan terminal should be disabled.

HDR Blocking Probability and Failure Rate The blocking probability evaluated in the tool is more similar to a Lost Call Held blocking probability than a Lost Call Cleared (Erlang-B) blocking probability. This is a consequence of the way the simulator works. The simulator simply tries to serve as much of the offered traffic as possible. The following formulae show how these probabilities are related in a simple situation. Note : These formulae are not used to explicitly calculate blocking probabilities in the tool, since probabilities in the tool are all found by sampling snapshots. Take a system with fixed capacity second and mean holding time

, and poisson traffic with arrival rate second. The mean offered traffic is

users per .

(16) (17)

(18)

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


(19)


It is easy to show that to each other for low blocking probabilities. The Failure Rate (


) is the proportion of offered terminals that fail. (21)

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

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

Mean Internet Protocol (IP) packet arrival rate

•

Mean IP packet transmission time

•

Mean IP packet delays caused by queuing at the packet scheduler

•

Mean total IP packet transmission delay

•

Mean gross user throughput

•

Mean gross sector throughput

•

Mean net sector throughput

•

Mean percentage of packets timed out.

This chapter includes: •

HDR outline

•

IP packet transmission time

•

IP packet queueing delay

•

Throughput


Page 83

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

Page 84


•

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.


Page 85

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, maximum waiting time.

Page 86

, without exceeding the


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, the sector and is calculated by:

, is the actual throughput that is handled by

where - percentage of packets timed out - size of the IP packet in bits.


Page 87

Page 88


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


Page 89

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

The number of queues to model

•

The parameters of the traffic streams to generate, and the

•

Priorities of the service types, during before the time simulation

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

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

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

•

Zero traffic on all services will result in zero delays

•

Zero blocking on all services will result in zero delays

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

Traffic Generator for QoS Analysis This section describes the following:

Page 90

•

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

•

WWW Traffic Model

•

Packet Model

•

About the Code Schemes for GPRS

•

QoS Profiles for GPRS


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

The red line represents the mean number of users input from the Monte Carlo simulation. The orange blocks represent the number of users varying over time. The blue blocks represent the holding times of the packet sessions produced by the traffic generator. Little’s theorem gives us the relation between the arrival rate of packet sessions, the mean number of users in the cell and their mean session holding time. Let λ = mean session arrival rate

T = mean session holding time = mean number of users in the cell Little’s result says that:

N = λ .T ASSET3g Technical Reference Guide Version 5.0.2

Page 91

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:

Page 92

•

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. ASSET3g Technical Reference Guide Version 5.0.2

•

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 by:

is given

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.


Page 93

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

GPRS

CS - 1

EGPRS

Link Adaption Family

Modulation

Peak Rate per Slot Blocks Per (kb/s) 20 ms

RLC Block Size (bits)

GMSK

9.05

181

1

CS - 2

13.4

268

CS - 3

15.6

312

CS - 4

21.4

428

8.8

176

MCS - 1

C

GMSK

MCS - 2

B

11.2

224

MCS - 3

A

14.8

296

MCS - 4

C

17.6

352

MCS - 5

B

MCS - 6

A

29.6

MCS - 7

B

44.8

MCS - 8

A

54.5

1090

MCS - 9

A

59.2

1184

8 - PSK

22.4

1

448 592

2

896

In order to calculate the block size, the coding scheme allocated to each connection needs to be input from the Monte Carlo simulation (a mean number of MS connections per coding scheme, per bearer, per service type, per sub-cell array will be required as input). The block size can be inferred directly from the GPRS coding schemes, however, the following mapping is used to calculate the block size for the first transmission attempt for the link adaptation families: •

A – 592 bits

•

B – 448 bits

•

C – 352 bits

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

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

Page 94

•

Precedence class

•

Delay class

•

Reliability class

•

Throughput class


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

Delay Class GPRS has four different traffic classes. The following table shows that parameters that specifies their QoS requirements: Traffic Class

Medium

Application

Data Rate (kbit/s)

One-way Delay

Conversational

Audio

Telephony

4-25

<150ms

Data

Telnet

<8

<250ms

Audio

Streaming (HQ)

32-128

<10s

Video

On-way

32-384

<10

Data

FTP

-

<10s

Audio

Voice messaging

4-13

<1s

Data

Web browsing

-

<4s/page

Streaming

Interactive

For background traffic, only bit integrity is required. 3g service types have traffic classes and are used in the packet service types dialog box in 3g to set default www parameters and delay targets. In the ASSET3g QoS Analysis the achieved 95th percentile delay per service type, per carrier, per cell is compared with the target 95th percentile delay. Traffic class is used to prioritise the queues. For more information, see Simulation Model on page 97.

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

Lost Block Probability

1

10

2

10

3

10


Page 95

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

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

Peak throughput (kb/s)

Mean throughput class

Mean throughput (bytes per hour)

1

8

1

100

2

16

2

200

3

32

3

500

4

64

4

1 000

5

128

5

2 000

6

256

6

5 000

7

512*

8

1024*

17

20 000 000

9

2048*

18

50 000 000

*Data rate only reachable 31 with UMTS or EDGE

Best Effort

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

PeakThroug hput = PeakDataRa tePerSlot * BlocksPerF rame * MaxNumberO fSlots Page 96


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

Time Simulator for QoS Analysis This section describes the following: •

System Model

•

Simulation Model

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

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

•

The capacity of the destination cell is monitored

•

The system either accepts or blocks the new connection

•

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

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

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

•

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

•

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

•

The dropping of existing connections is not modelled

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


Page 97

If the packet call mode is selected instead of the packet mode, connection admission decisions are taken on a packet call, instead of an individual packet basis. The service prioritisation is modelled in the simulator. All the packets awaiting transmission through a cell are stored in a set of queues, one for each service type. A diagram of the queuing model which would be used for three packet services being transmitted through a cell is shown here:

The rule is then applied that if admissions for each service are considered in priority order, and that if any higher priority packets remain queued, no lower priority packets are admitted. By the end of the simulation, the simulator will have produced a list of transmitted packets, each stamped with its arrival and departure times from the cell. A histogram of the queue length throughout the simulation is displayed for each service on each cell and carrier in the graphs tab of the QoS Analysis dialog box.

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

Page 98


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

Results of QoS Analysis This section describes the following: •

Confidence Interval Half Width

•

Simulation Duration

•

Delay and Cumulative Delay Probability Distributions

•

Mean and Standard Deviations of the Queuing Delays

•

95th Percentile Delay

•

Mean Transmission Time

•

Mean Retransmission Delay

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

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

2

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

3

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

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


Page 99

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

, and variance σ . 2

k

Yi i =1 k

Y =∑

k

σ2 =∑

(Y

−Y ) (k − 1)

2

i

i =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

= number of sessions required to generate

Treq

= time until the

S req

N req

packets

session arrives

D = recommended simulation duration Each session contains

S req =

N pc .N d

packets, so

N req N pc .N d

(1)

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

S req

Treq =

session arrives is:

S req

λ

(2)

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

Treq =

Page 100

N req .T N pc .N d .N


Adding the duration of the

S req

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:

P ( n) =

cn TP

Cumulative delay probability of n.F frames: n

CP(n) =

∑c i =0

i

TP


Page 101

Mean and Standard Deviations of the Queuing Delays The following are the mean and standard deviations of the queuing delays: N

Mean delay

D = F .∑ n.P (n) n =0

σ= Standard deviation

∑ (F .n − D ) .P(n) N

2

n =0

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:

Ttrans =

8.S d 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-andWait ARQ (Automatic Repeat reQuest). This has the following features:

Page 102

•

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 + 1⎟⎟seconds Mean retransmis sion delay = 0.01.⎜⎜τ rt ⎝ (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, CollierMacmillan Ltd, p.193


Page 103

Page 104


APPENDIX F

ASSET3g File Formats This chapter describes the following topics:

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

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

3gr File - This is a proprietary file which contains a complete dump of the simulation. (the proprietary file's format is not disclosed in this manual)

•

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

Note : these formats are also applicable to 2g Monte Carlo simulations. The advantages and disadvantages of the files are shown below:

3gr Files Advantages

Disadvantages

The fact that the file contains everything from the simulation Because the file contains everything it is large means you can load the file on a PC anywhere and run it, even if it is from a completely different database Can be loaded and saved from the Array Manager


You can only have one 3gr file loaded at any one time

Page 105

3ga Files Advantages

Disadvantages

Small file size

Cannot be used to rerun the simulator

Simple, published file format

Only takes a copy of the information, which is useful for comparison purposes

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

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

Contains information about an individual display, for example, Reasons for Failure You can have multiple files loaded simultaneously Can be loaded and saved from the Array Manager

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

File Header

•

Array Instance Body

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

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

Type

Description

Comments

4 Bytes

int

Magic Number

should be 0x02121975

4 Bytes

int

Version Number

Currently 4202

4 Bytes

int

Archive Name Length

inc NULL terminator

char[ ]

Archive Name

User Visible Name

int

Network Type

Enumeration of one of the following:

4 Bytes

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

Page 106

4 Bytes

int

Region xMin

4 Bytes

int

Region xMax

4 Bytes

int

Region yMin

4 Bytes

int

Region yMax

4 Bytes

int

Resolution

4 Bytes

int

Memory Usage

Mb

4 Bytes

int

Unique Name String Length

inc NULL terminator

char[ ]

Unique String

GUID

4 Bytes

time_t

Date / Time

4 Bytes

int

User Name String Length

inc NULL terminator


char[ ]

User Name String

int

Comment String Length

char[ ]

Comment String

4 Bytes

int

Insertion String List Len

4 Bytes

int

Insertion String Len

} Section Repeated

char[ ]

Insertion String

} for each

int

Insertion String2 Len (inc NULL Terminator)

} Insertion

char[ ]

Insertion String2

} String

4 Bytes

Int

Current Provisions

4 Bytes

int

Reserved1

4 Bytes

int

Opaque Data Block Length

4 Bytes

4 Bytes

Opaque Data Block 4 Bytes

int

inc NULL terminator

Reserved for future. Size specified above

Array Instance Count (must be >= 1)


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

Description

Comments

4 Bytes

int

Magic Number

should be 0x21081970

4 Bytes

time_t

Date / Time

4 Bytes

int

Generic Name String Length

char[ ]

Generic Name String

4 Bytes

int

Instance Number

4 Bytes

int

Carrier/Service Name Str Len

char[ ]

Carrier/Service Name String

4 Bytes

int

Data Array Type

4 Bytes

int

Data Array Num Elements

TYPE[ ]

Data Array

int[ ]

Index Array

4 Bytes

int

String Array Num Elements

4 Bytes

int

String Length

char[ ]

String

int

Legend Colours Array Length

COLOREF

Category Colour

} Repeated

Int

CategoryString Length

} for each

S i z e

4 Bytes


inc NULL terminator

inc NULL terminator

currently 0 = float

Type specified above

inc NULL terminator

Page 107

Char[ ]

Category String

int

Thresholds Array Length

int[ ]

Threshold

4 Bytes

int

Reserved1

4 Bytes

int

Opaque Data Block Length

4 Bytes

} category

For enumeration renderers only

Opaque Data Block

Reserved for future. Size specified above


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

File Type

Contains

NMS 2000

*.nms

Live NMS2000 traffic information Can contain circuit-switched, HSCSD and GPRS traffic Uses LAC and GSMID

GSM

*.gts

Live GSM traffic Can contain circuit-switched, HSCSD and GPRS traffic Uses LAC, GSMID and Cell Layer Name

General Purpose

*.tps

GSM, Analog or TETRA traffic Can contain circuit-switched, HSCSD and GPRS traffic Uses CellID and Cell Layer Name

NMS File Format The NMS file format is as shown here: LAC white-space GSMID white-space CSTraffic white-space HSCSDTraffic white-space GPRSTraffic If there is no data for the CSTraffic or HSCSDTraffic or GPRSTraffic then the column must contain a - (hyphen).

GSM File Format The GSM file format is as shown here: LAC white-space GSMID white-space Cell Layer Name white-space CSTraffic white-space HSCSDTraffic white-space GPRSTraffic If there is no data for the CSTraffic or HSCSDTraffic or GPRSTraffic then the column must contain a - (hyphen).

Page 108


TPS File Format The TPS file format is a general purpose format which can contain GSM, EGPRS, TETRA or AMPS live traffic. This file starts with this header: # AIRCOM V1.0 Live Traffic File And contains data in this format: CELLID white-space Cell Layer Name white-space CSTraffic whitespace HSCSDTraffic white-space GPRSTraffic white-space EGPRSTraffic The HSCSD Traffic, GPRS Traffic and EGPRS columns may be left blank unless there is data in a later column else they must contain a - (hyphen). This is done so as to support TETRA and AMPS network live traffic data loading.

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

*.tpc

•

*.cbc

•

*.cbd

About the *.tpc File Format The file defines the number of terminals to spread for each cell. This file format is an extension of the ENTERPRISE general purpose live traffic import file (*.tps). The file format is as follows: The first line is the header and the second line contains the word 'cell' (or 'sector' if the traffic to be spread is CDMA2000 traffic), followed by the word 'Terminals'. The remaining lines then contain the traffic data to be spread. The formats for each technology type are:

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

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

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

TD-SCDMA CDMA 2000 Sector Name (white-space) TD-SCDMA Traffic (Terminals) ASSET3g Technical Reference Guide Version 5.0.2

Page 109

In all technologies the units of traffic will be Terminals.

Example *.tpc Live Traffic File An example *.tpc file is shown here: Traffic Per Cell File V1 Terminals 4.0 5.0 6.0 4.0 5.0 6.0

About the Bearer Traffic File Formats (*.cbc / *.cbd) The bearer file format consists of two files which both share the same filename but differ in file extension. The first extension is a *.cbc (cell bearer configuration) file which defines what is contained in the *.cbd (cell bearer data) file. When you choose to select a bearer traffic file, you browse for the *.cbc file only. The *.cbd file is automatically loaded and a check is made to ensure that it exist. The file format is case insensitive and a version header check is performed for both formats. The *.cbc file chooses between one of two naming methods (String/Number): •

String refers to matching by UMTS Cell Identity "NodeB1A"

•

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

The *.cbc file is necessary to provide a lookup table to map between the name of the bearer from the network and with the planning tool. There is an indication of number of bearers that exist in the lookup table: Cell Bearer Configuration File V1 Naming Method

String

Bearers

5

Network-bearer1

Bearer1

Network-bearer2

Bearer1

Network-bearer3

Bearer2

Network-bearer4

Bearer2

Network-bearer5

Bearer3

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

Page 110


If five bearers are defined in the *.cbc file, then there should be five bearer data columns in the *.cbd file. If the number of bearer data columns do not match the number specified in the *.cbc file, then an error dialog aborts the import process. For example: Error The number of bearers specified in the *.cbc file (X) does not match the number of bearer data columns in the *.cbd file. Cell Bearer Data File V1 Cell

net-bearer1

net-bearer2

net-bearer3

net-bearer4

net-bearer5

NodeB1a

1.3

1.3

1.3

1.3

1.3

NodeB1b

2.4

2.4

2.4

2.4

2.4

NodeB1c

3.5

3.5

3.5

3.5

3.5

NodeB2a

4.6

4.6

4.6

4.6

4.6

NodeB2b

5.7

5.7

5.7

5.7

5.7

NodeB2c

6.8

6.8

6.8

6.8

6.8

NodeB3a

7.9

7.9

7.9

7.9

7.9

NodeB3b

9.0

9.0

9.0

9.0

9.0

NodeB3c

10.1

10.1

10.1

10.1

10.1

A *.cbd file should contain only be one row per cell. If duplication is detected during import then a warning message is given in the message log. For example: “CellXXX: Skipping duplicate bearer traffic data.” Whilst the traffic wizard is processing the *.cbd file, as multiple network bearers can map to the same tool bearer, the application should generate a total for each tool bearer. If the import detects that values are missing, then a value of 0.00 Erlangs should be assumed. A warning message should be added to the message log in those cases. For example: “CellXXX: BearerXXX traffic not specified. Defaulting to 0.0” If there are no data values for the bearers, then 0 should be assumed - but a warning message in the message log indicates that this has occurred. For example: “CellXXX: BearerXXX traffic not specified. Defaulting to 0.” The cell matching criteria will vary according to the Naming Method specified in the *.cbc file. If no match occurs between the Cell ID and that in the database, a warning message is displayed in the message log stating that. For example: “CellXXX: Failed to import traffic. Cell does not exist.” (ID as appropriate to naming method) As there can be up to 15,000 cells contained in the *.cbd file, a progress bar with an Abort button appears if the processing contains more than XXXX cells. XXXX is determined during testing to appear after 2 seconds. The *.cbc file format allows a '-' instead of a Bearer ID to mean just ignore that column.


Page 111

Page 112


Q QoS algorithms • 89

Index

S Snapshots algorithm • 32

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

TETRA algorithms • 5 The main limitation on • 98

U UMTS algorithms • 23

C CDMA2000 algorithms • 43

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

G GPRS algorithms • 5 GSM algorithms • 5

H HDR algorithms • 69 HSCSD algorithms • 5

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

P Packet Switched QoS algorithms • 89


Page i

Page ii


ASSET3g Technical Reference Guide

Recommend Documents