Escolar Documentos
Profissional Documentos
Cultura Documentos
BSS release B9
TRAINING MANUAL
3FL10493ACAAWBZZA ed 3 November 2006
Page 2
Page 3
Contents
Page 4
1 TYPICAL RADIO PROBLEMS
Page 5
1 TYPICAL RADIO PROBLEMS
Session presentation
> Program:
1.1 Theoretical presentation
1.2 Coverage problem
1.3 Interference problem
1.4 Unbalanced power budget problem
1.5 TCH Congestion problem
1.6 Deducing the right team for intervention
1.7 Exercises
Page 6
1 TYPICAL RADIO PROBLEMS
Page 7
1.1 Theoretical presentation
Justification
> Several sources of information can alert RFTM team:
QoS indicators
Customers complaints
Drive tests
Other teams information (NSS statistics)
Page 8
1 TYPICAL RADIO PROBLEMS
Page 9
1.2 Coverage problem
Definition and symptoms
> Definition: Bad coverage
A network or cell facing coverage problems presents a bad RxLev
and RxQual in the same time on some areas.
> Symptoms:
Customers complain about dropped calls or/and no network
OMC QoS indicators
TCH failure rate
Call drop rate
Low proportion of better cell HO
High rate of DL quality HO
A interface indicators
High rate of Clear Request messages, cause radio interface
failure
Introduction to Radio Fine Tuning BSS Release B9 10
> No information is available on non-covered parts of the network, as there are non-mobiles making calls over there!
> Nevertheless, cells in border of non-covered zones do have a particular behavior:
B
A
> Cell A will mainly perform Better Cell handovers towards its neighbours, whereas cell B, bordering the non-coverage
area, will perform emergency handovers for MSs exiting the network.
For these MS, mainly DL Quality HO will be triggered:
DL because MS antenna is less efficient than BTS one,
Quality rather than Level since Qual has a greater priority in Alcatel HO causes.
Page 10
1.2 Coverage problem
Examination
> Depending on the information sources you have:
Radio Measurement Statistics (RMS)
(RxLevel , RxQuality) matrix
Radio Link Counter S vector
Number of calls with DL/UL bad coverage (bad RxLev, bad
RxQual)
Abis interface (for example with COMPASS)
bad quality > 5%
bad level RxLev < - 95 dBm and RxQual > 4
OMC-R or A interface
unexpected high traffic, induced by call repetition
Billing information
High recall rate detected
Page 11
1.2 Coverage problem
Typical causes
> If the actual coverage is not the one predicted by RNP tools
check antenna system
increase or decrease antenna down-tilt
check BS_TXPWR_MAX
to be increased if value different to RNP power budget
Page 12
1.2 Coverage problem
Investigation with Abis trace (1/2)
> Example of an Abis trace analysis
TRX index RxLev_UL RxLev_DL RxQual_UL RxQual_DL Path_loss_UL Path_loss_DL delta_Path_loss Delta_quality AV_MS_PWR Nb_of_samples
1 -89.29 -84.67 0.42 0.43 123.82 123.67 0.15 -0.01 34.53 3074
2 -89.77 -89.09 0.41 0.38 124.87 128.09 -3.21 0.03 35.11 10 253
3 -83.15 -79.15 0.17 0.33 116.05 121.22 -5.16 -0.16 32.9 5339
> It could have been coverage problems if this trace was made for 3 mono-TRX cells. In this case, the 3 lines are
uncorrelated. Anyway, delta path loss of frequency 111 is greater than 5dB, showing a problem on this TRX.
> If this is a 3-TRX cell, it cannot be a coverage problem as the three TRXs are not impacted. It will be either
interference or malfunction of one TRE.
> If the trace is done on 3 mono-TRX cells, in that case, it could be a coverage problem. Be careful when interpreting
this result table: even if average levels in the UL and the DL are high and a lot of Quality problems are seen, nobody
can say that samples with bad quality have a good level ! The level seen is just an average
> One should have a look to the next slide
Page 13
1.2 Coverage problem
Investigation with Abis trace (2/2)
> Example of an Abis trace analysis
5 6 -88.00 3
Thresholds
7 3 -95.33 3
11 3 -71.00 1
1 6 -80.00 1 Bad Coverage
12 3 -80.00 1
BC_DL: 115 3.74% <RxLev_Serving>= -102.17 dBm RxLev -95
Neigh_Cell_N BSIC <Lev> Samples
b -100.53
0
10
2
2 -98.71
57
45
- RxQual > 4
5 6 -98.03 34
7 3 -98.61 33 Interference
Frequency: 92
Number_UL: 10 253
RxLev > -95
Number_DL: 10 253
Int_UL: 2 0.02%
RxQual > 4
BC_UL: 358 3.49%
Int_DL: 0%
BC_DL: 244 2.38% <RxLev_Serving>= -106.17 dBm
Neigh_Cell_Nb BSIC <Lev> Samples
0 2 - 67
1 5 104.64
- 48
Frequency: 111 107.50
Number_UL: 5339
Number_DL: 5339
Int_UL: 0 0.00%
BC_UL: 290 5.43%
Int_DL: 0%
BC_DL: 626 11.73% <RxLev_Serving>= -106.56 dBm
Neigh_Cell_N BSIC <Lev> Samples
b
10 2 -101.54 63
> All samples are Bad Coverage samples (BC). None is interference, showing that this cell is not facing any
interference problem.
Page 14
1.2 Coverage problem
Investigation with RMS (1/3)
> Suspecting a cell coverage problem
Distribution of samples per RxQual value and RxLev band
Downlink Samples Matrix in log scale
> A coverage problem is observed when a significant amount of the traffic of a cell is suffering from both low level and
bad quality (RxQual).
> To confirm, distribution of samples per RXLEV band should be also considered to know the proportion of calls which
are experiencing a low signal level.
> If a lot of samples of low level and bad quality are observed for only a sub-part of the TRXs (can be one only) then a
BTS hardware problem or a problem on the antennae should be suspected.
> If all the TRXs are experiencing a lot of samples of low level and bad quality then a coverage problem must be
suspected.
> These RMS indicators are provided on RNO tool per TRX, per Cell:
Matrix of Number of Measurement Results per DL RxQual value and per DL RxLev band
RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample
Vector of Percentage of Samples per DL RxLev band
RMQLDLVDV = RMS_DL_RxLevel_distrib
Vector of Percentage of Samples per DL RxQual band
RMQLDQUDV = RMS_DL_RxQuality_distrib
Page 15
1.2 Coverage problem
Investigation with RMS (2/3)
> Suspecting a cell coverage problem
Average TA values per RxQual value and RxLev band
Uplink average TA Distribution
Down
RxQuality (Nb)
7
6
Interval of average
5 Timing Advance
4
[0, 2]
3 ]2, 4]
2 ]4, 6]
1 ]6, 8]
X Out of Range
0 RxLevel
[-110, [-104, [-98, [-92, [-86, [-80, [-74, [-68, [-62, [-56, (dB)
-104[ -98[ -92[ -86[ -80[ -74[ -68[ -62[ -56[ -47[
01/12/2001
01/01/2002
02/01/2002
03/01/2002
04/01/2002
05/01/2002
06/01/2002
07/01/2002
08/01/2002
09/01/2002
10/01/2002
11/01/2002
12/01/2002
13/01/2002
14/01/2002
considered
> In order to know if the coverage problem is due to a big amount of traffic at the cell border or rather to indoor calls, the
average TA value per RXQUAL value and RXLEV band as well as the Percentage of TA values over TA threshold
should be observed.
Matrix of Average TA per UL RxQual value and per UL RxLev band
RMQLUTAM = RMS_UL_RxQuality_RxLevel_TimingAdvance
Rate of Measurements Results whose TA is greater than the TA threshold
RMTAGTR = RMS_TimingAdvance_greater_threshold_rate
Maximum TA value of all values reported in Measurement Results
RMTAMXN = RMS_TimingAdvance_max
Page 16
1.2 Coverage problem
B9
Investigation with RMS (3/3)
> Suspecting a local cell coverage problem
RxQual and RxLev per TA bands
5 2.5
4
Bad quality 3
-47 - 59
- 60
- 70
- 80
- 90
- 110
[0,5[ [6,11[ [12,18[ [19,24[ [25,30[ [31,36[ [37,42[ [43,48[ [49,54[ [55,63[
Coverage problem
> In order to know if the coverage problem is due to a big amount of traffic at the cell border or rather to indoor calls, the
average TA value per RXQUAL value and RXLEV band as well as the Percentage of TA values over TA threshold
should be observed.
Matrix of Average TA per UL RxQual value and per UL RxLev band
RMQLUTAM = RMS_UL_RxQuality_RxLevel_TimingAdvance
Rate of Measurements Results whose TA is greater than the TA threshold
RMTAGTR = RMS_TimingAdvance_greater_threshold_rate
Maximum TA value of all values reported in Measurement Results
RMTAMXN = RMS_TimingAdvance_max
Page 17
1 TYPICAL RADIO PROBLEMS
Page 18
1.3 Interference problem
Definition and symptoms
> Definition: Interference
A network facing interference problems presents good RxLev and bad
RxQual in the same time on some areas.
> Symptoms
Customers complain about bad speech quality (noisy calls) and/or call drops
OMC QoS indicators
SDCCH/TCH Drop
Low proportion of better cell HO
High rate of DL/UL quality HO and interference HO
Low HO success rate
A interface indicators
High rate of Clear Request messages, cause radio interface failure
> Mainly, interferences are in the DL, due to bad frequency planning introducing interferences in the network. And this
problem will not change till the frequency plan is not returned
> Sometimes, interference can be in the UL in very dense area (for example, microcell area), since MSs are very close.
> Finally, sometimes interferences are not coming from BS or MS but from another radio equipment, either in the UL or
the DL.
Page 19
1.3 Interference problem
Examination with RMS (1/4)
> Radio Measurement Statistics (RMS)
RxQual/RxLev matrix
CFE/RxLev matrix
C/I vectors for neighbours
C/I vectors for MAFA frequencies
MAFA is a new standardized GSM feature for mobiles
MAFA mobiles can provide C/I measurements from
non-neighbour cells
Number of calls with DL/UL interference (good RxLev, bad RxQual)
Number of noisy calls (bad RxQual) with bad voice quality (bad
FER)
A high rate use of the most robust AMR codecs also denounce
interferences problems . But be careful, this can also be due to a
pessimistic choice of the thresholds used for codec change.
> The feature Radio Measurement Statistics (RMS) is designed to make far easier the work for planning and
optimization of the network by providing the operator with useful statistics on reported radio measurements.
> In fact these statistics give directly the real cell characteristics by taking into account the MS distribution.
> Thanks to this feature, the operator is able to:
detect interfered frequencies.
assess the quality of the cell coverage.
detect and quantify cell unexpected propagation.
assess the traffic distribution in the cell from statistics on reported neighbouring cells.
evaluate the voice quality in the cell.
etc.
> In regards to the RTCH Measurements Observation (measurement type 11), the Radio Measurement Statistics
(RMS) bring the following advantages:
smaller report files.
the report files always have the same maximum length whatever the measurement duration is.
every measurement is taken into account (no sampling).
no more need for measurement post-processing tools for statistics. Directly available with RNO or NPA.
Page 20
1.3 Interference problem
Examination with RMS (2/4)
> Suspecting a cell interference problem
Number of samples per RxQual value and RxLev band
Downlink Samples Matrix in log scale
Page 21
1.3 Interference problem
Examination with RMS (3/4)
> Suspecting a Voice Quality problem
Number of samples per BFI band and RxLev band
Consecutive Frame Erasure Matrix in log scale
CFE (Nb)
[22,
[14, 25[
18[
Interval of number
[18,
[14, 22[
18[ of samples
[14, 18[ [0, 14 793]
[10, 14[ ]14 793, 23 446]
[8, 10[ ]23 446, 29 586]
]29 586, 34 348]
[6, 8[
]34 348, 38 239]
[4, 6[ ]38 239, 41 529]
[2, 4[ ]41 529, 44 378]
[1, 2[ ]44 378, 46 892]
X Out of Range
[0, 1[ RxLevel
[-110, [-104, [-98, [-92, [-86, [-80, [-74, [-68, [-62, [-56, (dB)
-104[ -98[ -92[ -86[ -80[ -74[ -68[ -62[ -56[ -47[
> These RMS indicators are provided on RNO tool per TRX, per Cell:
Matrix of Number of Measurements Results per CFE band (or BFI band) and per UL RxLev band
RMFEM = RMS_UL_ConsecutiveFrameErasure_RxLevel_sample
Vector of Average number of Consecutive Frame Erasure per UL RxLev band
RMFEBFAV = RMS_UL_ConsecutiveFrameErasure_avg_per_RxLevel
Vector of Average UL RxQual per RxLev band
RMQLUQUAV = RMS_UL_RxQuality_avg_per_RxLevel
Page 22
1.3 Interference problem
B9
Examination with RMS (4/4)
> Suspecting a local interference problem
RxQual and RxLev per TA bands
5 2.5
4
Bad quality 3
-47 - 59
- 60
- 70
- 80
- 90
- 110
[0,5[ [6,11[ [12,18[ [19,24[ [25,30[ [31,36[ [37,42[ [43,48[ [49,54[ [55,63[
interference problem
> These RMS indicators are provided on RNO tool per TRX, per Cell:
Matrix of Number of Measurements Results per CFE band (or BFI band) and per UL RxLev band
RMFEM = RMS_UL_ConsecutiveFrameErasure_RxLevel_sample
Vector of Average number of Consecutive Frame Erasure per UL RxLev band
RMFEBFAV = RMS_UL_ConsecutiveFrameErasure_avg_per_RxLevel
Vector of Average UL RxQual per RxLev band
RMQLUQUAV = RMS_UL_RxQuality_avg_per_RxLevel
Page 23
1.3 Interference problem
Typical causes
> GSM interference
co-channel
adjacent
Page 24
1.3 Interference problem
GSM interference: adjacent channel (1/2)
> Adjacent channel interference
+6 dB are sufficient to interfere (9 dB according GSM)
F(BTS1) = F(BTS2)+1
Level F(BTS2)
F(BTS1)
6 dB
Frequency
Page 25
1.3 Interference problem
GSM interference: adjacent channel (2/2)
> Adjacent channel interference:
Symptom
Usually downlink interference
High rate of quality HO, call drop (due to HO but mainly due to
radio) and TCH assignment failure
Examination
neighbour cells in Abis trace (only for BCCH)
Non-neighbour cells in RMS (MAFA frequencies)
Frequency planning C/(I adjacent) < -6 dB
Correction
Downtilt increase of interferer, or even change of antenna
orientation
Reduction of BS power if necessary, Change of frequency (best
solution)
Concentric cell implementation (1 extra TRX needed if traffic cannot
be supported by Outer+Inner configuration)
Page 26
1.3 Interference problem
GSM interference: co-channel (1/2)
> GSM Interference
Co-Channel interference
-12 dB are sufficient (-9 dB according GSM)
F(BTS1) = F(BTS2)
Level F(BTS2)
F(BTS1)
-12 dB
Frequency
Page 27
1.3 Interference problem
GSM interference: co-channel (2/2)
> Co-channel interference
Symptom
Usually downlink interference
High rate of quality HO, call drop and call failure
Examination
neighbour cells in Abis trace (only for BCCH)
Non-neighbour cells in RMS (MAFA frequencies)
Frequency planning C/I < 12 dB
Correction
Downtilt increase of interferer, or even change of antenna
orientation
Reduction of BS power, Change of frequency
Concentric cell implementation (1 extra TRX needed if traffic cannot
be supported by Outer+Inner configuration)
Page 28
1.3 Interference problem
GSM interference: cellular
> GSM interference: cellular
MS 2
BTS1: ARFCN 5 BTS 1 (outdoor) BTS
1 2
BTS2: ARFCN 6 (Micro)
MS 1
(indoor)
MS1 indoor
RxLev_UL: - 90 dBm
MS2 outdoor, connected to BTS2
2
1: no level on BTS1
(BTS 1 under-roof)
2: - 80 dBm on BTS1:
interferer UL/DL
3: no level on BTS1
cell algo prevents BTS2->BTS1
HO
3
> When interferences are created by frequency plannig, its not so hard to detect them. But frequency planning tools
mainly consider DL C/I and coverage.
> Some problems are more difficult to predict. For example, lets consider a microcell layer:
B
A
A and B are 2 microcells with the coverage described before in dense urban environment.
Even if both cells A & B are using adjacent frequencies (5 and 6), the overlapping area is far from cell A
antenna. Thus, in this area C/I is lower than 6 dB.
A red MS is connected on cell A. When the MS starts its call, it transmits full power and a PC algorithm
quickly reduces MS power as the received level is very good (microcell coverage). When MS A enters the
building, it faces a loss of signal of 20 dB. Then, MS power increases to MS_TXPWR_MAX.
A second mobile B is connected to cell B and moves down in the coverage area of cell B. MS power of B
decreases quickly down to MS_TXPWR_MIN as the MS is close to the antenna. But when MS B arrives
outside the building where A is sitting, A and B are close and transmitting on adjacent frequencies Then B
has to increase its power to avoid dropping its call. By the way, global level of freq B is increased in all cell
B creating interference in the UL.
Page 29
1.3 Interference problem
GSM interference: Forced Directed Retry
> GSM Interference: Forced Directed
Retry
The MS should connect to
cell2, but no TCH available 4
:2
The MS connects to cell 1 with
C e ll 1
forced directed retry
The MS is emitting at high level BTS
1
(far from BTS1)
UL interference for BTS 3 MS
capture FDR
microcell
> The situation described on the slide corresponds to the usage of FDR in a single layer network. This is in that case a
heavy-to-tune algorithm presenting of lot of interference and bad quality call risks, since the mobile will be connected
to a cell when being not in its service area.
Page 30
1.3 Interference problem
Non-GSM interference
shop
interference
The Spectrum analyzer connected on the antenna feeder highlights a peak on GSM freq 6 in the UL
Anti-theft mechanism turned off: no more problem
Page 31
1 TYPICAL RADIO PROBLEMS
Page 32
1.4 Unbalanced power budget problem
Definition and symptoms
> Definition: Unbalanced power budget
A cell facing unbalanced power budget problems presents a too high
path-loss difference between UL and DL (often DL>UL)
Rule: try to have delta as small as possible to avoid access network possible
only in 1 direction (usually BTS->MS: OK and MS->BTS: NOK)
> Symptoms:
OMC QoS indicators
High rate of Uplink quality Handover causes
Low incoming HO success rate (no HO Access triggered on the uplink)
Degradation of TCH failures and OC call drop indicators
A interface indicators
High rate of Clear Request messages, cause radio interface failure
O&M Alarms
Voltage Standing Wave Ratio BTS Alarm (VSWR)
TMA Alarm (in case of G2 BTS or Evolium BTS with high power TRE)
Introduction to Radio Fine Tuning BSS Release B9 33
Page 33
1.4 Unbalanced power budget problem
Examination
> Examination
RMS
Path Balance vector per TRX
Number of calls with abnormal bad FER (good RxQual & bad
FER)
Abis monitoring:
|delta path-loss| > 5dB
Check if problem is occurring for 1 TRX or all
> Problem on 1 TRX: FU/CU or TRE problem or ANY problem or cables connected to this equipment.
> All TRXs: problem on antenna, feeder, jumper or common equipment (ex: ANX, ANC).
Page 34
1.4 Unbalanced power budget problem
Abis trace
> Example of an Abis trace analysis
Frequency RxLev_UL RxLev_DL RxQual_UL RxQual_DL Path_loss_UL Path_loss_DL delta_Path_loss Delta_quality AV_MS_PWR Nb_of_samples
106 -94.52 -87.19 0.43 0.25 127.55 130.19 -2.64 0.18 33.03 2066
89 -84.29 -75.17 0.65 0.44 115.32 118.17 -2.85 0.21 31.03 2001
118 -90.75 -83.36 0.46 0.41 123.22 126.36 -3.14 0.04 32.46 3193
124 -88.89 -85.30 0.29 0.67 120.48 128.30 -7.82 -0.37 31.59 2931
Page 35
1.4 Unbalanced power budget problem
RMS data
> Suspecting a TRX hardware problem
Average Path Balance
PathBalance Distribution
Nb Samples
3000
2500 Nb
Samples
2000
1500
1000
500
PathBalance
0
[-110, [-20, [-10, [-6, [-3, [0, [3, [6, [10, [20, (dB)
-20[ -10[ -6[ -3[ 0[ 3[ 6[ 10[ 20[ 110[
> These RMS indicators are provided on RNO tool per TRX, per Cell:
Vector of the Number of Measurement Results per Path Balance band
RMPBV = RMS_PathBalance_sample
Average Path Balance value
RMPBAN = RMS_PathBalance_avg
Page 36
1.4 Unbalanced power budget problem
Typical causes
> Antennae or common RF components, TMA (pb common to all
TRXs of the BTS)
> Every BTS has its proper architecture and the diagnosis must be adapted.
Page 37
1 TYPICAL RADIO PROBLEMS
Page 38
1.5 TCH Congestion problem
Definition and symptoms
> Definition: TCH Congestion
TCH Congestion rate (TCH Assignment Phase) is too high (more
than 2%)
Rule: try to meet the offered traffic (asked by users) by providing
the right number of resources (TRX extension)
> Symptoms:
Customers complain about Network busy
OMC QoS indicators
High TCH Congestion rate
Low incoming Intra/Inter BSC HO success rate (no TCH
available)
High Directed Retry rate if activated
A interface indicator: BSS Congestion failure in OC
High rate of Assignment Failure messages, No radio
resource available
Introduction to Radio Fine Tuning BSS Release B9 39
Page 39
1.5 TCH Congestion problem
Examination and typical causes
> Examination: TCH Congestion
On a per cell basis examination, check the evolution of the
TCH Congestion rate.
> Typical causes:
Special events:
Foreseeable: football match, important meeting
Activate some TRXs already installed
(and use Synthesized FH)
Add special moving BTSs
Not foreseeable:
car crash on the highway
> Cells on wheel operational by several operators around the world for special events coverage & capacity
IRMA (SFR) connected to Caens BSC.
Orange coverage / Football WC 1998 for Paris Stade de France :
Specific cells covering Paris Stadium. During games, only small capacity (using joker frequencies).
During breaks, some TRX off cells around are turned off, and frequencies are reused for stadium
cells.
Page 40
1.5 TCH Congestion problem
Typical causes (1/2)
Daily periodic problems
At peak hour, the cell is not correctly dimensioned.
Add TRXs to reach the new target configuration and find joker
frequencies and / or implement concentric cells.
> Warning: offered traffic is not the capacity delivered by the system but the traffic asked by the users.
Page 41
1.5 TCH Congestion problem
Typical causes (2/2)
> Daily periodic problems
At peak hour, the cell is not correctly dimensioned.
Software solution
Use specific densification features
Half Rate
Forced Directed Retry
Traffic handover
Fast Traffic handover
Candidate Cell Evaluation (FREEFACTOR /
LOADFACTOR)
> Half rate may not only mean SW solution. Need of G2 BSC/TC, Evolium TRE or G2 DRFU.
Page 42
1 TYPICAL RADIO PROBLEMS
Page 43
1.6 Deducing the right team for intervention
Process
QOS team Drive test team
Problem characterization RFT team - Interferences
- Coverage (indoor)
- Power budget
QOS alarm on the network, Make assumption causes - Congestion (TCH, SDCCH)
on a BSC or some cells Investig problem ? - BSS problem
END
DHCP No No Recurrent problem ?
- Indicators (% call drop)
- Field measurements/planning Yes Yes
- Subscriber complains
Yes Planning/BSS causes
No
Correction
Check the tuning of default radio parameters
action
Planning team
Standard parameters ?
Maintenance team
Dimensionning team
Consult the config. db No Yes Choose an (other) classical algo
On
Yes Identify the tunable parameters
purpose
Cell corrected ?
No
Neighbor cell ?
Impact simulation of a
NOK Impact estimation parameter modification
N times
Check ? System
No No Simulation
With QOS ? problem ?
OK ?
Yes =N Yes
OK
Standard setting ? Call expert Parameters modification
Database updating
END
DHCP
Page 44
1.6 Deducing the right team for intervention
Coverage problem
> Coverage problem:
If the field reality does not match the RNP prediction
Maintenance team to change physical configuration (tilt,
azimuth, antenna height, etc.) and drive test team to check it
Page 45
1.6 Deducing the right team for intervention
Others problems
> Interference problem:
Planning team to identify the interference source and correct it
(joker frequency, new frequency planning, etc.)
Page 46
1. Typical radio problems
Training exercise
Unbalanced TCH
Bad coverage Interferences
Power Budget Congestion
High rate of UL QUAL HO
causes
Good RxLev and Bad
RxQual
VSWR alarm (OMC-R)
(Voltage Standing Wave Ratio)
Page 47
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 48
2 ALGORITHMS & ASSOCIATED PARAMETERS
Session presentation
> Program:
2.1 Theoretical presentation
2.2 Radio measurements principles
2.3 Averaging windows and book-keeping
2.4 Radio Link Supervision and Power control
2.5 Handover Detection
2.6 Handover Candidate Cell Evaluation
2.7 Handover Management
2.8 Exercises
Page 49
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 50
2.1 Theoretical presentation
Justification
JUSTIFICATION
When the detected problem does not concern another team (Network
planning and frequency planning, Dimensioning, Radio engineering,
Maintenance) or
when the other teams cannot give any solution (too tight frequency planning,
no additional TRX available, no financial budget for new sites, etc.)
the Radio Fine Tuning team has to find a compromise between:
High traffic density (Erl/km/Hz)
High quality of service (Call drop, CSSR, Speech quality,
indoor, etc.)
Page 51
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 52
2.2 Radio measurements principles
Radio measurement mechanisms (1/2)
> MS connected (TCH or SDCCH)
> The serving cell gives the MS the list of the neighbour cells to
listen to
> Every SACCH, the MS reports to the serving cell: measurement
s t c e ll
Be
report message st
c e ll
e
s t c e ll
B
Be
Received level of 6 best cells
(which can change) C e ll
ll
ce
DL level and quality g SYS_INFO_5
n
s t c el l
Be
S e r vi
of serving cell message (list)
MS reporting
C e ll
es
B
t c e ll
Be
s t c e ll
C e ll
> The BTS sends a SYS_INFO_5 message that contains the list of neighbour cells for connected mode. (The
SYS_INFO_2 message contains the list of neighbour cells for idle mode).
Sys info 2bis, 2ter, 5bis and 5ter are also used for multiband networks.
MS reporting depends on EN_INTERBAND_NEIGH and on MULTIBAND_REPORTING parameters.
The MS may report:
6 strongest cells of any band (MULTIBAND_REPORTING=0), or
5 strongest cells of the serving band + 1 strongest cell of another band
(MULTIBAND_REPORTING=1), or
4+2 (MULTIBAND_REPORTING=2), or
3+3 (MULTIBAND_REPORTING=3).
> RXLEV
Range: [-110dBm, -47dBm]
Binary range: [0, 63]; 0=-110dBm, 63=-47dBm
The higher the physical or binary value, the higher the receiving level
> RXQUAL
Range: [0.14%, 18.10%]
Binary range: [0, 7]; 0=0.14%, 7=18.10%
The lower the physical or binary value, the lower the bit error rate, the better the quality
0-2=excellent; 3=good; 4=ok; 5=bad; 6=very bad; 7=not acceptable
Page 53
2.2 Radio measurements principles
Radio measurement mechanisms (2/2)
> For each MS connected to the BTS (TCH or SDCCH)
UL received level and quality
sureme measurem
mea
is measured every SACCH DL
nt
s
L+DL en
ts
U
The Timing Advance (TA) is Measurement computed
Measurement BSC
report result
The UL information is MS gathered
BTS
PC execution
Candidate cell
HO execution
evaluation
The BSC is computing algorithms
usually using average value (sliding window) of these measurements
Introduction to Radio Fine Tuning BSS Release B9 54
> The BTS starts sending MEASUREMENT RESULT messages as soon as it receives the RL ESTABLISH
INDICATION message from the MS.
> The BTS stops sending MEASUREMENT RESULT messages upon receipt of one of the two following messages:
DEACTIVATE SACCH
RF CHANNEL RELEASE
Page 54
2.2 Radio measurements principles
Structure of a measurement result
MSG_DISK
MSG_TYPE
CHAN_NUMBER_IEID
CHANNEL_NUMBER
Meas_result_number_IEID
Meas_result_number
Element Identifier
Length
SACCH_BFI / DTX_DL{1} / RXLEV_UL_FULL
{2} / RXLEV_UL_SUB_
{2} / RXQUAL_UL_FULL / RXQUAL_UL_SUB
BS_POWER_IEID
{3} / BS_POWER
Element Identifier
MS_TXPWR_CONF / R{3}
TOA / R{2}
Element Identifier
L1 Info Length
Length
TI {4} / Prot. Disc{4}
0 / Message Type{7}
BA_USED / DTX_UL / RXLEV_DL_FULL
0 / MEAS_VALID / RXLEV_DL_SUB
0 / RXQUAL_DL_FULL / RXQUAL_DL_SUB / NO_NCELL_M
NO_NCELL_M / RXLEV_NCELL(1)
FREQ(1) / BSIC(1) L3 Info:
BSIC(1) / RXLEV_NCELL(2)
RXLEV_NCELL(2) / FREQ(2) / BSIC(2) Measurement
BSIC(2) / RXLEV_NCELL(3)
RXLEV_NCELL(3) / FREQ(3) / BSIC(3) report from
BSIC(3) / RXLEV_NCELL(4) the MS
RXLEV_NCELL(4) / FREQ(4)
BSIC(4) / RXLEV_NCELL(5)
RXLEV_NCELL(5) / FREQ(5)
FREQ(5) / BSIC(5) / RXLEV_NCELL(6)
RXLEV_NCELL(6) / FREQ(6)
FREQ(6) / BSIC(6)
> MS TXPOWER CONF: which is the actual power emitted by the MS.
> SACCH BFI: bad frame indicator; 2 values 0 or 1; 0 means that the BTS succeeded in decoding the measurement
report.
Page 55
2.2 Radio measurements principles
Extended Measurement Reporting (EMR)
> Extended Measurement Reporting mechanisms
MS BTS BSC MSC Extended Measurement
TCH ASSIGNMENT (OC or TC) Order includes the
Assignment Request MAFA frequencies the
Physical Context Request
MS is asked to measure
Physical Context Confirm
> When the BTS receives a CHANNEL ACTIVATION with the Extended Measurement Order (EMO) included, it must
send this information on the SACCH to the corresponding mobile only once.
> When the BTS has to send this information, it must replace the sending of system information 5, 5bis, 5ter or 6 by
this information. At the next SACCH multiframe, the BTS must resume the sending of this system information by the
replaced one.
> The EMO must be sent after 2 complete sets of SYS_INFO5 and 6, i.e. after the 2nd SYSINFO 6 after the reception of
SABM. This guarantees the MS has received a complete set.
> Then, the BTS normally receives from the MS an EXTENDED MEASUREMENT RESULT with the level of the
frequencies to monitor. The BTS must make the correlation between these levels and the frequencies contained in
the latest EMO information, after having decoded them, according to the order of the ARFCN. The
EXTENDED_MEASUREMENT_RESULT is NOT forwarded to the BSC, instead a MEASUREMENT_RESULT with
indication no_MS_results is sent to the BSC.
> In particular, the BTS must identify the level of the BCCH frequency of the serving cell (which must always be part of
the frequencies to monitor) and apply it as the RXLEV_DL in the Radio Measurement Statistics. The other
frequencies will be considered in the same way as the BCCH frequency of neighbour cells: they will be linked to the
neighbour level and C/I statistics.
Page 56
2.2 Radio measurements principles
Training exercise (1/2)
(BSIC, BCCH index)/(LAC, CI) problem
Time allowed:
5 minutes
Page 57
2.2 Radio measurements principles
Training exercise (2/2)
> Explain why cell 2 has a very high outgoing HO unsuccessful rate and
a high call drop
CI=6169
2006
GSM900
C ell 3
( 7 , 62 )
C e ll C e ll
CI=6169
GSM900
C e ll 2
( 3, 4 6 )
CI=1964
GSM900
C e ll 1
( 7, 6 2)
Page 58
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 59
2.3 Radio measurements data processing
Functional entities
BTS BSC
> The active channel pre-processing function calculates average values of signal levels, qualities and timing advance
provided by the radio link measurements function.
> The pre-processing is based on a sliding window averaging technique. The averaging is either weighted or
unweighted depending on the type of the input parameters.
Page 60
2.3 Radio measurements data processing
Active channel pre-processing
> Active channel pre-processing
Page 61
2.3 Radio measurements data processing
Active channel pre-processing - Principles
> Active channel pre-processing Principles
HANDLED by the BSC
ACTIVATED when the BSC receives:
ESTABLISH INDICATION from the MS on SAPI 0, or
HANDOVER FAILURE from the MS, or
ASSIGNMENT FAILURE from the MS (in case of intracell
handover)
STOPPED when a HANDOVER COMMAND is emitted in the
serving BSC
> The pre-processing function is stopped when a HANDOVER COMMAND is emitted by the serving BSC. At this time,
the MEASUREMENT RESULT messages are ignored by the pre-processing function and no update of the book-
keeping tables or averaging is done anymore.
> The pre-processing function is enabled again (in case of failure of an intracell or intercell handover) after reception of
either messages listed above, and the old measurements are kept in the book-keeping list and taken into account in
the new averaging.
> The pre-processing function is completely handled by the BSC. The input parameters of this function are provided by
the BTS every SACCH multiframe in the MEASUREMENT RESULT message.
> The function calculates average values of levels, qualities and timing advance. The pre-processing method is based
on a sliding window averaging technique. The pre-processing is done for every measurement sample, i.e. every
SACCH multiframe. The averaging intervals are expressed in terms of SACCH multiframe periods and their range is
between 1 and 31.
> The averaging process for any variable can start as soon as A_YYYY_XX (YYYY stands for LEV, QUAL, PBGT
or RANGE and XX for HO, DR, PC or MCHO) samples, each with MEAS_VALID bit set to 0 (validity indicator
reported by the MS in the MEASUREMENT REPORT message), are actually available except in case of the
averaging of the received level from the neighbour cells and the averaging of AV_RXLEV_PBGT_HO,
AV_BS_TXPWR_HO and AV_BS_TXPWR_DR.
Page 62
2.3 Radio measurements data processing
Measurement averaging (1/2)
> Avoid reacting too early to some atypical measurement(s)
- 105.00
- 100.00
- 95.00
- 90.00
- 85.00
- 80.00
- 75.00
> The calculation of levels, qualities and timing advance (i.e. distance information) uses a variety of averaging window
sizes as well as specific weighting factors for quality estimates.
> One separate window exists for:
power control on the uplink and the downlink (A_LEV_PC , A_QUAL_PC),
emergency handover (A_LEV_HO , A_QUAL_HO , A_RANGE_HO),
fast emergency handover for microcells (A_LEV_MCHO),
better cell handover and better zone handover (A_PBGT_HO) for intra-layer, interlayer and interzone
handovers,
forced directed retry (A_PBGT_DR),
neighbour filtering and ranking for all HOs (A_PBGT_HO),
codec adaptation (A_QUAL_CA_HR_FR , A_QUAL_CA_FR_HR).
Page 63
2.3 Radio measurements data processing
Measurement averaging (2/2)
> Objective: average measurements to avoid reacting to transient
degradation
Principle: sliding window: level/quality/distance values are averaged for
N last samples
N = A_LEV_HO samples for uplink and downlink level
N = A_QUAL_HO samples for uplink and downlink quality
N = A_RANGE_HO samples for distance
N = A_PGBT_HO for level used in power budget equation
Example (A_LEV_HO=6, A_QUAL_HO=4, A_PBGT_HO=8)
Meas 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
DL Level -90 -92 -93 -98 -100 -99 -98 -90 -80 -75 -72 -71 -110 -70 -69 -68 -78 -88 -95 -98 -100 -110 -110 -110
AV-RxLev -95 -97 -96 -94 -90 -86 -81 -83 -80 -78 -77 -78 -81 -78 -83 -88 -95 -100 -104
AV-Lev-PGBT -95 -94 -92 -89 -86 -87 -83 -80 -77 -77 -78 -81 -85 -83 -88 -93 -99
DL Qual 2 3 3 4 7 7 7 5 2 1 1 0 6 0 0 0 0 1 2 3 6 7 7 7
AV-RxQual 3 4 5 6 7 5 4 2 1 2 2 2 2 0 0 1 2 3 5 6 7
Experiences
some experiments have shown that the number of HOs is very
sensitive to modification of these values
Introduction to Radio Fine Tuning BSS Release B9 64
> An MS is required to measure the BCCH power level of a number of BCCH frequencies. These measurements are
used for the power budget computation in the BSC and the candidate cell evaluation in the BSC.
> The MS reports to the BTS, in the MEASUREMENT REPORT message, the measurements of the NO_NCELL_M
(NO_NCELL_M <= 6) best cells it receives (RXLEV_NCELL, BCCH frequency index and BSIC number) for each
multiframe. In case of multiband capability, the mobile reports the best cells of each supported frequency band (if
available). This reporting is allowed at BSS level by the flag EN_INTERBAND_NEIGH and it is specified by the
parameter MULTIBAND_REPORTING.
> The adjacent cells reported by an MS can change over the averaging interval. The book-keeping function keeps a
table composed of the last 32 reported adjacent cells, the maximum number of which is NBR_ADJ. The total number
of adjacent cells for which measurements reported by the MSs are available within the average interval is BTSnum.
> The BSC G1 maintains a table of up to 150 cells, from which up to 64 can be declared as adjacent cells to a given
cell.
> The BSC G2 maintains a list of up to 1000 cells, from which up to 64 can be declared as adjacent cells to a given
cell.
> Because the maximum number of adjacent cells may be greater than 32, the number of adjacent BCCH frequencies
is limited to 32. Moreover, a mechanism for overwriting obsolete entries in the bookkeeping table, when new cells are
reported, is provided.
> When the variable BTSnum reaches its maximum value of 32 and at least one new cell has to be entered in the list,
then the BSC sorts out all cells in the bookkeeping list, which have been reported with signal level = 0 for the last 20
measurements (10 seconds).
> This is done by summing the raw measurement values over the last 20 samples. All the corresponding cell entries
are cleared from the bookkeeping list, BTSnum is decreased by the number of cleared entries and some of the
vacant entries are used to include the new cells.
Page 65
2.3 Radio measurements data processing
Training exercise
Raw measurements
> Measurements averaging DL Level -80 -78 -84 -87 -80 -75 -77 -94 -79 -77 -78 -84 -89 -90 -91
DL Quality 2 2 3 3 2 1 4 4 3 1 2 3 3 3 4
Average measurements
excel sheet... AV_RXLEV_DL_HO
A_LEV_HO=8 -82 -82 -82 -81 -81 -82 -84 -85
A_LEV_HO=2 -85
Quality
DL Level 4
A_QUAL_HO=8
A_QUAL_HO=4 3
A_QUAL_HO=2 2
1
Number of
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 measurements
AV_RANGE_HO
A_RANGE_HO=8 12 13 13 15 15 16 17 18
A_RANGE_HO=4 10 11 11 13 14 14 16 17 17 18 19 19
A_RANGE_HO=2 11 10 10 12 13 13 15 16 17 18 18 18 20 20
10 minutes A_RANGE_HO=2 15
10
Number of
5
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 measurements
> Fill up the table with average function. The chart will be automatically processed
> The fact that there may not be enough cleared entries to store new measurements is excluded, see justification
below:
> Because the MS must resynchronize at most every 10s with the neighbour cells it monitors, it is useless to keep cells
in the bookkeeping list which have not been reported for more than 10s, it will be impossible to makkes an handover
towards these cells.
> Therefore, the overwriting mechanism described above will function correctly if there are less than 32 cells reported
in every 10s, which makes an average rate of 3 new cells per second.
> The potentiality of overflow of the book-keeping list is therefore excluded.
> The book-keeping is performed according to the BSIC and BCCH frequency couple. This function updates the table
every multiframe except if the measurement report is missing or Measurement Valid Bit is set to not valid. When the
level of a cell is not reported, a zero must be entered as measurement value. For each multiframe and for each of the
NO_NCELL_M cell measurements it receives, the function has to check the BSIC number and the BCCH frequency
index (FREQ(n)).
> When the couple (BSIC, BCCH frequency) is not in the reference list (received from the OMC), the corresponding
measurements should be discarded.
> The BTSnum variable is updated every multiframe except if the measurement report from the MS is missing. It is
incremented by the number of new couples (BSIC number, BCCH frequency index) registered as described above.
> Remark: Two cells can have the same BSIC number or the same BCCH frequency index. Therefore, the couple of
these parameters is needed to define a cell.
Page 66
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 67
2.4 Radio link supervision and power control
Functional entities
BTS BSC
Active Channel
Pre-processing
PC Threshold
PC Command
Comparison
> The two main functions specified in this document and implemented in the ALCATEL BSS are:
Radio link supervision and radio link command:
These functions handle the detection of the radio link failure so that calls which fail either from loss of
radio coverage or unacceptable interference are satisfactorily handled by the network. The radio link
supervision is responsible for detection of the loss of the radio link, based on incorrectly received
SACCH frames. The radio link command is responsible for commanding to set the power at a
maximum level for radio link recovery or to clear the call when the radio link has failed.
The radio link recovery can be activated or not, depending on a configuration flag (EN_RL_RECOV).
The radio link failure procedure is always running and clears the call when the radio link has failed.
Power control:
This function handles the adaptive control of the RF transmit power from the MS and the BS. The RF
power control aims at minimizing the co-channel interference and also at reducing the DC power
consumption of the MS. This function is in charge of detecting a need for a power command and then
of applying this power command. Therefore it can be divided into two processes: PC threshold
comparison and PC command. MS and BS power control are operating independently, they can be
activated or not, depending on configuration flags (EN_MS_PC and EN_BS_PC).
> All these functions require directly or indirectly input parameters provided by the function in charge of the radio link
measurements.
> Most of the input data required by the power control functions are provided by Active channel pre-processing function.
Page 68
2.4 Radio link supervision and power control
Radio link supervision
> Principles
> The determination of the radio link failure is based on a counter. According to the GSM Technical Specification 05.08
for the BSS, the criterion for incrementing/decrementing this counter should be based:
either on the error rate on the uplink SACCH,
or on RXLEV/RXQUAL measurements of the MS.
> In the ALCATEL BSS, it is based on the number of SACCH frames which cannot be decoded.
> It must be stressed that this criterion is related to the first one recommended above but it is not exactly the same. The
ALCATEL criterion is in fact the one recommended by the GSM Technical Specification 05.08 for the MS.
Page 69
2.4 Radio link supervision and power control
Principles of radio uplink supervision
> For each active radio channel, a counter S is
decremented by 1 each time an SACCH frame cannot be decoded
(BFI=1)
incremented by 2 each time a valid SACCH frame is received
> The value of S gives a measure of the quality of uplink radio link
> Initial value of S = BS_RADIO_LINK_TIMEOUT
if S reaches N_BSTXPWR_M, a radio link recovery is triggered optional)
if S reaches 0, a radio link failure is detected
> RADIOLINK_TIMEOUT_BS RADIOLINK_TIMEOUT is important
because the mobile must release the radio channel first.
MS
BT
S
C o u n te r S C o u n te r S '
S A C C H b lo c k S A C C H b lo c k
lo s t: - 1 r e c e iv e d : + 2
R LTO_B S
18
(B S _ R A D IO _ L IN K _ T IM E O U T ) R L T O (T 1 0 0 )
16
(R A D IO _ L IN K _ T IM E O U T )
N _B S R a d io lin k
13
TX P W R _M R e c o v e ry
R a d io lin k
0 0
F a ilu re
> The radio link supervision function is performed in the BTS and it uses three parameters given to the BTS in the TRX
configuration data message:
EN_RL_RECOV: flag enabling/disabling the sending of CONNECTION FAILURE INDICATION by the BTS
when the need for radio link recovery is detected,
N_BSTXPWR_M: threshold for the radio link recovery,
RADIOLINK_TIMEOUT_BS: threshold (number of SACCH messages) for the radio link failure.
> In addition, the function handles a counter named S. RADIOLINK_TIMEOUT_BS is the initial and maximum value of
S.
For each SACCH not decoded, S is decremented by 1 while for each SACCH decoded, it is incremented by
2. The incrementation or decrementation is performed if the following condition is met:
RADIOLINK_TIMEOUT_BS >= counter S >= 0.
As soon as the counter S is equal to the threshold N_BSTXPWR_M, the radio link recovery is triggered if
EN_RL_RECOV = ENABLE. Therefore, in the case where the shadowing is so strong that all SACCH frames
are lost, the radio link recovery will be triggered after (RADIOLINK_TIMEOUT_BS - N_BSTXPWR_M)
SACCH periods.
> The parameter N_BSTXPWR_M must be set according this simple behavior.
> If the radio link recovery is not successful, as soon as S reaches 0, the radio link failure procedure is applied.
> As soon as a radio link failure is detected, the radio link supervision must be started again in the BTS.
Page 70
2.4 Radio link supervision and power control
S counter for radio link supervision
S value S = f [ BFI(t)]
25
RADIO_LINK_TIMEOUT_BS
20
N_BSTXPWR_M
15
10
1
SACCH
0 number
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
BFI
S
> These events are sent to the BSC in the CONNECTION FAILURE INDICATION message:
In case of Radio link recovery, the BTS sends only once (to avoid overload of the Abis interface) the
CONNECTION FAILURE INDICATION message to the BSC with cause "set MS/BS-TXPWR-M (value: '001
1111', reserved for National use). This action (message formatting) is performed by the GSM layer 3.
In case of Radio link failure, the BTS sends the CONNECTION FAILURE INDICATION message with cause
'Radio link Failure' to the BSC.
> Thus, the CONNECTION FAILURE INDICATION message on Abis is not showing any call drop. One should look at
the cause of CONFAIL.
Page 71
2.4 Radio link supervision and power control
Radio link recovery
> The BTS is sending a Connection Failure Indication message
cause 001 1111 reserved for national usage (ALCATEL:
RLR)
On K1205: set MS/BS_TXPWR_MAX (Alcatel only)
> The action consists in increasing the power of the MS and of the BTS to their maximum, in a single step, if the link is
failing, i.e. the BTS is not able to decode the SACCH anymore for some period of time.
> This functionality is performed upon reception of the CONNECTION FAILURE INDICATION message (cause set
MS/BS-TXPWR-M) from the BTS. This message can be sent by the BTS only if EN_RL_RECOV = ENABLE. Upon
reception of this message, the radio link command function:
1. sends to the BTS a power increase command up to BS_TXPWR_MAX (BS_TXPWR_MAX_INNER if the MS is
on the inner zone of a concentric or multiband cell) in the BS POWER CONTROL message.
2. sends to the MS a power increase command up to min(MS_TXPWR_MAX,P) (min
(MS_TXPWR_MAX_INNER,P) if the MS is in the inner zone of a concentric or multiband cell) in the message
MS POWER CONTROL.
> When a radio link recovery occurs, the radio link command function gives an indication to the power control function
once the power increase has been commanded.
> The maximum power increase of the MS is 2dB per 60 ms. Thus, if MS_TXPWR_MAX=33dBm and
MS_TXPWR_MIN=13dBm, the MS coming from MIN to Max will take 600 ms.
Note: the BS Power Control process does not interfere with the recovery procedure since the former comes to a halt
when no SACCH multiframe is received. Thus, the BS power control process does not take into account the radio link
recovery event.
Page 72
2.4 Radio link supervision and power control
Radio link failure
> Radio link failure
> The task of the radio link command consists in informing the call control function to release the call.
> Concentric cell or multiband cell
> The power value BS_TXPWR_MAX_INNER is applied in case of radio link recovery for an MS in the inner zone. The
power value BS_TXPWR_MAX is applied in case of radio link recovery for an MS on an outer zone channel.
> Note: the radio link supervision procedure will function also if SACCH frames are not lost continuously, but with a
longer reaction time.
Page 73
2.4 Radio link supervision and power control
Radio link supervision: training exercise
Radio Link Supervision
> With the RLS excel sheet...
Parameters: BFI S Action
5 minutes 1
1
4
3
Page 74
2.4 Radio link supervision and power control
Power control
> Aims of Power control
Reduce emitted power to the
minimum RXL
EV_U
L
Uplin
possible BS_T
XPW
k
MS_
TXP
R Dow WR
nlink
Minimum power levels: BTS
RXLE
MS
V_DL
GSM: 11dBm, 9dBm, 7dBm
and 5dBm
DCS: 2dBm, 0dBm
Power Output Power (dBm) Output Power (dBm)
Ensuring quality and received level GSM-900 DCS-1800
level of peer entity 14 15 2
Adapted in real-time 15 13 0
16 11 -
For Uplink PC: decrease UL 17 9 -
interference and save MS battery 18 7 -
interference
> The main objective of the power control, in connection with handover algorithms, is to allow a maximum number of
MSs to operate in the network while maintaining a minimum interference level.
> The algorithms must ensure that any mobile is connected with the cell in which the output powers from the MS and
the BS are as low as possible (to reduce MS power consumption and interference in the network) while keeping a
satisfactory link quality.
> When on a sufficient duration, the propagation conditions keep worsening, then action must be taken.
> The first action is to increase the output power levels at the MS or the BS. When the maximum allowed value has
been reached, a handover may become necessary.
> To reflect this philosophy in macrocells (not in microcellular environment), the algorithm allows for handover on
quality and strength reasons only when the last step of power control has been reached. If propagation conditions
worsen rapidly when the MS is at low power, the power control algorithm allows to reach quickly the maximum power.
> Nevertheless great care must be taken in choosing the relative values of the thresholds for power control and
handover as well as the averaging window sizes (smaller window size and higher threshold for power control than for
handover). It must be remembered that, although it is desired that the MS transmits with the lowest possible power, it
is more important not to lose a call. Thus early triggering for the power control is possible, by choosing, small values
for the averaging window sizes and higher comparison thresholds.
Page 75
2.4 Radio link supervision and power control
Power Control principles
> Based on a threshold comparison mechanism
> Decrease emitted power when received level AND quality measured by
peer entity are better than a given value
> Increase emitted power when the received level OR quality is lower than
a given value
> Does not decrease power if the resulting level is below the low level
threshold
> The threshold comparison process detects the need to change the MS power level. This detection is done by
comparison between the averaged values produced by the active channel pre-processing function and thresholds.
Page 76
2.4 Radio link supervision and power control
Power Control detection
> MS Power control (for BS PC, replace MS by BS and UL by DL)
Quality
U_RXQUAL_UL_P 21
L_RXQUAL_UL_P 2
3
Level
-95
-90 -93
-86 -85
-75
L_RXLEV_UL_P U_RXLEV_UL_P
POW_RED_STEP_SIZE
> A need for a PC command is detected when one of the conditions above is true. Then, the information for the
execution of the PC command is given to the PC command process.
> The MS power control function can be disabled with a flag EN_MS_PC. This flag is changeable from the OMC-R.
Note: The GSM coding of quality is contra-intuitive, since the value 0 codes for the best quality and 7 for the worst. Thus,
the comparison between two quality values must be understood in the opposite way in terms of quality.
Note: POW_RED_STEP_SIZE is used in two ways: for PC_COMMAND (decrease of MS power) and for
PC_THRESHOD_COMPARISON (to avoid ping-pong effect).
Page 77
2.4 Radio link supervision and power control
MS PC Threshold comparison
> Power increase: If
AV_RXQUAL_UL_PC > L_RXQUAL_UL_P + OFFSET_RXQUAL_FH
AV_RXQUAL_UL_PC L_RXQUAL_UL_P + OFFSET_RXQUAL_FH
and AV_RXLEV_UL_PC < L_RXLEV_UL_P
Then PC_COMMAND(MS, INC, MS_P_INC dB, <min(MS_TXPWR_MAX, P))
> OFFSET_RXQUAL_FH is an internal variable that is equal to 0 in case of Non-Hopping cell and
OFFSET_HOPPING_PC in case of BBH or RH.
Page 78
2.4 Radio link supervision and power control
MS Power Control Command
> Power command philosophy:
> Whenever any of the threshold conditions occurs, a PC command must be sent to the MS over the air interface.
> In order to compute the adaptive power step size, the middle threshold between the upper threshold
U_RXLEV_UL_P and the lower threshold L_RXLEV_UL_P is considered.
> This threshold is regarded as the target received level around which the MS should always stay. The following
algorithm tries to maintain and bring the MS power closer to this target threshold. The size of the power step is limited
to MAX_POW_INC for an increase of the MS power and MAX_POW_RED for a decrease of the MS power.
> When the received level is between the two thresholds U_RXLEV_UL_P and L_RXLEV_UL_P (i.e. no need to
change the level) and a power control on quality cause is triggered, fixed power step sizes are applied:
POW_INC_STEP_SIZE for power increase and POW_RED_STEP_SIZE for power decrease.
> Two weighting factors POW_INC_FACTOR (for power increase) and POW_RED_FACTOR (for power decrease)
allow to modify the reactivity of the algorithm (the more POW_INC_FACTOR is nearby 1, the greater the reactivity of
the algorithm is and the larger the power step size is).
> The target received level is TARGET_RXLEV_UL for the uplink path.
> TARGET_RXLEV_UL corresponds to the next higher multiple of 1 dB from (U_RXLEV_UL_P + L_RXLEV_UL_P)/2.
Page 79
2.4 Radio link supervision and power control
Fast and Normal PC comparison
> Example Need for PC Command detected
PC Command
Power level
(dB) Normal Power Control
-80
-90 20 dB
6 dB (POW_INC_STEP_SIZE)
-100
-110
Time
(ms)
0 480 960 1440 1920 2400
MR 2 MR 3 MR 4
4 SACCH =
1 Measurement Report (MR)
Page 80
2.4 Radio link supervision and power control
MS Power Increase Command computation
> PC_COMMAND (MS, INC, MS_P_INC dB, < power max)
If MS_TXPWR < power max
then increase MS_TXPWR by min(MS_P_INC, MAX_POW_INC, powermax-
MS_TXPWR)
Where MS_P_INC is evaluated by the following algorithm:
Page 81
2.4 Radio link supervision and power control
MS Power Decrease Command computation
> PC_COMMAND (MS, RED, MS_P_RED dB, > power min)
If MS_TXPWR > power min
then decrease MS_TXPWR by min(MS_P_RED, MAX_POW_RED,
MS_TXPWR- power min)
Where MS_P_RED is evaluated by the following algorithm:
Page 82
2.4 Radio link supervision and power control
Frequency Hopping cases
> OFFSET_RXQUAL_FH
Algorithm:
If Frequency hopping applied
then OFFSET_RXQUAL_FH = Offset_hopping_PC
Else OFFSET_RXQUAL_FH = 0
> In order to take into account the frequency hopping in the RXQUAL evaluation, the variable OFFSET_RXQUAL_FH
is introduced.
> If on the corresponding channel, Frequency hopping is applied then OFFSET_RXQUAL_FH = Offset_Hopping_PC
otherwise OFFSET_RXQUAL_FH = 0
> Offset_Hopping_PC is a parameter defined on a per cell basis.
> PC Downlink in Frequency hopping case
In this case, the BSC inhibits the BS power control on all the channels which use the BCCH carrier. The
entity performing the BS power control in the BSC gets all the information concerning a new channel and
decides whether to activate the BS power control for this channel. The power control must be inhibited when
the frequency used by the new channel is the same as the frequency used for the BCCH in the BTS (cell) in
which the channel is activated.
For any channel which has the BCCH frequency in its hopping sequence (MA), the MS is measuring a very
good downlink level each time it hops on the BCCH. To avoid that this results in a too optimistic average, it is
possible to require from the MS not to include the BCCH measurement in the averages. This is achieved by
setting the PWRC flag to 1 in the SYSTEM INFORMATION type 6 message sent by the BSS on the SACCH.
If the channel is hopping only on the BCCH frequency (after a transmitter failure), it is considered as a non-
hopping channel and it is concerned by the non-frequency hopping case.
Page 83
2.4 Radio link supervision and power control
Power Control timers (1/2)
> Timers
> The timer T_SDCCH_PC allows to inhibit the MS and BS power control on SDCCH.
This timer is changeable at the OMC-R level on a per cell basis. It is triggered upon receipt of the
ESTABLISH INDICATION message after SDCCH activation for immediate assignment procedure. As long as
the timer runs, the power control is inhibited on SDCCH.
If the timer expires, the power control will be enabled again on SDCCH.
If the timer is running at the sending of the RF CHANNEL RELEASE message, the timer is stopped.
> T_SDCCH_PC is useful in case of long SDCCH phases.
> During SDCCH for call establishment, PC disabled should be preferred with a view to secure call setup.
Nevertheless, if SMS usage is very high, SDCCH phases may be long. In this case, to avoid interference, PC will be
enabled after T_SDCCH_PC expiry (about 5s).
> After any PC command is sent to the MS, some time must be expected before MS_TXPWR_CONF (power
confirmation sent by the MS on the uplink SACCH) can reach the desired value. The timer MS_P_CON_ACK is
triggered after any power modification command to monitor that the desired transmission power MS_TXPWR is
reached.
If MS_P_CON_ACK elapses before the expected value of MS_TXPWR_CONF is received, the power control
decision process is resumed immediately with the last MS_TXPWR_CONF received.
If the expected value of MS_TXPWR_CONF is received before the timer MS_P_CON_ACK is elapsed, the
timer MS_P_CON_ACK is stopped and the timer MS_P_CON_INT is triggered. Then the MS PC threshold
comparison process is resumed with MS_TXPWR_CONF for the same MS as soon as MS_P_CON_INT
expires.
Page 84
2.4 Radio link supervision and power control
Power Control timers (2/2)
> IF xx_P_CON_ACK is expiring, it is a system problem:
Wrong setting of xx_P_CON_ACK (too short)
No reception of power command by the MS
a radio link recovery can be activated
Problem on Abis
repetition of BS power command
Page 85
2.4 Radio link supervision and power control
Extra information
> LEVEL and QUALITY USED in EQUATION are average ones with
window size A_QUAL_PC and A_LEV_PC
> BS POWER CONTROL INHIBITED ON BCCH frequency
BCCH must be emitted at the maximum level
> MS dynamic constraint
minimum 2dB every 60 ms
> Emitted power can be changed by radio link supervision algorithm
Radio link supervision has a greater priority
> Activation of power control can slow down HO decision
some causes can be triggered only if the MS (BTS) is
emitting at the maximum power
> According to GSM Technical Specification 05.08 section 7.1, the BCCH carrier must be broadcast with a constant
power in the cell. In this release of the ALCATEL BSS, this constant value is set to the maximum power allowed in
the cell that is defined by the parameter BS_TXPWR_MAX.
This means that all dedicated channels (TCH, SDCCH) which are on the BCCH frequency must always be
transmitted with the maximum power, i.e. the BCCH power must not be changed by the BS power control
function.
Page 86
2.4 Radio link supervision and power control
Power Control: Training exercise (1/3)
> Power control UL
(Remark: Use the default parameters document)
What happens if we do not use Frequency
Hopping?
Why is it better to have A_LEV_PC=A_LEV_HO/2?
Thresholds:
Lower QUAL of RX uplink = 3
High QUAL of RX uplink = 2
Lower LEV of RX uplink = -90dBm
Upper LEV of RX uplink = -75dBm
Time allowed: POW_RED_STEP_SIZE= 4
25 minutes POW_INC_STEP_SIZE= 6
Put the right threshold in the next slide chart
Page 87
2.4 Radio link supervision and power control
Power Control: Training exercise (2/3)
Quality
> Power control UL
QUESTION
Nb of case 1 2 3 4 5 6
AV RXQUAL UL PC 0 1 2 6 3 4
AV RXLEV UL PC -98 -80 -73 -69 -86 -91
Power control
Delta value
Page 88
2.4 Radio link supervision and power control
Power Control: Training exercise (3/3)
> Power control DL
Thresholds:
L_RXLEV_DL_P = -85dBm POW_INC_FACTOR = 0.6
U_RXLEV_DL_P = -75dBm POW_RED_FACTOR = 0.8
L_RXQUAL_DL_P = 2.9 MAX_POW_INC = 16dB
U_RXQUAL_DL_P = 1 MAX_POW_RED = 16dB
A_QUAL_PC = 4 BS_P_CON_ACK = 3s
A_LEV_PC = 4 BS_TXPWR_MIN = -16dB
Using the Trace Abis Excel file, find each parameter value:
POW_INC_STEP_SIZE = ? BS_P_CON_INT = ?
POW_RED_STEP_SIZE = ? OFFSET_RXQUAL_FH = 0 or 1 ?
Page 89
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 90
2.5 Handover Detection
Handover main objective
> Send connected MS to another cell
When needed: rescue/emergency handover
If useful: better cell handover
Page 91
2.5 Handover Detection
Principles
> The BSC is analyzing averaged measurement results
active channel pre-processing (measurements averaging and
book-keeping)
Page 92
2.5 Handover Detection
Functional entities
Assignment of HO functions in the ALCATEL BSS
BTS BSC
HO Preparation
HO Candidate
HO Detection
Cell Evaluation
HO Management
MSC
HO Protocol
> The HO Preparation function can also be named "handover algorithms" as the algorithms described are the "heart" of
this function.
The ALCATEL handover preparation is derived from the basic algorithm found in Annex A of the GSM
Technical Specification 05.08.
The handover preparation is in charge of detecting a need for handover and proposing a list of target cells.
Therefore it can be divided into two processes: handover detection and handover candidate cell
evaluation.
> The handover detection process analyzes the radio measurements reported by the BTS and triggers the candidate
cell evaluation process each time a handover cause (emergency or better cell type) is fulfilled.
> The handover candidate cell evaluation works out a list of possible candidate cells for the handover. This list is sorted
according to the evaluation of each cell as well as the layer they belong to (in a hierarchical network) and the
frequency band they use (in a multiband network).
> Once the handover preparation is completed, the handover decision and execution (handover management entity) is
performed under the MSC or BSC control. The directed retry preparation is performed by the handover preparation
function.
Once the directed retry preparation is completed, the directed retry is performed either under the BSC control
(internal directed retry) or under the MSC control (external directed retry).
> An example of implementation of these functions except for directed retry is given in the GSM Technical Specification
05.08.
> The handover preparation requires indirectly input parameters provided by the function in charge of the radio link
measurements.
> Most of the input data required by the handover functions are provided by a function called: Active channel pre-
processing.
> The figure above depicts in a general way:
the interconnections between these functions,
the implementation of these functions in the ALCATEL BSS.
Page 93
2.5 Handover Detection
Handover causes detection
> Based on the contents of the measurement results
> In case of a handover alarm, the handover detection process gives to the cell evaluation process:
the preferred target cell layer: lower, upper or none.
the raw candidate cell list, which can be either all neighbours, or the subset which verify the handover causes
(plus other specific cells in particular cases). With each cell is given one of the handover causes which have
been verified.
The cause of handover.
> Four main handover categories are provided, depending on the cause of handover and the context of application.
The context of application for a handover is either "intercell" (the handover is performed between two different cells)
or "intracell" (the handover is performed in the same cell).
> The detection of a need for handover is performed through handover causes which are going to be detailed.
> The cause of handover is based either on a situation of emergency (this cause is therefore called "emergency
cause") or on the existence of better conditions. In this last case, the name of the cause depends on the context of
application: for intercell handovers, it is called "Better cell cause". For intracell handovers, it is called "Better zone
cause", as it is applied only in the case of interzone handovers in concentric or multiband cells.
Page 94
2.5 Handover Detection
B9
Handover causes
> 16 HO causes for standard networks (26 on the whole)
Emergency HO
Better conditions HO
Cause 2 Too low quality on the uplink
Cause 12 Power budget evaluation
Cause 3 Too low level on the uplink
Cause 20 Forced directed retry
Cause 4 Too low quality on the downlink
Cause 23 Traffic
Cause 5 Too low level on the downlink
Cause 24 General capture
Cause 6 Too long distance between the
MS and the BTS Cause 27 AMR channel adaptation
HO (FR to HR)
Cause 15 High interference on the uplink Cause 28 Fast traffic HO
(intracell HO)
Cause 16 High interference on the downlink Cause 29 TFO HO
(intracell HO) 30 Move from PS to CS zone
Cause 26 AMR channel adaptation HO
(HR to FR)
Page 95
2.5 Handover Detection
Handover Cause 2: UL Quality
> CAUSE 2: too low quality on the Uplink
Page 96
2.5 Handover Detection
Handover Cause 3: UL Level
> CAUSE 3: too low level on the uplink
Page 97
2.5 Handover Detection
Handover Cause 4: DL Quality
> CAUSE 4: too low quality on the downlink
Page 98
2.5 Handover Detection
Handover Cause 5: DL Level
> CAUSE 5: too low level on the downlink
Page 99
2.5 Handover Detection
Handover Cause 6: Distance
> CAUSE 6: Too long distance between the MS and the BTS
> This cause is used when a dominant cell provides a lot of scattered coverages inside other cells, due to propagation
conditions of the operational network. The consequence of these spurious coverages is the probable production of a
high level of co-channel interference.
> This cause is different from the others as it is more preventive. It does not make use of the propagation conditions of
a call. It just does not allow an MS to talk to a BTS if it is too far away.
> It may happen for example that some peculiar propagation conditions exist at one point in time that provide
exceptional quality and level although the serving BTS is far and another is closer and should be the one the mobile
should be connected to if the conditions were normal.
> It may then happen that these exceptional conditions suddenly drop and the link is lost, which would not have
happened if the mobile had been connected to the closest cell. So for these reasons, this cause does not wait for the
power control to react.
Page 100
2.5 Handover Detection
Handover Cause 12: Power Budget (1/11)
> CAUSE 12: Power budget
Decision based mainly on comparison of serving and neighbour
cells for:
downlink level of serving and neighbour cells
maximum emitting level of MS
> In this case, there is another cell with a better power budget i.e., the link quality can be improved or maintained with a
reduced transmit power of both the MS and the BTS. The radio link is not degraded but there is the opportunity to
decrease the overall interference level by changing the serving cell of the given MS.
> In conjunction with power control, it presents the advantage to keep the interference as low as possible, since it
minimizes the path loss between the BTS and the MS.
> This cause is especially designed to cope with the requirement that the mobile should be connected with the cell with
which the lowest possible output powers are used. To assess which of the cells is this "best cell", the algorithm
performs every measurement reporting period the comparison of the path loss in the current and in the neighbour
cell. This is a feature special to GSM which is made possible because the mobile measures the adjacent cell signal
levels and reports the six best ones.
> This power budget gives the difference in path loss between the current cell and the adjacent cells reported by the
mobile.
> When PBGT(n) is greater than 0, then the path loss from cell n is less than the path loss from the serving cell and
thus the radiated power in the downlink direction, and therefore in the uplink direction as well, will be lower in cell n
than in the current cell.
> However it would not be advisable to hand over the MS to another cell as soon as PBGT is greater than 0, because
the MS would probably oscillate between the two adjacent cells as the propagation conditions vary. An hysteresis
mechanism is implemented to avoid this undesirable effect.
Page 101
2.5 Handover Detection
Handover Cause 12: Power Budget (2/11)
> CAUSE 12: Power budget equation
> The MS may be handed over from the serving cell indexed 0 to a neighbour cell indexed n only if the power budget
exceeds the handover Margin(0,n). The handover Margin(0,n) can be modified according to the traffic situation in the
serving cell and the neighbour cell n. In this way, power budget handover can be delayed towards a loaded cell and
traffic load handover can be triggered from a loaded cell. Once the MS is handed over, the same algorithm is applied
in the new cell, and a new PBGT is computed (which will be close to the opposite value of PBGT in the old cell) and
compared to a new HOMargin. (Thus, the global hysteresis (from cell 0 to cell n and back to cell 0) is the sum of the
two HOMargins).
> However, It is still possible that a ping-pong mechanism is created by different handover causes, for instance a
handover may be triggered towards a neighbour cell for bad quality, but in the neighbour cell, a handover back may
be triggered for power budget reasons. In order to avoid this, an additional anti-ping-pong mechanism is implemented
in the power budget calculation. It enables to penalize for a certain time the cell on which the call has been before.
> In case of handover from SDCCH to SDCCH, this cause does not take the traffic situation into account.
> In multiband cell environment, the mobile can operate in a different band than the frequency band of the BCCHs. This
can lead to circular ping-pong handovers from the inner zone if the new band is DCS 1800 or to the impossibility to
trigger PBGT handovers from the inner zone if the preferred band is GSM 900.
> To avoid this problem, when the MS is in the inner zone of a multiband cell, it may be handed over from the serving
cell indexed 0 to a neighbour multiband cell indexed n only if the power budget exceeds the handover Margin(0,n)
plus the offset handover margin which allows to handicap or favor the PBGT (In the inner zone, the cause power
budget is only checked between multiband cells, in a way to maintain the MS in the preferred band).
> The offset handover margin can possibly be used in concentric cells.
Page 102
2.5 Handover Detection
Handover Cause 12: Power Budget (3/11)
> CAUSE 12: Power budget PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO
- (BS_TXPWR_MAX AV_BS_TXPWR_HO)
- (MS_TXPWR_MAX(n) MS_TXPWR_MAX)
- PING_PONG_MARGIN(n, call_ref)
AV_RXLEV_NCELL
received level of BCCH of neighbour cell
AV_RXLEV_PBGT_HO
received level of serving cell (BCCH or not)
AV_RXLEV_NCELL - AV_RXLEV_PBGT_HO
the highest is the best neighbour cell
but serving might not be at the maximum level (with DL
power control)
necessity to have a corrective factor
Page 103
2.5 Handover Detection
Handover Cause 12: Power Budget (4/11)
> CAUSE 12: Power budget PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO
- (BS_TXPWR_MAX AV_BS_TXPWR_HO)
- (MS_TXPWR_MAX(n) MS_TXPWR_MAX)
- PING_PONG_MARGIN(n, call_ref)
BS_TXPWR_MAX AV_BS_TXPWR_HO
AV_RXLEV_NCELL-[AV_RXLEV_PBGT_HO+(BS_TXPWR_MAX-
AV_BS_TXPWR_HO)]
compare received level of neighbour and serving cells as if the
serving one was emitting at the maximum level
Page 104
2.5 Handover Detection
Handover Cause 12: Power Budget (5/11)
> CAUSE 12: Power budget PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO
- (BS_TXPWR_MAX AV_BS_TXPWR_HO)
- (MS_TXPWR_MAX(n) MS_TXPWR_MAX)
- PING_PONG_MARGIN(n, call_ref)
MS_TXPWR_MAX(n)
maximum emitting power for the MS in neighbour cell n
MS_TXPWR_MAX
maximum emitting power for the MS in the serving cell
> MS_TXPWR_MAX(n) - MS_TXPWR_MAX
Corrective factor to compensate for the difference of maximum
power of each cell
MS_TXPWR_MAX(n) - MS_TXPWR_MAX = bts_max_power(n) -
bts_max_power
which should be the case if delta_path_loss is equilibrated
if not exact, can be corrected with HO_MARGIN(0,n)
> Then, another correction factor must be taken into account because the maximum BS powers of the serving and
neighbour cells may be different:
TXPWR= MS_TXPWR_MAX(n) - MS_TXPWR_MAX.
> As the first step of calculation is based on the downlink parameters, this correction factor should be based on the
maximum BS powers used in the serving and neighbour cells.
> Two reasons (which are not completely de-correlated) for not using the BS powers can be envisaged:
for a given cell, the GSM does not specify formally the maximum BS power of the neighbour cells. Only
BS_TXPWR_MAX is defined (it is sent on the air interface),
it is not easy for the evaluating BSC to know the maximum BS powers of the neighbour cells.
> The use of the maximum MS powers requires that the difference of MS powers is equal to the difference of BS
powers. This condition is met in most cases. If it is not the case, the difference can be corrected by the operator with
the HO_MARGIN(0,n) parameter (HO hysteresis).
> PBGT >0: the neighbour cell is more advantageous as the path loss is lower than in the current cell.
> PBGT <0: the serving cell is more advantageous than the current cell.
Page 105
2.5 Handover Detection
Handover Cause 12: Power Budget (6/11)
> CAUSE 12: Power budget PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO
- (BS_TXPWR_MAX AV_BS_TXPWR_HO)
- (MS_TXPWR_MAX(n) MS_TXPWR_MAX)
- PING_PONG_MARGIN(n, call_ref)
Hysteresis to avoid ping-pong HO
> The main drawback of this handover category is the risk of "ping-pong " effect, which is an oscillating back and forth
handover between two (or three) cells. As the "better cell" handovers are meant to find the "best cell", the variation of
the radio conditions will trigger a big amount of better cell handovers, if the algorithms have a too sensitive reaction.
Hence, some mechanisms are forecast, in order to prevent these oscillations from occurring repeatedly at given
places.
Page 106
2.5 Handover Detection
Handover Cause 12: Power Budget (7/11)
> CAUSE 12: Power budget
ping_pong_margin example
Case 1
Case 3
Case 2
C e ll C e ll C e ll
> Warning: this mechanism is not applied for emergency handovers (new mechanism in B7 exists for capture HO,
based on T_INHIBIT_CPT timer).
Page 107
2.5 Handover Detection
Handover Cause 12: Power Budget (8/11)
> CAUSE 12: Power budget
> If EN_TRAFFIC_HO(0,n)=ENABLE
Then PBGT(n) > HO_MARGIN(0,n) + OFFSET_HO_MARGIN_INNER
+ max(0, DELTA_HO_MARGIN(0,n))
(n=1BTSnum)
Else PBGT(n) > HO _MARGIN(0,n)
+OFFSET_HO_MARGIN_INNER
> Cause 12 HO is correlated with HO cause 23. This is why there are two equations according to the activation of HO
cause 23 (EN_TRAFFIC_HO).
Page 108
2.5 Handover Detection
Handover Cause 12: Power Budget (9/11)
> CAUSE 12: Power budget
> Mechanism to avoid PBGT HO if the level from the serving cell is
high enough
> RXLEV_LIMIT_PBGT_HO: threshold above which it is not
necessary to trigger a handover on power budget
> AV_RXLEV_PBGT_HO: average of the received levels over
A_PBGT_HO measurements
W/O B6 WITH B6
Page 109
2.5 Handover Detection
Handover Cause 12: Power Budget (10/11)
> CAUSE 12: Power budget
> DELTA_HO_MARGIN(0,n) is evaluated according to the traffic situation of the serving cell and the neighbour cell n
(Traffic_load(n)) in the following way:
If Traffic_load(0)=high and Traffic_load(n)=low
DELTA_HO_MARGIN(0,n)= -DELTA_DEC_HO_margin
If Traffic_load(0)=low and Traffic_load(n)=high
DELTA_HO_MARGIN(0,n)= DELTA_INC_HO_margin
else DELTA_HO_MARGIN(0,n)=0
where DELTA_DEC_HO_margin allows the cause 23 (traffic handover) detection.
> When the traffic in the serving cell is high and is low in the cell n:
DELTA_INC_HO_margin allows to penalize the cause 12 detection when the traffic in the serving cell is low
and is high in the cell n.
Note:
In the case of concentric or multiband cells, if the channel is in the inner zone (ZONE_TYPE = INNER),
BS_TXPWR_MAX and MS_TXPWR_MAX in equation must be replaced by BS_TXPWR_MAX_INNER and
MS_TXPWR_MAX_INNER respectively.
If the channel is in the outer zone (ZONE_TYPE = OUTER), the formulation of equation is not changed.
Note: The value of PBGT(n) is calculated every SACCH period for each neighbour cell n whose measures are kept in the
book-keeping list.
Page 110
2.5 Handover Detection
Handover Cause 12: Power Budget (11/11)
> CAUSE 12: Power budget
> TCH_INFO_PERIOD = 5s period used by the BSC to count the number of free TCHs.
Page 111
2.5 Handover Detection
Handover Cause 23: Traffic (1/2)
> CAUSE 23: Traffic Handover
> The principle of this handover is to reduce the size of the serving cell when it is high-loaded relatively to a low-loaded
cell.
> When the mobile moves away from the BTS, the power budget will increase and a better cell handover will be
triggered earlier.
> It is recommended to inhibit Traffic handover towards 1-TRX cells. These cells do not have enough resources to
receive incoming handovers due to congestion of neighbour cells. Moreover because of the great variation of traffic in
the 1-TRX cells, traffic load is never considered as low.
> This cause is inhibited for handover from SDCCH to SDCCH.
> Cause 23 is checked over all the neighbouring cells belonging to the same layer. It means that it is checked between
cells whose CELL_LAYER_TYPE is single or upper, between cells whose CELL_LAYER_TYPE is lower, and
between cells whose CELL_LAYER_TYPE is indoor.
> In addition to the condition on the cell layer type, the cell frequency band condition for checking Cause 23 is as
follows whether or not the MS is in the inner zone of a multi-band cell:
a) The MS is not in the inner zone of a multi-band cell
If the flag EN_MULTI-BAND_PBGT_HO is set to disabled, Cause 23 must not be checked between
cells which use different frequency bands (i.e cells having different CELL_BAND_TYPE).
If the flag EN_MULTI-BAND_PBGT_HO is set to enabled, Cause 23 will be checked over all the
neighbouring cells without any cell frequency band restriction.
b) The MS is in the inner zone of a multi-band cell
If the flag EN_MULTI-BAND_PBGT_HO is set to disabled, Cause 23 is checked over all the
neighbouring cell multi-band cells (FREQUENCY_RANGE= PGSM-DCS1800 or EGSM-DCS1800)
which belong to the same BSC as the serving cell.
If the flag EN_MULTI-BAND_PBGT_HO is set to enabled, Cause 23 will be checked over all the
neighbouring cells without any cell frequency band restriction.
Page 112
2.5 Handover Detection
Handover Cause 23: Traffic (2/2)
> CAUSE 23: Traffic Handover
DELTA_HO_MARGIN(0,n) computation is already described in
Cause 12 HO
DELTA_HO_MARGIN(0,n) < 0dB means that
The serving cell is loaded
The target cell is unloaded
PBGT(n) > HO_MARGIN(0,n) + OFFSET_HO_MARGIN_INNER
+ DELTA_HO_MARGIN(0,n) (n=1BTSnum)
This constraint is less discriminative than Cause 12
In specific traffic distribution, this cause is triggered before
cause 12
Introduction to Radio Fine Tuning BSS Release B9 113
Page 113
2.5 Handover Detection
Handover Cause 12 & 23 interworking
> Cause 12 & 23: A dynamic way to handle traffic load
PBGT (n2) Handover from n1 to n2
N2 loaded
PBGT Handover
PBGT Handover
HO_MARGING(n1, n2) + DELTA_INC_HO_margin
Traffic Handover
HO_MARGING(n1, n2)
HO_MARGING(n2, n1)
Traffic Handover 2 x HO_MARGIN
+ DELTA_INC_HO_margin
HO_MARGING(n2, n1) + DELTA_INC_HO_margin
PBGT Handover - DELTA_DEC_HO_margin
PBGT Handover
N1 loaded
2 x HO_MARGIN
> The figure represents the triggering areas of PBGT and traffic handovers according to the traffic load in the serving
cell and in the neighbour cell.
Page 114
2.5 Handover Detection
Directed Retry principles
> Directed Retry is:
an SDCCH to TCH intercell handover
Triggered during call setup procedure
> If the serving cell is completely congested, the MS is allocated an SDCCH
> If no TCH is available, the MS is queued
Under certain conditions, the MS obtains TCH in another cell
> SDCCH-TCH handover on:
better condition or emergency causes = Directed Retry
cause 20 = Forced Directed Retry
> Internal and External Directed Retries are possible (since B6.2)
Page 115
2.5 Handover Detection
Directed Retry
> Directed Retry
Page 116
2.5 Handover Detection
Forced Directed Retry: cause 20
> CAUSE 20: Forced Directed Retry
Page 117
2.5 Handover Detection
FDR: Candidate cell evaluation
> Pre-ranking
using PREF_LAYER, PRIORITY(0,n), frequency band
Page 118
2.5 Handover Detection
FDR: parameters
> L_RXLEV_NCELL_DR(n): level required in the neighbour cell n
The parameter considered is the one set in the neighbour
cell
The default value depends on network architecture
See next slide
> Freelevel_DR(n): number of free TCH channels required in the
neighbour cell n
The parameter considered is the one set in the neighbour
cell
Default value = 0 to 4 TCHs (linked to the nb of TRXs)
> A_PBGT_DR: Averaging window
Default value = 4 SACCHs
Page 119
2.5 Handover Detection
Cause 24: general capture
> CAUSE 24: general capture
Capture handover
Modified in B8:Inhibition of capture handovers for Single
layer serving cell
C ell
rvi n g c e Se ll
May be triggered C ell
Page 120
2.5 Handover Detection
Cause 24: general capture
> CAUSE 24: general capture
> Case the serving cell is in the upper or single layer (CELL_LAYER_TYPE(n0) = upper or single):
> Condition 1: The immediately preceding cell n-1 is in the indoor or lower layer, i.e. CELL_LAYER_TYPE(n1) =
lower or indoor, or the frequency band of the immediately preceding cell n-1 is different from the frequency band
of the serving cell n0, i.e. CELL_BAND_TYPE(n1) <> CELL_BAND_TYPE(n0).
> Condition 2: The call has previously performed i) an emergency internal handover on quality (Cause 2, 4, and
7) towards the serving cell or ii) an external handover with the A interface GSM cause uplink quality or downlink
quality and there is a bi-directional adjacency link between the preceding external cell n-1and the serving cell n0.
Page 121
2.5 Handover Detection
Handover Cause 28: Fast Traffic HO (1/4)
> CAUSE 28: Fast Traffic HO
Push out of a cell a mobile in dedicated mode to allow a queued
request to be served in the serving cell
Complement the current traffic HO (Cause 23), for sudden
traffic peaks (no averaging window used)
More efficient where the overlap of adjacent cells is reduced
Most appropriate MS
c all attem pt to be pushed out
N ew
HO
C o n g es te d N e ig h bo r c el l C el l
Servi ng cell
Congested N e ig h bo r c el l C el l
Serving cell
Page 122
2.5 Handover Detection
Handover Cause 28: Fast Traffic HO (2/4)
> CAUSE 28: Fast Traffic Handover
Page 123
2.5 Handover Detection
Handover Cause 28: Fast Traffic HO (3/4)
> CAUSE 28: Fast Traffic Handover equation
Page 124
2.5 Handover Detection
Handover Cause 28: Fast Traffic HO (4/4)
> CAUSE 28: Fast Traffic Handover process
Resource Allocation Handover Handover
Management Preparation Management
HO alarm:
No
cause 28?
Yes
Fast Traffic HO Acknowledge
- Queued request reference EN_CAUSE_28=disable
- Reference of MS can perform HO
Check first
Start HO 2 conditions of cause 28
- Cause number 28 T_FILTER
Yes - Reference of the call to handover OK
is started
(which corresponds to the first
NO Request candidate MS received) NOK
still queued?
END
DHCP END
DHCP
Note: the first two conditions of cause 28 are tested twice in order to be sure that the candidate cells are still valid when
the cause 28 start HO message is received from the RAM process.
Page 125
2.5 Handover Detection
Handover Cause 15: UL Interference
> CAUSE 15: High interference on the uplink
Intracell HO
AV_RXQUAL_UL_HO > THR_RXQUAL_CAUSE_15 +
OFFSET_RXQUAL_FH
AND AV_RXLEV_UL_HO > RXLEV_UL_IH
AND EN_CAUSE_15 = ENABLE
AND [ no previous intracell handover for this connection
failed
OR EN_INTRACELL_REPEATED = ENABLE ]
Size of window for averaging quality: A_QUAL_HO
Size of window for averaging level: A_LEV_HO
> THR_RXQUAL_CAUSE_15 and EN_CAUSE_15 are not parameters but variables defined just after.
> In B7:
New causes (26 & 27) introduced due to AMR support
Cause 26 is an emergency condition:
Intracell HO: speech codec from AMR-HR to AMR-FR
Cause 27 is a better condition
Intracell HO: speech codec from AMR-FR to AMR-HR
Causes 15 & 16 are modified due to AMR support
Specifics enablers and thresholds for AMR calls
AMR emergency HO (cause 26) is triggered if cause 15 or 16 has already been triggered
Cause 29 is created for intracell handover due to TFO
Codec sharing and optimization for MTM calls
Page 126
2.5 Handover Detection
Handover Cause 16: DL Interference
> CAUSE 16: High interference on the downlink
Intracell HO
AV_RXQUAL_DL_HO > THR_RXQUAL_CAUSE_16 +
OFFSET_RXQUAL_FH
AND AV_RXLEV_DL_HO > RXLEV_DL_IH
AND EN_CAUSE_16 = ENABLE
AND [ no previous intracell handover for this connection failed
OR EN_INTRACELL_REPEATED = ENABLE ]
Size of window for averaging quality: A_QUAL_HO
Size of window for averaging level: A_LEV_HO
> THR_RXQUAL_CAUSE_16 and EN_CAUSE_16 are not parameters but variables defined after.
Page 127
2.5 Handover Detection
New parameters for causes 15 & 16
> CAUSE 15 and CAUSE 16:
THR_RXQUAL_CAUSE_15 (or 16) and EN_CAUSE_15 (or 16) are
specific to HOP
THR_RXQUAL_CAUSE_15 (or 16) =
L_RXQUAL_XX_H for a non AMR call (same threshold as
CAUSE 2 or CAUSE 4)
L_RXQUAL_XX_H_AMR for an AMR call
EN_ CAUSE _15 (or 16) =
EN_INTRA_XX for a non AMR call
EN_INTRA_XX_AMR for an AMR call
> XX = UL or DL
> For a non AMR call, the thresholds used are identical to the ones used for CAUSE 2 and CAUSE 4.
> In this case and if EN_INTRACELL_REPEATED = DISABLE, when aN HO CAUSE 15 (or 16) fails, it can be modified
as UPLINK (or DOWLINK) QUALITY, HO CAUSE 2 (respectively HO CAUSE 4).
Page 128
2.5 Handover Detection
Adaptive Multi-rate codec (AMR)
> Principles:
Two consecutive encodings: speech coding and channel coding
With current codecs, the share of each coding is FIXED (not
FIXED
optimized)
Channel coding
Speech coding Speech protection
Speech information "useful part" "against degradation"
13 Kbit/s (FR)
22.8 Kbit/s (FR TS)
ou 12.2 Kbit/s (EFR)
Voice
Radio
Channel coding
Speech coding Speech protection
Speech information "useful part" "against degradation"
5.6 Kbit/s (HR) 11.4 Kbit/s (HR TS)
Voice
Radio
> The main speech codec currently used in GSM networks, speech Full Rate, is quite old. It has been specified more
than 10 years ago. Around 1992, to increase network capacity, GSM has specified a half rate speech codec. But this
codec showed strong limitations in terms of speech quality, especially for mobile to mobile calls (double transcoding
degrades very much the speech quality of the half rate codec) and under poor radio conditions.
> Recently, studies on AMR have been launched to provide a solution to:
Increase speech quality in full rate and half rate,
Increase network capacity by offering a good half rate solution,
Use a long-term solution, to avoid adding more and more codecs handled independently from the others.
Page 129
2.5 Handover Detection
AMR: codec and channel adaptation
AMR uses a variable balance between speech coding and channel
coding (CODEC Mode Adaptation)
E XIBL
FL E Speech coding
Channel coding
Variable channel
Variable speech coding rate coding rate
4.75 Kbit/s 6.7 Kbit/s 10.2 Kbit/s
5.15 Kbit/s 7.4 Kbit/s 12.2 Kbit/s 22.8 Kbit/s (FR TS)
5.9 Kbit/s 7.95 Kbit/s
Voice Radio
Channel coding
Speech coding
Variable channel
Variable speech coding rate coding rate
4.75 Kbit/s 5.9 Kbit/s 7.4 Kbit/s 11.4 Kbit/s (HR TS)
5.15 Kbit/s 6.7 Kbit/s 7.95 Kbit/s (AMR HR 7.95 not supported)
Voice Radio
> In order to adapt the intermediate rate, a set of speech codecs has been defined by ETSI to be used by AMR:
When radio conditions are good, increases speech information.
When radio conditions are bad, protects speech information.
> Full Rate: Alcatel implementation is fully compliant with GSM recommendations. All these AMR FR codec modes are
supported. In particular, the Alcatel BSS has implemented the 7.95, 5.9 and 4.75 codec modes which use
polynomials of constraint length 7 to ensure a high protection.
> Half Rate: Alcatel implementation supports 5 out of 6 AMR HR codec modes (AMR HR 7.95 is not supported) which
are fully compliant with GSM recommendations. In particular, the Alcatel BSS has implemented the 4.75 codec mode
which uses polynomials of constraint length 7 to ensure a high protection.
> During a call, only a subset out of these 8 codecs is used. The subset can include from 1 to 4 codecs. It is up to the
operator to define its own codec subset. In particular, he can define a codec subset limited to the common codec
modes supported by all the BSSs of its network (some BSSs may not be able to support all of them due to
implementability problems).
The codec subset defined by the operator is the same in the uplink and in the downlink.
Page 130
2.5 Handover Detection
AMR codec adaptation objective
Based on adaptive trade-off between the share of throughput
given to speech coding and the one given to channel coding
(speech protection)
Depends on radio conditions estimated in real-time
> The AMR principle is to have a set of codecs and, for any radio conditions, to use the one with the best speech
quality.
Under good radio conditions, a codec with a high bit rate is used. Speech is encoded with more information
so the quality is better. In the channel coding, only little place is left for redundancy.
Under poor radio conditions, a codec with a low bit rate is chosen. Speech is encoded with less information,
but this information can be well protected due to redundancy in the channel coding.
> The BSS adapts dynamically the codec in uplink direction and in downlink direction, taking into account the C/I
measured by the BTS (for uplink adaptation) and by the MS (for downlink adaptation).
> The codec used in the uplink and used in the downlink can be different: the adaptation is independent in each
direction.
> This permits to use an optimal codec for each C/I value of each direction, as indicated in the figure below.
Speech
Quality
[dBQ]
or
[MOS]
C/I [dB]
Page 131
2.5 Handover Detection
AMR: codec mode adaptation (1/3)
> Codec mode adaptation
Only a subset out of these codecs can be used
This subset may include from 1 to 4 codecs
The same codec subset is used for both the Uplink and the
Downlink
Uplink codec mode adaptation:
For each SACCH frame, the BTS compares C/I value to the
threshold corresponding to the current codec (belonging to
the codec subset defined by the operator)
Downlink codec mode adaptation:
Same process as uplink adaptation
Nevertheless, the BTS remains the master
Unrelated processes uplink and downlink codecs may be
different at a given time
Page 132
2.5 Handover Detection
AMR codec mode adaptation (2/3)
> The Codec mode can be modified on one frame out of two (CMI /
CMC-CMR).
> Decision based on thresholds (OMC-R settable), for the uplink and the
downlink C/I norm
High CODEC_MODE_4
(less robust)
AMR_FR_THR_3 + AMR_FR_HYST
AMR_FR_THR_3
CODEC_MODE_3
AMR_FR_THR_2 + AMR_FR_HYST
AMR_FR_THR_2
CODEC_MODE_2
AMR_FR_THR_1 + AMR_FR_HYST
AMR_FR_THR_1
CODEC_MODE_1
(most robust)
Low
Page 133
2.5 Handover Detection
AMR: codec mode adaptation (3/3)
> Codec mode adaptation
Uplink MS BTS TC
adaptation
C/I evaluation &
thresholds comparison
Downlink MS BTS TC
adaptation
C/I evaluation &
thresholds comparison
Page 134
2.5 Handover Detection
AMR: codec and channel mode adaptation
> Codec mode adaptation is dynamically performed through a set of pre-
defined codec modes:
In FR mode: Speech coding Channel coding
Channel coding
In HR mode: Speech coding
Variable speech coding rate Variable speech coding rate
> The metric used for codec mode adaptation is the evaluation of the ratio: signal over noise.
Page 135
2.5 Handover Detection
AMR gain
> AMR: always gives end user the best satisfaction
Comparison between different codecs in terms of capacity and
quality:
EFR
HR
AMR-FR
AMR-HR
AMR-FR + AMR-HR
> The main speech codec currently used in GSM networks, speech Full Rate, is quite old. It has been specified more
than 10 years ago.
> Around 1992, to increase network capacity, GSM has specified a half rate speech codec. But this codec showed
strong limitations in terms of speech quality, especially for mobile to mobile calls (double transcoding degrades very
much the speech quality of the half rate codec) and under poor radio conditions.
> A few years later, when GSM started to be introduced in North America, American operators asked for an improved
speech codec for full rate channels. Indeed speech quality was a major argument for customers used to have a good
speech quality with analog systems. For that issue, EFR was specified for GSM.
> Recently, studies on AMR have been launched to provide a solution to:
Increase speech quality in full rate and half rate,
Increase network capacity by offering a good half rate solution,
Use a long-term solution, to avoid adding more and more codecs handled independently from the others,
Take into account Tandem Free Operation (TFO), especially between MSs on half rate on one side and on
full rate on the other side.
Page 136
2.5 Handover Detection
AMR: TCH allocation
> FR / HR discrimination
Cell load AV_LOAD() computed from
load samples = NB_BUSY_TS / NB_TS * 100
non sliding window (LOAD_EV_PERIOD) averaging process
AV_LOAD
100%
HR for any MS
THR_FR_LOAD_U_SV1=80%
HR for AMR MS
FR for other MS
THR_FR_LOAD_L_SV3=40%
FR for any MS
Time
> Load samples are computed by the BSC every TCH_INFO_PERIOD = 5 seconds.
> LOAD_EV_PERIOD is the averaging window size for cell load computation. It is equal to 12 but can be changed at
the OMC-R level on a per cell basis.
> Therefore cell load process has a periodicity of 1mn by default (TCH_INFO_PERIOD*LOAD_EV_PERIOD).
> The allocation of Half rate resources is decided upon the load evaluation in the serving cell.
> AMR HR (HR SV3) offers a better speech quality than HR SV1. The Alcatel BSS offers thus the possibility to define a
set of thresholds specific for AMR. If the load increases, AMR HR capable MSs can be the first to be allocated in HR
(HR SV3) for load reasons, and if the load still increases, then all the HR capable MSs can be allocated in HR (HR
SV1 & HR SV3) for load reasons.
This is why two variables of load are defined: LOAD_SV3 and LOAD_SV1.
> Each load variable is calculated through its own threshold set: the thresholds related to the variable LOAD_SV3
(THR_FR_LOAD_U_SV3 and THR_FR_LOAD_L_SV3) are less restrictive than the ones related to the variable
LOAD_SV1 (THR_FR_LOAD_U_SV1 and THR_FR_LOAD_L_SV1).
As a consequence, if the load of the cell increases, then the variable LOAD_SV3 will first equal TRUE, and if
the load still increases, the variable LOAD_SV1 will then equal TRUE.
> The variable LOAD_SV1 corresponds to a level of load where it is important to put as many MSs on half rate TCH as
possible: HR SV3 or HR SV1.
Previous state LOAD_SV1 = FALSE LOAD_SV1 = TRUE
AV_LOAD
AV_LOAD THR_FR_LOAD_L_SV1 LOAD_SV1 = FALSE LOAD_SV1 = FALSE
THR_FR_LOAD_L_SV1 < LOAD_SV1 = FALSE LOAD_SV1 = TRUE
AV_LOAD
THR_FR_LOAD_U_SV1
THR_FR_LOAD_U_SV1 < AV_LOAD LOAD_SV1 = TRUE LOAD_SV1 = TRUE
> The same computation is done to compute LOAD_SV3 with the thresholds: THR_FR_LOAD_U_SV3 and
THR_FR_LOAD_L_SV3 with the following relations:
THR_FR_LOAD_L_SV3 THR_FR_LOAD_U_SV3
THR_FR_LOAD_U_SV3 THR_FR_LOAD_U_SV1
THR_FR_LOAD_L_SV3 THR_FR_LOAD_L_SV1
Page 137
2.5 Handover Detection
Cause 26: AMR HR to FR HO (1/4)
Cause 26 is triggered if :
Current channel rate is HR
Current channel is dual rate and changes are allowed
AMR_FR speech codec is allowed:
EN_AMR_FR = ENABLE
Page 138
2.5 Handover Detection
Cause 26: AMR HR to FR HO (2/4)
> CAUSE 26: AMR channel adaptation HO (HR to FR) equation
> [ a previous intracell HO cause 15 or 16 has been triggered for this call
in the serving cell
OR
EN_INTRA_DL_AMR = DISABLE and EN_INTRA_UL_AMR = DISABLE]
> AND
AV_RXQUAL_UL_CA_HR_FR > THR_RXQUAL_CA + OFFSET_CA
+ OFFSET_RXQUAL_FH and AV_RXLEV_UL_HO > RXLEV_UL_IH
OR
AV_RXQUAL_DL_CA_HR_FR > THR_RXQUAL_CA + OFFSET_CA
+ OFFSET_RXQUAL_FH and AV_RXLEV_DL_HO > RXLEV_DL_IH
> AND EN_AMR_CA = ENABLE
Page 139
2.5 Handover Detection
Cause 26: AMR HR to FR HO (3/4)
> CAUSE 26: AMR channel adaptation HO (HR to FR)
Page 140
2.5 Handover Detection
Cause 26: AMR HR to FR HO (4/4)
> CAUSE 26: AMR channel adaptation HO (HR to FR)
Calculation of LOAD_SV3(0):
If previous value of LOAD_SV3 = false then
If AV_LOAD > THR_FR_LOAD_U_SV3 then
LOAD_SV3 = true
Else LOAD_SV3 = false
Annex 3
Page 141
2.5 Handover Detection
Cause 27: AMR FR to HR HO (1/2)
Page 142
2.5 Handover Detection
Cause 27: AMR FR to HR HO (2/2)
> CAUSE 27: AMR channel adaptation HO (FR to HR) equation
> AV_RXQUAL_UL_CA_FR_HR <= THR_RXQUAL_CA
+ OFFSET_RXQUAL_FH
> AND
AV_RXQUAL_DL_CA_FR_HR <= THR_RXQUAL_CA
+ OFFSET_RXQUAL_FH
> AND EN_AMR_CA = ENABLE
Page 143
2.5 Handover Detection
Cause 26 & 27 interworking
> Cause 26 & 27 interaction
Quality
Bad quality: 7
Half Rate Half Rate
HO cause 27
THR_RXQUAL_CA_NORMAL
THR_RXQUAL_CA_NORMAL +
OFFSET_CA_NORMAL
HO cause 26
HO cause 27
THR_RXQUAL_CA_HIGH
THR_RXQUAL_CA_HIGH +
OFFSET_CA_HIGH
HO cause 26
Page 144
2.5 Handover Detection
Introduction to TFO (1/2)
> Tandem Free Operation (TFO) solution
Double transcoding without TFO
MS A MS B
TC TC
No transcoding withTFO
MS A MS B
TC TC
> The Tandem Free Operation (TFO) feature is a way to avoid double transcoding in mobile to mobile speech calls.
> Indeed without TFO, one GSM codec type is used between the first mobile and the first transcoder, then the speech
is transcoded into A/ law between transcoders and finally this speech is transcoded again into a second GSM codec
type (which may be the same as the first one) between the second transcoder and the second mobile.
> With TFO, after call establishment, both BSSs at each side are able to negotiate a common GSM codec type which is
then used from one mobile to the other mobile. This negotiation is performed through in-band signaling between
transcoders.
Page 145
2.5 Handover Detection
Introduction to TFO (2/2)
> Applicability: Only MS to MS speech calls
> TFO is based on information exchanged between transcoders
TRAU TRAU
Page 146
2.5 Handover Detection
TFO principles
> In the case of first allocation (normal assignment at call setup, inter-BSS
handover, intra-BSS handover where no TFO was previously on-going):
Yes No
Match
Look for common codec
Yes No
Found
Intracell HO
Page 147
2.5 Handover Detection
Cause 29: TFO HO
> CAUSE 29: TFO HO
Page 148
2.5 Handover Detection
Cause 29: TFO parameters (1/5)
> EN_TFO
enables/disables the feature, per cell
> EN_TFO_MATCH
enables/disables resolution of codec mismatch, per cell
> EN_TFO_OPT
enables/disables codec optimization, per cell
> FORCE_TFO_VS_AMR
enables/disables the basic functions of TFO for GSM EFR, FR
and HR codec types when the current codec is AMR FR or AMR
HR
> FORCE_TFO_HR_WHEN_LOADED
controls the establishment of TFO in HR when the cell is loaded
> KEEP_CODEC_HO
indicates if the BSC tries to keep the same codec in case of
internal intercell HO
At call setup for a mobile to mobile speech call, when both BSSs do not use the same codec type, a codec
mismatch occurs. If a common codec type can be found, either one or possibly both BSSs perform an
intracell handover to use the common codec type found. Afterwards TFO can be started using this common
codec type. Codec mismatch resolution is authorized in the BSC using an O&M flag: EN_TFO_MATCH. This
flag is forwarded to the TC, via the BTS.
> Codec optimization:
At call setup for a mobile to mobile speech call, it can occur that a first common codec type can be found but
a better speech quality would be provided with another common codec type. Once both BSSs operate in
Tandem Free, they exchange their complete codec capabilities, to try to find a better codec type than the
current one. Codec optimization is authorized in the BSC using an O&M flag : EN_TFO_OPT. This flag is
forwarded to the TC, via the BTS.
> Classification of codec types :
In all cases, TFO is considered better as any tandeming configuration. In TFO, EFR is considered as better
than FR, considered as better than HR.
> Force TFO vs. AMR :
TFO + AMR is not supported in this implementation of TFO. In the normal operation, a call established with
AMR will not initiate a TFO negotiation. The goal of the function Force TFO vs. AMR is to allow a call,
established with AMR to initiate a TFO negotiation and, if possible, to change of codec type to FR, HR or EFR
to establish TFO.
> In-Path Equipments (IPEs):
TFO can only be activated if TFO frames (at 8 or 16 Kbit/s) can be sent transparently through the public
switching network. In-path equipments are equipments such as echo cancelers or A/ law converters that
modify the 64 Kbit/s speech signal. Such equipments need to be deactivated for TFO calls.
Page 149
2.5 Handover Detection
Cause 29: TFO parameters (2/5)
> EN_TFO_OPT: enables/disables codec optimization, per cell
Allows new TFO negotiation on an on-going MTM call to find a
better common codec
For example, HR is used at both sides, but FR is possible too
HO cause 29 will be triggered on both sides towards best
codec
Page 150
2.5 Handover Detection
Cause 29: TFO parameters (3/5)
> FORCE_TFO_VS_AMR:
TFO AMR not specified
Call setup in AMR is not followed by TFO negotiation
FORCE_TFO_VS_AMR enables HO cause 29 after AMR call
establishment towards best TFO codec
MS A MS B
A C el ap: C e ll c a p :
M R/H l c F R/ F R H R/ E F R/ F R
R/ E
Page 151
2.5 Handover Detection
Cause 29: TFO parameters (4/5)
> FORCE_TFO_HR_WHEN_LOADED:
Gives control on load regulation precedence vs. TFO
3 values: TFO_HR_NOT_FORCED, TFO_HR_ONLY,
TFO_HR_PREFERRED enable different behaviours in case of
loaded cell
MS A MS B
Page 152
2.5 Handover Detection
Cause 29: TFO parameters (5/5)
> KEEP_CODEC_HO
keeps the same codec type in the new cell in case of internal
intercell HO in order to avoid resolving a new mismatch codec
situation
Avoids double speech quality transition:
TFO --> non-TFO --> TFO
3 possible behaviors:
TFO_CALLS_ONLY: codec is preferably kept in case of
internal intercell HO for TFO calls only
ALL_CALLS: codec is preferably kept in case of internal
intercell HO for all calls (whatever the TFO state)
FREE: the choice of the codec type is free and depends on
the situation in the target cell
Page 153
2.5 Handover Detection B9
Cause 30: Move from PS to CS zone
PS PS PS PS CS PS PS CS BCCH SDCCH CS
TRX3 TRX1
Non pre-emptable zone
HO cause 30
MAX_SPDCH_HIGH_LOAD zone
MAX_SPDCH_LIMIT zone
PS traffic zone
> Non pre-emptable PS zone: this zone is always inside the MAX_SPDCH_HIGH_LOAD zone. In this latter zone, we
search for the rightest timeslot allocated to the MFS and used. Then, all timeslots situated at its left define this non
pre-emptable PS zone.
> MAX_SPDCH_LIMIT zone: this zone corresponds to the MAX_SPDCH_LIMIT consecutive PS capable timeslots
that are preferred for PS allocation.
> PS traffic zone: this zone corresponds to the larger zone between the non pre-emptable PS zone and the
MAX_SPDCH_LIMIT zone.
Page 154
2.5 Handover Detection
Handover causes priorities
HANDOVER PRIORITIES
> The causes 24, 12 and 23 have the same priority. Nevertheless, if a cell is a candidate for both causes, triggered in
the same time, it is kept only for cause 12.
> Dealing with all available causes, we get the following list:
Emergency: 7 > 17 > 18 > 2 > 4 > 3 > 5 > 6 > 22 > 10 > 11 > 26 > 15 > 16
Better conditions: 21=14=24=12=23 > 13 > 27 > 20 > 28
29,30 and 31 has no priority (can be detected at any time)
Page 155
2.5 Handover Detection
Training exercises (1/16)
> Emergency causes
1- What is the HO cause 2?
2- Which is the flag to activate the HO
cause 2?
Time allowed:
45 minutes
Page 156
2.5 Handover Detection
Training exercises (2/16)
> Emergency causes
Complete the diagram below and fill in the chart with:
L_RXQUAL_UL_H = 3
RXLEV_UL_IH = -70 dBm
P=MS_TXPWR_MAX=33dBm
Quality
Nb of case 1 2 3 4 5 6
AV_RXQUAL_UL_HO 4 1 3 4 4 4
AV_RXLEV_UL_HO -81 -79 -75 -70 -69 -72
29 Level
Current MS power 33 33 33 33 33 (0.8 w)
HO cause 2: YES/NO?
Page 157
2.5 Handover Detection
Training exercises (3/16)
> Better condition causes (simple case)
There are only 2W cells and 2W MS
EN_TRAFFIC_HO(0,n) =Disable
No Ping-Pong margin
S e rvi n g c e l l N c el l
HO_MARGIN(0,n) =5 dB
NO DL PC,
RXLEV_LIMIT_PBGT_LIMIT=-47dBm,
The serving is not a concentric cell.
> Fill up the chart: Nb of case 1 2 3 4 5 6
AV_RXLEV_NCELL(n) -70 -70 -80 -70 -70 -75
AV_RXLEV_PBGT_HO -80 -70 -75 -75 -79 -96
PBGT(n)
HO cause 12: YES/NO?
Page 158
2.5 Handover Detection
Training exercises (4/16)
> Better condition causes (ping-pong case)
EN_TRAFFIC_HO(0,n) =Disable
Ping-Pong margin
PING_PONG_HCP=15db
T_HCP =15s ?
ing c el S e rv c ell N l
HO_MARGIN(0,n) =5 dB
A_PBGT_HO = 8 SACCH
A n to 0 HO has just been triggered, what happens after 4s?
Nb of case 1 2 3 4 5 6
AV_RXLEV_NCELL(n) -70 -70 -80 -70 -70 -75
AV_RXLEV_PBGT_HO -80 -70 -75 -75 -79 -96
PBGT(n) 10 0 -5 5 9 21
HO cause 12: YES/NO? PBGT>HO margin YES NO NO NO YES YES
PING_PONG_HCP=15 -> PBGT(n)
HO cause 12:YES/NO?
Page 159
2.5 Handover Detection
Training exercise (5/16)
> Training exercise: Handover Detection
Better condition causes (traffic case)
EN_TRAFFIC_HO(0,n) =Enable
No Ping-Pong margin
HO
HO_MARGIN(0,n) =5 dB
DELTA_DEC_HO_margin =5dB
DELTA_INC_HO_margin =5dB S e rvi n g c e l l N c el l
Page 160
2.5 Handover Detection
Training exercises (6/16)
> Better condition causes (traffic case)
HO ?
Fill up the chart: S e rvi n g c e l l N c el l
Nb of case 1 2 3 4
AV_RXLEV_NCELL(n) -71 dBm -71 dBm -76 dBm -71 dBm
AV_RXLEV_PBGT_HO -80 dBm -80 dBm -80 dBm -80 dBm
Traffic distribution 0: traffic low 0: traffic high 0: traffic high 0: traffic low
N: traffic high N: traffic low N: traffic low N: traffic low
PBGT(n)
DELTA_HO_MARGIN (0, n)
Cause 12 HO: YES/NO?
Cause 23 HO: YES/NO?
Page 161
2.5 Handover Detection
Training exercises (7/16)
> Channel adaptation (cause 26 and cause 27)
1- Why is it recommended to have A_QUAL_CA_FR_HR
A_QUAL_CA_HR_FR ?
2- An operator may be willing to:
- Under normal load, use only HR calls for quality 0
- Under high load, use HR calls for qualities 0 to 3, with an
hysteresis of 1
Find the thresholds and offsets for normal and high load:
THR_RXQUAL_CA_NORMAL = ? OFFSET_CA_NORMAL = ?
THR_RXQUAL_CA_HIGH = ? OFFSET_CA_HIGH = ?
Page 162
2.5 Handover Detection
Training exercises (8/16)
> Channel adaptation (cause 26 and cause 27)
EN_INTRA_XX_AMR = Disable
RXLEV_XX_IH = -110 dBm
OFFSET_RXQUAL_FH = 0
A_QUAL_CA_FR_HR =4 and A_QUAL_CA_HR_FR = 2
> Use the previous thresholds and fill up the chart:
UL_QUAL 0 1 2 3 3 1 1 0 0 1
DL_QUAL 0 0 1 1 1 0 0 2 4 3
LOAD_SV3 False False False False True True True True True True
AV_RXQUAL_UL_CA_HR_FR
AV_RXQUAL_DL_CA_HR_FR
AV_RXQUAL_UL_CA_FR_HR
AV_RXQUAL_DL_CA_FR_HR
CHANNEL TYPE FR FR FR
Page 163
2.5 Handover Detection
Training exercises (9/16)
> Capture HO (Cause 24 )
There are only 2W cells and 2W MS
L_RXLEV_CPT_HO(0,n) = -85dBm
EN_GENERAL_CAPTURE_HO = ENABLE
HO ?
>
S e rvi n g c e l l
> Fill up the chart: N c el l
Nb of case 1 2 3 4 5 6
AV_RXLEV_NCELL(n) - 70 - 70 - 80 - 70 - 70 - 85
CAPTURE_TRAFFIC_CONDITION NOT_LOW HIGH ANY_LOAD HIGH HIGH HIGH
TRAFFIC_LOAD(0) HIGH LOW INDEFINITE HIGH LOW HIGH
TRAFFIC_LOAD(n) HIGH LOW INDEFINITE LOW LOW LOW
HO cause 24: YES/NO?
Page 164
2.5 Handover Detection
Training exercises (10/16)
> Fast Traffic HO (cause 28)
> Find the appropriate candidate MS for this queued request:
Channel rate required: HR
L_RXLEV_NCELL_DR(n) = -85 dBm (whatever n)
FREElevel_DR(n) = 1 (whatever n)
Channel rate: MS1FR on Full rate TRX, MS2HR, MS3FR on
Dual rate TRX
t(n) for neighbour cells: t(1)=1, t(2)=2, t(3)=2
AV_RXLEV_NCELL(n) in dBm:
Neighbors 1 2 3
Page 165
2.5 Handover Detection
Training exercises (11/16)
> TFO HO (cause 29): after call setup
Find the 2 speech version types of the following MS to MS call
EN_TFO = enable, EN_TFO_MATCH = enable
FORCE_TFO_HR_WHEN_LOADED = TFO_HR_NOT_FORCED
MS A MS B
Page 166
2.5 Handover Detection
Training exercises (12/16)
> TFO HO (cause 29): after call setup
Find the 2 speech version types of the following MS to MS call
EN_TFO = enable, EN_TFO_MATCH = enable
FORCE_TFO_HR_WHEN_LOADED = TFO_HR_ONLY
MS A MS B
Page 167
2.5 Handover Detection
Training exercises (13/16)
> TFO HO (cause 29): after call setup
Find the 2 speech version types of the following MS to MS call
EN_TFO = enable, EN_TFO_MATCH = enable
FORCE_TFO_HR_WHEN_LOADED = TFO_HR_PREFERRED
MS A MS B
Page 168
2.5 Handover Detection
Training exercises (14/16)
> TFO HO (cause 29): after call setup
Find the 2 speech version types of the following MS to MS call
EN_TFO = enable, EN_TFO_MATCH = enable
FORCE_TFO_HR_WHEN_LOADED = TFO_HR_ONLY
MS A MS B
After
call setup
TCH = ? TCH = ?
After TFO
negociation
TCH = ? TCH = ?
Page 169
2.5 Handover Detection
Training exercises (15/16)
> TFO HO (cause 29): after handover
Find the speech version types of the following MS to MS call
EN_TFO = enable, EN_TFO_MATCH = enable
FORCE_TFO_HR_WHEN_LOADED = TFO_HR_ONLY
1. KEEP_CODEC_HO = TFO_CALLS_ONLY
2. KEEP_CODEC_HO = FREE
MS 2
MS 2
MS 1 Call setup +
HO HO
TFO negociation
MS 2
Page 170
2.5 Handover Detection
Training exercises (16/16)
> TFO HO (cause 29): after handover
Find the speech version types of the following MS to MS call
EN_TFO = enable, EN_TFO_MATCH = enable
FORCE_TFO_HR_WHEN_LOADED = TFO_HR_ONLY
KEEP_CODEC_HO = TFO_CALLS_ONLY
1. EN_TFO_OPT = disable
2. EN_TFO_OPT = enable
MS 2
MS 2
MS 1 Call setup +
HO HO
TFO negociation
MS 2
Page 171
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
Page 172
2.6 Handover Candidate Cell Evaluation
Principles
> Used to rank potential target cells:
BTS BSC
HO Preparation
Radio Active
Link HO Candidate
Channel HO Detection
Measurements Cell Evaluation
Pre-processing
HO
management
HO
protocol
MSC
Page 173
2.6 Handover Candidate Cell Evaluation
Evaluation process
HO Detection
Measurement Measurement Raw cell list
result Preprocessing Preprocess Cause 2: uplink quality
measurement Max
Cause 3: uplink level Cell 1: cause C2
A_LEV_HO every SACCH
Cause 4: downlink quality Cell 2: cause C2
A_QUAL_HO
Cause 5: downlink level Cell 3: cause C2
A_PBGT_HO
Cause 6: distance Cell 4: cause C2
A_RANGE_HO
Cause 12: power budget Cell 5: cause C2
Performed every SACCH Cell 6: cause C2
Performed every SACCH Cell 7: cause C2
Cell 8: cause C2
... max 32 cells
> The HO candidate evaluation process is run after all intercell handover alarms.
> In case of intracell handover alarm (HO causes 10, 11, 13, 15, 16), the candidate cell evaluation process is skipped:
the target cell is the serving cell.
> The handover detection gives as indication the raw cell list (built from book-keeping list) and the preferred layer for
the handover. In case of emergency handover alarms or cause 20 alarm, the cell evaluation will order the cells given
in the raw list, putting in the first position the cells belonging to the preferred layer, having the highest priority (if
EN_PRIORITY_ORDERING=ENABLE) and/or having the same frequency band type as the serving cell. In case of
an intercell handover alarm, if the serving cell belongs to the raw cell list (emergency handover from the DCS 1800
inner zone of a multiband cell), this cell is put at the end of the candidate cell list with the MS zone indication OUTER.
> In case of better condition handover alarms (except cause 20), the cell evaluation will order the cells given in the raw
list, putting in the first position the cells belonging to the preferred layer and having the highest priority (if
EN_PRIORITY_ORDERING=ENABLE).
Page 174
2.6 Handover Candidate Cell Evaluation
Pre-ranking
> Pre-ranking in hierarchical or multi-band networks:
For emergency handover and causes 20 and 28 only.
Cell_band_type = serving_cell
Cell_layer_type = Pref_layer Priority(0,n) = 0
Cell_band_type = serving_cell
Priority(0,n) = 1
List of
candidate
cells n Priority(0,n) = 5
!
Cell_layer_type = Pref_layer Priority(0,n) = 0 Cell_band_type
not applicable
Priority(0,n) = 1 to comfort causes
Priority(0,n) = 5
Page 175
2.6 Handover Candidate Cell Evaluation
Pre-ranking
> with priority(0,n) settings, the operator can, for each couple of cells:
tag the target cell with a defined priority (from 0 = max to 5 = min)
this definition has an higher priority than usual order/grade ranking
> especially useful for multi band/hierarchical architectures:
a simple way to force a target cell whatever its RxLev level and PBGT
nevertheless can be skipped over by filtering processes
low interest for standard networks
Priority
RxLev: - 70 dBm
P1
PBGT: + 10 dB
Ca
ndidate cell 1
S ervin g c e ll
RxLev: - 90 dBm
P0
PBGT: + 5 dB
Ca
ndidate cell 2
Page 176
2.6 Handover Candidate Cell Evaluation
PBGT Filtering
> PBGT filtering:
optional, flag EN_PBGT_FILTERING
filter out cells from the target list
inhibited for better cell handovers
based on power budget
per couple of cells
> The filtering process allows to filter out cells from the target list before sending them to the ORDER or GRADE
evaluation process.
> It can be enabled/disabled on-line on a per cell basis from the OMC-R with the flag EN_PBGT_FILTERING.
> The candidate cells are filtered on their power budget in relation to a handover margin threshold based on the
handover cause.
Note: the averaging window used for this process is A_PBGT_HO (even for emergency handovers, where a handover
alarm could have been raised through A_LEV_HO or A_QUAL_HO samples)
Page 177
2.6 Handover Candidate Cell Evaluation
ORDER evaluation
> ORDER cell evaluation process
Cell "n" is ranked among other accordingly:
If EN_LOAD_ORDER = ENABLE and cell n is internal to the BSC
ORDER (n) = PBGT(n) + LINK_FACTOR(0,n) + FREEfactor(n)
- FREEfactor(0)- HO_MARGIN_XX(0,n)
Link_factor (0,n) is an operator parameter to give a bonus/penalty to
a cell
ex: avoid external HO, decrease incoming flow of HO to a cell from
another
FREEfactor is TCH traffic based bonus/penalty to rank cells
If EN_LOAD_ORDER = DISABLE or cell n is external to the BSC
ORDER (n) = PBGT(n) + LINK_FACTOR(0,n) - HO_MARGIN_XX(0,n)
> Two types of cell evaluation algorithms can be used: ORDER and GRADE.
> ORDER and GRADE are two different methods of cell ranking. They both consist in giving a mark or figure of merit
to each candidate cell.
> The basic differences between ORDER and GRADE are that:
with ORDER
The candidate cell evaluation process interacts with the handover detection by use of cause-
dependent handover margins.
The candidate cell evaluation process takes into account the number of free TCHs in the candidate
cells.
with GRADE
The candidate cell evaluation process does not interact with the handover detection.
The candidate cell evaluation process takes into account the relative load of traffic channels in the
candidate cells.
> The type of cell evaluation is chosen by the operator on a (serving) cell basis and is provided to the BSC with the
parameter CELL_EV.
> For any handover cause, the first cell in the list is taken as a target cell, i.e. the cell with the highest value of
ORDER(n). The cells do not need to fulfil any other condition.
> If no cell fulfils the condition and the serving cell does not belong to the target cell list, the target cell list is empty and
no further action is carried out.
Page 178
2.6 Handover Candidate Cell Evaluation
GRADE Evaluation
> GRADE cell evaluation process
Annex 4
Cell "n" is ranked among other accordingly:
If EN_LOAD_ORDER = ENABLE and cell n is internal to the BSC
GRADE (n) = PBGT(n) + LINK_FACTOR(0,n) + LOADfactor(n)
> For any handover cause, the first cell in the list is taken as a target cell, i.e. the cell with the highest value of
GRADE(n). If no cell fulfils the condition and the serving cell does not belong to the target cell list, the target cell list is
empty and no further action is carried out.
Page 179
2.6 Handover Candidate Cell Evaluation
Training exercise (1/2)
> Emergency HO detected
With the Candidate evaluation.xls excel sheet...
Filtering simulation for a list of candidate cells
Ranking simulation for a list ofcandidate cells
Candidate Cell Evaluation
HO Cause DL Level
A_PBGT_HO 6
GRADE EVALUATION
Priority(0,n) 0 for all neighbor cell
HO_MARGIN_LEV(0,n) 0
RX_LEV_MIN(n) -100
LINK_FACTOR(0,n) 0 for all neighbor cell
LoadFactor(n) 0
Time allowed: **
**
**
-93
-93
-93
14
1
1
3
0
0
-92
-89
-90
0
14
14
0 -110
3
3
-91
-94
0
0
0
0 -110
0 -110
0 -110
0
0
0
0 -110
0 -110
0 -110
0
0
0
0 -110
0 -110
0 -110
0
0
0
0 -110
0 -110
0 -110
** -93 1 -0 -88 14 3 -94 3 1 -101 0 0 -110 0 0 -110 0 0 -110
15 minutes **
**
-94
-96
8
1
7
0
-93
-93
1
8
0
7
-93
-95
14
14
3
3
-96
-99
3
3
1 -103
1 -106
0
0
0 -110
0 -110
0
0
0 -110
0 -110
** -96 -1 0 -91 8 7 -95 14 3 -99 3 1 -104 0 0 -110 0 0 -110
** -98 1 0 -92 14 3 -98 8 7 -99 3 1 -107 0 0 -110 0 0 -110
** -101 8 7 -97 1 0 -97 14 3 -102 3 1 -107 0 0 -110 0 0 -110
HOCMD -101 8 7 -96 1 0 -99 14 3 -103 3 1 -108 0 0 -110 0 0 -110
Page 180
2.6 Handover Candidate Cell Evaluation
Training exercise (2/2)
> Emergency HO detected
?
(1;0) 3
2 Averaging measurement
(8;7) 2
Averaged measurements and PBGT(n)
AV_RXLEV_PBGT_HO
AV_RXLEV_PBGT_HO PBGT(n) 4 GRADE evaluation process
(14;3) -100 -2 GRADE evaluation process
(1;0)
(8;7) ?
-95
-96 ? 3
2 (1;0)
GRADE(n)
3
(3;1) -106 -8 (8;7) ? 2
5 Target Cell
? (1;0)
Page 181
2 ALGORITHMS AND ASSOCIATED
PARAMETERS
2.7 Exercise
Page 182
2.8 Exercise
Page 183
3 OTHER ALGORITHMS
Page 184
3 OTHER ALGORITHMS
Session presentation
> Objective: to be able to describe TCH resource allocation,
MS reselection algorithms and list the associated parameters
> Program:
3.1 TCH resource allocation algorithm
3.2 MS Reselection algorithms
Page 185
3 OTHER ALGORITHMS
Page 186
3.1 TCH resource allocation algorithm
Radio Allocation and Management
> Radio resource allocation and management (RAM) aims at:
Managing pools of TCH radio resources by:
defining TCH radio timeslots as a function of the cell radio
configuration from the operator
sorting these TCH TS according to their radio capabilities (FR
or DR, frequency band (G1 or GSM/DCS))
Allocating dedicated TCH radio resources by:
selecting the TCH pool in which the TCH should be chosen
according to:
the requested channel rate (FR or HR)
the radio capability of the mobile
the TRE DR capability and the TRE band
selecting the best TCH resource among the available TCH
channels of this pool according to several criteria
Page 187
3.1 TCH resource allocation algorithm
Radio Timeslot of a cell : Operator view
> On the OMC-R the operator can configure the following Radio TS per
cell:
Main BCCH timeslot (BCC): TS carrying FCCH + SCH + BCCH +
CCCH
Main combined BCCH timeslot (CBC): TS carrying FCCH + SCH
+ BCCH + CCCH + SDCCH/4 + SACCH/4
Static SDCCH timeslot (SDC): TS carrying SDCCH/8 + SACCH/8
Dynamic SDCCH/8 timeslot (SDD): TS carrying TCH + SACCH or
SDCCH/8 + SACCH/8
TCH timeslot (TCH): TS carrying TCH + SACCH or used as a PS
timeslot (PDCH)
> The operator has to choose between a Combined BCCH (CBC TS) or a Non-combined BCCH configuration (BCC
TS).
> SDD TS can carry either TCH or SDCCH channels but not both at the same time.
> TCH TS can carry either CS traffic channel TCH or PS logical channels but not both at the same time.
Page 188
3.1 TCH resource allocation algorithm
Radio Timeslot of a cell : RAM view
> In the BSS the RAM software module maps the OMC-R cell radio
configuration to its own types of TS :
Pure BCCH timeslot: BCC TS carrying only common CS signalling
(BCCH+CCCH)
Pure SDCCH timeslot: CBC or SDC TS carrying only dedicated CS
signalling (SDCCH)
Pure TCH timeslot: TCH TS carrying only TCH traffic
TCH/SDCCH timeslot: SDD TS carrying either CS traffic (TCH) or
dedicated CS signalling (SDCCH)
TCH/SPDCH timeslot: TCH TS carrying either CS traffic (TCH) or
PS traffic (SPDCH channels)
MPDCH timeslot: TCH TS carrying common PS signalling
(PBCCH+PCCCH or PCCCH only)
> TCH/SDCCH timeslots are allocated as TCH or SDCCH according to an SDCCH dynamic allocation algorithm
presented in the Introduction to Radio Fine Tuning B8 training course.
> TCH/SPDCH timeslots are allocated as TCH or SPDCH according to a SPDCH dynamic allocation algorithm
presented in the Introduction to GPRS & E-GPRS Quality of Service Monitoring B8 training course.
Page 189
3.1 TCH resource allocation algorithm
Radio Timeslot : OMC-R / RAM mapping
> NB_TS_MPDCH MPDCH TS are defined on the BCCH TRX :
on the timeslots configured as TCH TS on the OMC-R
having the lowest timeslot index
OMC-R RAM
radio TS BCC Pure BCCH radio TS
SDC
TCH
TCH
SDD TCH/SDCCH
TCH TCH/SPDCH
MPDCH
Pure TCH
> MPDCH TS are defined on the BCCH TRX even if the corresponding TRX_PREF_MARK is different than 0.
Page 190
3.1 TCH resource allocation algorithm
Definition of a TCH/SPDCH TS
> For PS traffic resource allocation, an SPDCH group is defined on a per
TRX basis and is made of consecutive timeslots:
mapped on OMC-R TCH TS
located on a PS capable TRX (TRX_PREF_MARK = 0)
not defined as MPDCH TS
having the same radio configuration (MA, MAIO)
> If several SPDCH groups can be defined on a given TRX, the BSS
chooses the SPDCH group of timeslots having the highest number of
consecutive timeslots.
> A radio timeslot belonging to one of the different SPDCH groups of the
cell is identified in RAM as a TCH/SPDCH timeslot.
> The timeslots shall be consecutive on a given TRX means that there shall be no hole in the SPDCH group.
> If several SPDCH groups can be defined on the same TRX and having the same number of consecutive timeslots
then the group that is located on the left side of the TRX (i.e. the timeslots having the lowest index) shall be chosen.
Page 191
3.1 TCH resource allocation algorithm
Exercise 1
> A non hopping cell is configured on the OMC-R
TRX_PREF_MARK 0 1 2 3 4 5 6 7
TRX3
TRX4
> The timeslots shall be consecutive on a given TRX means that there shall be no hole in the SPDCH group.
> If several SPDCH groups can be defined on the same TRX and having the same number of consecutive timeslots
then the group that is located on the left side of the TRX (i.e. the timeslots having the lowest index) shall be chosen.
Page 192
3.1 TCH resource allocation algorithm
TCH pools
> 3 pools of TCH resources are managed per cell:
G1 pure TCH pool: contains all the free TCH sub-channels (FR or
HR) free on the pure TCH TS of the G1 TRXs
GSM/DCS pure TCH - TCH/SPDCH pool: contains all the free TCH
sub-channels (FR or HR) free on the pure TCH TS and on the
TCH/SPDCH TS of the GSM/DCS TRXs
GSM/DCS TCH/SDCCH pool: contains all the free TCH sub-
channels (FR or HR) free on the TCH/SDCCH TS of the GSM/DCS
TRXs
> A DR TS (timeslot on a DR TRX) is free if no FR TCH or HR TCH is allocated for a call on this timeslot.
> A DR TS is busy if at least one TCH is allocated for a call on this timeslot:
1 FR TCH
or 1 HR TCH (HR 0 TCH or HR 1 TCH)
or 2 HR TCHs (HR 0 TCH and HR 1 TCH)
Page 193
3.1 TCH resource allocation algorithm
TCH sub-pools
> FR TCH channels can be allocated on both FR and DR TRXs whereas HR
TCH channels can only be allocated on DR TRXs
Page 194
3.1 TCH resource allocation algorithm
TCH allocation process 1/2
TCH Request
TCH Allocation
Yes No
TCH free?
Queuing?
Select a TCH in this sub-pool Yes No
Page 195
3.1 TCH resource allocation algorithm
TCH allocation process 2/2
TCH Allocation
NUM_TCH_EGNCY_HO
Yes No
ALLOC_ANYWAY
TCH free? T11
T11_FORCED
T_QHO
Select a TCH sub-pool
Queuing?
Select a TCH in this sub-pool Yes No
- NUM_TCH_EGNCY_HO : Number of RTCH reserved for incoming HO. These RTCH can not be allocated for call
establishment. (from the user point of view, it can be better to avoid a drop rather than to allow a new call)
- ALLOC_ANYWAY: set to TRUE , it allows to use a RTS normally reserved for incoming HO
(NUM_TCH_EGNCY_HO ) for call establishment. But only after having passed by the queue.
Page 196
3.1 TCH resource allocation algorithm B9
TCH sub-pool selection
> The BSS selects the TCH sub-pools in which a TCH channel can be allocated
according to:
The requested channel rate and the cell load situation
favour HR if cell is loaded
A priority given to generic resources
1. G1 pool (E-GSM mobile only) on non PS capable TRX
2. GSM/DCS pure TCH - TCH/SPDCH pool on non PS capable TRX
3. GSM/DCS pure TCH - TCH/SPDCH pool on PS capable TRX
4. G1 pool (E-GSM mobile only) on PS capable TRX
5. GSM/DCS TCH/SDCCH pool
An optimisation of FR/HR resources
favour FR pool over DR pool for a FR TCH request
favour HR pool over DR pool for an HR TCH request
The availability of a TCH channel in the sub-pool
> From B9 and due to the new feature Enhanced E-GSM band handling, a new parameter has to be set:
EGSM_RR_Alloc_Strategy = 0 (default) (Different behaviour for EGSM capable MS) :
The BSS handles differently EGSM capable MS from PGSM only capable MS in EGSM cells; this means that
not all GSM900 MS in the network are assumed to be E-GSM capable. G1 and PGSM TRX are not managed
in the same way.
EGSM_RR_Alloc_Strategy = 1 (Same behaviour for EGSM capable MS) :
The BSS handles in the same way PGSM capable only MS as EGSM capable MS in EGSM cells; this means
that all GSM900 MS in the network are assumed to be E-GSM capable. No difference made between a G1
TRX and a PGSM TRX.
So, if PGSM only capable MS have to be supported the parameter must be set to the value 0. Otherwise 1.
> As (E)GPRS service was not supported on G1 TRX (B7.2, B8), consequently, new pools have to be taken into
account:
Capable or not capable PS TRX in G1 and in GSM/DCS bands.
> Independently of the E-GSM preference, a TCH request is preferentially allocated firstly on TCH/VGCH timeslots,
secondly on TCH/SPDCH/VGCH timeslots. Finally, TCH requests are served on TCH/SDCCH timeslots, which
timeslots can also be used for SDCCH allocations (i.e. TCH requests are preferentially not served on TCH/SDCCH
timeslots).
VGCH : Voice Group Call Channel
Page 197
3.1 TCH resource allocation algorithm
TCH selection
> PS traffic resources optimization
TCH allocated on TRX of highest TRX rank
and on TS of highest TS index
SPDCH allocated on TRX of lowest TRX rank
and on TS of lowest TS index
Page 198
3.1 TCH resource allocation algorithm
TCH selection on pure TCH or TCH/SDCCH TS
> The TCH is chosen from the selected sub-pool according to the
following criteria:
Highest TRX_PREF_MARK
Highest TS index
FR allocation or
HR 0 TCH sub-channel
HR allocation on busy TS
TCH selected
> The BSS attempts to offer the best quality of service for TCH calls in accordance with the privileged order between
the groups of TRXs (if any) defined by the operator. Among a group of TRXs the BSS attempts to allocate traffic
channels that have the best quality characteristics (channels using frequency with low reuse factor, large hopping
frequency sets, low measured interference).
> The benefits from this type of allocation are that the operator has the possibility to define groups of TRXs and to
favour (or to disadvantage) them on the other if he wants to do so. Among a group of pure TCH or TCH/SDCCH
timeslots, the overall interference is kept as low as possible, thus the user will perceive a better quality of service.
> The BSS chooses the best TCH among the sub-channels of the selected TCH sub-pool applying criteria below in the
specified order of priority:
Page 199
3.1 TCH resource allocation algorithm
TCH selection on TCH/SPDCH TS
> The TCH is chosen from the selected sub-pool according to the
following criteria:
Highest TS index
TCH selected
> The BSS tends to allocate to the MFS the TCH/SPDCH timeslots so as to avoid conflicts between CS and PS
allocations on PS capable TRX.
> In order to be able to allocate as much slave PDCHs as possible to a given TBF, it is important to avoid any mix of
allocation between TCHs and SPDCHs (e.g. avoid on a TRX a configuration such as TCH TCH SPDCH SPDCH
TCH SPDCH SPDCH SPDCH). For that purpose, a TRX rank is assigned to each PS capable TRX. The TRX
having the highest TRX rank is preferentially selected for TCH allocations, whereas TRX having the lowest TRX rank
is preferentially selected for SPDCH allocations
> This rule only applies on PS capable TRX. On a given PS capable TRX, TCH are preferentially allocated on the right
side of the TRX (highest TS index), whereas SPDCH are preferentially allocated on the left side (lowest TS index).
Page 200
3.1 TCH resource allocation algorithm
Exercise 2 - 1/3
> A cell is configured on the OMC-R and TRE are mapped by BSS
TRX_PREF_
TRE
MARK 0 1 2 3 4 5 6 7
Time allowed:
10 minutes
Page 201
3.1 TCH resource allocation algorithm
Exercise 2 - 2/3
> Find the radio TS configuration in RAM if NB_TS_MPDCH= 2
MPD MPDCH
TSD TCH/SDDCH TS
TSP TCH/SPDCH TS
TRX_PREF_
TRE
MARK 0 1 2 3 4 5 6 7
0 TRX1 G4 MP FR
0 TRX2 G4 MP DR
1 TRX3 G3 DR
0 TRX4 G4 MP FR
1 TRX5 G3 DR
Page 202
3.1 TCH resource allocation algorithm
Exercise 2 - 3/3
> Find which TCH sub-channel is allocated:
Pure TCH TS
1. For MS1: E-GSM, DR
TCH/SPDCH TS
2. For MS2: GSM/DCS, DR TCH/SDDCH TS
as TCH TS
3. For MS3: GSM, FR
F : FR TCH call
4. For MS4, MS5, ., MSn: E-GSM, DR H : HR TCH call
P : SPDCH TS
n=?
Cell load = true
TRX_Rank TRE
0 1 2 3 4 5 6 7
2 TRX1 P P P GSM/FR
- TRX3 F F F F F F GSM/DR
1 TRX4 P P P P P P P GSM/FR
- TRX5 H H H H F H F H H G1/DR
Page 203
3 OTHER ALGORITHMS
Page 204
3.2 MS Reselection algorithms
Selection and reselection principles
> At startup (IMSI Attach), the MS is selecting a cell with
best C1
once camped on one cell (in idle mode)
The BTS sends the neighbour cells list (BCCH allocation BA) on BCCH in System Information (SI) 2,
2bis and 2ter if BSS parameter EN_INTERBAND_NEIGH in dual band networks:
GSM900 serving cell
GSM900 neighbour cells put into SI 2
GSM1800 neighbour cells put into SI 2ter/2bis
GSM1800 serving cell
GSM900 neighbour cells put into SI 2ter
GSM1800 neighbour cells put into SI 2/2bis
The MS measures RXLEV from BCCH of the serving and neighbour cells.
Camping on a cell is performed using C1 criteria only (the chosen cell is the one with the best C1)
The MS needs to have access to the network.
The MS needs to be accessible by the network.
Reselection is done using the mechanisms referenced above
handover algorithms in idle mode
Page 205
3.2 MS Reselection algorithms
C1 criteria (1/2)
> C1
ensure that, if a call was attempted, it would be done with a
sufficient downlink and uplink received level
based on 2 parameters, broadcast on BCCH
RXLEV_ACCESS_MIN [dBm]
minimum level to access the cell
MS_TXPWR_MAX_CCH [dBm]
maximum level for MS emitting
Page 206
3.2 MS Reselection algorithms
C1 criteria (2/2)
> C1
evaluated every 5 sec (minimum)
C1 = A - MAX(0,B) > 0
A = RxLev - RXLEV_ACCESS_MIN
assess that the MS received level is sufficient
B= MS_TXPWR_MAX_CCH - P
P maximum power of MS
assess that the BTS received level will be sufficient
if MS_TXPWR_MAX_CCH < P
If A > 0 & B < 0 OK, if B > 0, it can be compensated by A
A >> 0 means that the MS is closer to the BTS
Page 207
3.2 MS Reselection algorithms
C2 criteria
> C2
CELL_RESELECT_PARAM_IND= not present THEN C2=C1 else
C2 = C1 + CELL_RESELECT_OFFSET - TEMPORARY_OFFSET (T)
(if PENALTY_TIME 31)
if T > PENALTY_TIME, TEMPORARY_OFFSET(T) = 0
used to avoid locating on transient cell
CELL_RESELECT_OFFSET used to favor cell among other (e.g.
micro-cell vs. umbrella, once T > PENALTY_TIME)
Or C2 = C1 - CELL_RESELECT_OFFSET
(if PENALTY_TIME = 31)
CELL_RESELECT_OFFSET used to handicap some cells among others
One reselection criterion is compared to C2s
C2neighbour > C2current if cells belong to same LA
C2neighbour > C2current+Cell_Reselect_Hysteresis if cells from a
different LA
> Note:
CRO: from 0 to 126 dB, step 2dB
PENALTY_TIME: from 0=20s to 30=620s, step: 20s; 31=infinite
TEMPORARY_OFFSET: from 1=10dB to 6=60dB; 7 = infinite
> The use of a second formula (Penalty_time = 31) is restricted to very special cases, as we do not like to penalize a
cell. If a cell is parametered with PT=31, it will be penalized compared to ALL its neighbours. To penalize a cell
compared to one neighbour, one should better boost the neighbour cell (using the first formula).
> The first formula is very useful for favoring indoor cell or microcell.
Page 208
3.2 MS Reselection algorithms
Training Exercise (1/2)
> On this network example
List the parameters involved in the selection /
reselection process
CI=6271
GSM900
CI=6270, GSM900
C on c
CI=1823 e n tr i c c e l l
GSM900 ( 8 5 57 , 18 2 3 )
C e ll
CI=6169
GSM900
S e cto
ri ze d c e l l CI=1964
( 8 56 4 , 6 1 6 9 ) GSM900
Time allowed:
C ell
5 minutes ( 8 564 , 1 9 6 4)
Page 209
3.2 MS Reselection algorithms
Training Exercise (2/2)
Find the selected cell by the MS
Measurements RxLev (cell 1) RxLev (cell 2) RxLev (cell 3)
1 -80 -96 -104
2 -84 -90 -100
3 -88 -90 -87
4 -88 -87 -82 CI=6271
GSM900
5 -89 -85 -78 CI=6270, GSM900
C e ll 3
CI=1823 ( 855 7 , 1 82 3)
GSM900
C ell
CI=6169
GSM900
C e ll 2 CI=1964
( 8 5 64 , 61 6 9 ) GSM900
C e ll 1
( 8 56 4 , 1 9 6 4 )
Page 210
4 ALGORITHMS DYNAMIC BEHAVIOR
Page 211
4 ALGORITHMS DYNAMIC BEHAVIOR
Session presentation
> Program:
4.1 Theoretical presentation
4.2 Examples and exercises
Page 212
4 ALGORITHMS DYNAMIC BEHAVIOR
Page 213
4.1 Theoretical presentation
Session objectives
> SESSION OBJECTIVES
Be able to estimate qualitatively the impact of a parameter
change
> JUSTIFICATION
Tuning is not an exact science
The optimizer has to control every parameter change and predict
qualitatively what the consequences will be
Note: Each change of parameter and its justification have to be
registered in a database for operation convenience
> DETAILED PROGRAM
Three Example/Exercises
Page 214
4 ALGORITHMS DYNAMIC BEHAVIOR
Page 215
4.2 Examples and Exercises
Overview
> Example 1: Optimization of handover algorithms
Sliding averaging window
Page 216
4.2 Examples and Exercises
Example 1: Optimization of Handover Algorithms (1/4)
> Search for best tuning of HO parameters to decrease call
drop
Call drop
HO/Call
Page 217
4.2 Examples and Exercises
Example 1: Optimization of Handover Algorithms (2/4)
> Main Objective: make the HO algorithm as efficient as possible
Minimize call drop rate
trigger HO soon enough
toward the best neighbour
while keeping a good speech quality
avoid HO due to quality: too late
avoid having HO/call rate too high
Page 218
4.2 Examples and Exercises
Example 1: Optimization of Handover Algorithms (3/4)
> Method
Collect Abis trace chart
Search for HO level to avoid quality
<R x Q u a l _ D L >=f(A V _ R x L e v_ D L) <R x Q u a l _ U L >=f(A V _ R x L e v_ U L )
7 7
6 6
5 5
2
4
0 0
quality samples
N b_s am ple s N b_ sa m p le s
6 00 1000
800
4 00 600
2 00 400
200
0 0
2
S ta n d a r d D e v i a t i o n
1
1
activated
> Then tune according to QoS indicators (OMC-R) by repetitive process
A_PBGT_HO/A_LEV_HO/A_QUAL_HO
L_RXLEV_UL_H, L_RXLEV_DL_H, L_RXLEV_UL_P,
L_RXLEV_DL_P
OK as soon as HO success rate stabilized
Introduction to Radio Fine Tuning BSS Release B9 219
> Never forget that Abis information takes into account the traffic distribution in the cell. Any parameter tuning done
after an Abis study has to be checked periodically as the distribution in the cell can change from one week to another.
> Use the pivot table function (Excel) to build this graph.
RxQUAL
RxQUAL
0
10
08
06
04
02
00
8
6
4
2
0
8
6
4
2
0
8
6
4
2
0
8
6
4
2
0
8
6
4
2
0
8
-9
-9
-9
-9
-9
-8
-8
-8
-8
-8
-7
-7
-7
-7
-7
-6
-6
-6
-6
-6
-5
-5
-5
-5
-5
-4
-1
-1
-1
-1
-1
-1
Page 219
4.2 Examples and Exercises
Example 1: Optimization of Handover Algorithms (4/4)
> neighbouring relationship cleanup
Remove useless relationships (A interface statistics, PM Type 180)
Remove the common BCCH/BSIC couple
Add new relationships when a new site is created
Page 220
4.2 Examples and Exercises
Example 1: training exercise
> According to the Abis results and some parameters
already set, tune qualitatively the sliding averaging windows:
A_QUAL_HO
A_LEV_HO
Time allowed:
5 minutes
Page 221
4.2 Examples and Exercises
Example 2: Power Control Algorithms Optimization (1/2)
> Optimization of Downlink Power Control
Decrease of downlink interference
Risks of delay of HO (without fast power control)
Page 222
4.2 Examples and Exercises
Example 2: Power Control Algorithms Optimization (2/2)
> The main tuning problem is the interaction with handover, which
can slow down HO decision, and debase call drop rate
Power control threshold must be within HO ones
Dynamic step size must be activated if possible
> In the example below, a dynamic MS PC is activated. The MS power changes are really reactive and control the UL
level between -80 and -90dBm. In this example, the HO threshold is -98 dBm.
RxLev_UL
1 39 77 115 153 191 229 267 305 343 381 419 457 495 533 571 609 647 685 723 761 799 837 875 913 951 989 1027
-70
-75
-80
-85 RxLev_UL
-90
-95
-100
33
31
29
27
25
23 MS_PwrLevel
21
19
17
15
13
1 40 79 118 157 196 235 274 313 352 391 430 469 508 547 586 625 664 703 742 781 820 859 898 937 976 1015
Page 223
4.2 Examples and Exercises
Example 2: Training Exercise
> Explain qualitatively the impacts of some parameter changes
Time allowed:
5 minutes
Page 224
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (1/12)
> Used to unload cell with too high traffic, without HW extension
> Trade-off between traffic sharing/radio quality
> Different algorithm
Fast Traffic Handover: Cause 28
Traffic Handover: Cause 23 and 12 with
DELTA_HO_MARGIN(0,n)
Static (couple of cells): HO_MARGIN, LINK_FACTOR
On a local traffic basis:
Load_Factor/Free_Factor
Forced Directed Retry
Page 225
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (2/12)
> Fast Traffic HO
Useful in case of sudden traffic peaks as the process response is
instantaneous (no averaging window)
The principle is to force handover towards neighbour cells which
have lower traffic when a request is queued in the serving cell.
Interaction with Forced DR due to the use of same thresholds
Optimization method (repetitive process)
Tunes L_RXLEV_NCELL_DR(n), FREElevel_DR(n)
Applies new values, checks traffic peaks, QoS indicators
Page 226
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (3/12)
> The Pros and cons of Fast Traffic HO
Efficiency depends on
Traffic location in the loaded cell
Capacity of neighbour cells
Increase of the number of HO/call
Increase of incoming HOs fail rate (risk of ping-pong effect)
In case of internal HO: use PING_PONG_HCP with T_HCP
or/and enable HO CAUSE 23
Heavy to tune (has to be done for each couple of cells)
Page 227
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (4/12)
> DELTA_HO_MARGIN (0,n)
Page 228
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (5/12)
> The Pros and cons of DELTA_HO_MARGIN (0,n) method
Efficiency depends on
Traffic location in the loaded cell
Cells overlap
Capacity of neighbour cells
Page 229
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (6/12)
> HO_MARGIN / LINK_FACTOR
Page 230
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (7/12)
> The Pros and cons of LINK_FACTOR/HO_MARGIN
Can be efficient (up to 20% increase of capacity) in some cases
Cell overlap
Capacity of neighbour cells
Increase the number of HO/call
The call has to be first established on a loaded cell, before being
exported
It can be rejected
Heavy to tune (has to be done for each couple of cells)
No adaptability to instantaneous and long term traffic
modifications
Page 231
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (8/12)
> FREE_FACTOR/LOAD_FACTOR
> Taking into account the current load of cells, send the MS toward the
less loaded cell with HO
Ease outgoing better cell HO, according to
Load_Factor (% of TCH occupancy) of serving and target
cells
Free_Factor (number of free TCHs) of serving and target cells
(order only)
cannot make a candidate cell, only change ranking
Tuning method (repetitive)
to be activated locally for each cell with default parameter
setting
look for QoS indicators (esp. traffic intensity and blocking
rate)
tune tables accordingly
Introduction to Radio Fine Tuning BSS Release B9 232
Page 232
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (9/12)
> The Pros and cons of load/free factors method
Page 233
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (10/12)
> Forced directed retry method
Mechanisms
The MS is connected on an SDCCH of cell1
It must switch on TCH
No TCH is free on cell1
There is at least 1 neighbour cell which has
sufficient DL level seen by the MS
enough free TCHs
The MS is handed over to TCH towards this cell
if there are several cells, the one with the best PBGT is
selected
Page 234
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (11/12)
> Method: trade-off between traffic and radio quality
Mainly L_RXLEV_NCELL_DR(n)
parameter to tune
4
the lower, the better the
:2
traffic sharing
C ell 1
the lower, the higher the
interference risks
Page 235
4.2 Examples and Exercises
Example 3: Traffic Load Sharing (12/12)
> The Pros and cons of Forced directed retry
Page 236
4.2 Examples and Exercises
Example 3: training exercise (1/3)
> Draw qualitatively the new serving areas on the pseudo map
when enabling traffic HO with:
DELTA_DEC_HO_MARGIN=6dB
DELTA_INC_HO_MARGIN=4dB Time allowed:
5 minutes
Traffic_load
Cause 12 Cause 12
EN_TRAFFIC_HO = 0
PBGT(0) = 5 PBGT(n) = 5
Page 237
4.2 Examples and Exercises
Example 3: training exercise (2/3)
> What happens when EN_FAST_TRAFFIC_HO = ENABLE and
EN_TRAFFIC_HO(0,n) = DISABLE
Time allowed:
5 minutes
Traffic_load
Queued
Assignment Av_Rxlev_Ncell(n) = -82 dBm Av_Rxlev_Ncell(0) = -74 dBm
Request Av_Rxlev_PBGT_HO = -82 dBm
PBGT(0) = 5 PBGT(n) = 5
Page 238
4.2 Examples and Exercises
Example 3: training exercise (3/3)
> What happens when EN_FAST_TRAFFIC_HO = ENABLE and
EN_TRAFFIC_HO(0,n) = ENABLE
Time allowed:
5 minutes
Traffic_load
Queued
Assignment Av_Rxlev_Ncell(n) = -82 dBm Av_Rxlev_Ncell(0) = -74 dBm
Request Av_Rxlev_PBGT_HO = -82 dBm
PBGT(0) = 9 PBGT(n) = -1
Page 239
5 CASE STUDIES
Page 240
5 CASE STUDIES
Session presentation
Page 241
5 CASE STUDIES
Page 242
5.1 Theoretical presentation
Session objectives
> JUSTIFICATION
Page 243
5 CASE STUDIES
Page 244
5.2 Tunnel Case
Question:
Risks of such a
configuration Indoor BTS
Page 245
5 CASE STUDIES
Page 246
5.3 Radar Case
Page 247
5 CASE STUDIES
Page 248
5.4 Tower Case
> Objective
Define a set of parameters
to avoid that effect
Indoor
antenna
Indoor
mobile
O u t d o o r c el l
Page 249
5 CASE STUDIES
Page 250
5.5 Resurgence Case
Define a set of
parameters to avoid
radio link
establishment to
those cells and TCH
Resurgence
traffic on those cells from cell A
Page 251
5 CASE STUDIES
Page 252
5.6 Forest Case
Define a set of
parameters to
avoid radio link -90 dBm
failure
-75 dBm
ay
w
gh
Hi
BTS
Page 253
5 CASE STUDIES
Page 254
5.7 Highway Case
Cell A
Page 255
5 CASE STUDIES
Page 256
5.8 TCH/SDCCH Congestion Case
LA 2
LA 1
LA
f ron
C e ll A tie
r
Page 257
5 CASE STUDIES
Page 258
5.9 Indoor cell congestion
Page 259
END SESSION
Page 260
ANNEXES
Page 261
ANNEXES
Page 262
Annex.1 Erlang B law
Erlang definition
> ERLANG: unit used to quantify traffic
Erlang definition
Example:
1 TCH is observed during 1 hour
one can observe 1 call of 80 sec and 1 call of 100 sec
the observed traffic is T = (80+100)/3600 = 0.05 ERLANG
Page 263
Annex.1 Erlang B law
Call mix definition
> ERLANG <-> CALL MIX
ERLANG COMPUTATION
TCH = (350 * 85)/3600 = 8.26 ERLANG
SDCCH = [ (350 + 350*3) * 4.5 ] / 3600 = 1.75 ERLANG
Page 264
Annex.1 Erlang B law
Erlang B (1/5)
> ERLANG B LAW
Relationship between
offered traffic
number of resources
blocking rate
> In a telecom system, call arrival frequency is ruled by the POISSON LAW
Call
10
9
8
7
6
5
4
3
2
1
0 Second
1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 97
> The graph gives the number of connection requests per second during 35 seconds.
Page 265
Annex.1 Erlang B law
Erlang B (2/5)
> Call request arrival rate (and leaving) is not stable
Number of resources = average number of requests * mean
duration
Is sometime not sufficient => probability of blocking
Erlang B law
> => Erlang B law
Pblock: blocking probability E
N
N!
N: number of resources Pblock =
N k
E
k=0
k!
E: offered traffic [Erlang]
Good approximation when
the blocking rate is low (< 5%)
Page 266
Annex.1 Erlang B law
Erlang B (3/5)
> There is two different ways to use this law
Using Abacus
Page 267
Annex.1 Erlang B law
Erlang B (4/5)
> Example:
Page 268
Annex.1 Erlang B law
Erlang B (5/5)
> But be careful, the law is not linear:
Page 269
Annex.1 Erlang B law
Cell dimensioning (1/5)
> CELL DIMENSIONING
Page 270
Annex.1 Erlang B law
Cell dimensioning (2/5)
> CELL DIMENSIONING
Channels (12;2%) = 19
Page 271
Annex.1 Erlang B law
Cell dimensioning (3/5)
> CELL DIMENSIONING, based on field measurement
Page 272
Annex.1 Erlang B law
Cell dimensioning (4/5)
> FORECASTING TRAFFIC/CRITICAL TRAFFIC
Page 273
Annex.1 Erlang B law
Cell dimensioning (5/5)
> WARNING: in case of too high blocking rate
Page 274
Annex.1 Erlang B law
Training exercise
> Training exercise
Complete this form in order to get less than 2% of blocking in all cases.
Erlang TCH
Cell Call mix info Traffic forecast Proposed configuration
offered traffic
450 call/hour
30% offered traffic 13.1 Erlang TCH -> 20 TCH
12,743 Mean TCH call duration: 80 sec 10.08 Erlang TCH
increase 3 TRX
Blocking rate TCH: 0.8%
330 call/hour
30% offered traffic
12,675 Mean TCH call duration: 129 sec
increase
Blocking rate TCH: 4%
600 call/hour
30% offered traffic
12,865 Mean TCH call duration: 96 sec
increase
Blocking rate TCH: 8%
Back
cell call mix info Erlang TCH traffic forecast proposed config
12, 743 450 call/hour 10 Erlang TCH 30 %TCHincrease 13,1 Erlang TCH- >20
mean TCHcall duration : 80 TCH
sec (450*80)/3600 10,081*1.3=13.1
blocking rate TCH: 0.8% =10 3 TRX
10/.992=10.08
1
12,675 330 call/hour (330*129)/360 30 %TCHincrease 16 Erlang TCH->24 TCH
mean TCHcall duration 129 0
sec =11.825/0.96 12.3177*1.3 =16 4 TRX
blocking rate 4% =12.3177
12,865 600 call/hour (600*96)/3600 30 %TCHincrease 22.6 Erlang TCH->31 TCH
mean TCHcall duration 96 =16/.92 =17.4
sec 17.4*1.3 =22.6 5 TRX
blocking rate 8 %
Page 275
ANNEXES
Page 276
Annex.2 Frequency Hopping influence on PCHO process
(1/4)
> Signal decoding process
In a GSM system, the number of frames that are not erased are
sent as an input to the voice decoder
Encoder
Page 277
Annex.2 Frequency Hopping influence on PCHO process
(2/4)
Page 278
Annex.2 Frequency Hopping influence on PCHO process
(3/4)
> Quality impact of frequency hopping on the reception chain
FER is improved when frequency hopping is activated (cyclic or
random)
RxQual is not impacted whereas the speech quality is better
RxQ Average FER Average
1.4 2.50%
1.2
2.00%
1
0.8 1.50%
0.6
1.00%
0.4
0.50%
0.2
0 0.00%
Ref Cyclic Random
RxQ Average
FER Average
Page 279
Annex.2 Frequency Hopping influence on PCHO process
Conclusion (4/4)
> Conclusion
Back
Page 280
ANNEXES
Page 281
Annex.3 Load & Traffic evaluation
Cell TCH radio resource evaluation usage
Load
Period Usage
evaluation
Short FREEfactor
TCH_INFO_PERIOD
term LOADfactor
Back - Cause 12
Back - Cause 26
Page 282
Annex.3 Load & Traffic evaluation
Load evaluation (1/5)
> Medium term measurement of the load of a cell
Corresponds to function AV_LOAD(cell)
A new sample of the Nb free TCH in the cell is available every
TCH_INFO_PERIOD seconds
AV_LOAD() is a non-sliding window load average from Nb free
TCH samples updated every LOAD_EV_PERIOD x
TCH_INFO_PERIOD sec
TCH_INFO_PERIOD sec
Nb of free TCHs
LOADfactors
FREEfactors
Non-sliding average
Load evaluation
LOAD_EV_PERIOD
Page 283
Annex.3 Load & Traffic evaluation
Load evaluation (2/5)
> AV_LOAD(cell n) calculated from N Nb free TCH samples available
during LOAD_EV_PERIOD x TCH_INFO_PERIOD sec
AV_LOADdefinition
Nsamples
1 Nb free TCH (n)
AV_LOAD = (1 - ) x 100
Nsamples i=1
Nb total TCH (n)
Page 284
Annex.3 Load & Traffic evaluation
Load evaluation (3/5)
> LOADfactor determination:
LOADlevel in %
LOADfactor in dB
Page 285
Annex.3 Load & Traffic evaluation
Load evaluation (4/5)
> FREEfactor determination:
Page 286
Annex.3 Load & Traffic evaluation
Load evaluation (5/5)
> Example: cells with 4 TRXs (28 TCHs)
Load = (1 - Nb free TCH/Total Nb TCH) x 100 LOADfactor Nb free TCH FREEfactor
t <= 10% +10 dB t <= 3 -16 dB
10% < t <= 25% +5 dB 3 < t <= 8 -8 dB
25% < t <= 50% 0 dB 8 < t <= 15 0 dB
50% < t <= 80% -10 dB 15 < t <= 21 +7 dB
80% < t -15 dB 21 < t +10 dB
Nb free TCHs = 4
Load = 85.7%
HO ? Nb free TCHs = 20
Load = 28.6%
Page 287
Annex.3 Load & Traffic evaluation
Traffic evaluation (1/4)
> Long term measurement of the load of a cell
Corresponds to function Traffic_load(cell)
Traffic_load() value is determined from a number
N_TRAFFIC_LOAD of consecutive non-sliding window load
averages AV_TRAFFIC_LOAD calculated from Nb of free TCH
samples updated every A_TRAFFIC_LOAD x TCH_INFO_PERIOD
sec
TCH_INFO_PERIOD sec
Nb of free TCHs
LOADfactors
FREEfactors
A_TRAFFIC_LOAD
(N_TRAFFIC_LOAD non-sliding average)
Traffic evaluation
TRAFFIC_EV_PERIOD
Page 288
Annex.3 Load & Traffic evaluation
Traffic evaluation (2/4)
HIGH_ LOW_ IND_
TRAFFIC_LOAD TRAFFIC_LOAD TRAFFIC_LOAD
Page 289
Annex.3 Load & Traffic evaluation
Traffic evaluation (3/4)
Traffic_load() becomes indefinite if:
Traffic_load() was high and the last AV_TRAFFIC_LOAD load
average is lower than LOW_TRAFFIC_LOAD (or
IND_TRAFFIC_LOAD if not 0%)
Traffic_load() was low and the last AV_TRAFFIC_LOAD load
average is greater than HIGH_TRAFFIC_LOAD (or
IND_TRAFFIC_LOAD if not 0%)
HIGH_TRAFFIC_LOAD IND_TRAFFIC_LOAD
LOW_TRAFFIC_LOAD
Page 290
Annex.3 Load & Traffic evaluation
Traffic evaluation (4/4)
> Example with N_TRAFFIC_LOAD = 3
Variation of
AV_TRAFFIC_LOAD
Traffic_load = high
Traffic_load = high Traffic_load =
indefinite
HIGH_TRAFFIC_LOAD
Traffic_load =
indefinite
IND_TRAFFIC_LOAD
Traffic_load =
indefinite
LOW_TRAFFIC_LOAD
Traffic_load =
Traffic_load = low Traffic_load = low indefinite
Page 291
ANNEXES
Page 292
Annex.4 Handover Management
Principles
BTS BSC
HO Preparation
Radio Active
Link HO Candidate
Channel HO Detection
Measurements Cell Evaluation
Pre-processing
HO
management
HO
protocol
MSC
Page 293
Annex.4 Handover Management
Global Handover Process
Handover
Handover preparation Handover management protocol
External
Candidate Cell
Handover Handover or internal
cell filtering
detection decision channel
evaluation process
change
Page 294
Annex.4 Handover Management
Cell Lists usage
REJ_CELL_LIST
cells internally rejected by the MSC or BSC
MS_CELL_REJ_LIST
cells to which the MS failed to hand over
> Since B6 release, some changes have been provided to the HO management process which is in charge of the HO
execution triggering, when the need of handover is detected by the HO preparation process.
> These changes are :
use of the T_FILTER parameter in a different way than for B5,
the parameter NBR_HO_ATTEMPTS which was used for internal HO in B5 is removed,
use of the T7 parameter and of the REJ_CELL_LIST list also for internal HO in B7,
same behavior in case of internal and external HO in B7,
immediate attempt after rejection or failure without waiting for a new alarm in case of internal and external HO
in B7,
implicit rejection of cells in B7 with the help of the target cell identity in the HO command received from the
MSC.
Page 295
Annex.4 Handover Management
Timers usage
> T_FILTER: controls the global handover procedure
started: when a cell list is to be sent by Candidate Cell Evaluation
expiry empty target cell list sent to the Handover Management
> T7: controls the clean-up of REJ_CELL_LIST
started: when a target cell list is to be sent to Handover Protocol
expiry empty REJ_CELL_LIST
> T_MS_CELL_REJ: clean-up of MS_CELL_REJ_LIST
started: when an MS reports a failure to seize the target channel
expiry empty MS_CELL_REJ_LIST
> T_HO_REQ_LOST: to supervise answer of MSC (no HANDOVER REQUIRED
REJECT message sent)
Started: HO REQUIRED sent
Stopped: HO COMMAND received
Expiry external channel change procedure is terminated.
Introduction to Radio Fine Tuning BSS Release B9 296
> If the candidate cell list provided by the candidate cell evaluation process is different from the previous one (the
number of cells is different or same number of cells but new cells in the list), an alarm is sent to the HOM process. In
B7, if T_FILTER expires, it means that the HO is no more necessary.
> For both internal and external HOs in case of HO failure from the MS, the cell is filtered until the expiry of the
T_MS_CELL_REJ timer. When the T_MS_CELL_REJ timer expires, the rejected cell may be a candidate.
> In B7 release, T7 timer is used to manage the REJ_CELL_LIST list and a subsequent HO REQUIRED can be sent to
the MSC before T7 expiry if the target cell list has changed (new cell or removed cell).
> The REJ_CELL_LIST list is used for both internal and external Hos.
> T_HO_REQD_LOST Expiry
This timer is used to supervise response from the MSC. It is started when sending the first HANDOVER
REQUIRED to the MSC and it is stopped in the following cases:
when HANDOVER COMMAND is received from the MSC or
> when HANDOVER REQUIRED REJECT is received from the MSC only if the same number of
HANDOVER REQUIRED REJECT messages have been received from the MSC than the number of HANDOVER
REQUIRED messages sent to the MSC for this channel change procedure) (i.e. no message crossing over A
interface).
In case where more HANDOVER REQUIRED messages have been sent to the MSC, the timer
T_HO_REQD_LOST is not stopped upon HANDOVER REQUIRED REJECT receipt, as there is no way for
the BSC to know if the received HANDOVER REQUIRED REJECT is a response to the last HANDOVER
REQUIRED message or a response to a previous one (message crossing over A interface).
On expiry, an O&M error report is raised only when no message has been received from the MSC since the
last HANDOVER REQUIRED message, and the external channel change procedure is terminated.
Page 296
Annex.4 Handover Management
Handover Execution Process
Handover
Handover preparation protocol
Cell 4 Cell 8
REJ_CELL_LIST list MS_CELL_REJ_LIST list
cleared at T7 expiry cleared at
T_MS_CELL_REJ expiry
Page 297
Annex.4 Handover Management
HO execution example
Handover management Handover Update
protocol
Ordered Ordered
target cell list target cell list HO fails Cell 1 -> MS
on cell 1 rejected list
Cell 1 Rejected lists Cell 1
Cell 2 Cell 2 ROC
Cell 3 MS empty Cell 3
BSC/MSC empty
Page 298
Annex.4 Handover Management
T_FILTER controls HO procedure (1/2)
Page 299
Annex.4 Handover Management
T_FILTER controls HO procedure (2/2)
No Yes
Is T_FILTER running?
Start T_FILTER:
No Yes
an HO alarm containing the
candidate cell is sent to the
Is the candidate cell list
HO management entity
different from the previous one?
T_FILTER is restarted
each time the alarm is still on
Back
Page 300
ANNEXES
Annex.5 LCS
Page 301
Annex.5 LCS
Definitions
> New end-user services which provide the geographical location of an
MS:
On MS request to know its own location
On network request (especially during Emergency calls)
On external request (LCS Client)
Mobile-based: The MS performs OTD signal measurements and computes its own location estimate. In this
case, the network provides the MS with the additional information such as BTS coordinates and the RTD
values. These assistance data can be either broadcast on the CBCH (using SMSCB function) or provided by
the BSS in a point-to-point connection (either spontaneously or on request from the MS).
Mobile-assisted: The MS performs and reports OTD signal measurements to the network and the network
computes the MSs location estimate.
With
OTD: Observed Time Difference: the time interval that is observed by an MS between the receptions of
signals (bursts) from two different BTSs.
RTD: Real Time Difference: This means the relative synchronization difference in the network between
two BTSs.
> Finally, 4 methods are possible for positioning:
Cell ID+ TA,
This is the simplest method for determining the location of a mobile. It relies on the hypothesis that the
geographical coverage of a cell corresponds to that predicted by radio coverage studies. When an
active mobile is connected to a base station, the mobile is assumed to be located geographically within
the area predicted to be best served by this base station
Conventional (MS equipped with GPS System),
MS-based Assisted GPS,
MS-Assisted GPS.
Page 302
Annex.5 LCS
LCS architecture
> LCS function: Architecture 1 MS Request A-GPS : Assisted GPS
GMLC : Gateway Mobile Location Center
2 Network Request
LCS : Location Services
3 External Request SMLC : Serving Mobile Location Center
1 2 3
Abis
Where Emergency call Where is Where is
am I? the accident? my son?
BTS OSP
A Lg Le
MSC External
BSC GMLC
LCS client
Abis
Lh
BTS Lb
HLR
Page 303
Annex.5 LCS
LCS Positionning procedure
Provide
subscriber location
5
Paging,
authentication, Provide
BTS OSP
ciphering, subscriber Location
notification location request
MSC
BSC 4 3 GMLC 1
6 7 Location report 7 2 8
BTS
Individual Routing Location
positioning information response
MFS HLR
SMLC
> If the MS is in idle mode, the MSC first performs a CS paging, authentication and ciphering in order to establish an
SDCCH with the MS. The MS subscriber is not aware of it, i.e. no ringing tone, except towards GPRS MS in Packet
Transfer Mode which may suspend its GPRS traffic in order to answer to the CS Paging (i.e. not fully transparent for
the subscriber).
>
> When the MS is in dedicated mode (after a specific SDCCH establishment for location, or during an on-going call), the
MSC sends the location request to BSC in the existing SCCP connection for the current call, which forwards it to the
SMLC
Page 304
Annex.5 LCS
LCS protocol (1/2)
SMLC
Target MS BSC
(MFS)
RRLP RRLP
(04.31) (04.31)
Relay BSSLAP
BSSLAP (08.71)
RR
RR
(04.18) BSSAP-LE
BSSAP-LE
(09.31)
L2 L2
L2-GSL L2-GSL
(LAPDm) (LAPDm)
L1 L1 L1-GSL L1-GSL
Um Lb
Page 305
Annex.5 LCS
LCS protocol (2/2)
> Example: Mobile terminated location request success (External request)
MS BTS BSC SMLC MSC GMLC HLR LCS client
Send_Routing_Info request
Send_Routing_Info response
Provide_Subscriber_Location
Paging
Authentication + Ciphering
BSSMAP Perform_Location_Request
BSSAP-LE Perform_Location_Request
Starts
T_Location
> The useful B8 content of the received PERFORM LOCATION REQUEST message is:
Location type,
Classmark information 3,
Requested QoS: provides service requirement concerning geographic positioning and response time
accuracy, the response time category (Low Delay or Delay Tolerant),
Current Cell Id + TA information are always provided to the SMLC.
> The time of transfer of the assitance data on the SDCCH is estimated about 14s for a 1000 octets information,
Page 306
Annex.5 LCS
Positioning methods : CI+TA positioning
> Principles of CI + TA Positioning Method
LCS_LATITUDE
ID
given by the azimuth)
TH
MS
estimated location
TA
LCS_LONGITUDE
553
m
Serv
in
ce
g
ll (
CI)
3dB point
given by the azimuth
and the HPBW
> With the TA positioning method, no signalling exchange is required between the SMLC and the MS (i.e. RRLP
protocol is not required). The TA positioning method is applicable to all the MSs (supporting LCS or not).
> Based on:
Cell Identity (CI) of the serving cell and
Timing Advance (TA) value reported by MS
intersection point of a line from the BTS antenna in their main direction with a circle which radius is
corresponding with the propagation delay (timing advance) is the MS estimated position
Omni-directional cells: MS position = site position
> Parameters:
> EN_LCS flag to enable/disable the Location Services per BSS
0 = Enabled; 1= Disabled; Default = 0
IF EN_LCS=1, CI+TA method is enabled in all the BSS cells
LCS_LATITUDE
Latitude of the BTS supporting the cell
LCS_LONGITUDE
Longitude of the BTS supporting the cell
LCS_AZIMUTH
Antenna direction orientation for the sector supporting the cell
HALFPWR_BEAM_WIDTH
Antenna half power beamwidth for the sector supporting the cell
MAX_RADIUS_FACTOR
Factor used in the computation of the maximum radius of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method
Page 307
Annex.5 LCS
Positioning methods : Conventional GPS
> Conventional GPS location procedure
This optional location procedure is chosen by the SMLC (if
the MS support it) upon reception of a Perform Location
Request message from the BSC
Perform
Location
Request
Location
Measurement Position Request
Request
Page 308
Annex.5 LCS
Positioning method : Assisted GPS Positioning 1/3
> Assisted GPS Positioning Method (A-GPS)
Assistance GPS Positioning Method is split into:
MS Based A-GPS method
MS Assisted A-GPS method
> Assistance data gathered from a GPS reference network receiver is broadcasted to the GPS MS
> Flags/Parameters
EN_LCS = 1
EN_MS_BASED_AGPS enables/disables the positioning method MS Based A-GPS per CELL
0 = disabled; 1 = enabled; default = 0
EN_MS_ASSISTED_AGPS enables/disables the positioning method MS Assisted A-GPS per CELL
0 = disabled; 1 = enabled; default = 0
Page 309
Annex.5 LCS
Positioning method : Assisted GPS Positioning 2/3
> A-GPS location procedure / MS Based A-GPS
A-GPS
MS BTS BSC SMLC Server
Perform
Location
Request GPS info
Request
GPS info
Location Response
Request
Assistance Data
Assistance
Data Assistance Data Acknowledge
Positioning calculation:
latitude, longitude Position
and altitude Measurement Position Request
Request
Location Perform
Response Location
(X,Y): Response (X,Y)
computed position
> Using assistance data, MS computes by itself the position and sends it back to the SMLC
Page 310
Annex.5 LCS
Positioning method : Assisted GPS Positioning 3/3
> A-GPS location procedure / MS Assisted A-GPS
A-GPS
MS BTS BSC SMLC Server
Perform
Location
Request GPS info
Request
GPS info
Location Response
Request
Assistance Data
Assistance
Data Assistance Data Acknowledge
Pseudo-range
measurements (M) Position Measurement Position Request
Request
Using a reduced set of assistance data, the MS makes pseudorange measurements and sends the result
to the A-GPS server, which fixes the position in the end
Page 311
Annex.5 LCS
LCS impact on HO 1/3
> HO preparation
Inhibition of better cell handovers
Other HO
MS BTS BSC SMLC MSC GMLC HLR LCS client
Send_Routing_Info request
Send_Routing_Info response
Provide_Subscriber_Location
Paging
Authentication + Ciphering
BSSMAP Perform_Location_Request
BSSAP-LE Perform_Location_Request
Starts
T_Location
Page 312
Annex.5 LCS
LCS impact on HO 2/3
> HO management
Internal HO
Intra BSC
HO
on going
BSSMAP Perform_Location_Request
BSSAP-LE Perform_Location_Response
BSSLAP - Reset
Mobile in communication
Page 313
Annex.5 LCS
LCS impact on HO 2/3
> HO management
External HO
MS BTS Serving BSC SMLC MSC GMLC HLR LCS client
BSSAP-LE Perform_Location_Abort
BSSAP-LE Perform_Location_Response
BSSAP-LE Perform_Location_Response
Page 314
Annex.5 LCS
BSS Parameters
Optimization data:
ARC_SIZE_FACTOR
Factor used in the computation of the width in degree of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method.
MIN_RADIUS_FACTOR
Factor used in the computation of the minimum radius of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method
MAX_RADIUS_FACTOR
Factor used in the computation of the maximum radius of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method
Page 315
Annex.5 LCS
Cell Parameters
EN_CONV_GPS LCS_LATITUDE
EN_MS_ASSISTED_AGPS LCS_LONGITUDE
EN_MS_BASED_AGPS LCS_SIGNIFICANT_GC
LCS_AZIMUTH
HALF_POWER_BANDWIDTH
Remark: To have LCS supported for a cell, the operator must activate LCS on the BSS handling this cell but
he must also activate GPRS for this cell (i.e. setting of MAX_PDCH to a value > 0, the cell being kept locked
for GPRS if the operator does not want to have GPRS running on this cell) and configure all the required
transmission resources (Ater and Gb resources) on the GPU(s) connected to this BSC
Page 316
Annex.5 LCS
Exercise
Time allowed:
10 minutes
Page 317
Annex.5 LCS
Positioning methods : CI+TA positioning
> Ellipsoid arc definition:
Serv
r1
R2=(B+C)*554 in [m]
in
ce
g
A: ARC_SIZE_FACTOR ll (
CI)
r2
B: MIN_RADIUS_FACTOR
C: MAX_RADIUS_FACTOR S
Back
> An ellipsoid arc is a shape characterised by the co-ordinates of an ellipsoid point o (the origin), inner radius r1,
uncertainty radius r2, both radii being geodesic distances over the surface of the ellipsoid, the offset angle () between
the first defining radius of the ellipsoid arc and North, and the included angle () being the angle between the first and
second defining radii. The offset angle is within the range of 0 to 359,999 while the included angle is within the
range from 0,0001 to 360. This is to be able to describe a full circle, 0 to 360
> For CI+TA method which is default one , the answer is given by description of "ellipsoid arc".
MAX_RADIUS_FACTOR
Factor used in the computation of the maximum radius of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method
Page 318
ANNEXES
Page 319
Annex.6 Dynamic SDCCH allocation
Purpose
> SDCCH/8 time slots can be dynamically allocated on demand
on a cell-by-cell basis.
Allocated
Dynamic SDCCH/8 Max
timeslots
Min
TCH Capacity
Static SDCCH
timeslots
> Definitions
A Static SDCCH timeslot is a physical timeslot fixed allocated on the air interface. It contains 3, 4, 7 or 8 SDCCH sub-
channels depending on whether the timeslot is an SDCCH/3, SDCCH/4, SDCCH/7, or SDCCH/8 timeslot.
Page 320
Annex.6 Dynamic SDCCH allocation
Principle (1/2)
> Principles
Too few SDCCH time slots could result in high blocking rate on
SDCCH (Configuration 1)
Too many SDCCH time slots could lead to a lack of TCH resources
(Configuration 2)
Configuration 1 Configuration 2
SDCCH
SDCCH time slots
time slots
> Definition
An SDCCH is a logical SDCCH sub-channel mapped on a Static SDCCH timeslot or a Dynamic SDCCH/8 timeslot.
Page 321
Annex.6 Dynamic SDCCH allocation
Principle (2/2)
> Allocation and de-allocation of Dynamic SDCCH/8 time slots
An additional dynamic SDCCH/8 timeslot is allocated by the
BSC if there is no SDCCH sub-channel free in the cell.
A dynamic SDCCH/8 timeslot is de-allocated by the BSC after
T_DYN_SDCCH_HOLD (10s) delay if all of its SDCCH sub-
Allocation of
channels become free
Dynamic SDCCH/8
times slots
BCC: BCCH
SDC : Static SDCCH
SDD : Dynamic SDCCH
BCC
BCC SDC
SDC TCH TCH TCH TCH TCH TCH
SDD
TCH TCH
TCH TCH TCH TCH TCH TCH TCH
Cell SDD
TCH
TCH TCH
TCH TCH TCH TCH TCH TCH TCH
> The location of the Dynamic SDCCH/8 time slots are fixed by O&M configuration.
>
Page 322
Annex.6 Dynamic SDCCH allocation
TIMESLOT types
> NEW TIMESLOT TYPES :
SDCCH
Pure SDCCH or static SDCCH
TCH
Pure TCH
TCH/SDCCH
dynamic SDCCH
TCH/SPDCH
MPDCH
>The OMC-R provides the BSC with the following O&M type of radio timeslots:
Main BCCH timeslot (BCC): It is a timeslot carrying FCCH + SCH + BCCH + CCCH.
Main combined BCCH timeslot (CBC): It is a timeslot carrying FCCH + SCH + BCCH + CCCH +
SDCCH/4 + SACCH/4.
Static SDCCH timeslot (SDC): It is a timeslot carrying SDCCH/8 + SACCH/8.
Dynamic SDCCH/8 timeslot (SDD): It is a timeslot carrying TCH + SACCH or SDCCH/8 + SACCH/8
TCH timeslot (TCH): It is a timeslot carrying TCH + SACCH or PDCH
>A pure SDCCH timeslot can carry x SDCCH sub-channels where x equal to:
4 in case of combined CCCH and when CBCH is not configured on the timeslot,
7 in case of non-combined CCCH and when CBCH is configured on the timeslot,
3 in case of combined CCCH and when CBCH is configured on the timeslot,
8 for a normal SDCCH timeslot.
>When allocated as SDCCH, a TCH/SDCCH timeslot can carry up to 8 SDCCH sub-channels.
Page 323
Annex.6 Dynamic SDCCH allocation
Allocation algorithm
SDCCH Request
Yes No
Page 324
Annex.6 Dynamic SDCCH allocation
SDCCH sub-channel selection
> Pure SDCCH Timeslot
TS with LOWEST TCU LOAD
TS with MAXIMUM FREE SDCCH Sub channels
TS with lowest index on TRX with lowest TRX_ID
Note that a SDCCH request can not access the timeslots reserved by NUM_TCH_EGNCY_HO. If all remaining
TCH/SDCCH timeslots are reserved by NUM_TCH_EGNCY_HO, then the SDCCH request shall be rejected.
Page 325
Annex.6 Dynamic SDCCH allocation
De allocation algorithm
> GENERAL CASE :
all SDCCH sub-channels of a TCH/SDCCH timeslot become back free.
the T_DYN_SDCCH_HOLD timer (10s, not tunable) is started.
If the timeslot is still free of SDCCH sub-channel when the timer expires, it
is de-allocated (it becomes back TCH).
> SPECIAL CASE :
several TCH/SDCCH timeslots are allocated as SDCCH
one of them becomes free of SDCCH sub-channels. Its timer starts.
a subsequent one becomes free of SDCCH sub-channels too before
expiration of the first ones timer (10s).
one of them is immediately de-allocated (the one with lowest priority
: see previous slide in reverse order) and becomes back TCH.
For the last one, its timer is restarted (it will be de-allocated in 10s)
Page 326
Annex.6 Dynamic SDCCH allocation
O&M configuration 1/2
> Selection of static or dynamic > Massive modification by
SDCCH script
Timeslot configuration menu 10 templates
Template
customization
Template launched
through PRC
10 5
3 BTS 8 BTS
2 1 11
BTS 7 6
4 9 BTS
12
Page 327
Annex.6 Dynamic SDCCH allocation
O&M configuration 2/2
> Default configuration for a cell which has only Full rate TRX
Maximum Is BCCH/CCCH
Number of TRX Number of Number of Total number
SDCCH/TRX combined with
in the cell Static SDCCH Dynamic SDCCH of SDCCH
ratio SDCCH?
1 4 8 12 12.0 (note 1) Yes
2 4 8 12 6.0 Yes
2 8 16 24 12.0 No
3 8 16 24 8.0 No
4 8 24 32 8.0 No
5 8 24 32 6.4 No
6 8 24 32 5.3 No
7 16 24 40 5.7 No
8 16 24 40 5.0 No
9 16 32 48 5.3 No
10 16 32 48 4.8 No
11 16 32 48 4.4 No
12 16 40 56 4.7 No
13 16 40 56 4.3 No
14 24 40 64 4.6 No
15 24 48 72 4.8 No
16 24 48 72 4.5 No
Note1: For one TRX, dynamic SDCCHs are over-dimensioned because of the granularity of 8.
According to the Alcatel traffic model, all dynamic SDCCHs will not be used.
Note2: An additional dynamic SDCCH/8 must be provided for each DR TRX (these are expected
mainly on small cells).
> rules:
At least one static SDCCH/4 or SDCCH/8 on BCCH TRX
Up to 24 static/dynamic SDCCH sub-channels per TRX
Up to 32 static/dynamic SDCCH sub-channels per TCU
Up to 88 static/dynamic SDCCH sub-channels per CELL
Page 328
Annex.7 Handover detection for concentric cells
Algorithms
> Emergency handovers specific to concentric cells
Intracell handovers from inner to outer zone
cause 10: too low level on the uplink in inner zone
cause 11: too low level on the downlink in inner zone
n c e n t ri c c e
Co ll
e
ne
r zon
O ute
r zone
Page 329
Annex.7 Handover detection for concentric cells
Handover algorithm cause 10
> CAUSE 10: too low level on the uplink in the inner zone
Page 330
Annex.7 Handover detection for concentric cells
Handover algorithm cause 11
> CAUSE 11: too low level on the downlink in the inner zone
Page 331
Annex.7 Handover detection for concentric cells
Handover algorithms cause 13 (1/6)
> CAUSE 13: too high level on UL and DL in the outer zone
Better condition intracell handover
If the cell is a multi-band cell, cause 13 is checked only for multi-
band MSs tr
n ce n ic ce
Co ll
e
ne
r zon
O ute
r zone
Page 332
Annex.7 Handover detection for concentric cells
Handover algorithms cause 13 (2/6)
> CAUSE 13: too high level on UL and DL in the outer zone
AV_RXLEV_UL_HO > RXLEV_UL_ZONE +
+ ZONE_HO_HYST_UL +
+ (MS_TXPWR - MS_TXPWR_MAX_INNER) +
+ PING_PONG_MARGIN(0,call_ref)
and AV_RXLEV_DL_HO > RXLEV_DL_ZONE +
+ ZONE_HO_HYST_DL +
+ (BS_TXPWR - BS_TXPWR_MAX_INNER) +
+ PING_PONG_MARGIN(0,call_ref)
and AV_RXLEV_NCELL_BIS(n) <= neighbour_RXLEV(0,n)
and EN_CAUSE_13 = ENABLE (B7)
and EN_BETTER_ZONE_HO = ENABLE
Page 333
Annex.7 Handover detection for concentric cells
Handover algorithms cause 13 (3/6)
> ZONE_HO_HYST_UL
UL static hysteresis for interzone HO from outer to inner
In case of multi-band cell, should take into account the
difference of propagation between GSM and DCS
Added to cause 10 threshold RXLEV_UL_ZONE
> ZONE_HO_HYST_DL
DL static hysteresis for interzone HO from outer to inner
In case of multi-band cell, should take into account the
difference of propagation between GSM and DCS and the
difference of BTS transmission power in the two bands
Added to cause 11 threshold RXLEV_DL_ZONE
Page 334
Annex.7 Handover detection for concentric cells
Handover algorithms cause 13 (4/6)
> PING_PONG_MARGIN(0,call_ref)
Penalty PING_PONG_HCP put on cause 13 if
The immediately preceding zone in which the call has been is
the inner zone of the serving cell
And The last handover was not external intracell
And T_HCP is still running c e n t ri c c e
on ll C
PING_PONG_MARGIN(0,call_ref) = 0
If the call was not previously
in servings inner zone
Or T_HCP has expired
n
e
ne
r zon
O ute
r zone
Introduction to Radio Fine Tuning BSS Release B9 335
Page 335
Annex.7 Handover detection for concentric cells
Handover algorithms cause 13 (5/6)
> neighbour_RXLEV(0,n)
Inner zone Inner zone
interferer 1 I n ner zo n e interferer 2
?
Concentric cells are designed to
create an INNER zone Outer zone
C o n c e n tr i c c e l l
protected from external interferers
and creating no interferences on other cells
to be able to face more aggressive frequency reuse in
INNER zone TRXs
neighbour_RXLEV(0,n) tuning enables to avoid handovers if the MS
position will lead to interferences
the condition is checked towards all neighbour cells belonging to
the same layer and band than the serving cell
Page 336
Annex.7 Handover detection for concentric cells
Handover algorithms cause 13 (6/6)
> EN_CAUSE_13
Load balance between inner and outer zones may be allowed by
setting EN_LOAD_BALANCE = ENABLE
If EN_LOAD_BALANCE = ENABLE
If INNER zone is less loaded than OUTER,
EN_CAUSE_13 = ENABLE
If INNER zone is more loaded than OUTER,
EN_CAUSE_13 = DISABLE
If EN_LOAD_BALANCE = DISABLE
EN_CAUSE_13 = ENABLE
Page 337
Annex.7 Handover detection for concentric cells
Outgoing intercell handovers from concentric Cell
> Outgoing intercell handovers from concentric cells
As explained here before, the MS located in a
concentric cell can make intercell, emergency or
better condition HO regardless their current zone I n n er z o n e
Outer zone
C o n c en t ric c e l l
> The only restrictions are linked to EN_MULTI-BAND_PBGT_HO and EN_BI-BAND_MS parameters.
Page 338
Annex.7 Handover detection for concentric cells
Incoming intercell handovers towards Concentric Cell (1/2)
> Incoming intercell handovers towards a concentric cell
In case an MS is making an incoming handover towards a concentric
cell (due to outer PBGT measurements,etc.), a TCH may be allocated
either in the INNER or in the OUTER zone, as for call setup
depending on radio conditions
In case of a multi-band cell, if the MS is not multi-band, it will always
be sent to the OUTER zone
I n n er z o n e ?
?
Outer zone
C o n c e n t ric c e l l C el l
Page 339
Annex.7 Handover detection for concentric cells
Incoming intercell handovers towards Concentric Cell (2/2)
> Use part of Handover cause 13 algorithm on each potential target
> IF Cell(n) is external
The MS is directed to the OUTER zone of (n)
> ELSE (cell(n) is internal)
IF
AV_RXLEV_NCELL(n) > RXLEV_DL_ZONE + ZONE_HO_HYST_DL +
+ (BS_TXPWR - BS_TXPWR_MAX_INNER)
and EN_BETTER_ZONE_HO = ENABLE
The MS is directed towards the INNER zone
ELSE
The MS is directed towards the OUTER zone
Page 340