Acatel Case Study

B7
Introduction to
Radio Fine Tuning
BSS release B7
1.1
© Alcatel University - 8AS 90200 0421VH ZZA Ed.02
TYPICAL MODULE STRUCTURE

objective(s)
theoretical presentation
training exercises and/or cases study + feedback
© Alcatel University - 8AS902000421vhzza2 Page 1.1

B7 PROGRAM
1 TYPICAL RADIO PROBLEMS

2 ALGORITHMS AND ASSOCIATED PARAMETERS
3 OMC-R RADIO PARAMETERS
4 ALGORITHMS DYNAMIC BEHAVIOUR
5 CASE STUDIES
1.2

B7
1.3

B7 Session presentation
▼ Objective : to be able to characterize typical radio problems in

order to trigger an intervention of the appropriate team
▼ Program:
1.1Theoretical 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
1.4
S1 : TYPICAL RADIO PROBLEMS

S2 : ALGORITHMS AND ASSOCIATED PARAMETERS
S3 : OMC-R RADIO PARAMETERS
S4 : ALGORITHMS DYNAMIC BEHAVIOR
S5 : CASE STUDIES

1.1 Theoretical presentation
1.5
Theoretical presentation
Coverage problem
Interference problem
Unbalanced power budget problem
TCH Congestion problem
Deducing the right team for intervention
Exercices

Justification
▼ Several sources of information can alert RFTM

team :
l QoS indicators
l Customers complaints
l Drive tests
l Other teams information (NSS statistics)
▼ As many symptoms are common to several

causes, it can be necessary to :
l Consolidate standard sources of information
l Carry-out specific examinations
l Deduce the appropriate team for intervention
1.6

B7
1.7
Coverage problem
Exercises

Definition and symptoms
▼ Definition : Bad coverage

l A network or cell facing coverage problems presents a bad RxLev and
RxQual in the same time on some areas.
▼ Symptoms :
l Customers complain about dropped calls or/and “no network”
l OMC QoS indicators
è TCH failure rate
è Call drop rate
è Low proportion of better cell HO
è High rate of DL quality HO
l A interface indicators
è High rate of Clear Request message, cause radio interface failure
1.8
▼ 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 behaviour :
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 MS exiting the network.
l 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

B7 Examination
▼ Depending on the information sources you have:

l RMS (Radio Measurement Statistics) – New feature in B7
è (RxLevel , RxQuality) matrix
è Radio Link Counter S vector
è Number of calls with DL/UL bad coverage (bad RxLev,
bad RxQual)
l Abis interface (for example with COMPASS)
è bad quality > 5%
è bad level RxLev < - 95 dBm and RxQual > 4
l OMC-R or A interface
è unexpected high traffic, induced by call repetition
l Billing information
è High recall rate detected
1.9
▼ RMS : new PM type in B7

l Provides statistics from any area in the network which are available at any time.
l Cost-effective.
l Easier and cheaper to perform than Drive test or Abis Trace.
l The operator can tune 54 parameters (based on RxLev, BFI, C/I, Radio Link Counter S, Path Balance, etc.) to define
up to 16 templates (depending on cell type – rural, urban, etc. – for example).
l Trigger from the OMC-R.
l NPA can save up to 15 days of RMS for the complete network

l Templates can be designed in RNO
l Result reports are available in RNO and NPA

1.2 coverage problem
Typical causes
▼ If 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
▼ If actual coverage OK compared to predicted ones

è indoor traffic, to be handled by specific means
è if black spot close to cell border, ease outgoing HO
1.10

Investigation with Abis trace (1/2)
▼ 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_PW R nb_of sam ples
119 -89.29 -84.67 0.42 0.43 123.82 123.67 0.15 -0.01 34.53 3074
92 -89.77 -89.09 0.41 0.38 124.87 128.09 -3.21 0.03 35.11 10253
111 -83.15 -79.15 0.17 0.33 116.05 121.22 -5.16 -0.16 32.9 5339
DISTRIBUTION OF UPLINK QUALITY

Frequency Qual0 Qual1 Qual2 Qual3 Qual4 Qual5 Qual6 Qual7 Bad_Quality
119 86.50% 3.19% 2.50% 2.57% 1.92% 2.08% 0.98% 0.26% 3.32%
92 88.11% 1.82% 1.91% 2.51% 2.14% 2.17% 1.15% 0.19% 3.51%
111 77.70% 4.30% 4.30% 4.36% 3.56% 3.56% 1.70% 0.17% 5.43%
DISTRIBUTION OF DOW NLINK QUALITY

Frequency Qual0 Qual1 Qual2 Qual3 Qual4 Qual5 Qual6 Qual7 Bad_Quality
119 88.29% 1.82% 2.05% 2.37% 1.30% 1.46% 1.76% 0.94% 4.16%
92 87.50% 2.98% 2.60% 2.43% 2.11% 1.14% 0.74% 0.50% 2.38%
111 71.30% 3.82% 4.02% 4.89% 4.16% 4.30% 4.23% 3.16% 11.73%
1.11
▼ 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 coverage problem as the three TRX 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 with interpretation of this
result table: even if average levels in UL and DL are high and a lot of Quality problems are seen, nobody can say that
samples with bad quality are have a good level ! Level seen is just an average…
▼ One should have a look to the next slide…

Investigation with Abis trace (2/2)
▼ Example of an Abis trace analysis

5 6 -8 8 . 0 0 3
7 3 -9 5 . 3 3 3
11 3 -7 1 . 0 0 1
1 6 -8 0 . 0 0 1
12 3 -8 0 . 0 0 1
BC_D L: 115 3 .7 4 % < R x L e v _ S e r v in g > = -1 0 2 .1 7 d B m
N e ig h _ C e ll_ N b B S IC < L ev> S a m p le s
0 2 -1 0 0 .5 3 57
10 2 -9 8 . 7 1 45
5 6 -9 8 . 0 3 34
7 3 -9 8 . 6 1 33 Thresholds
F re q u e n c y :9 2
N u m b e r _ U L :1 0 2 5 3
N u m b e r_ D L :1 0 2 5 3 ❏ Bad Coverage
I n t_ U L : 2 0 .0 2 %
– RxLev ≤ -95
BC_UL: 358 3 .4 9 %
I n t_ D L : 0 %
BC_D L: 244 2 .3 8 % < R x L e v _ S e r v in g > = -1 0 6 .1 7 d B m
N e ig h _ C e ll_ N b B S IC < L ev> S a m p le s – RxQual > 4
0 2 -1 0 4 .6 4 67
1 5 -1 0 7 .5 0 48 ❏ Interference
F r e q u e n c y :1 1 1
N u m b e r _ U L :5 3 3 9
N u m b e r _ D L :5 3 3 9
– RxLev > -95
I n t_ U L : 0 0 .0 0 %
BC_UL: 290 5 .4 3 % – RxQual > 4
I n t_ D L : 0 %
BC_D L: 626 1 1 .7 3 % < R x L e v _ S e r v in g > = -1 0 6 .5 6 d B m
N e ig h _ C e ll_ N b B S IC < L ev> S a m p le s
10 2 -1 0 1 .5 4 63
1.12
▼ All samples are Bad Coverage samples (BC). No one is interference, showing that this cell is not facing any interference
problem.
▼ By the way, if the cell is mono TRX, this is a coverage pb

▼ If the cell is 3 TRXs, this is a malfunction of the TRE (shown also by the high value of delta_path_loss)

B7 Investigation with RMS (1/2)
▼ Suspecting a cell coverage problem

l Distribution of samples per RxQual value and RxLev band
Not acceptable
coverage limit :
Too low level
Too bad quality
l Distribution of samples per RxLev band
1.13
▼ 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 aerials should be suspected.
▼ If all the TRXs are experiencing a lot of samples of low level and bad quality then a coverage problem shall be suspected.
▼ These RMS indicators are provided on RNO tool per TRX, per Cell :
l Matrix of Number of Measurement Results per DL RxQual value and per DL RxLev band
RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample
l Vector of Percentage of Samples per DL RxLev band
RMQLDLVDV = RMS_DL_RxLevel_distrib
l Vector of Percentage of Samples per DL RxQual band
RMQLDQUDV = RMS_DL_RxQuality_distrib

B7 Investigation with RMS (2/2)
▼ Suspecting a cell coverage problem

l Average TA values per RxQual value and RxLev band
Not acceptable
coverage limit : Acceptable coverage limit :
Too low level Sufficient level and good quality
Too bad quality
% of TA value over TA threshold

has also to be considered
1.14
▼ 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 Percentage of TA value over TA threshold should be observed.
l Matrix of Average TA per UL RxQual value and per UL RxLev band
RMQLUTAM = RMS_UL_RxQuality_RxLevel_TimingAdvance
l Rate of Measurements Results whose TA is greater than the TA threshold
RMTAGTR = RMS_TimingAdvance_greater_threshold_rate
l Maximum TA value of all values reported in Measurement Results
RMTAMXN = RMS_TimingAdvance_max

B7
1.15
Coverage problem
Exercises

▼ Definition : Interference
l A network facing interferences problems presents good RxLev and
bad RxQual in the same time on some areas.
▼ Symptoms
l Customers complain about bad speech quality (noisy calls) and/or
call drops
è SDCCH/TCH Drop
è Low proportion of better cell HO
è High rate of DL/UL quality HO and interference HO
è Low HO success rate
è High rate of Clear Request message, cause radio interface
failure
1.16
▼ DL/UL depends on which way the interference is present
▼ Mainly, interferences are DL, due to bad frequency planning introducing interferences in the network. And this problem will
not change till the frequency plan has not been returned…
▼ Sometimes, interference can be UL in very dense area (for example, microcell area), since MS are very close.
▼ Finally, sometimes interferences are not coming form BS or MS but from another radio equipment, either in UL or DL.

B7 Examination with RMS (1/3)
▼ RMS (Radio Measurement Statistics) – New feature in B7

è 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-neighboring cells
è Number of calls with DL/UL interference (good RxLev,
bad RxQual)
è Number of noisy calls (bad RxQual) with bad voice
quality (bad FER)
1.17
▼ The feature Radio Measurements Statistics (RMS) is designed to make far easier the work for planning and optimisation 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:
l detect interfered frequencies.
l assess the quality of the cell coverage.
l detect and quantify cell unexpected propagation.
l assess the traffic distribution in the cell from statistics on reported neighbour cells.
l evaluate the voice quality in the cell
l etc...
▼ In regards the “RTCH Measurements Observation” (measurement type 11) the Radio Measurements Statistics (RMS) bring
the following advantages:
l smaller report files
l report files always have the same maximum length whatever the measurement duration is
l every measurement is taken into account (no sampling)
l no more need for measurement post-processing tools for statistics. Directly available with RNO or NPA

▼ Suspecting a cell interference problem

l Number of samples per RxQual value and RxLev band
Average DL RxQuality = 2.81
Quality problems are obvious at

any level of RMS data
➨ Interference highlighted
Average RxQual value per RxLev ➨ Network fine tuning needed
band has also to be considered 1.18

▼ Suspecting a Voice Quality problem

l Number of samples per BFI band and RxLev band
Consecutive Frame Erasure
(BFI) is a measurement based on
loss of consecutive speech
frames over one SACCH mf
It is directly linked to
Voice Quality
RxQual to be compared with

CFE
since
Bad RxQual does not always
mean bad VQ
1.19
l Matrix of Number of Measurements Results per CFE band (or BFI band) and per UL RxLev band
RMFEM = RMS_UL_ConsecutiveFrameErasure_RxLevel_sample
l Vector of Average number of Consecutive Frame Erasure per UL RxLev band
RMFEBFAV = RMS_UL_ConsecutiveFrameErasure_avg_per_RxLevel
l Vector of Average UL RxQual per RxLev band
RMQLUQUAV = RMS_UL_RxQuality_avg_per_RxLevel

Typical causes
▼ GSM interference
è co-channel
è adjacent
▼ Non GSM interference

è other Mobile Network
è other RF sources
1.20

GSM interference: adjacent channel (1/2)
▼ Adjacent channel interference

è +6 dB is sufficient to interfere (9 dB according GSM)
Level
F(BTS1) F(BTS2)
6 dB
F(BTS1)=F(BTS2)+1 Frequency
1.21

GSM interference: adjacent channel (2/2)
▼ Adjacent channel interference : usually 20% of GSM interferences

l Symptom
è Usually downlink interference
è High rate of quality HO, call drop (due to HO but mainly due to
radio) and TCH assignment failure
l Examination
è Neighbour cells in Abis trace (only for BCCH)
è Non-neighbour cells in RMS (MAFA frequencies)
è Frequency plan C/(I adjacent) < -6dB
l 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)
1.22

GSM interference: co-channel (1/2)
▼ GSM Interference
l Co-Channel interference
è -12 dB is sufficient (-9 dB according GSM)
Level
-12 dB
F(BTS1)=F(BTS2) Frequency
1.23

GSM interference: co-channel (2/2)
▼ Co-channel interference (usually 80% of GSM interferences)
l Symptom
è Usually downlink interference
è High rate of quality HO, call drop and call failure
l Examination
è Neighbour cells in Abis trace (only for BCCH)
è Non-neighbour cells in RMS (MAFA frequencies)
è Frequency plan C/I < 12 dB
l 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)
1.24

GSM interference: µcellular
▼ GSM interference : µcellular

l BTS1 : ARFCN 5 BTS2
l BTS 2 : ARFCN 6 MS2
l MS1 indoor 2
è RxLev_UL : - 90 dBm BTS1
l MS2 outdoor, connected to BTS2 MS1

3
è 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 HO BTS2-
>BTS1
1.25
▼ When interferences are created by frequency plan, it’s 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, let’s consider a microcell layer:
B
A
l A and B are 2 microcells with the coverage described before in dense urban environment.
l 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.
l A “red” MS is connected on cell A. when MS starts its call, it transmits full power and 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 20dB. Then, MS power increases to MS_TXPWR_MAX.
l 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 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 UL.

GSM interference: Forced Directed Retry
▼ GSM Interference : Forced

Directed Retry
l MS should connect to
cell2, but no TCH
available
l MS connects to cell 1
with forced directed retry
l MS is emitting at high
level (far from BTS1) cell 1 : 24
è UL interference for
BTS 3
l BTS 1 is emitting at high
cell 2 : 45
level
è DL interference at cell 3 : 23
BTS 3
1.26
▼ Another more difficult case of interference : FDR

l When examining the preceding situation of planning tool : no problem of C/I. No risk of interference.
l FDR algorithm allows a MS connected on a SDDCH on a cell without any free TCH to make a SDCCH-TCH handover
(cause 20) so that it takes a TCH on its neighbour. As seen from the user, this is not a handover (call establishment
phase, no impact on speech quality), an this algorithm is very efficient to avoid cell congestion cases.
l This algorithm is mainly based on neighbour level compared to parameter L_RXLEV_NCELL_DR (n). If level greater
than this threshold, TCH is to be seized on neighbour.
l FDR is mandatory for dual layer or dual band networks (and very easy to configure in this case), since we have
capture handovers. Capture handovers sends traffic to lower or preferred band cells. In case these cells are
congested, calls may not be established, even if upper or non-preferred band cells are free (due to MS idle mode
selection, advantaging microcell for example). With FDR algorithm, MS takes a SDCCH in the preferred cell, and FDR
is user to take a TCH on the non preferred cell in case of congestion. This situation highlights a good network
behaviour, since MS is at the same time in the coverage area of both cells (preferred and not preferred)
umbrella
capture FDR
microcell
▼ Situation described on the slide corresponds to 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.

Non GSM interference
▼ Other mobile network : TACS/AMPS/NMT900

è Inter-modulation with GSM BS/MS receiver
è spurious RACH for AMPS (AMPS Tx bands close to
GSM uplink band)
è examination
ü TASC : coverage hole with 600 m from TASC BTS
è AMPS => 50 % reduction of range if AMPS/GSM BTS
collocated
▼ Other RF interferer (Radar, shop anti-theft mechanisms, medical

device ...)
1.27
▼ Other RF interferer :
l medical devices : GSM equipments disturb them more than the opposite !
l anti-theft mechanisms.
l Example:
Microcell
antenna
shop
l Microcell is showing very high call drop rate. On one frequency, very small call duration.
l No problem seen in frequency plan. No potential interferer.
l Abis trace :
Qual
DL Qual
UL
Level Level
interference
l Spectrum analyser connected on antenna feeder highlights a peak on GSM freq 6 in UL…
l Anti-theft mechanism turned off : no more problem…

B7
1.28
Coverage problem
Exercises

▼ Definition : Unbalanced power budget
l A cell facing unbalanced power budget problems presents a too high
path-loss difference between UL and DL (often DL>UL)
l 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 :
è High ratio of Uplink quality Handover cause
è Low incoming HO success rate (no HO Access triggered on uplink)
è Degradation of TCH failures and OC call drop indicators
è High rate of Clear Request message, cause radio interface failure
l O&M Alarms
è Voltage Standing Wave Ratio BTS Alarm (VSWR)
è TMA Alarm (in case of G2 BTS or Evolium BTS with high power TRE)
1.29
▼ UL Quality HO is triggered:
l UL since the problem is in UL
l Quality as Quality has greater priority than level

B7 Examination
▼Examination :
lRMS – New in B7
è Path Balance vector per TRX
è Number of calls with abnormal bad FER (good
RxQual & bad FER)
lAbis monitoring :
è |delta path-loss| > 5dB)
è check if problem is occurring for 1 TRX or all
1.30
▼ 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)

Abis trace
▼Example of an Abis trace analysis
delta_Path_loss
nb_of samples
AV_MS_PWR
Path_loss_UL
Path_loss_DL
delta_quality
RxQual_UL
RxQual_DL
Frequency
RxLev_UL
RxLev_DL
106 -9 4 . 5 2 -8 7 . 1 9 0.43 0.25 127.55 130.19 -2 . 6 4 0.18 33.03 2066
89 -8 4 . 2 9 -7 5 . 1 7 0.65 0.44 115.32 118.17 -2 . 8 5 0.21 31.03 2001
118 -9 0 . 7 5 -8 3 . 3 6 0.46 0.41 123.22 126.36 -3 . 1 4 0.04 32.46 3193
124 -8 8 . 8 9 -8 5 . 3 0 0.29 0.67 120.48 128.30 -7 . 8 2 -0 . 3 7 31.59 2931
D IS TR IB U TIO N O F U P L IN K Q U A L ITY
F re q u e n c y Q u a l0 Q u a l1 Q u a l2 Q u a l3 Q u a l4 Q u a l5 Q u a l6 Q u a l7 B a d _ Q u a lit y
106 84.75 % 4.07 % 3.68 % 3.19 % 1.36 % 1.50 % 0.92 % 0.53 % 2.95 %
89 81.41 % 1.70 % 2.95 % 3.65 % 6.35 % 2.55 % 1.30 % 0.10 % 3.95 %
118 83.62 % 4.23 % 4.23 % 3.35 % 1.57 % 1.79 % 0.97 % 0.25 % 3.01 %
124 90.79 % 1.06 % 2.18 % 2.35 % 1.77 % 1.30 % 0.48 % 0.07 % 1.84 %
D IS TR IB U TIO N O F D O W N L IN K Q U A L ITY
F re q u e n c y Q u a l0 Q u a l1 Q u a l2 Q u a l3 Q u a l4 Q u a l5 Q u a l6 Q u a l7 B a d _ Q u a lit y
106 90.27 % 3.44 % 2.08 % 1.55 % 0.92 % 1.36 % 0.34 % 0.05 % 1.74 %
89 80.16 % 6.45 % 7.00 % 3.85 % 1.50 % 0.50 % 0.45 % 0.10 % 1.05 %
118 86.78 % 2.72 % 3.95 % 1.82 % 1.41 % 1.13 % 1.19 % 1.00 % 3.32 %
124 77.14 % 4.37 % 5.87 % 5.94 % 3.48 % 1.36 % 0.82 % 1.02 % 3.21 %
1.31
Exemple of Computation of delta path loss based on Abis measurements
BTS transmitted power 45,4 MS transmitted power 33

combiner loss -4,4
measured received DL level -93 measured received UL level -98
DL Path loss 134 UL path loss 131
delta path loss computed on Abis -3 dBm

B7 RMS data
▼ Suspecting a TRX hardware problem

l Average Path Balance
Average Cell Path Balance

= -0. 9 dB
l Fair average Path Balance at Cell level can hide a bad value
for one TRX
1.32
l Vector of the Number of Measurement Results per Path Balance band
RMPBV = RMS_PathBalance_sample
l Average Path Balance value
RMPBAN = RMS_PathBalance_avg

Typical causes
▼ Aerials or common RF components, TMA (pb common to all

TRX of the BTS)
▼ TRX RF cables/LNA ... if problem located on only 1 FU
1.33
▼ Every BTS has its proper architecture and the diagnostic must be adapted

B7
1.34
Coverage problem
Exercises

▼ Definition : TCH Congestion
l TCH Congestion rate (TCH Assignment Phase) is too high (more
than 2%)
l Rule : try to meet the offered traffic (asked by users) by providing the
right number of resources (TRX extension)
▼ Symptoms :
l Customers complain about ‘Network busy’
è High “TCH Congestion rate”
è Low “incoming Intra/Inter BSC HO success rate” (no TCH available)
è High “Directed Retry rate” if activated
l A interface indicator: “BSS Congestion failure in OC”
è High rate of Assignment Failure message, No radio resource
available
1.35

Examination and typical causes
▼ Examination : TCH Congestion
l On a per cell basis examination, check the evolution of the TCH
Congestion rate.
▼ Typical causes :
l Special events :
è Foreseeable: football match, important meeting
ü Activate some TRXs already installed (and use Synthesised
FH)
ü Add special moving BTSs
è Not foreseeable: car crash on the highway
1.36
▼ Cells on wheel operational by several operators around the world for special events coverage & capacity
l IRMA (SFR) connected to Caen ’s BSC.
l 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.

Typical causes
l Daily periodic problems

è At peak hour, the cell is not correctly dimensioned.
Hardware solution (refer to Annex 1)
Annex 1
ü Estimate the offered traffic :
– At OMC-R: Traffic in Erlang/(1- TCH Congestion rate)
ü Use the B-Erlang law to estimate the number of TCH required

for a 2% blocking rate, thus the target configuration
ü Add TRXs to reach the new target configuration and find ‘joker
frequencies’ and / or implement concentric cells.
1.37
▼ Warning : “offered traffic” is not the capacity delivered by the system but the traffic asked by the users.

B7 Typical causes
▼ 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 – New feature in B7
❉ Candidate Cell Evaluation (FREEFACTOR /
LOADFACTOR)
1.38
▼ Half rate may not only “SW” solution. Need of G2 BSC/TC, Evolium TRE or G2 DRFU.

1.39
Coverage problem
Exercises

Process
1.40

Coverage problem
▼ Coverage problem :
l If the field reality does not match the RNP prediction
è Maintenance team to change physical configuration (tilt,
azimuth, antenna height...) and drive test team to check
l If the field reality matches the RNP prediction

è Deployment team to add sites (tri-sector, micro cellular,
indoor cells)
1.41

Others problems
▼ Interference problem :
l Planning team to identify the interference source and correct
it (joker frequency, new frequency planning...)
▼ Unbalanced power budget problem :

l Maintenance team to check the impacted BTS (Aerials,
TMA, RF cables, LNA, diversity system...)
▼ TCH Congestion problem :

l Traffic team (theoretically always in relation with the
marketing team) to manage the need of TRX extension,
densification policy ...
1.42

1. Typical radio problems
Training exercise
Unbalanced Bad Coverage Interferences TCH

Power Congestion
Budget
High ratio of UL QUAL
HO cause
Good RXLEV and
Bad RXQUAL
Alarm VWSR (OMC-
(OMC-R)
(Voltage Standing Wave
Ratio)
Bad RXLEV and
Bad RXQUAL
High Path-
Path-loss difference
between UL and DL
Low incoming HO
success rate
OMC QOS indicators:
Time allowed : %TCH ASS failure high
%call drop high
10 minutes %QUAL HO
%call drop
%call failure
1.43

B7
2 ALGORITHMS AND ASSOCIATED

PARAMETERS
1.44

B7

PARAMETERS
1.45

2 ALGORITHMS AND ASSOCIATED PARAMETERS
▼ Objective : to be able to describe the Power control and Hand-

over algorithms and list the associated parameters
▼ Program:
l 2.1 Theoretical presentation
l 2.2 Radio measurements principles
l 2.3 Averaging windows and book-keeping
l 2.4 Radio Link Time-out and Recovery and Power control
l 2.5 Handover Detection
l 2.6 Handover Candidate Cell Evaluation
l 2.7 Handover Management
l 2.8 MS Re-selection Algorithms
l 2.9 Case Studies
1.46

S5 : CASE STUDIES

PARAMETERS
1.47
Radio measurements principles
Radio measurements data processing
Radio Link Supervision and Power control
Handover Detection
Handover Candidate Cell Evaluation
Handover Management
MS Re-selection Algorithms
Case Studies

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 plan, no
additional TRX available, no financial budget for new sites...)
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...)
Its role: take charge of radio resources management process

▼ This process can be fully described by Power Control and Handover algorithms.
➨ In-depth knowledge of this algorithms is required for tuning
1.48

B7

PARAMETERS
2.2 Radio measurements principles
1.49
Handover Detection
Handover Management
Case Studies

Radio measurement mechanisms (1/2)
l MS connected (TCH or SDCCH)

l The serving cell gives MS the list of neighbour cells to listen to
l Every SACCH, MS reports to serving cell : measurement report message
è Received level of 6 best cells (which can change)
è DL level and quality of serving cell
1.50
▼ The BTS sends SYS_INFO_5 message that contains the list of neighbour cells for connected mode. (SYS_INFO_2 message
contains the list of neighbour cells for idle mode).
l Sys info 2bis, 2ter, 5bis and 5ter are also used for multiband networks.
l MS reporting depends on EN_INTERBAND_NEIGH and on MULTIBAND_REPORTING parameters.
MS may report
è 6 strongest cells of any band (MULTIBAND_REPORTING=0),
è or 5 strongest cells serving band + 1 strongest cells other band
(MULTIBAND_REPORTING=1),
è or 4+2 (MULTIBAND_REPORTING=2),
è or 3+3 (MULTIBAND_REPORTING=3).
▼ RXLEV
l Range: [-110dBm, -47dBm]
l Binary range: [0, 63]; 0=-110dBm, 63=-47dBm
l The higher the physical or binary value, the higher the receiving level
▼ RXQUAL
l Range: [0.14%, 18.10%]
l Binary range: [0, 7]; 0=0.14%, 7=18.10%
l The lower the physical or binary value, the lower the bit error rate, the better the quality
l 0-2=excellent; 3=good; 4=ok; 5=bad; 6=very bad; 7=not acceptable

Radio measurement mechanisms (2/2)
▼ For each MS connected to the BTS (TCH or

SDCCH)
l UL received level and quality is
measured every SACCH
BSC
l The TA (Time advance) is computed DL measurements UL+DL measurements

measurement report measurement result
l The UL information is gathered to

measurement report
l this is the message result sent by
BTS to BSC
PC execution
Active channel HO & PC

Measurements
preprocessing decision
Candidate cell
HO execution
evaluation
• BSC is computing algorithms
• usually using average value (sliding window) of these measurement
1.51
▼ 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 message upon receipt of one of the two following messages:
l DEACTIVATE SACCH
l or RF CHANNEL RELEASE
▼ Every SACCH multiframe, the BTS:

l receives the MEASUREMENT REPORT message from the MS. For power control and handover algorithms, this
message contains downlink measurements and, in the layer 1 header, the power used by the MS.
l does uplink measurements,
l reports the uplink and downlink measurements to the BSC in the MEASUREMENT RESULT message.
l Input flows
è Uplink radio signal : radio signal received on the Air interface.
è BS_TXPWR_CONF : BS transmit power currently used by the BS.
è DTX_DL : indicator of downlink DTX use.
l Output flows
è Abis MEASUREMENT RESULT message
l Internal flows
è Radio measurements :
è Air MEASUREMENT REPORT message (DL) containing DL MS radio measurements
è Uplink radio measurements (quality and level) and a flag indicating whether DTX was used in the downlink
(DTX/DL).
è Timing advance : last TA calculated by the BTS.
è MS_TXPWR_CONF : last reported value of MS power (reported by the MS).
è BS_TXPWR_CONF : value of the BS transmit power currently in use.
è BFI_SACCH : bad frame indicator of the SACCH block produced every SACCH multiframe (# 480ms) :
Ä 0 = SACCH frame successfully decoded
Ä 1 = SACCH frame not successfully decoded

Structure of a measurement result
L1 Info
L3 Info
Measurement
Report
From the MS
1.52
▼ Basically, the MEASUREMENT RESULT message is composed of :

l L1 info : SACCH Layer 1 header containing MS_TXPWR_CONF and TOA.
l L3 info : MEASUREMENT REPORT from the MS. This message contains the downlink measurements and neighbour
cell measurements.
l Uplink measurements performed by the BTS,
l BTS power level used.
▼ SUB frames correspond to the use of DTX

l if the mobile is in DTX the rxlevsub or rxqualsub is used to avoid to measure the TS where there is nothing to transmit
in order not to false measurements
l else rxlevfull is used that is to say all TS are measured
▼ MS TXPOWER CONF : what is the actual power emitted by the MS
▼ TOA is timing advance
▼ SACCH BFI: bad frame indicator; 2 values 0 or 1; 0 means that the BTS succeeded in decoding the measurement report
▼ How the neighbour cells are coded:

l BCCH1 index in BA list / BSIC1; BCCH2 index in BA list / BSIC2
l why ? because it does not receive LAC/CI (too long ) but BCCH and replies with BCCH/BSIC

B7 Extended Measurement Reporting (EMR)
▼ Extended Measurement Reporting mechanisms

MS BTS BSC MSC l Extended Measurement
TCH ASSIGNMENT PHASE (OC or TC)
< -----------------------------------
ASSIGNMENT REQUEST
Order includes the MAFA
< --------------------------------------------------------
PHYSICAL CONTEXT REQUEST
frequencies the MS is
-------------------------------------------------------- >
PHYSICAL CONTEXT CONFIRM
asked to measure
< --------------------------------------------------------
CHANNEL ACTIVATION (TCH)
l EMO sent once to MS on
(EMO included)
-------------------------------------------------------- >
SACCH after TCH seizure
CHANNEL ACTIVATION ACKNOWLEDGE
. l Extended Measurement
.
--------TCH--------->
TCH establishment.
.
Results includes the
ASSIGNT COMPLETE ------------------------------------------------------- >
ASSIGNMENT COMPLETE ----------------------------------- >
average signal level
<------SACCH--------
--------SACCH------>
ASSIGNMENT COMPLETE
measured on each MAFA
<------SACCH--------
--------SACCH------>
frequency over one SACCH
<-------SACCH--------
EMO mf duration
(MAFA freq. List)
.
.
l EMR received once per call
.
--------SACCH------>
on SACCH
EMR
(MAFA freq. RxLev)
1.53
▼ When the BTS receives a CHANNEL ACTIVATION with the EMO (Extended Measurement Order) included, it shall send this
information on the SACCH to the corresponding mobile only once.
▼ When the BTS has to send this information, it shall replace the sending of system information 5, 5bis, 5ter or 6 by this
information. At the next SACCH multiframe, the BTS shall resume the sending of these system information’s by the replaced
one.
▼ The EMO shall be send 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 shall 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 shall identify the level of the BCCH frequency of the serving cell (which shall 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 BCCH frequency of neighbour cells : they will be linked to neighbour level and C/I statistics.

Training exercise (1/2)
l (BSIC, BCCH index)/(LAC, CI) problem
ü As LAC and CI information consume too much

space, the MS only reports the decoded BSIC
and the BCCH index when it sends
measurement on adjacent cell
ü The BSC make the correspondence between
the couple (BSIC, BCCH index) and the real
neighbour cell concerned [completely defined
by (LAC,CI)]
ü WHAT IS THE RISK?
Time allowed :
5 minutes
1.54

▼ Explain why cell 2 has a very high outgoing HO unsuccessful rate and a high
call drop
Cell 3 CI=6169
GSM900
(7, 62)
CI=6169
GSM900
Cell 2 CI=1964
GSM900
(3,46) Cell 1
(7, 62)
1.55

PARAMETERS
2.3 Radio measurements data processing
1.56
Handover Detection
Handover Management
Case Studies

Functional entities
BTS BSC
Radio Active
Link Channel
Measurements Pre-processing
Assignment of radio measurements data processing functions in the ALCATEL BSS
1.57
▼ The active channel preprocessing function calculates average values of signal levels, qualities and timing advance provided
by the radio link measurements function.
▼ The preprocessing is based on a sliding window averaging technique. The averaging is either weighted or un-weighted
depending on the type of the input parameters.

Active channel pre-processing
▼ Active channel pre-processing
l ACTIVATED EACH TIME A MEASUREMENT IS RECEIVED
l AVERAGING VALUES OF SIGNAL LEVELS, QUALITIES, TIMING

ADVANCE
è USING “SLIDING WINDOW” TECHNICAL
l BUILDING A BOOK-KEEPING LIST OF NEIGHBOR CELLS

è MS is reporting the 6 best cells at a time
è They can change from 1 measurement to another
è Maximum for 1 call : 32 last best (among 64 maximum declared as
neighbour)
1.58

Active channel pre-processing - Principles
▼ Active channel pre-processing – Principles
l HANDLED by the BSC
l ACTIVATED when the BSC receives either
è ESTABLISH INDICATION from the MS on SAPI 0
è HANDOVER FAILURE from the MS
è ASSIGNMENT FAILURE from the MS (in case of intracell
handover)
l STOPPED when a HANDOVER COMMAND is emitted in the serving
BSC
l AVERAGING VALUES OF SIGNAL LEVELS, QUALITIES, TIMING

ADVANCE
è USING “SLIDING WINDOW” TECHNICAL
l BUILDING A BOOK-KEEPING LIST OF NEIGHBOR CELLS
1.59
▼ The preprocessing function is stopped when a HANDOVER COMMAND is emitted by the serving BSC. At this time, the
MEASUREMENT RESULT messages are ignored by the preprocessing function and no update of the book-keeping tables or
averaging is done anymore.
▼ The preprocessing 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 preprocessing function is completely handled by the BSC. The input parameters of this function are provided by the BTS
every SACCH multiframe in the message MEASUREMENT RESULT.
▼ The function calculates average values of levels, qualities and timing advance. The preprocessing method is based on a
sliding window averaging technique. The preprocessing 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.

Measurement averaging (1/2)
▼ Avoid reacting too early to some “atypical” measurement(s)
(window 4) 88.00 89.00 89.00 93.00 93.50 95.00 97.50 96.75

(window 8) 88.00 89.00 89.00 93.00 92.40 93.00 93.86 94.88
sliding window effect
105.00
100.00
95.00
90.00
85.00
80.00 level
75 00 average (w indow 4)
1.60
▼ 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 exist for :
l power control on uplink and downlink (A_LEV_PC , A_QUAL_PC)
l emergency handover (A_LEV_HO , A_QUAL_HO , A_RANGE_HO)
l fast emergency handover for microcells (A_LEV_MCHO)
l better cell handover and better zone handover (A_PBGT_HO) for intra-layer, interlayer and
l interzone handovers
l forced directed retry (A_PBGT_DR)
l neighbour filtering and ranking for all HO (A_PBGT_HO)
l codec adaptation (A_QUAL_CA_HR_FR , A_QUAL_CA_FR_HR)

Measurement averaging (2/2)
▼ Objective : average measurements to avoid reacting to transient

degradation
l 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
l 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
l Experiences
some experiment have shown that the number of HO is very sensitive
to modification of these values
1.61
▼ At BSC level,
l Input flows
è MEASUREMENT RESULT
l Control flows
è active channel pre processing configuration parameters for PC :
Ä A_LEV_PC, W_LEV_PC, A_QUAL_PC and W_QUAL_PC,
è active channel pre processing configuration parameters for HO :
Ä A_LEV_HO, W_LEV_HO, A_PBGT_HO, W_PBGT_HO, A_QUAL_HO, W_QUAL_HO, A_RANGE_HO,
A_LEV_MCHO, W_LEV_MCHO, A_PBGT_DR.
è cells list for book-keeping :
Ä BA_IND_SACCH : indicator of the change of the BA_allocation,
Ä NBR_ADJ : number of declared adjacent cells of the serving cell denoted by n,
Ä for n=1 to NBR_ADJ : BSIC(n) and FREQ(n).
l Output flows
è Averaged measurements for power control :
Ä AV_RXQUAL_UL_PC ; AV_RXLEV_UL_PC : MS power control/threshold comparison,
Ä AV_RXQUAL_DL_PC ; AV_RXLEV_DL_PC : BS power control/threshold comparison.
è Averaged measurements for handover detection :
Ä AV_RXQUAL_UL_HO, AV_RXQUAL_DL_HO, AV_RXLEV_UL_MCHO,
Ä AV_RXLEV_UL_HO, AV_RXLEV_DL_HO, AV_RXLEV_DL_MCHO,
Ä AV_LOAD , averaged traffic load
Ä AV_BS_TXPWR_HO, AV_RANGE_HO,
Ä AV_RXLEV_PBGT_HO, AV_RXLEV_NCELL(n), AV_RXLEV_NCELL_BIS(n).
Ä AV_RXLEV_PBGT_DR,
Ä AV_RXLEV_NCELL_DR(n), n=1..BTSnum.
Ä BFI_SACCH
Ä AV_RXQUAL_xx_CA_HR_FR, AV_RXQUAL_xx_CA_FR_HR
è MS_TXPOWER_CONF / BS_POWER : last power level reported by the MS and transmit power currently used
by the BS

Neighbouring cell measurement book-keeping
▼ BUILDING A BOOK-KEEPING LIST OF NEIGHBOR CELLS

è MS reports the measurements of the NO_NCELL_M
(≤ 6) best cells every multi-frame
è The adjacent cells reported by MS can change from one
measurement to another
è The book-keeping function keeps a table of the last 32
reported adjacent cells
è Clearing process of bad neighbour during 10s (signal
level=0)
1.62
▼ 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 in the 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 32 last reported adjacent cells, the maximum number of which is NBR_ADJ. The total number of adjacent
cells for which measurements reported by the MS 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.
The end of the comment is on the next page...

Training exercise
l Measurements averaging
èWith ‘averaging window’ excel
sheet...
• Compute averaging on quality,
distance and level
• Make charts with different sliding
averaging windows
Solution
Time allowed :
10 minutes
1.63
▼ 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 resynchronise 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, for a handover will be impossible 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.

B7

PARAMETERS
2.4 Radio Link Supervision and Power Control
1.64
Handover Detection
Handover Management
Case Studies

2.4 Radio link supervision and power control
Functional entities
BTS BSC
Radio Radio
Link Link
Supervision Command
Radio Active
Link Channel
Measurements Pre-processing PC Threshold
PC Command
Comparison
Assignment of PC functions in the ALCATEL BSS
1.65
▼ The two main functions specified in this document and implemented in the ALCATEL BSS are :
l - 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 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.
l - 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 minimising 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.
▼ The figure depicts in a general way :

l the interconnections between all these functions,
l the implementation of these functions in the ALCATEL BSS.

Radio link supervision
▼ Principles
l Detection (by BTS) of a radio link failure with a MS
è notification to BSC for radio resource release
l Try to recover an MS when radio becomes poor
è optional mechanism “radio link recovery”
è by requiring BTS and MS to transmit at maximum power
l Equivalent mechanism in MS for Radio Link Failure detection
1.66
▼ 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 :
l either on the error rate on the uplink SACCH,
l 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.

Principles of uplink radio link supervision
l For each active radio channel, a counter “S” is

è decremented by 1 each time a SACCH frame
cannot be decoded (BFI=1)
è incremented by 2 each time a valid SACCH
frame is received
l The value of S give a measure of the “quality”
RLTO_BS
18
(T100)
of uplink radio link
RLTO
16
SACCH block lost : - 1
l Initial value of S = BS_RADIO_LINK_TIMEOUT
13
N_BS_TXPWR_M
è if S reaches N_BSTXPWR_M, a radio link
Radio link Recovery
recovery is triggered (optional)
è if S reaches 0, a radio link failure is detected SACCH block received : + 2
l RADIOLINK_TIMEOUT_BS ≥ S S
0 0
RADIOLINK_TIMEOUT is important because Radio link Failure
the mobile must release the radio channel first.

1.67
▼ 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 :
l EN_RL_RECOV : flag enabling/disabling the sending of CONNECTION FAILURE INDICATION by the BTS when the
need for radio link recovery is detected,
l N_BSTXPWR_M : threshold for the radio link recovery,
l 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.
l 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.
l 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 shall be set according this simple behaviour.

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

S counter for radio link supervision
S = f [ B FI(t) ]
25
RAD IO_LIN K_TIM EOU T_B S
N _BSTXPW R_M
15
S value
BFI
S
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
SA C C H n u m b er
1.68
▼ Received events
l Activate supervision : activation of the radio link supervision from the BTS telecom layer 3,
l SACCH, BFI = 1 : not decoded SACCH frame,
l SACCH, BFI = 0 : decoded SACCH frame,
è Note : the BFI flag is internal to the BTS and does not deal with the BFI flag defined by the GSM.
l Deactivate supervision : deactivation of the radio link supervision by the BTS telecom layer 3.
▼ Transmitted events
l Radio link recovery : indication sent to the radio link command function in order to set the BS and MS powers at
maximum.
l Radio link failure : indication sent to the radio link command function in order to release the call.
▼ These events are sent to the BSC in the CONNECTION FAILURE INDICATION message :
l 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.
l In case of Radio link failure, the BTS sends CONNECTION FAILURE INDICATION message with cause 'Radio link
Failure' to the BSC.
▼ Thus, message CONNNECTION FAILURE INDICATION on Abis is not showing any call drop. One should look at cause of
the CONFAIL.

Radio link recovery
▼ BTS is sending message Connection Failure Indication

è cause ‘001 1111’ reserved for national usage
(ALCATEL : RLR)
è On K1205 : “set MS/BS_TXPWR_MAX (Alcatel only)”
▼ BSC is sending messages BS and MS POWER CONTROL
è required for maximum possible values
è MS required level is embedded in SACCH header in
downlink
▼ Optional mechanism
è useless without power control
è “master” vs. power control
1.69
▼ The action consists in increasing the power of the MS and of the BTS to its maximum, in a single step, if the link is failing, i.e.
the BTS is not able to decode the SACCH any more for some period of time.
▼ This functionality is performed upon reception of the message CONNECTION FAILURE INDICATION (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 message BS POWER CONTROL.
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.
▼ Maximum power increase of the MS is 2dB per 60 ms. Thus, if MS_TXPWR_MAX=33dBm and MS_TXPWR_MIN=13dBm,
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

Radio link failure
▼ Radio link failure

l BTS is sending Connection Failure Indication
è Cause ‘radio link failure’
l BSC is notifying the loss to MSC

è Usually Clear Request “radio interface failure”
l BSC is releasing locally the radio resource (TCH or

SDCCH)
è Radio frequency Channel Release message sent to
BTS
l Call is dropped !
1.70
▼ 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.

Radio link supervision : training exercise
l With the “RLS” excel sheet...
è Taking into account the
measurements with BFI and
the parameter values
(N_BSTXPWR_M and
RADIOLINK_TIMEOUT_BS)
è Indicate when
ü A radio link recovery
is triggered
ü A radio link failure is
triggered
Solution
Time allowed :
5 minutes 1.71

B7 Power control
▼ Aims of Power control

l Reduce emitted power to the minimum
BS_TXPWR
possible d ow
nlin
k
l New minimum power levels in B7 :

RXLEV_UL
up
lin k RXLEV_DL
è GSM : 11dBm, 9dBm, 7dBm and MS_TXPWR
5dBm
è DCS : 2dBm, 0dBm
GSM-900 DCS-1800
l Ensuring quality and received level of Power Output Output
peer entity level Power(dBm) Power(dBm)
14 15 2
l Adapted in real-time
15 13 0
l For Uplink PC : decrease UL interference 16 11 -
and 17 9 -
save MS battery 18 7 -
l For Downlink PC, decrease DL 19 5 -
interference 1.72
▼ The main objective of the power control, in connection with handover algorithms, is to allow a maximum number of MS to
operate in the network while maintaining a minimum interference level.
▼ The algorithms shall 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 are possible, by choosing, small values for the averaging window sizes
and higher comparison thresholds.

Power Control principles
▼ Based on a threshold comparison mechanism
▼ Decrease emitted power when received level AND quality

measured by peer entity is better than a given value
▼ Increase emitted power when received level OR quality lower

than a given value
▼ Does not decrease power if resulting level is below low level

threshold
➨ FEATURE REAL FAST PC GIVES REACTIVITY TO THE ALGORITHMS
1.73
▼ 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 preprocessing function and thresholds.

Power Control detection
▼ MS Power control (for BS PC, replace MS by BS and UL by DL)
Decrease
U_RXQUAL_UL_P
No PC
1 Increase required No PC
Decrease
required
L_RXQUAL_UL_P
2
Increase
-95 -93 -85

L_RXLEV_UL_P U_RXLEV_UL_P
POW_RED_STEP_SIZE
1.74
▼ 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).

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))
▼ Power decrease: If
è AV_RXQUAL_UL_PC < U_RXQUAL_UL_P
and AV_RXLEV_UL_PC >= L_RXLEV_UL_P + POW_RED_STEP_SIZE
è AV_RXQUAL_UL_PC ≤ L_RXQUAL_UL_P + OFFSET_RXQUAL_FH

and AV_RXQUAL_UL_PC ≥ U_RXQUAL_UL_P
and AV_RXLEV_UL_PC > U_RXLEV_UL_P
Then PC_COMMAND(MS, RED, MS_P_RED dB, >MS_TXPWR_MIN)
1.75
▼ OFFSET_RXQUAL_FH is an internal variable that is equal to 0 is case of Non-Hopping cell and OFFSET_HOPPING_PC in
case of BBH or RH

MS Power Control Command
▼ Power command philosophy :

l Target received level TARGET_RXLEV_UL
è middle threshold between U_RXLEV_UL_P and L_RXLEV_UL_P
l Adaptive power step size

è According to the average received level
è Limited power step size to MAX_POW_INC and
MAX_POW_RED
è If only Quality problem: fixed power step size
ü POW_INC_STEP_SIZE and POW_RED_STEP_SIZE
è Two weighting factors to modify the algorithm reactivity
when level problem
ü POW_INC_FACTOR for power increase
ü POW_RED_FACTOR for power decrease
1.76
▼ Whenever any of the threshold condition 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 (ie 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 more the reactivity of the algorithm is
great and the more power step size is large).
▼ 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.

Fast and Normal PC comparison
▼ Example
4 SACCH=1 Measurement 3. MR
p/dBm Report (MR) Need for PC command
2. MR 4. MR
detected
-80
PC Command
-90 20dB
Fast Power Control
POW_INC_STEP_SIZE=6dB
-100 Normal Power Control
-110
t/ms
0 480 960 1440 1920
t/ms
60 180 300 420
0 120 240 360 480
1.77

MS Power Increase Command computation
▼ PC_COMMAND (MS, INC, MS_P_INC dB, < power max)

l If MS_TXPWR < power max
then increase MS_TXPWR by min(MS_P_INC, MAX_POW_INC, powermax-
MS_TXPWR)
l where MS_P_INC is evaluated by the following algorithm:
if (AV_RXLEV_UL_PC < L_RXLEV_UL_P) (problem of level)

if (AV_RXQUAL_UL_PC ≤ L_RXQUAL_UL_P + OFFSET_RXQUAL_FH)
(sufficient quality)
then MS_P_INC = roundup[ POW_INC_FACTOR* (TARGET_RXLEV_UL -
AV_RXLEV_UL_PC)]
else MS_P_INC = roundup[ MAX ( POW_INC_FACTOR * (TARGET_RXLEV_UL
- AV_RXLEV_UL_PC ), POW_INC_STEP_SIZE )]
else (problem of quality)
MS_P_INC = POW_INC_STEP_SIZE
1.78
▼ In the equations :
l MS_TXPWR is the last MS_TXPWR_CONF value reported by the BTS.
l ‘roundup’ means ‘round to its next higher multiple of 2 dB’.
l ‘rounddown’ means ‘round to its next lower multiple of 2 dB’.
▼ The rate of change of MS power is required to be one nominal 2 dB step every 60 msec. Thus a 30 dB step change should
be accomplished in 900 msec. The operator should be warned of this as it may impact on the choice of settings for
MS_P_CON_ACK and MS_P_CON_INT.
▼ Then the ordered value of the MS transmit power, called MS_TXPWR, is sent to the MS as follows:
l The BSC sends the message MS POWER CONTROL to the BTS (i.e. to the TRX handling the relevant channel)
which then forwards the PC command to the MS in the Layer 1 header.
l The MS applies the PC command and confirms this action by transmitting the applied power value
(MS_TXPWR_CONF) on the uplink SACCH in the layer 1 header.
▼ On SACCH channel, the MS may not send the MEASUREMENT REPORT message (e.g. in case of transmission of Short
Message).
l In this case, the BSC receives a MEASUREMENT RESULT message which does not contain the MEASUREMENT
REPORT. The BSC takes into account the MS_TXPWR_CONF variable.

MS Power Decrease Command computation
▼ PC_COMMAND (MS, RED, MS_P_RED dB, > power min)

l If MS_TXPWR > power min
then decrease MS_TXPWR by min(MS_P_RED, MAX_POW_RED,
MS_TXPWR- power min)
l where MS_P_RED is evaluated by the following algorithm:
if (AV_RXLEV_UL_PC > U_RXLEV_UL_P) (good level)

if (AV_RXQUAL_UL_PC ≥ U_RXQUAL_UL_P) (sufficient quality)
then MS_P_RED = roundup[ MAX(POW_RED_FACTOR*
(AV_RXLEV_UL_PC- TARGET_RXLEV_UL)), 2dB]
else MS_P_RED = roundup[ MAX ( POW_RED_FACTOR *
(AV_RXLEV_UL_PC- TARGET_RXLEV_UL), POW_RED_STEP_SIZE )]
else (good quality)
MS_P_RED = POW_RED_STEP_SIZE
1.79

Frequency Hopping cases
▼ OFFSET_RXQUAL_FH
l This variable allows to take into account the frequency

hopping in the RxQual evaluation (see Annex 2)
l Defined on a per cell basis Annex 2
l Algorithm:
If Frequency hopping applied
è then OFFSET_RXQUAL_FH = Offset_hopping_PC
è Else OFFSET_RXQUAL_FH = 0
1.80
▼ 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
l 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.
l 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.
l 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.

Power Control timers (1/2)
▼ Timers
l T_SDCCH_PC allows the inhibition of PC on SDCCH
l When a new power is required, the confirmation is awaited :

è MS_P_CON_ACK
è BS_P_CON_ACK
l As soon as the new power is acknowledged, a fixed

duration is awaited to trigger a new change of power, if
necessary :
è MS_P_CON_INT
è BS_P_CON_INT
1.81
▼ The timer T_SDCCH_PC allows to inhibit the MS and BS power control on SDCCH.
l This timer is changeable at the OMC-R on a per cell basis. It is triggered upon receipt of the message ESTABLISH
INDICATION after SDCCH activation for immediate assignment procedure. As long as the timer runs, the power
control is inhibited on SDCCH.
l If the timer expires, the power control will be enabled again on SDCCH.
l If the timer is running at the sending of the message RF CHANNEL RELEASE, 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 securing call setup. Nevertheless, if
SMS usage is very high, SDCCH phases may be long. In that 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.
l 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.
l 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.

Power Control timers (2/2)
▼ IF xx_P_CON_ACK is expiring, it is a system problem :

l Wrong setting of xx_P_CON_ACK (too short)
l No reception of power command by MS
è a radio link recovery can be activated
l Problem on Abis
è repetition of BS power command
▼ The expiry of P_CON_INT is a normal mechanism
1.82

Extra information
▼ LEVEL and QUALITY USED in EQUATION are averages

ones with window size A_QUAL_PC and A_LEV_PC
▼ BS POWER CONTROL INHIBITED ON BCCH frequency
è BCCH must be emitted at maximum level
▼ MS dynamic constraint
è maximum 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 MS (BTS) is
emitting at maximum power
1.83
▼ Interaction with radio link command

l The MS power control function is informed of a radio link recovery by the radio link command function. Once the
indication is received, the PC command process is resumed immediately :
è timer MS_P_CON_ACK is started (or reset and started if running),
è 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 MS_TXPWR_CONF = min(MS_TXPWR_MAX,P).
▼ 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.
l 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.

Power Control : Training exercise (1/3)
▼ Power control UL
(Remark: Use the default parameters document)
l What happens if we do not use Frequency Hopping ?
l Why is it better to have A_LEV_PC=A_LEV_HO/2 ?
l 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
è POW_RED_STEP_SIZE= 4
è POW_INC_STEP_SIZE= 6
l Put the right threshold in the next slide chart
Time allowed :
25 minutes 1.84

▼ Power control UL
Qual QUESTION
For each case
• PC triggered?
• Step size value?
With
POW_INC_FACTOR=0,6
And
POW_RED_FACTOR=0,6
and
MAX_POW_INC=MAX_PO
W_RED=8
Lev
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
Solution
1.85

▼ Power control DL
l 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
l 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 ?
l Which phenomenon can you observe as regards the successive PC

commands ? Solution
1.86

B7

PARAMETERS
2.5 Handover Detection
1.87
Handover Detection
Handover Management
Case Studies

Handover main objective
l SEND CONNECTED MS TO l TOWARD THE “BEST” CELL

ANOTHER CELL è From a radio point of view
è When needed : “rescue/emergency” ü power budget
handover
ü level
è If useful : “better cell” handover
è From a traffic point of view
ü less loaded target
è From a dynamic point of view
ü MS speed
ü “history” of the call
è From a operator point of view
1.88
▼ Emergency intercell handovers

l These handovers are triggered when the call conditions deteriorate significantly in order to rescue the call. The causes
are : "too low quality" , "too low level", " too long MS-BS distance", “too short MS-BS distance”, "consecutive bad SACCH
frames", "level dropping under high threshold".
▼ Better cell HO:

l These handovers are triggered to improve the overall system traffic capacity. This spans : interference reduction,
signalling load reduction, traffic unbalance smoothing. The basic assumption for these handovers is that they should
respect the cell planning decided by the operator.
l The causes are : "power budget" , "high level in neighbour lower layer cell for slow mobile", "high level in neighbour cell
in the preferred band" and “traffic handover”.

Principles
▼ BSC is analysing averaged measurement results

è active channel pre-processing (measurements
averaging and book-keeping)
▼ To detect need/utility to handover

è Handover detection process
▼ To choose/rank target cells according several criteria

è Candidate cell evaluation process
▼ To perform the handover

è Handover management process
1.89

Functional entities
BTS BSC
HO Preparation
Radio Active
Link HO Candidate
Channel HO Detection
Measurements Cell Evaluation
Pre-processing
HO
management
HO
protocol
MSC
Assignment of HO functions in the ALCATEL BSS
1.90
▼ The HO Preparation function can also be named "handover algorithms" as the algorithms described are the "heart" of this
function.
l The ALCATEL handover preparation is derived from the basic algorithm found in Annex A of the GSM Technical
Specification 05.08.
l 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 analyses 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.
l 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 :
l the interconnections between these functions,
l the implementation of these functions in the ALCATEL BSS.

Handover causes detection
▼ Based on the contents of the measurement results

▼ BSC is computing the need or utility to trigger an handover
▼ 25 HO causes, split into 2 main categories :

l emergency handover
è quality, level, distance ...
l better cell handover
è power budget, traffic...
▼ Some are specific to hierarchical and concentric architecture
1.91
▼ The process is achieved in the BSC.

▼ Each time a set of pre-processed (averaged) measurements is available, this process checks whether a handover is needed.
If the need for a handover is detected, the target cell evaluation process is triggered.
▼ In case of a handover alarm, the handover detection process gives to the cell evaluation process :
l the preferred target cell layer : lower, upper or none
l 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.
l 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 an 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.

B7 Handover causes
▼ HO causes for standard networks
l cause 2 : uplink quality too low

l cause 3 : uplink level too low
l cause 4 : downlink quality too low
l cause 5 : downlink level too low
l cause 6 : distance MS<->BTS too large
l cause 15 : high interference in uplink (intra-cell HO) – Modified in B7
l cause 16 : high interference in downlink (intra-cell HO) – Modified in B7
l cause 26 : AMR channel adaptation HO (HR to FR) – New in B7
l cause 12 : power budget evaluation

l cause 23 : traffic
l cause 27 : AMR channel adaptation HO (FR to HR) – New in B7
l cause 28 : Fast traffic HO – New in B7
l cause 29 : TFO HO – New in B7
1.92
▼ HO causes for Concentric Cells :
l Emergency causes
è cause 10 : too low level on the uplink in inner zone
è cause 11 : too low level on the downlink in inner zone
l Better causes
è cause 13 : too high level on the uplink and the downlink in outer zone
▼ HO causes for Extended Cells :

l Emergency causes
è cause 22 : too short MS-BTS distance
▼ HO causes for hierarchical or multiband network :

l Emergency causes
è cause 7 : consecutive bad SACCH frames received in a microcell
è cause 17 : too low level on the uplink in a microcell compared to a high threshold
è cause 18 : too low level on the downlink in a microcell compared to a high threshold
l Better causes
è cause 14 : high level in neighbour lower layer cell for slow mobile
è cause 21 : high level in neighbour cell in the preferred band
è cause 24 : general capture
▼ Forced directed retry :

l Better causes
è cause 20

Handover Cause 2 : UL Quality
▼ CAUSE 2 : Uplink quality too low

QUAL
AV_RXQUAL_UL_HO > L_RXQUAL_UL_H + LEV
OFFSET_RXQUAL_FH
and AV_RXLEV_UL_HO <= RXLEV_UL_IH
and MS_TXPWR = min (P, MS_TXPWR_MAX)
and EN_RXQUAL_UL= ENABLE
l Size of window for averaging quality : A_QUAL_HO

l Size of window for averaging level : A_LEV_HO
1.93
▼ Quality and Level causes (2, 3, 4, 5, 15, 16)

▼ The aim of these causes is to keep the call going when the radio link is degrading otherwise the radio link failure might be
detected and the call released. These causes wait generally for the power control process to increase the BS and MS power
to their maximum values, except for the causes specific to microcellular environment.
▼ Handover on "too low level" is used to avoid situations where the interference level is low, while the attenuation is quite high.
These conditions may appear for example in big city streets which enable a line of sight propagation from the BTS antenna.
There is in this case a risk of abrupt quality degradation, if the MS moves away from the line of sight street.
▼ In case of simultaneous low-level low-quality signals, an intercell handover is requested.

Handover Cause 3 : UL Level
▼ CAUSE 3 : Uplink level tow low

QUAL
AV_RXQUAL_UL_HO <= L_RXQUAL_UL_H + LEV
OFFSET_RXQUAL_FH
and AV_RXLEV_UL_HO < L_RXLEV_UL_H
and MS_TXPWR = min (P, MS_TXPWR_MAX)
and EN_RXLEV_UL= ENABLE

1.94

Handover Cause 4 : DL Quality
▼ CAUSE 4 : Downlink quality too low

QUAL
AV_RXQUAL_DL_HO > L_RXQUAL_DL_H + LEV
OFFSET_RXQUAL_FH
and AV_RXLEV_DL_HO <= RXLEV_DL_IH
and BS_TXPWR = BS_TXPWR_MAX
and EN_RXQUAL_DL= ENABLE

1.95

Handover Cause 5 : DL Level
▼ CAUSE 5 : Downlink level too low

QUAL
AV_RXQUAL_DL_HO <= L_RXQUAL_DL_H + LEV
OFFSET_RXQUAL_FH
AV_RXLEV_DL_HO < L_RXLEV_DL_H
BS_TXPWR = BS_TXPWR_MAX
and EN_RXLEV_DL= ENABLE

1.96

Handover Cause 6 : Distance
▼ CAUSE 6 : Too long distance
AV_RANGE_HO > U_TIME_ADVANCE

and EN_DIST_HO= ENABLE
l Size of window for distance averaging : A_RANGE_HO
1.97
▼ This cause is used when a dominant cell provides a lot of scattered coverages inside other cells, due to propagation
conditions of operational network. These spurious coverages have the consequence of producing a high level of co-channel
interference probability.
▼ 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 a MS to talk to a BS 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 BS is far and another is closer and should be the one the mobile should be connected
with 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. For these reasons also, this cause does not wait for the power control to react.

Handover Cause 12 : Power Budget (1/11)
▼ CAUSE 12 : Power budget

l Decision based mainly on comparison of serving and
neighbour cells for
è downlink level of serving and neighbour cells
è maximum emitting level of MS
l Aiming to decrease UL & DL emitted power
l Should be the “normal” handover type

è no matter of emergency
1.98
▼ 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
transmission 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 minimises the
path loss between the BTS and 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. A hysteresis mechanism is
implemented to avoid this undesirable effect.
▼ No PBGT between different layers

▼ Ok between different bands if EN_INTERBAND_PBGT_HO = 1

▼ CAUSE 12 : Power budget equation
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)
1.99
▼ 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 penalise 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 favour 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.

▼ CAUSE 12 : Power budget PBGT(n) = AV_RXLEV_N CELL(n) − AV_RXLEV_P BGT_HO

− (BS_TXPWR_ MAX − AV_BS_TXPW R_HO )
− (MS_TXPWR_ MAX(n) − MS_TWXPWR_ MAX)
− PING_PONG_ MARGIN(n, call_ref)
l AV_RXLEV_NCELL
è received level of BCCH of neighbour cell
l AV_RXLEV_PBGT_HO
è received level of serving cell (BCCH or not)
l AV_RXLEV_NCELL - AV_RXLEV_PBGT_HO
è the highest is the best neighbour cell
è but serving might not be at maximum level (with DL
power control)
ü necessity to have a corrective factor
1.100
▼ ∆ BCCH = AV_RXLEV_NCELL(n) - (AV_RXLEV_PBGT_HO + C)

l with C = BS_TXPWR_MAX - AV_BS_TXPWR_HO.
▼ This corresponds to the difference of received BCCH signal levels.
l A correction factor C is taken into account for the serving cell, because the received signal level (i.e.
AV_RXLEV_PBGT_HO) may not be measured on BCCH,


l BS_TXPWR_MAX – AV_BS_TXPWR_HO
è BS_TXPWR_MAX are attenuations, not absolute level

ü = (“bts_max_power”+BS_TXPWR_MAX) -
(“bts_max_power”+AV_BS_TXPWR_HO)
è AV_BS_TXPWR_HO: average of BS_POWER over A_PBGT_HO
measurements
è corrective factor used to compensate for the fact that serving cell
may not emit at maximum level
l AV_RXLEV_NCELL-[AV_RXLEV_PBGT_HO+(BS_TXPWR_MAX-
AV_BS_TXPWR_HO)]
è compare received level of neighbour and serving cell as if the
serving was emitting at maximum level
1.101


l MS_TXPWR_MAX(n)
è maximum emitting power for MS in neighbour cell n
l MS_TXPWR_MAX
è maximum emitting power for MS in serving cell
l 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)
1.102
▼ Then, another correction factor must be taken into account because the maximum BS powers of the serving and
neighbouring 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 neighbouring cells.
▼ Two reasons (which are not completely de-correlated) for not using the BS powers can be envisaged :
l for a given cell, the GSM does not specify formally the maximum BS power of the neighbouring cells. Only
BS_TXPWR_MAX is defined (it is sent on the air interface),
l it is not easy for the evaluating BSC to know the maximum BS powers of the neighbouring 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 less than in the current cell.
▼ PBGT <0 : the serving cell is more advantageous as the current cell.


l Hysteresis to avoid ping-pong HO
l Static hysteresis defined for each couple of cells :

HO_MARGIN (0,n)
è can also be used to correct delta_path_loss
l “Dynamic” penalty for call coming from cell n :

ping_pong_margin(n,call_ref)
è penalty applied during a limited duration : T_HCP
è not used if call arrived with a forced directed retry
è penalty defined on a cell basis
1.103
▼ 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" handover 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.
▼ PING_PONG_MARGIN(n,call_ref) is a penalty put on the cell n if :

l it is the immediately precedent cell on which the call has been,
l this cell belongs to the same BSC as the serving cell,
l the call has not performed a forced directed retry towards the serving cell,
l less than T_HCP seconds have elapsed since the last handover.
è In this case PING_PONG_MARGIN(n,call_ref) = PING_PONG_HCP
▼ If the call was not precedently on cell n, or if the preceding cell was external, or if the call has just performed a forced directed
retry, or if the timer T_HCP has expired,
è then PING_PONG_MARGIN(n,call_ref) = 0

Case 3:
l ping_pong_margin example Not a ping-pong case
OK with ping_pong_margin
Case 2: and T_HCP
ping-pong in normal case
OK with ping_pong_margin
Case 1: OK
1.104
▼ This chart shows the efficiency of the anti-ping_pong mechanism.

▼ But, never forget that anti-ping-pong mechanism distorts the serving areas of the cells.
▼ This is why interference problems might occurs when enabling this mechanism. Tuning PING_PONG_HCP parameter is thus
very important.
▼ Warning : this mechanism is not applied for emergency handovers (new mechanism in B7 exists for capture HO, based on
T_INHIBIT_CPT timer)

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=1…BTSnum)
Else PBGT(n) > HO _MARGIN(0,n) + OFFSET_HO_MARGIN_INNER
AND AV_RXLEV_PBGT_HO ≤ RXLEV_LIMIT_PBGT_HO
AND EN_PBGT_HO = ENABLE
l Size of window for level averaging : A_PBGT_HO

1.105
▼ Cause 12 HO is correlated with cause 23 HO. This is why there are two equations according to the activation of cause 23 HO
(EN_TRAFFIC_HO).

l 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
l Specific to particular algorithms (not mentioned in this course)

OFFSET_HO_MARGIN_INNER: offset which allows to take into account the radio
differences between outer and inner zone (especially in
case of multi band cell)
1.106
▼ RXLEV_LIMIT_PBGT_HO: Dense Network Handover Regulator features

▼ The feature aims at optimizing the better cell handovers, especially in the microcellular environment.
▼ In very dense networks, there is a lot of overlapping between adjacent cells: the better cell handover will be realised very
often. Since B6, the Alcatel BSS tune the number of handovers performed to the accurate need by taking into account the
level received by the serving cell.
▼ Therefore, the best trade-off between quality of speech and intempestive handovers is achieved.
▼ Why ?
l Especially in microcellular environment (where cell radius is smaller) the better cell HO (based on Power Budget) is
likely to be performed at a high rate to the detriment of the quality
l But it is necessary to maintain the better cell HO
▼ How ?
l With a modification of the power budget triggering cause
▼ Principles :
l HO cause 12 (Power Budget HO) is modified and takes into account the received downlink level of the serving cell
(new criterion): if the received level is high enough, there is no need to perform a HO
▼ Consequence :
l less HOs when number of overlapping cells is high
W/O B6 WITH B6

l Specific to traffic considerations

DELTA_HO_MARGIN(0,n): 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
Philosophy
This mechanism aims to penalize cause 12 detection when the
traffic in the serving cell is low and is high in the cell n.
1.107
▼ 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.
l If Traffic_load(0)=high and Traffic_load(n)=low
è DELTA_HO_MARGIN(0,n)= -DELTA_DEC_HO_margin
l If Traffic_load(0)=low and Traffic_load(n)=high
è DELTA_HO_MARGIN(0,n)= DELTA_INC_HO_margin
l 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
l DELTA_INC_HO_margin allows to penalise 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.

l Traffic_load() is a function managed for every cell of a BSC

l Traffic_load() can have three values :
è high : cell is loaded
è low : cell is unloaded
è indefinite : cell load is neither loaded nor unloaded
l Traffic_load() value is modified according to the long term traffic
evaluation algorithm using the following parameters :
è A_TRAFFIC_LOAD, N_TRAFFIC_LOAD,
HIGH_TRAFFIC_LOAD, IND_TRAFFIC_LOAD,
LOW_TRAFFIC_LOAD : can be modified per cell
è TCH_INFO_PERIOD : cannot be modified Annex 3
1.108
▼ TCH_INFO_PERIOD = 5s period used by the BSC to count the number of free TCH.

Handover Cause 23 : Traffic (1/2)
▼ CAUSE 23 : Traffic Handover
DELTA_HO_MARGIN(0,n) < 0dB
AND PBGT(n) > HO_MARGIN(0,n) + OFFSET_HO_MARGIN_INNER

+ DELTA_HO_MARGIN(0,n) (n=1…BTSnum)
AND EN_TRAFFIC_HO(0,n) = ENABLE
l Size of window for level averaging : A_PBGT_HO
1.109
▼ 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.
▼ The cause is checked over all the neighbour cells belonging to the same layer. It means that it is checked between cells
whose CELL_LAYER_TYPE is single or upper and between cells whose CELL_LAYER_TYPE is lower.
▼ This cause must not be checked between cells which use different frequency band (i.e cells having different
CELL_BAND_TYPE)
▼ If the MS is in the inner zone of a multiband cell, the cause 23 is checked over all the neighbour multiband cells
(FREQUENCY_RANGE=GSM-DCS) which belong to the same BSC as the serving cell.

Handover Cause 23 : Traffic (2/2)
▼ CAUSE 23 : Traffic Handover

l DELTA_HO_MARGIN(0,n) computation is already described in Cause
12 HO
l DELTA_HO_MARGIN(0,n) < 0dB means that
è The serving cell is loaded
è The target cell is unloaded
l PBGT(n) > HO_MARGIN(0,n) + OFFSET_HO_MARGIN_INNER
+ DELTA_HO_MARGIN(0,n) (n=1…BTSnum)
è This constraint is less discriminative than Cause 12
è In specific traffic distribution, this cause is triggered before cause
12
1.110

Handover Cause 12 & 23 interworking
▼ Cause 12 & 23 : A dynamic way to handle traffic load
1.111
▼ 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.

B7 Handover Cause 28 : Fast Traffic HO (1/4)
▼ CAUSE 28 :
l 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 average window used)
è More efficient where the overlap of adjacent cells is reduced
New call attempt Most appropriate MS
to be pushed out
HO
Congested cell
Upper Layer Cell

New call attempt
O
H
Most appropriated MS
to be pushed out
1.112
l AV_RXLEV_NCELL( n) > L_RXLEV_NCELL_DR( n) + max(0,[MS_TXPWR_MAX( n)-P])

è The threshold L_RXLEV_NCELL_DR(n) is the observed level from the neighbor cell n at the border of the area where fast
traffic handovers are enabled. This threshold fixes the size of the overlapping area where fast traffic handovers can be
performed. It should be greater than RXLEVmin(n).
l And t(n) > FREElevel_DR(n)
è FREElevel_DR(n) is the minimum threshold of free TCHs in the neighbor cell n for forced directed retry and fast traffic
handover.
è t(n) is the absolute number of free (dual rate) TCHs in the neighbor cell n.
è For external cells, t( n) is fixed to the arbitrary value t(n) = 255. Therefore, setting FREElevel_DR(n) to 255 for an external
cell inhibits outgoing external fast traffic handover towards this cell. Setting FREElevel_DR(n) to any other value will allow
outgoing external fast traffic handover towards this cell.
l EN_CAUSE_28 = enable
è The flag EN_CAUSE_28 is not an OMC flag but a HOP flag.

▼ CAUSE 28 : Fast Traffic Handover
l Cause 28 is only checked if the channel of the candidate MS can

support the channel rate (HR or FR) required by the queued request :
Q UEUED REQU EST CANDIDATE MS
HR
HR or
FR on dual rate TR X
FR FR (whatever the TR X type)
l HO is triggered when a request is queued at the top of the queue
1.113

▼ CAUSE 28 : Fast Traffic Handover equation
AV_RXLEV_NCELL(n) > L_RXLEV_NCELL_DR(n) +

max(0,[MS_TXPWR_MAX(n)-P])
AND t(n) > FREElevel_DR(n)
AND EN_CAUSE_28 = ENABLE
AND EN_FAST_TRAFFIC_HO = ENABLE
l Size of window for averaging level : A_PBGT_DR
è Same thresholds and window as Cause 20 (Forced Directed

Retry)
è EN_CAUSE_28 is an internal HOP process variable
1.114

▼ CAUSE 28 : Fast Traffic Handover process
Ressource Handover Handover

Allocation Preparation Management
Management Fast Traffic HO Request
Assignment request queued
Queued request reference
EN_CAUSE_28=enable
Channel rate of queued request
HO alarm NO
Cause 28 ?
Fast Traffic HO Acknowledge YES

Queued request reference
Request still Reference of MS can perform HO
queued ? EN_CAUSE_28=disable
Start HO
Cause number (28) Check first 2 OK
conditions of
NO YES Reference of the call to handover Cause 28
END NOK T_FILTER is started
(which corresponds to the first
candidate MS received)
END
1.115
▼ HO cause 28 process :
l If EN_FAST_TRAFFIC_HO = enable, when a assignment request (or external emergency HO request) is queued, the
RAM process sends to the HOP process a Fast Traffic HO request which contents the queued request reference and
its channel rate.
l Then, HO cause 28 becomes checkable (EN_CAUSE_28=enable).
l Once a HO alarm for cause 28 is triggered, the flag EN_CAUSE_28 is set to “disable” so as not to perform more than
one handover. In the same time, the HOP process gets back to the RAM process a Fast Traffic HO Acknowledge
which contents the queued request reference and the reference of MS that can perform HO.
l If several answers are sent to the RAM process, only the first one corresponding to the queued request is taken into
account.
è the RAM process checks if the request is still queued. If that is so, RAM asks HOP to start HO for this mobile;
otherwise the process is stopped.
l Once the HOP process receives this message, the first two conditions of Cause 28 (good enough level, enough free
resources in the target cell) are checked one more time. If the conditions are fulfilled, the HOP process sends an
alarm to the HOM entity and the timer T_FILTER is started ; otherwise the process is stopped.
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.

B7 Intracell handovers
▼ New causes (26 & 27) introduced due to AMR support

l Cause 26 is an emergency condition :
è Intracell HO : speech codec from AMR-HR to AMR-FR
l 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
l Specifics enablers and thresholds for AMR calls
l 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
l Codec sharing and optimisation for MTM calls
1.116

B7 Handover Cause 15 : UL Interference
▼ CAUSE 15 : High interference in uplink - Modified in B7
l Intra-cell HO
AV_RXQUAL_UL_HO > THR_RXQUAL_CAUSE_15 +
OFFSET_RXQUAL_FH
AND AV_RXLEV_UL_HO > RXLEV_UL_IH
AND [ no previous intracell handover for this connection
failed
OR EN_INTRACELL_REPEATED = ENABLE ]
1.117
▼ THR_RXQUAL_CAUSE_15 and EN_CAUSE_15 are not parameters but variables defined just after

B7 Handover Cause 15 : DL Interference
▼ CAUSE 16 : High interference in downlink - Modified in B7
l Intra-cell HO
AV_RXQUAL_DL_HO > THR_RXQUAL_CAUSE_16 +
OFFSET_RXQUAL_FH
AND AV_RXLEV_DL_HO > RXLEV_DL_IH
AND [ no previous intracell handover for this connection
failed
OR EN_INTRACELL_REPEATED = ENABLE ]
1.118
▼ THR_RXQUAL_CAUSE_16 and EN_CAUSE_16 are not parameters but variables defined after

B7 New parameters for causes 15 & 16
▼ CAUSE 15 and CAUSE 16 : Modifications in B7
l THR_RXQUAL_CAUSE_15 (or 16) and EN_CAUSE_15 (or

16) are specific to HOP
l 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
l EN_ CAUSE _15 (or 16) =
è EN_INTRA_XX for a non AMR call
è EN_INTRA_XX_AMR for an AMR call
1.119
▼ 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 a HO CAUSE 15 (or 16) fails, it can be modified as
UPLINK (or DOWLINK) QUALITY, HO CAUSE 2 (respectively HO CAUSE 4).

B7 Adaptive Multi-rate codec (AMR)
▼ Principles:
l Two consecutive encoding : speech coding and channel
coding
l With current codecs, the share of each coding is FIXED

(not optimized)
13 kbps (FR) 22.8 kbps (FR TS)

12.2 kbps (EFR)
5.6 kbps (HR) 11.4 kbps (HR TS)
Audio Speech coding Channel coding Radio

Speech information Speech protection
“useful part” “against degradation”
1.120
▼ Speech coding contains speech information (the “useful” part)

▼ Channel coding protects speech information (against radio degradations)
▼ 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 where launched to provide a solution for:

• Increasing speech quality in full rate and half rate,
• Increasing network capacity by offering a good half rate solution,
• Using a long-term solution, avoiding to add more and more codecs handled independently from the others.

B7 AMR : codec and channel adaptation
l AMR uses a variable balance between speech coding and

channel coding (CODEC Mode Adaptation)
12.2
10.2
7.95
7.4 22.8 kbps (FR TS)
6.7
11.4 kbps (HR TS)
5.9 AMR HR 7.95 not supported
5.15
4.75
Audio Speech coding Channel coding Radio
Variable speech Variable channel
coding rate coding rate
l Choice between FR and HR Codecs : Channel Mode

Adaptation
1.121
▼ In order to adapt the intermediate rate, a set of speech codecs has been defined by ETSI to be used by AMR :
l When radio conditions are good, increases speech information
l 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 uses 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 uplink and in downlink.
▼ Codec Mode adaptation :

è dynamic change from one codec to another, using the same channel (FR or HR)
è metric used : C/I (Carrier over interference ratio)
▼ Channel Mode adaptation :
è change from one FR channel to an HR one and vice-versa independently from the codec mode
è metric used : RX_QUAL uplink and downlink

B7 AMR codec adaptation objective
l Based on adaptive trade-off between the share of

throughput given to speech coding and the one given to
channel coding (speech protection)
l Depends on radio conditions estimated in real-time
Medium radio Bad radio Good radio

conditions conditions conditions
Speech coding = speech information

Channel coding = speech protection
1.122
▼ The AMR principle is to have a set of codecs and, for any radio conditions, to use the one with the best speech quality.
l 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.
l 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 uplink and used in 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]
High bit rate (for example 12.2 kbit/s: EFR)

Medium bit rate (for example 7.95 kbit/s)
Low bit rate (for example 5.90 kbit/s)
AMR-FR with codec subset (12.2, 7.95, 5.90)
C/I [dB]

B7 AMR : codec mode adaptation (1/3)
▼ Codec mode adaptation

l Only a subset out of these codecs can be used
l This subset may include from 1 to 4 codecs
l Same codec subset is used for both Uplink and Downlink
l 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)
l Downlink codec mode adaptation :
è Same process as uplink adaptation
è Nevertheless, the BTS remains the master
l Unrelated processes Þ uplink and downlink codecs may be
different at a given time
1.123

B7 AMR codec mode adaptation (2/3)
▼ Codec mode can be modified one frame out of two (CMI / CMC-CMR).
▼ Decision based on thresholds (OMC-R settable), for uplink and downlink
C/Inorm
High
CODEC_MODE_4
(less robust)
AMR_FR_THR_3 + AMR_FR_HYST
AMR_FR_THR_3
CODEC_MODE_3
AMR_FR_THR_2
CODEC_MODE_2
AMR_FR_THR_1
CODEC_MODE_1
(most robust)
Low
1.124

B7 AMR : codec mode adaptation (3/3)
▼ Codec mode adaptation

MS BTS TC
l Uplink adaptation
C/I evaluation & thresholds
comparison
Codec Mode Command

(new codec mode)
Codec Mode Indication

(new codec mode) Codec Mode Indication
(new codec mode)
l Downlink adaptation
MS BTS TC
C/I evaluation &

thresholds comparison
Codec Mode Request

(new codec mode) Codec Mode Request
(new codec mode)
Codec Mode Indication
Codec Mode Indication (new codec mode)
(new codec mode)
1.125

B7 AMR : codec and channel mode adaptation
▼ Codec mode adaptation is dynamically performed through a set

of pre-defined “codec modes” :
è In FR mode : 12.2
10.2
7.95
7.4 22.8 kb/s (FR TS)
6.7
5.9
5.15
4.75
From
acoustic Speech coding Channel coding To end of chain
parts Variable speech
coding rate
7.4
6.7
è In HR mode : 5.9
5.15
11.4 kb/s (HR TS)
4.75
From
acoustic Speech coding Channel coding To end of chain
parts Variable speech
coding rate
▼ Choice between HR and FR (Channel mode adaptation) is done

at call setup and during call through causes 26 & 27 HO
1.126
▼ Codec mode adaptation:

▼ The codec mode adaptation is the dynamic change from one codec to another codec, using the same channel (FR or HR).
This adaptation is performed by the layer 1 of the BTS. It is transparent for the BSC and the layer 3 of the BTS.
▼ The metric used for codec mode adaptation is the evaluation of the ratio: signal over noise.

B7 AMR gain
▼ AMR : always give end user the best satisfaction

l Comparison between different codecs in terms of capacity
and quality :
SPEECH QUALITY CAPACITY

REQUIREMENT REQUIREMENT
FR K L
EFR J L
HR L J
AMR-FR J L
AMR-HR K J
AMR-FR + AMR-HR J J
1.127
▼ 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 analogue systems. For that issue, EFR was specified for GSM.
▼ Recently, studies on AMR where launched to provide a solution for:
• Increasing speech quality in full rate and half rate,
• Increasing network capacity by offering a good half rate solution,
• Using a long-term solution, avoiding to add more and more codecs handled independently from the others.
• Taking into account Tandem Free Operation (TFO), especially between MS on half rate on one side and on full rate
on the other side.

B7 AMR : TCH allocation
▼ FR / HR discrimination
l 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%
THR_FR_LOAD_U_SV1
= 80%
THR_FR_LOAD_U_SV3
=60%
THR_FR_LOAD_L_SV1 time
=50%
THR_FR_LOAD_L_SV3
=40%
1.128
▼ 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 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 MSs HR capable can be allocated in HR (HR SV1 & HR SV3) for load
reasons.
l That 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).
l 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 :
l THR_FR_LOAD_L_SV3 ≤ THR_FR_LOAD_U_SV3
l THR_FR_LOAD_U_SV3 ≤ THR_FR_LOAD_U_SV1
l THR_FR_LOAD_L_SV3 ≤ THR_FR_LOAD_L_SV1

B7 Cause 26 : AMR HR to FR HO (1/4)
▼ CAUSE 26 : AMR channel adaptation HO (HR to FR)
l 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
1.129

▼ CAUSE 26 : AMR channel adaptation HO (HR to FR) equation

[ a previous intra-cell 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
l Size of window for averaging quality : A_QUAL_CA_HR_FR
1.130

l THR_RXQUAL_CA and OFFSET_CA are set as follows :

if LOAD_SV3(0) = false then
THR_RXQUAL_CA = THR_RXQUAL_CA_NORMAL
OFFSET_CA = OFFSET_CA_NORMAL
if LOAD_SV3(0) = true then
THR_RXQUAL_CA = THR_RXQUAL_CA_HIGH
OFFSET_CA = OFFSET_CA_HIGH
1.131

l 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
Else ( if previous value of LOAD_SV3 = true then)

if AV_LOAD <= THR_FR_LOAD_L_SV3 then
LOAD_SV3 = false
else
LOAD_SV3 = true
Annex 3
1.132

B7 Cause 27 : AMR FR to HR HO (1/2)
▼ CAUSE 27 : AMR channel adaptation HO (FR to HR)
▼ Cause 27 is triggered if :
è Current channel rate is FR

è Current channel is dual rate and changes are allowed
è AMR_HR speech codec is allowed :
ü EN_AMR_HR = ENABLE
1.133

B7 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
l Size of window for averaging quality : A_QUAL_CA_FR_HR
1.134

B7 Cause 26 & 27 interworking
▼ Cause 26 & 27 interaction
Quality
good quality: 0 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
Full Rate Full Rate
HO cause 26
bad quality: 7
Load = FALSE Load = TRUE
1.135

B7 Introduction to TFO (1/2)
▼ TFO (Tandem Free Operation) solution
TC TC
Codec GSM (a) A/µ law Codec GSM (b)

(8 or 16 kbit/s) (64 kbit/s) (8 or 16 kbit/s)
Double transcoding without TFO
TC TC
Codec GSM
(8 or 16 kbit/s)
No transcoding with TFO
1.136
▼ 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 signalling between transcoders.

B7 Introduction to TFO (2/2)
▼ Applicability: Only MS to MS speech calls

▼ TFO is based on information exchanged between transcoders
BTS BSC MSC MSC BSC BTS

IPE IPE
MS TRAU TRAU MS
64 kbit/s Speech Samples carrying

- TFO Frames on the LSB containing
- Compressed speech samples
- Control bits
- TFO Messages
- Original PCM speech samples on the MSB
1.137

B7 TFO principles
▼ In the case of first allocation (normal assignment at call set-up, inter-

BSS handover, intra-BSS handover where no TFO was previously on-
going):
Exchange of codec
capabilities
New call Codec mismatch
setup
No common codec
found
Common codec
found
Exchange of codec
capabilities Intracell HO Normal operation
Exchange of codec
Codec match capabilities
TFO mode ON
1.138

B7 Cause 29 : TFO HO
▼ CAUSE 29 : TFO HO
l Intracell HO used in case of codec mismatch between two

MS calling, in order to match their speech codec
l No radio measurements needed à No priority and may be
triggered at any time
l Conditions :
HO_INTRACELL_ALLOWED = ENABLE
AND
EN_TFO_MATCH = ENABLE
1.139

B7 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 optimisation, per cell
▼ FORCE_TFO_VS_AMR
è enable/disable 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
1.140
▼ Codec mismatch :
l 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 intra-cell handover to use
the common codec type found. Afterwards TFO can be started using this common codec type. Codec mismatch
resolution is authorised in the BSC using an O&M flag : EN_TFO_MATCH. This flag is forwarded to the TC, via the
BTS.
▼ Codec optimisation :
l 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 optimisation
is authorised 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 :
l 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 :
l 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) :
l 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 cancellers or A/µ law converters that modify the 64 kbit/s
speech signal. Such equipments need to be deactivated for TFO calls.

▼ EN_TFO_OPT : enables/disables codec optimisation, per cell

l 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 HR is
possible too
è HO cause 29 will be triggered on both sides towards
best codec
1.141

▼ FORCE_TFO_HR_AMR :
l TFO AMR not specified
è Call setup in AMR is not followed by TFO negotiation
è FORCE_TFO_VS_AMR enables cause 29 HO after
AMR call establishment towards best TFO codec
MS / cell cap : AMR/HR/EFR/FR MS / cell cap : HR/EFR/FR
MS using AMR, could use HR/EFR/FR

DISABLED TFO not
(ETSI implementation) MS can use HR/EFR/FR possible
ENABLED MS can only use HR/EFR/FR
(Alcatel patent)
MS can use HR/EFR/FR
EFR + TFO
FORCE_TFO_VS_AMR
1.142

▼ FORCE_TFO_HR_WHEN_LOADED :
l 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
Loaded cell Unloaded cell
MS / cell cap : HR/EFR/FR MS / cell cap : HR/EFR/FR

DISABLED
(ETSI implementation) MS can use HR/EFR/FR EFR + TFO
ENABLED MS can only use HR

(Alcatel patent)
HR + TFO
FORCE_TFO_HR_WHEN_LOADED
1.143

▼ KEEP_CODEC_HO
l 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
l Avoids double speech quality transition :
TFO --> non-TFO --> TFO
l 3 possible behaviours :
è 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 TFO state)
è FREE : the choice of the codec type is free and
depends on the situation in the target cell.
1.144

B7 Handover causes priorities
HANDOVER
PRIORITIES
EMERGENCY BETTER CONDITION

HANDOVER HANDOVER
UPLINK QUALITY POWER BUDGET

CAUSE 2 CAUSE 12
DONWLINK QUALITY TRAFFIC

CAUSE 4 CAUSE 23
UPLINK LEVEL FR to HR CHANNEL ADAPTATION

CAUSE 3 CAUSE 27 Intracell
DOWNLINK LEVEL FORCED DIRECTED RETRY

CAUSE 5 CAUSE 20
DISTANCE FAST TRAFFIC HO

CAUSE 6 CAUSE 28
HR to FR CHANNEL ADAPTATION
CAUSE 26 Intracell
UPLINK INTERFERENCE
CAUSE 15 Intracell
DONWLINK INTERFERENCE
CAUSE 16 Intracell
XXXXXXXXXXXXXXXXXXXXXXX
1.145
▼ The causes 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:

l Emergency : 7 > 17 > 18 > 2 > 4 > 3 > 5 > 6 > 22 > 10 > 11 > 26 > 15 > 16
l Better conditions : 21=14=24=12=23 > 13 > 27 > 20 > 28
l 29 has no priority

Training exercises (1/15)
▼ Emergency causes
1- What is the HO cause 2 ?
2- What is the flag to activate the HO
cause 2 ?
Time allowed :
45 minutes
1.146

Complete the diagram below and fill in the chart with:
L_RXQUAL_UL_H = 3
RXLEV_UL_IH = -70 dBm
N b o f case - -- > 1 2 3 4 5 6
QUAL
AV _RX Q U AL_U L_H O 4 1 3 4 4 4
AV _RX LE V _U L_H O - 81 - 79 - 75 - 70 - 69 - 72
C urrent M S Po w er 33 33 33 33 33 29
(0,8 w) LEV
H O cause 2 : YE S/N O ?
Solution
1.147

▼ Better condition causes (simple case)

è There is only 2W cells and 2W MS
è EN_TRAFFIC_HO(0,n)=Disable
è No Ping-Pong margin
Ncell
è HO_MARGIN(0,n)=5 dB
Serving cell
MS
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 ?
Solution
1.148

▼ Better condition causes (ping-pong case)

è Ping-Pong margin PING_PONG_HCP=15db
T_HCP =15s Ncell
è HO_MARGIN(0,n)=5 dB A_PBGT_HO = 8 SACCH
A n to 0 HO has just been triggered, what happens after 4s? Serving cell
MS
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) « a » only 10 0 -5 5 9 21
HO cause 12: YES/NO ? YES NO NO NO YES YES
PBGT > HO margin
PING_PONG_HCP=15 - > PBGT(n)
HO cause 12: YES/NO ?
Solution
1.149

▼ Training exercise: Handover Detection

l Better condition causes (traffic case)
è EN_TRAFFIC_HO(0,n)=Enable
è No Ping-Pong margin
Ncell
è HO_MARGIN(0,n)=5 dB
è DELTA_DEC_HO_margin=5dB Serving cell

MS
è DELTA_INC_HO_margin=5dB
1.150

▼ Better condition causes (traffic case)

Fill up the chart: Ncell
Serving cell
MS
Number 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: tr low 0: tr high 0: tr high 0: tr low

N: tr high N: tr low N: tr low N: tr low
PBGT(n)
DELTA_HO_MARGIN(0,
n)
Cause 12 HO: YES/NO?
Cause 23 HO: YES/NO?

Solution
1.151

B7 Training exercises (7/15)
▼ Channel adaptation (cause 26 and cause 27)

1- Why is having A_QUAL_CA_FR_HR ≥
A_QUAL_CA_HR_FR recommended ?
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 a
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 = ?
1.152


è 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 :
Solution
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
1.153

▼ 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 : MS1àFR on Full rate TRX, MS2àHR, MS3àFR on Dual rate TRX
è t(n) for neighbor cells : t(1)=1, t(2)=2, t(3)=2
è AV_RXLEV_NCELL(n) in dBm :
Neighbors 1 2 3
MS
1 -82 -85 -78
2 -79 -86 -92
3 -90 -82 -89
Solution
1.154

▼ TFO HO (cause 29) : after call set-up

Find the 2 speech version types of the following MS to MS call
l EN_TFO = enable, EN_TFO_MATCH = enable
l FORCE_TFO_HR_WHEN_LOADED = TFO_HR_NOT_FORCED
MS / cell cap : HR/EFR/FR MS / cell cap : EFR/FR
After call set-up TCH = ? TCH = ?
After TFO negociation TCH = ? TCH = ?
Solution
1.155


l FORCE_TFO_HR_WHEN_LOADED = TFO_HR_ONLY
Solution
1.156


l FORCE_TFO_HR_WHEN_LOADED = TFO_HR_PREFERRED
Solution
1.157


Solution
1.158

▼ TFO HO (cause 29) : after handover

Find the speech version types of the following MS to MS call
Unloaded cell
1. KEEP_CODEC_HO = enable Unloaded cell MS / cell cap : HR/EFR/FR
MS / cell cap : HR/EFR/FR
2. KEEP_CODEC_HO = disable
MS2
MS2 HO
Loaded cell call set-up ?
MS / cell cap : HR/EFR/FR + TFO negociation
?
TFO ?
?
Solution
MS1 TFO ?
1.159


l KEEP_CODEC_HO = enable Unloaded cell
Loaded cell MS / cell cap : HR/EFR/FR
1. EN_TFO = disable
2. EN_TFO = enable
MS2
MS2 HO
Unloaded cell call set-up ?
?
TFO ?
?
Solution
MS1 TFO ?
1.160

PARAMETERS
2.6 Handover Candidate Cell Evaluation
1.161
Handover Detection
Handover Management
Case Studies

2.6 Handover Candidate Cells Evaluation
Principles
▼ Used to rank potential target cells :
l Ranking based on radio characteristics
l Ranking based on operator preferences
l Ranking based on traffic intensity
1.162
▼ Handover candidate cell evaluation
l The process is performed in the BSC.
l Once a need for handover is detected, this process looks for possible target cells (except if it is an intracell handover
or an interzone handover) and provides the BSC entity in charge of the HO decision and execution entity with a list of
candidate cells and their respective HO cause
BTS BSC
HO Preparation
Radio Active
Link HO Candidate
Pre-processing
HO
management
HO
protocol
MSC

Evaluation process
Raw cell list
MEASUREMENT PREPROCESSING HO_DETECTION
Preprocess measurement
max Every SACCH

cell 1 : cause C1
Measurement result
according cause 2 : uplink quality cell 2 : cause C2
cause 3 : uplink level cell 3 : cause C3
• A_LEV_HO cause 4 : downlink quality cell 4 : cause C4
• A_QUAL_HO cause 5 : downlink level cell 5 : cause C5
• A_PBGT_HO cause 6 : distance cell 6 : cause C6
• A_RANGE_HO cause 12 : power budget cell 7 : cause C7
cell 8 : cause C8
Performed every SACCH …
Performed every SACCH
Max 32 cells
PBGT_FILTERING
CELLS EVALUATION PROCESS
PRE-RANKING HO_MARGIN_XX(0,n) Order or Grade
Priority (0,n) = 0 Priority (0,n) = 0

cell 2 : cause C2 cell 2 : cause C2 Grade Order
cell 3 : cause C3 cell 3 : cause C3
cell 4 : cause C4 cell 4 : cause C4 Priority (0,n) = 0 Priority (0,n) = 0
cell 4 cell 4
Priority (0,n) = 1 Priority (0,n) = 1 cell 2 cell 3
cell 1 : cause C1 ----------------------- cell 2
Priority (0,n) = 1
Priority (0,n) = 2 Priority (0,n) = 2 Priority (0,n) = 1
Priority (0,n) = 2
Priority (0,n) = 3 Priority (0,n) = 3 Priority (0,n) = 2
cell 5 : cause C5 ---------------------- Priority (0,n) = 3
cell 6 : cause C6 cell 6 : cause C6 cell 8 Priority (0,n) = 3
cell 7 : cause C7 ----------------------- cell 8
cell 8 : cause C8 cell 8 : cause C8
HO CANDIDATE CELLS EVALUATION
1.163
▼ The HO candidate evaluation process is run after all intercell handover alarms.
▼ In case of intra-cell 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 (build 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).

B7 Pre-ranking
▼ with priority(0,n) settings,

settings operator can :
èfor each couple of cells
ètag target cell with a defined priority (from 0 = max to 5 = min) – Modified in B7
èthis definition has an higher priority than usual order/grade ranking
▼ especially useful for multi band/hierarchical architectures :

èa simple way to force target cell whatever is RxLev level and PBGT
ènevertheless can be skipped over by filtering processes
èlow interest for standard networks
Candidate cell 1 : RxLev : - 70 dBm, pbgt : + 10 dB

P1
Serving cell
P0
Candidate cell 2 : Rxlev : - 90 dBm, PBGT : + 5dB
1.164
▼ Cell ordering according to target layer and target band

▼ In hierarchical or multiband environment, cells are characterised by the layer they belong to or/and the frequency band they
use. The candidate cell evaluation process takes into account these characteristics in the candidate cell ordering.
▼ In hierarchical environment, the HO detection process can indicate a preferred layer where the handover must be directed to.
If this indication is used, the candidate cell evaluation puts in the first places of the list, the candidate cells belonging to the
preferred layer. They are followed by the cells of the other layer, providing they are also correct candidates.
▼ After this possible distinction, in each part of the list, the candidate cell evaluation sorts the candidate cells according to the
parameter PRIORITY(0,n) (parameter on line changeable from the OMC-R).
▼ The cells having the highest priority are put in the first place of the list. They are followed by the cells having lowest priorities.
The PRIORITY(0,n) is only used when the flag EN_PRIORTY_ORDERING is set to enable.
▼ In case of emergency handover, for each category (preferred layer and other layer) and between cells having the same
priority, the candidate cell evaluation sorts the candidate cells according to the frequency band they use : the cells which use
the same frequency band as the serving cell are put first and they are followed by the cells which use the other frequency
band.
▼ The cell evaluation function is then applied to the different candidate cell lists defined from the preferred layer indication, the
PRIORITY(0,n) parameter and the frequency band of the serving cell (only in case of emergency handover).

PBGT Filtering
▼ PBGT filtering : process introduced since B5

l optional, flag EN_PBGT_FILTERING
l filter out cells from the target list

l inhibited for better cell handovers
l based on power budget
l per couple of cells
l was needed for multiband architecture
l PBGT(n) > HO_MARGIN_XX (0,n) + OFFSET_HO_MARGIN_INNER
èHO_MARGIN_XX (0,n) = HO_MARGIN_QUAL (0,n) for cause 2,4

èHO_MARGIN_XX (0,n) = HO_MARGIN_LEV (0,n) for cause 3,5
èHO_MARGIN_XX (0,n) = HO_MARGIN_DIST (0,n) for cause 6
èOFFSET_HO_MARGIN_INNER is only applied when the MS is in the inner zone of a

concentric or multi band cell
èAveraging window is A_PBGT_HO

1.165
▼ 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 : averaging window used for this process is A_PBGT_HO (even for emergency handovers, where handover alarm could
have been raised through A_LEV_HO or A_QUAL_HO samples)

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)
l 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
l FREEfactor are 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)
Cell "n" is kept if :
l AV_RXLEV_NCELL (n) > RXLEVmin (n) + max [0;(MS_TXPWR_MAX(n)-P)]

[dBm]
1.166
▼ 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 :
l 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 TCH in the candidate cells.
l 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 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.
Note : A_PBGT_HO averaging window is used for this process

GRADE Evaluation
▼ GRADE cell evaluation process
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)
l Link_factor (0,n) is an operator parameter to give a bonus/penalty to a cell
l LOADfactor(n) is a weighting factor that takes into account the relative load of
traffic channels in a cell
If EN_LOAD_ORDER = DISABLE or cell n is external to the BSC
GRADE (n) = PBGT(n) + LINK_FACTOR(0,n)
l Cell "n" is kept if :
è AV_RXLEV_NCELL (n) > RXLEVmin(n) + max [0;(MS_TXPWR_MAX(n)-P)]

1.167
▼ LINKfactor(0,n) is a parameter set by OMC command for each cell(n).

▼ LINKfactor(n1,n2) allows the operator to handicap or to favour the cell n1 with respect to its neighbour cell n2. In particular, it
can be used to disadvantage an external cell when an internal cell is also a possible candidate.
▼ For any handover cause the first cell in the list is taken as 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.
Note : A_PBGT_HO averaging window is used for this process

▼ Emergency HO detected
è With the “Candidate
evaluation.xls” excel
sheet...
ü Filtering simulation for a
list of candidate cell
ü Ranking simulation for a
1- Book-keeping list
Time allowed :
15 minutes 1.168

Averaging
2- measurement
?
3- PBGT Filtering
?
4- GRADE evaluation process
?
5- Target Cell
Solution
1.169

PARAMETERS
2.7 Handover Management
1.170
Handover Detection
Handover Management
Case Studies

Principles
▼ Handover Management made up of :
l Cell Filtering Process (according to call history)
l Handover Decision (according to best cell in the list)
▼ Handover Management followed by :
l Handover Protocol
1.171
BTS BSC
HO Preparation
Radio Active
Link HO Candidate
Pre-processing
HO
management
HO
protocol
MSC

Global Handover Process
Handover Preparation Handover Management Handover protocol
Handover Candidate Cell Handover

External or
Detection Cell Filtering Decision Internal
Channel
Evaluation Process change
Raw cell list Ordered target Filtered target Execution target

cell list Cell list Cell list
1.172

Cells Lists usage
▼ Three cell lists :
l Ordered target Cell list

è target cells provided by Candidate Cell Evaluation
l REJ_CELL_LIST
è cells internally rejected by the MSC or BSC
l MS_CELL_REJ_LIST
è cells to which the MS failed to handover
1.173
▼ 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 :
l use of the T_FILTER parameter in a different way than for B5
l the parameter NBR_HO_ATTEMPTS which was used for internal HO in B5 is removed,
l use of the T7 parameter and of the REJ_CELL_LIST list also for internal HO in B7,
l same behaviour in case of internal and external HO in B7,
l immediate attempt after rejection or failure without waiting for a new alarm in case of internal and external HO in B7,
l implicit rejection of cells in B7 with the help of the target cell identity in HO command received from MSC

Timers usage
▼ Three timers :
l 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 Handover Management
l 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
l T_MS_CELL_REJ : clean-up of MS_CELL_REJ_LIST

è started : when a MS reports a failure to seize the target channel
è expiry Þ empty MS_CELL_REJ_LIST
1.174
▼ If the candidate cells 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, this means that the HO is no more necessary.
▼ For both internal and external HO in case of HO failure from 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 HO.

Handover Execution Process
Handover Management Handover protocol
Cell Filtering Handover Internal

Process decision Handover
Ordered target cell Filtered Target cell
list remove cells previously rejected list relevant handover protocol
from MSC or BSC is chosen according to the
cell 4 type of GSM procedure
remove cells previously rejected for ongoing and the first
cell 2 cell 2
MS failure reason target cell of the list
cell 8
External
remove cells not suitable due to
O&M reason
T7 is started Handover
List of cells previously List of cells previously

rejected from MSC or rejected for MS failure
BSC
cell 8
cell 4
MS_CELL_REJ_LIST list
REJ_CELL_LIST list emptied at emptied at T_MS_CELL_REJ
T7 expiry expiry
1.175

Exit from HO Protocol for Internal Handovers
List of cells previously rejected
Next cell is external from MSC or BSC
all rejected cells are added to

Handover management
Handover protocol the REJ_CELL_LIST list
Internal failure on all cells T7 is restarted
List of cells previously rejected for

MS failure
the cell to which the MS failed to Restart

handover is added to the
Cell Filtering
HO FAIL from MS T_MS_CELL_REJ is restarted
Process
Internal Handover and
List of cells previously rejected from Handover
MSC or BSC Decision
the cells which were preferred in
the target cell list are added to the
REJ_CELL_LIST list
T7 is restarted

MS failure
MS_CELL_REJ_LIST is emptied
T_MS_CELL_REJ is stopped
End of HO Execution
Exit and clear
from MSC or BSC
REJ_CELL_LIST is emptied
T7 is stopped
1.176
Note : this algorithm is used so that the list of possible candidate delivered by HOprep can be parsed completely. The following
example highlights well this process :
ordered
▼ Call begins and then a first HO alarm is detected by the BSC. Output of HOprep is 1. Cell1
2. Cell2
3. Cell3
HO prot update
ordered filtered
1. Cell1
2. Cell2
HO
-
Rej.mgt
1. Cell1
2. Cell2
HO fails
on cell1
Cell1 ->
MS
3. Cell3 lists 3. Cell3
rej list
MS BSC/MSC ROC
empty empty
update HO prot update

ordered filtered Cell2 ->
1. Cell1
2. Cell2
HO
-
Rej.mgt
Cell1
1. Cell2
T_MS_CELL
_REJ
HO fails
on cell2
MS
rej list
3. Cell3 lists 2. Cell3 Expires
Cell1 ->
MS BSC/MSC MS rej list ROC BSC
cell1 empty empty rej list
HO prot If cell1 is not

ordered filtered
rejected by the
1. Cell1
2. Cell2
3. Cell3 HO
-
Rej.mgt
lists
Cell1
Cell2
1. Cell3
HO to
cell3
BSC, next HO is
triggered again
Cell1 is
rejected by
to cell 1, and BSC as it is
MS BSC/MSC not cell 3 upper than
cell2 cell1 cell2 in
ordered list

Exit from HO Protocol for External Handovers
from MSC or BSC
Handover management
Handover protocol all rejected cells are added to
the REJ_CELL_LIST list
Reject from MSC T7 is restarted

MS failure
if known the cell to which the MS Restart

failed to handover is added to the
Cell Filtering
HO FAIL from MS T_MS_CELL_REJ is restarted
Process
External and
Handover Handover
List of cells previously rejected from
MSC or BSC Decision
if known the cells which were
preferred in the target cell list are
added to the REJ_CELL_LIST list
T7 is restarted

MS failure
MS_CELL_REJ_LIST is emptied
T_MS_CELL_REJ is stopped
End of HO Execution
Exit and clear
from MSC or BSC
T7 is stopped
1.177

Reaction to Timers and Lists updates during handover
Handover management T7 expiry

from MSC or BSC Handover management
Internal Handover
List of cells previously rejected for Wait for the
MS failure
in progress T_MS_CELL_REJ expiry outcome of
MS_CELL_REJ_LIST is emptied Internal Handover
New target cell list : not empty Stored new target cell list received
from HO candidate cell evaluation
New target cell list : empty

Restart
from MSC or BSC Cell Filtering
T7 expiry
Process and
Handover
Decision
External List of cells previously rejected for
MS failure
Handover T_MS_CELL_REJ expiry
in progress MS_CELL_REJ_LIST is emptied
New target cell list : not empty Stored new target cell list received
from HO candidate cell evaluation
Wait for the

outcome of
Stored empty target cell list
New target cell list : empty External Handover
1.178
Note : see next slide : a new target cell list (not empty) is sent by candidate cell evaluation to HO management each time it is
different from the previous one.

T_FILTER controls HO procedure (1/2)
▼ End of Handover procedure = T_FILTER timer expiry
l T_FILTER restarted each time a target cell list is to be sent

by Candidate Cell Evaluation to Handover Management
(same list than the one previously sent or not)
l target cell list is sent to Handover Management if different

from the last target cell list previously sent
l T_FILTER expiry means no handover is needed anymore
1.179

T_FILTER controls HO procedure (2/2)
New candidate cell list from the

candidate cell evaluation function
No handover is on-going
An handover is on-going
Yes Is No
T_FILTER
running ?
A handover is NOW on-
going
Start T_FILTER
Yes No A HO alarm containing the candidate cell
Is the candidate cell
list is sent to the HO management entity
list different from
the previous one ?
Restart T_FILTER
Restart T_FILTER
A HO alarm containing the candidate cell
list is sent to the HO management entity
T_FILTER is restarted
each time the alarm is
still on
1.180

PARAMETERS
2.8 MS Re-selection algorithms
1.181
Handover Detection
Handover Management
Case Studies

Selection and re-selection principles
▼ At startup (IMSI Attach), MS is selecting cell with

l best C1
l once “camped on” one cell (in idle mode)…
▼ …MS can decide to reselect on another one if

l C1 criteria is too low
l MS cannot decode downlink messages
l current cell is becoming forbidden (e.g. barred)
l MS cannot access to the cell
l there is a better cell, regarding C2 criteria
1.182
▼ Idle mode
l Status null:
mobile station (MS) is off
l Status search BCCH:
MS searches broadcast channel with best signal level (cell selection and reselection)
è BCCH list: up to 36 BCCH frequencies plus BSIC can be saved on SIM per visited network
è Look, if frequencies of BCCH list can be used
è No entries in BCCH list, or location is completely different: scan frequency band
l Status BCCH:
MS is synchronized on a BCCH. The MS camps on a cell
è BTS sends 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
è MS measures RXLEV from BCCH of serving and neighbour cells
è Camping on a cell is performed using C1 criteria only (chosen cell is the one with the best C1)
Ä MS needs to have access to the network
Ä MS needs to be accessible by the network
è Reselection is done using the mechanisms referenced above
Ä ‘handover algorithms’ in idle mode

C1 criteria (1/2)
▼ C1
l ensure that, if a call was attempted, it would be done with a
sufficient downlink and uplink received level
l based on 2 parameters, broadcasted on BCCH
è RXLEV_ACCESS_MIN [dBm]
ü minimum level to access to the cell
è MS_TXPWR_MAX_CCH [dBm]
ü maximum level for MS emitting
1.183

C1 criteria (2/2)
▼ C1
l evaluated every 5 sec (minimum)
l C1 = A - MAX(0,B) > 0
l A = RxLev - RXLEV_ACCESS_MIN
è assess that MS received level is sufficient
l B = MS_TXPWR_MAX_CCH - P
è P maximum power of MS
è assess that BTS received level will be sufficient
è if MS_TXPWR_MAX_CCH < P
l If A > 0 & B < 0 OK, if B > 0, it can be compensated by A
è A >> 0 means that MS is closer to BTS
1.184

C2 criteria
▼ C2
l 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
l One reselection criterion is compared of C2s
è C2neighbour > C2current if cells belong to same LA
è C2neighbour > C2current+Cell_Reselect_Hysteresis if cells from
different LA
1.185
▼ Note :
l - CRO : from 0 to 126 dB, step 2dB
l - PENALTY_TIME : from 1=20s to 30=600s, step : 20s; 31=infinite
l - TEMPORARY_OFFSET : from 1=10dB to 6=60dB; 7 = infinite
▼ Usage of 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 first formula)
▼ First formula is very useful for favouring indoor cell or microcell (see example is S5)
▼ Cell selection and cell reselection considering CELL_BAR_QUALIFY

l in case of phase 2 MS and CELL_RESELECT_PARAM_IND=1, it is possible to set priorities to cells
l CELL_BAR_QUALIFY
è Two values:
Ä 0 = normal priority (default value)
Ä 1 = lower priority
è Interacts with CELL_BAR_ACCESS (barring cell)
l A phase 2 MS selects the suitable cell with the highest C2 (C1>0) belonging to the list of normal priority
l If no cell with normal priority is available then MS would select lower priority cell with highest C2 (C1>0)

Training Exercise (1/2)
▼ On this network example

l List the parameters involved in
selection / reselection process CI=1823
CI=6271
Cell (8557, 1823)

GSM900
GSM900
CI=6270
GSM900
CI=6169
GSM900
Cell (8564,6169) CI=1964

GSM900
Cell (8564, 1964)

Time allowed :
5 minutes Solution
1.186

l Find the selected cell by MS

CI=1823
GSM900 CI=6271
Cell 3
(8557, 1823)
GSM900
CI=6270
GSM900
Measurements RxLev (1) RxLev (2) RxLev (3)
1 -80 -96 -104

2 -84 -90 -100
3 -88 -90 -87
CI=6169
4 -88 -87 -82

GSM900
5 -89 -85 -78 Cell 2 CI=1964

GSM900
(8564,6169) Cell 1
(8564, 1964)
Solution
1.187

l Theoretical presentation
l Radio measurements principles
l Radio measurements data processing
l Radio Link Supervision and Power control
l Handover Detection
l Handover Candidate Cell Evaluation
l Handover Management
l MS Re-selection Algorithms
l Exercises
1.188

PARAMETERS
2.9 Exercise
1.189
Handover Detection
Handover Management
Case Studies

2.9 Exercise
▼ List all the parameters involved in the

detection of cause 23
▼ List all the causes impacted by the
parameter DELTA_INC_HO_MARGIN
Time allowed : ▼ List all the causes impacted by the
10 minutes
parameter L_RXQUAL_UL_H
parameter BS_TXPWR_MAX
parameter BS_P_CON_ACK
1.190

B7
1.191

▼ Objective : to be able to check the radio parameters range and

default values, then localise OMC-R screen
▼ Program:
l 3.2 Guide for ‘Default Radio Parameters’ document
1.192

S5 : CASE STUDIES

1.193
Guide for “Radio Default Parameters” document

Session objectives
▼ SESSION OBJECTIVES
è Check the radio parameters conformity with the default values
▼ JUSTIFICATION
è Tuning a network is not a matter of absolute values but relative
ones.
è Default values have been defined to provide to the radio fine tuning
team reference templates
▼ DETAILED PROGRAM
è ‘Default radio parameters’ (reference: 3DF 01906 271 VAZZA)
document presentation (structure, default values, parameter
description, index...)
è Case studies
1.194

B7
Default Radio
Parameters
3 OMC-R RADIO PARAMETERS B7
3.2 Guide for “Radio Default Parameters”

document
1.195
Guide for “Radio Default Parameters” document

3.2 Guide for “Radio Default Parameters” document
Document structure (1/2)
▼ The parameters list has been split into 11 parts Default

Radio
è Cell description data Parameters

B7
è Cell selection parameters (idle mode)

è Paging, AG Control, RACH
è Radio Resource Management
è Power Control parameters
è Handover parameters
è Dual layer and dual band handover specific parameters
è Concentric cell specific handover parameters
è Directed retry and queuing
è Radio Channel configuration
è Neighbouring cell list
1.196
▼ Cell selection parameters - Highlight on Interference Band measurement function:

l Related to TCH selection function, the BTS has only the task to inform the BSC about the interference bands of the
idle TCHs. This enables the BSC to administer the interference band tables. Interference levels on the radio path,
reported by the physical layer every SACCH multiframe period, are averaged in the BTS for each TCH channel with
an averaging window size of INTAVE. The channel is then reported to be in one of the five defined interference
bands, corresponding to the averaged dBm value.
l The BTS will only report one measurement for each idle dual rate timeslot, if one half of the dual rate timeslot is in use
as a half rate channel, then a measurement is reported for the idle half channel.
l The result is packed into the RF RESOURCE INDICATION message, which contains the free channels and the
related interference bands.
l The start point for sending the first RF RESOURCE INDICATION message at BSS initialisation must be spread
among the different TRX (pseudo random) to avoid over-flowing the BSC with a burst of messages in a short time
frame. This pseudo random starting time (generated in the BTS) is based on the BCC and TEI.
l After the first RF RESOURCE INDICATION has been sent, the RF RESOURCE INDICATION message is sent
periodically based on the expiry of timer T_INTRF_L3. As soon as this timer expires, it is restarted (cyclic).INTAVE is
the timer used for the averaging of the idle channel measurements, it is based on a multiple of a SACCH multiframes.
It is a requirement that INTAVE is always smaller than T_INTRF_L3.
l The RF RESOURCE INDICATION message contains the idle TCH channels and the corresponding interference
bands. Five bands are defined, denoted X1, X2, X3, X4 and X5 where X1 contains the channels with the lowest and
X5 with the highest measured interference levels, i.e. : the band X1 contains the list of available TCH channels
reporting the lowest levels of interference and thus can be considered as the best available TCH channels whilst the
band X5 can be considered to contain the worst quality available channels.
l The interference measurements are graded into the five bands X1...X5 according to the interference band thresholds
set by the O&M parameters INTFBD1...INTFBD5. These interference measurements are always reported to the BSC
as the flag allowing this report, BTS_EN_RF_RES_IND, is set to ENABLE and it is not reachable by operators

Document structure (1/2)
▼ Each chapter handles one category of parameters. Default

Radio
▼ The structure of each chapter is identical:

Parameters
B7
è First spreadsheet: Reminds

ü Definitions associated to every presented parameters
ü Their range
ü The OMC screen in which it can be found and/or modified
è Second spreadsheet:
ü Recommended values for GSM 900
è Third spreadsheet: if the case arises
ü Recommended values for GSM 1800
1.197

▼ Check with the ‘Default Radio Parameters’ document if the values Default
Radio
implemented at OMC-R are correct Parameters
B7
Parameter Value at OMC-R Default value? If NO, what is the

correct value
POW_RED_STEP_SIZE 5 dB
A_LEV_HO for rural 8
HO_MARGIN_LEV(0,n) 4dB
U_RXLEV_DL_P -85dBm
CELL_RESELECT_OFFSET 10 dB
Cause_margin_G3 -3dB
A_RANGE_HO for urban 5
A_PBGT_DR 4
L_RXQUAL_UL_H 2
Time allowed :
Solution
10 minutes 1.198

B7 Training exercise (2/2)
▼ Check if the parameters listed below are OMC-R Default
parameters or internal system parameters : Radio

Parameters
B7
Parameters OMC-R Internal System

EN_CAUSE_28
EN_FAST_TRAFFIC_HO
THR_RXQUAL_CAUSE_15
L_RXQUAL_UL_H_AMR
EN_CAUSE_16
EN_INTRA_DL_AMR
THR_RXQUAL_CA
OFFSET_CA_HIGH
THR_RXQUAL_CA_NORMAL
OFFSET_CA
Solution
Time allowed :
10 minutes 1.199

B7
1.200

4 ALGORITHMS DYNAMIC BEHAVIOR
▼ Objective : to be able to Estimate qualitatively the impact of

parameters change
▼ Program:
l 4.2 Examples and exercises
1.201

S5 : CASE STUDIES

1.202
Examples and Exercises

Session objectives
è Be able to estimate qualitatively the impact of a parameter change
▼ JUSTIFICATION
è Tuning is not an exact science

è The optimiser 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
è Three Example/Exercises
1.203

B7
4.1 Examples and Exercises
1.204
Examples and Exercises

Overview
▼ Example 1: Optimisation of handover algorithms
l Sliding averaging window
▼ Example 2: Optimisation of power control algorithms
l Sliding averaging window
▼ Example 3: Traffic load sharing
l Parameters qualitative influence
1.205

Example 1 : Optimisation of Handover Algorithms (1/4)
▼ Search for best tuning of HO parameters to decrease

call drop
Call drop
HO/Call
1.206

▼ Main Objective: make the HO algorithm as efficient as

possible
l Minimize call drop rate
è trigger HO soon enough
è toward the “best” neighbour
l while keeping a good speech quality
è avoid HO due to quality : “too late”
è avoid to have HO/call rate too high
1.207

▼ Method
l Collect Abis trace chart
l Search for HO level to avoid quality
lower than 4 (or even 3)
è sufficient number of “bad 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
samples 5
3
5
è low standard deviation

2 2
1 1
0 0
è problem when HO already

N b_ s a m p le s N b_ sa m ple s
600 100 0
80 0
400 60 0
200 40 0
activated
20 0
0 0
S ta n d a r d D e via ti o n S t a n d a r d D e via ti o n
2 3
1 .5
2
1
1
0 .5
0 0
▼ Then tune according QoS indicators (OMC-R) by repetitive process

l A_PBGT_HO/A_LEV_HO/A_QUAL_HO
l L_RXLEV_UL_H, L_RXLEV_DL_H, L_RXLEV_UL_P,
L_RXLEV_DL_P
l OK as soon as HO success rate stabilized
1.208
▼ 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 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

▼ Neighbouring relationship clean-up
l Remove useless relationships (A interface statistics, PM Type 180)
l Remove common BCCH/BSIC couple
l Add new relationships when new site is created
▼ Finally, check main QoS indicators

l Call drop rate
l HO failure rate
l HO/call rate
1.209

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
Level at RxQual=3 -80dBm -96dBm -90dBm

Time allowed :
L_RXLEV_DL_H -85dBm -90dBm -90dBm
5 minutes
A_QUAL_HO 6 6 ?
A_LEV_HO ? ? 4
Solution
1.210

Example 2 : Optimisation of Power Control Algorithms (1/2)
▼ Optimisation of Downlink Power Control

è Decrease of downlink interference
è Risks of delay of HO (without fast power control)
▼ Optimisation of Uplink Power Control

è Decrease of Uplink interference
è MS battery saving
è Risks of delay of HO (without fast power control)
1.211

Example 2 : Optimisation of Power Control Algorithms (2/2)
▼ Main tuning problem is interaction with handover, which can

slow down HO decision, and debase call drop rate
l Power control threshold must be within HO ones
l Dynamic step size must be activated if possible
1.212
▼ In the example below, 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

Example 2 : Training Exercise
▼ Explain qualitatively the impacts of some parameter changes
Action Qualitative “Only quality Fixed or dynamic

Impact problem” Impact? step size?
1 A_QUAL_PC
2 A_LEV_PC
3 POW_INC_FACTO
R
4 MAX_POW_INC
Time allowed :
5 minutes
1.213

B7 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 – New in B7
è 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
1.214

▼ Fast Traffic HO
l Useful in case of sudden traffic peaks as the process
response is instantaneous (no average window)
l The principle is to force handover towards neighboring cells
which have lower traffic when a request is queued in the
serving cell.
l Interaction with Forced DR due to the use of same
thresholds
l Optimization method (repetitive process)
è Tunes L_RXLEL_NCELL_DR(n), FREElevel_DR(n)
è Applies new values, checks traffic peaks, QoS
indicators
1.215

▼ The Pros and the cons of Fast Traffic HO

è Efficiency depends on
ü traffic location in the loaded cell
ü capacity of neighbor cells
➘ increase of the number of HO/call
➘ increase of incoming HO 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)
➚ Adapted to instantaneous traffic modification
➚ can be used to send traffic towards a cell external to
the serving BSC
➚ adapted to hierarchical network, but also to standard
ones
1.216

Example 3 : Traffic Load Sharing (4/12)
▼ DELTA_HO_MARGIN (0,n)
▼ CHANGE DYNAMICALLY TRAFFIC DISTRIBUTION WITH HO:
l Traffic HO Cause 23
è Ease out-going better condition HO on a traffic point of
view
l Slow down outgoing better cell HO (to be tuned for given
couple of cells)
è When the better cell in radio condition is the worst cell
in traffic terms
l Optimisation method (repetitive process)
è Tunes DELTA_DEC_HO_MARGIN and
DELTA_INC_HO_MARGIN
è Applies new values, checks traffic, QoS indicators and
possibly speech quality
1.217

▼ The Pros and the cons DELTA_HO_MARGIN (0,n) method

è Efficiency depends on
ü traffic location in the loaded cell
ü cells overlap
ü capacity of neighbour cells
➘ increase the number of HO/call
➘ cannot be used to send traffic toward a cell external to
the serving BSC
➘ call has to first be established on loaded cell, before
being “exported”
ü they can be rejected
➚ Easy to tune (dynamic process)
➚ Adaptability to instantaneous and long term traffic
modification
1.218

▼ HO_MARGIN / LINK_FACTOR
▼ CHANGE STATICALLY TRAFFIC DISTRIBUTION WITH HO:
l Ease outgoing better cell HO (to be tuned for given couple of cells)
è Decrease HO_MARGIN (can make a cell “candidate”)
è Increase LINK_FACTOR (used to rank candidate cells)
l Optimisation method (repetitive process)

è Look for neighbour cells able to carry extra traffic
è Use Abis trace to check if these cells are candidate
ü if yes, use LINK_FACTOR to favour them
ü if not, use HO_MARGIN and LINK_FACTOR
è Apply new values, checks traffic, QoS indicators and possibly
speech quality
1.219

▼ The Pros and the cons LINK_FACTOR/HO_MARGIN method

è can be efficient (up to 20% increase of capacity) in
some cases
ü cell overlap
ü capacity of neighbour cells
➘ increase the number of HO/call
➘ call has to first be established on loaded cell, before
being “exported”
➘ they can be rejected
➘ heavy to tune (has to be done for each couple of cells)
➘ no adaptability to instantaneous and long term traffic
modification
➚ can be used to send traffic toward a cell external to the
serving BSC
1.220

▼ FREE_FACTOR/LOAD_FACTOR
▼ Taking into account current load of cells, send MS toward the less
loaded with HO
l Ease outgoing better cell HO, according to
è Load_Factor (% of TCH occupancy) of serving and “target” cell
è Free_Factor (number of free TCH) of serving and target cell (order
only)
è cannot make a “candidate” cell, only change ranking
l Tuning method (repetitive)

è to be activated locally for each cell with default parameter setting
è looks for QoS indicators (esp traffic intensity and blocking rate)
è tunes tables accordingly
1.221

l Pros and cons of load/free factors method

➘ Lower efficiency compared to
LINK_FACTOR/HO_MARGIN
➚ No increase of HO/call rate
➘ Call have to be established on loaded cell before being
“exported”
➘ Tuning is done cell per cell
➘ Cannot be used to send traffic toward external cell
➚ Adapted to dynamic change of traffic and capacity (for
Load_Factor)
1.222

▼ Forced directed retry method

l Mechanisms
è MS is connected on a 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 MS
ü enough free TCH
è the MS is handed over to TCH towards this cell
ü if there are several cells, the one with the best PBGT is
selected
1.223

▼ Optimisation method : trade-off between traffic and radio quality

è mainly L_RXLEV_NCELL_DR(n) parameter to tune
ü the lowest, the better the traffic sharing
ü the lowest, the higher the interference risks
è QoS indicators and field tests (speech quality) are
necessary for tuning
cell 1 : 24
cell 2 : 45 cell 3 : 23
1.224
▼ Forced directed retry

l The following condition is checked every measurement reporting period and if at least one input pre-processed
parameter AV_RXLEV_NCELL_DR(n) is available.
è CAUSE = 20 (high level in neighbour cell for forced directed retry)
Ä AV_RXLEV_NCELL_DR(n) > L_RXLEV_NCELL_DR(n) (n = 1 ... BTSnum)
è and EN_FORCED_DR = ENABLE
l The threshold L_RXLEV_NCELL_DR(n) is the observed level from the neighbour cell n at the border of the area
where forced directed retry is enabled. This threshold fixes the size of the overlapping area where forced directed
retry can be performed. It should be greater than RXLEVmin(n).

▼ Pros and cons of Forced directed retry
➚ highest efficiency (up to 30%)
➚ no increase of HO/call rate
➚ can be used to send traffic toward external cell
➚ adapted to dynamic change of traffic
➚ adapted to hierarchical network, but also to standard

ones
➘ tuning is done cell per cell
1.225

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
Loaded cell 0 Unloaded cell n
PBGT(0)=PBGT(n)=
Cause 12 Cause 12
0
EN_TRAFFIC_HO = 0
PBGT(0) = 5 PBGT(n) = 5
Time allowed : Solution
5 minutes
1.226

B7 Example 3 : training exercise (2/3)
▼ What happens when EN_FAST_TRAFFIC_HO = ENABLE

and EN_TRAFFIC_HO(0,n) = DISABLE
PBGT(0)=PBGT(n)=0
Queued Ass Req Av_Rxlev_Ncell(n) = -82dBm Av_Rxlev_Ncell(0) = -74dBm
Av_Rxlev_PBGT_HO = -82dBm
L_RLEV_NCELL_DR(n) = -85dBm
PBGT(0) = 5 PBGT(n) = 5
5 minutes
1.227

B7 Example 3 : training exercise (3/3)
▼ What happens when EN_FAST_TRAFFIC_HO = ENABLE and

EN_TRAFFIC_HO(0,n) = ENABLE
Queued Ass Req

Av_Rxlev_Ncell(0) = -74dBm
Av_Rxlev_Ncell(n) = -82dBm
PBGT(n) = -1
PBGT(0) = 9
PBGT(0) = 5
5 minutes
1.228

5 CASE STUDIES
1.229

5 CASE STUDIES
Session presentation
▼ Objective : to be able to propose a set of parameters to solve

typical radio problems
▼ Program:
l 5.2 TUNNEL Case
l 5.3 RADAR Case
l 5.4 TOWER Case
l 5.5 RESURGENCE Case
l 5.6 FOREST Case
l 5.7 HIGHWAY Case
l 5.8 TCH/SDCCH CONGESTION Case
1.230

S5 : CASE STUDIES

5 CASE STUDIES
1.231
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case
TCH/SDCCH CONGESTION Case

Session objectives
è Be able to propose an appropriate set of parameters to solve

typical field problems
▼ JUSTIFICATION
è Some typical problems due to particular field configuration always

occur in a GSM network.
è Seven typical case studies
1.232

5 CASE STUDIES
5.2 Tunnel Case
1.233
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.2 Tunnel Case
▼ Radiating cable in a tunnel

l Question:
è Risks of such a configuration
è tune the right parameters for the tunnel cell
ü catch quickly ‘car traffic’
ü avoid the pedestrian traffic
‘Indoor
BTS’ Radiating Tunnel
cable
Repeater
Outdoor
Pedestrian
BTS
mobile
1.234

5 CASE STUDIES
5.3 Radar Case
1.235
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.3 Priority Case
▼ Radar situation
l A “radar” cell situated on top of a hill provides a wide coverage area.
l An industrial zone in the valley is covered by small cells but also by the
“radar” cell. The serving areas in the IZ are not clearly defined.
▼ Objective
l Give a parameter set to prevent the radar cell from catching any traffic
in the industrial zone by HO assignment
1.236

5 CASE STUDIES
5.4 Tower Case
1.237
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.4 Tower Case
▼ Tower situation
l The indoor mobile selects in idle mode the outdoor cell (same LA)
▼ Objective Indoor
Antenna
l Define a set of parameters to avoid that effect
BS1
1.238

5 CASE STUDIES
5.5 Resurgence Case
1.239
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.5 Resurgence Case
▼ Resurgence situation
l In rural network, especially in hilly landscape, many resurgences occur
from very far cells.
▼ Objective
l Define a set of parameters to avoid radio link establishment to those
cells and TCH traffic on those cells
Cell A
Cell B
Resurgence
from cell A
25 km
1.240

5 CASE STUDIES
5.6 Forest Case
1.241
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.6 Forest Case
▼ Forest situation: A highway crosses a forest

l High call drop rate (radio cause) on the cell and drive tests: strong level
attenuation at the entrance of the forest
▼ Objective
l Define a set of parameters to avoid radio link failure
Forest
ATT=10dB every 100m
-75dBm -90dBm
Highway
BTS
1.242

5 CASE STUDIES
5.7 Highway Case
1.243
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.7 Highway Case
▼ Highway situation:
l A highway is slightly covered (best coverage on 200m) by an
‘orthogonal’ cell (cell C on the map)
▼ Objective
l Define a set of parameters to avoid traffic in the ‘orthogonal cell’
Cell C
Cell B
Cell A
1.244

5 CASE STUDIES
5.8 TCH/SDCCH congestion case
1.245
TUNNEL Case
RADAR Case
TOWER Case
RESURGENCE Case
FOREST Case
HIGHWAY Case

5.8 TCH/SDCCH Congestion Case
▼ SDCCH congestion situation

l A railway station is located at the frontier of two LA. Every train
stopping in this station come from LA 1 and then return to LA 1
after the stop.
▼ Objective
l Define a set of parameters to avoid SDCCH congestion on cell B
(LA 2)
Cell B Cell A
LA2 LA1
LA frontier
1.246

END SESSION
1.247

ANNEXES
1.248
TYPICAL MODULE STRUCTURE

objective(s)
theoretical presentation
training exercises and/or cases study + feedback

ANNEXES
Annex.1 Erlang B law
1.249
Erlang B law
Frequency hopping influence on PCHO process
Load & Traffic evaluation
Training exercises solutions

Erlang definition
▼ ERLANG : unit used to quantify traffic
l T = (resource usage duration)/(total observation duration) [ERLANG]
l Example :
è 1 TCH is observed during 1 hour
è one can observe 1 call of 80 sec and 1 call of 100 sec
è observed traffic is T = (80+100)/3600 = 0,05 ERLANG
1.250

Call mix definition
▼ ERLANG <-> CALL MIX
l CALL MIX EXAMPLE

è 350 call/hour
è 3 LU/call
è TCH duration : 85 sec
è SDCCH duration : 4,5 sec
l ERLANG COMPUTATION
è TCH = (350 * 85)/3600 = 8,26 ERLANG
è SDCCH = [ (350 + 350*3) * 4,5 ] / 3600 = 1.75
ERLANG
1.251
▼ 350 calls * 85 sec / 1 hour(3600 sec) :

l TCH = (350 * 85)/3600 = 8,26 ERLANG
▼ 350 calls means 350 SDCCH phases

▼ 3 LU/call means 3 * 350 LU so 1050 SDCCH phases more
▼ 1 SDCCH phase is 4.5 sec :
l SDCCH = [ (350 + 350*3) * 4,5 ] / 3600 = 1.75 ERLANG

Erlang B (1/5)
▼ ERLANG B LAW
l relationship
between
è offered traffic call/se cond
call/se cond
10
è number of
10
9
9
resources 8
8
è blocking rate
7
7
6
6
5
5
4
4
▼ In a telecom system, 3
2
3
call arrival frequency is

2
1
1
ruled by POISSON LAW 0

1
13
17
21
25
29
33
37
41
45
49
53
57
61
65
69
73
77
81
85
89
93
97
0
1
13
17
21
25
29
33
37
41
45
49
53
57
61
65
69
73
77
81
85
89
93
97
1.252
▼ Offered traffic is the traffic asked by the customers.
▼ The graph give the number of connection request each second during 35 seconds
▼ 83/30s => 83 * 2 * 60 = about 10 000 / hour
▼ Real example in Paris on 1 BSC (LA FOURCHE)

Erlang B (2/5)
▼ call request arrival rate (and leaving) is not stable

l number of resources = average number of requests * mean
duration
l is sometime not sufficient => probability of blocking
▼ => Erlang B law

l Pblock : blocking probability E
N
N!
P b lo c k =
l N : number of resources E
k
å
N
k =0 k!
l E : offered traffic [Erlang]
l good approximation when blocking rate is low (< 5 %)
1.253

Erlang B (3/5)
▼ There is two different ways to use this law
l Using Abacus
l Using SW (here Excel)

è Pblock = f ( T , Nc )
è Offered = f ( Nc, Pblock )
è Channels = f ( T, Pblock )
1.254

Erlang B (4/5)
▼ Example :
We have a BTS of 8 TRX (about 60 channels (Nc))
We do not want more than 2% blocking (Pblock)
=> The traffic is not to be greater than 50 Erlang (T)
l 83% resources used to reach 2% blocking
1.255

Erlang B (5/5)
▼ But be careful, the law is not linear :
▼ In B4 we use for example a combined BCCH with a micro BTS.

4 SDCCH, Pblock = 2% => T = 1.1 E
25% resources used to reach 2% blocking
▼ In B5 if we decide to provide SMSCB (Cell Broadcast

information)
1 subchannel SDCCH is therefore used.
3 SDCCH, Pblock = 2% => T = 0.6 E
25 % resources less => 50 % Traffic less !!
1.256

Cell dimensioning (1/5)
▼ CELL DIMENSIONING
l Given an Offered traffic, compute the number of TRX (and

SDCCH) needed to carry it
l default blocking rate

è RTCH : 2 %
è SDCCH : 0,5 %
è (TTCH : 0,1%)
1.257

▼ CELL DIMENSIONNING
l to handle an offered traffic of 12 Erlang (TCH), compute the

number of channels, then the number of TRXs
l Channels (12;2%) = 19
l example : 3 TRX , 21 TCH, 1 BCCH, 2 SDCCH8
1.258

▼ CELL DIMENSIONNING, based on field measurement
l one is measuring a traffic of 15 Erlang, with a blocking rate

of 10 %
l how to dimension the cell ?
l Offered traffic = 15 / (1-10%) = 16,7 Erlang !!!!

l Channels (16,7;2%) -> 25 TCH -> 4 TRX needed
1.259

▼ FORECASTING TRAFFIC/CRITICAL TRAFFIC
l traffic forecasting must be calculated according to offered

traffic
✭ not directly on measured traffic
l In order to plan necessary actions soon enough, one must

calculate regularly the date when the traffic of a cell will
become critical
l critical traffic : when offered traffic will induce 2% of blocking
1.260

▼ WARNING : IN CASE OF TOO HIGH BLOCKING RATE
l FIRST CHECK THAT THERE IS NO OUTAGE ON THE

BTS
l BEFORE STARTING A DIMENSIONNING/TUNING

ACTION
1.261

Training exercise
▼ TRAINING EXERCISE
Complete this form in order to get less than 2% blocking in all cases.
cell call mix info Erlang TCH traffic forecast proposed config
Offered traffic
12, 743 450 call/hour 10,08 Erlang TCH 30 % offered traffic 13,1 Erlang TCH - > 20 TCH
mean TCH call duration : 80 increase 3 TRX
sec
blocking rate TCH : 0.8%
12,675 330 call/hour 30 % offered traffic

mean TCH call duration 129 increase
sec
blocking rate 4%
12,865 600 call/hour 30 % offered traffic
mean TCH call duration 96 increase
sec
blocking rate 8 %
Back
1.262
cell call mix info Erlang TCH traffic forecast proposed config
12, 743 450 call/hour 10 Erlang TCH 30 % TCH increase 13,1 Erlang TCH - >20
mean TCH call 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 % TCH increase 16 Erlang TCH ->24 TCH
mean TCH call 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 % TCH increase 22.6 Erlang TCH ->31 TCH
mean TCH call duration 96 =16/.92 =17.4
sec 17.4*1.3 =22.6 5 TRX
blocking rate 8 %

ANNEXES
Annex.2 Frequency Hopping influence on

PCHO process
1.263
Erlang B law

Annex.2 Frequency Hopping influence on PCHO process
(1/4)
▼ Signal decoding process

l In a GSM system, the number of frames that are not erased
are sent as an input to the voice decoder
Frame Voice
DECODER Deinterleave Erasure
DEMOD Decoder
Error correct. Decision
- ENCODER
RXQUAL Frame Erasure Rate
Air Inside the mobile station
1.264

(2/4)
▼ Quality impact of frequency hopping on the reception chain
l In non hopping networks the RXQUAL and voice quality are
correlated
l In hopping networks, the voice quality is sooner correlated
to the FER. This is due to interferer averaging and due to
the non-linear mapping of BER to RXQUAL values.
1.265

(3/4)
▼ Quality impact of frequency hopping on the reception chain

l FER is improved when frequency hopping is activated
(cyclic or random)
l RxQual is not impacted whereas the speech quality is better
Moyenne (RxQ & FER) RxQ Moy

Moy FER
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%
Cycli
Ref
Random
1.266

Conclusion (4/4)
▼ Conclusion
l When frequency hopping is activated
l We can accept in Power Control and Handover
processes, a threshold increase:
è OFFSET_HOPPING_PC and
è OFFSET_HOPPING_HO
Back
1.267

ANNEXES
Annex.3 Load & Traffic evaluation
1.268
Erlang B law

Cell TCH radio resource evaluation usage
Load evaluation Period Usage

short term TCH_INFO_PERIOD FREEfactors
LOADfactors
medium term LOAD_EV_PERIOD x TCH_INFO_PERIOD Speed discrimination for hierarchical network
Full Rate / Half Rate channel allocation
long term N_TRAFFIC_LOAD x A_TRAFFIC_LOAD x TCH_INFO_PERIOD Power budget Handover
Traffic Handover
Multiband capture Handover
General capture Handover
Back
Cause 12
Back
Cause 26
1.269

Load evaluation (1/5)
▼ medium term measurement of the load of a cell

l corresponds to function AV_LOAD(cell)
l a new sample of the “Nb free TCH” in the cell is available
every TCH_INFO_PERIOD seconds
l AV_LOAD() is a non sliding window load average from Nb
free TCH samples updated every LOAD_EV_PERIOD x
TCH_INFO_PERIOD sec
1.270

▼ AV_LOAD(cell n) calculated from N Nb free TCH samples

available during LOAD_EV_PERIOD x TCH_INFO_PERIOD sec
Nsamples
1 Nb free TCH (n)
AV_LOAD(n) =
Nsamples
å
i =1
(1 −
Nb Tot TCH (n)
) * 100
l LOADfactors and FREEfactors also determined from Nb

free TCH samples every TCH_INFO_PERIOD seconds
(short term evaluation)
l LOADlevels are boundaries of load intervals associating a
LOADfactor (db) to a Nb free TCH sample
l FREElevels are boundaries of Nb free TCH intervals
associating a FREEfactor (db) to a Nb free TCH sample
1.271

▼ LOADfactor determination :
t = (1 - Nb free TCH/Total Nb TCH) x 100 LOADfactor

t <= LOADlevel_1 LOADfactor_1
LOADLevel_1< t <= LOADlevel_2 LOADfactor_2
LOADLevel_4< t LOADfactor_5
l LOADlevel in %
l LOADfactor in dB
1.272

▼ FREEfactor determination :
Nb free TCH FREEfactor

t <= FREElevel_1 FREEfactor_1
FREELevel_1< t <= FREElevel_2 FREEfactor_2
FREELevel_4< t FREEfactor_5
l FREElevel in absolute number of TCH

l FREEfactor in dB
1.273

▼ example : cells with 4 TRX (28 TCH)
Nb free TCH FREEfactor Load = (1-Nb free TCH/Total TCH)x 100 LOADfactor
t <= 3 - 16 dB t <= 10% +10 dB
3 < t <= 8 - 8 dB 10% < t <= 25% +5 dB
8 < t <= 15 0 dB 25% < t <= 50% 0 dB
15 < t <= 21 +7 dB 50% < t <= 80% -10 dB
21 < t +10 dB 80% < t -15 dB
Nb free TCH = 4 Nb free TCH = 20

Load = 85,7% HO ? Load = 28,6%
ò Cell 0 Cell n
ò
FREEfactor(0) = -8 dBm FREEfactor(n) = +7 dBm
LOADfactor(0) = -15 dBm LOADfactor(n) = 0 dBm
in cell evaluation of cell n for outgoing HO from cell 0 :

• in ORDER(n) : + FREEfactor(n) - FREEfactor(0) = +7 - (-8) = +15 dB
• in GRADE(n) : + LOADfactor(n) = +0 = 0 dB
1.274

Traffic evaluation (1/4)
▼ long term measurement of the load of a cell

l corresponds to function Traffic_load(cell)
l Traffic_load() value is determined from a number
N_TRAFFIC_LOAD of consecutive non sliding window load
averages AV_TRAFFIC_LOAD calculated from Nb free TCH
samples updated every A_TRAFFIC_LOAD x
TCH_INFO_PERIOD sec
1.275

l 3 possible values for Traffic_load() : high, low, indefinite

l initialisation : Traffic_load() = indefinite
l Traffic_load() becomes :
è high if the last N_TRAFFIC_LOAD consecutive
AV_TRAFFIC_LOAD load averages are all greater
than HIGH_TRAFFIC_LOAD threshold
è low if the last N_TRAFFIC_LOAD consecutive
AV_TRAFFIC_LOAD load averages are all lower
than LOW_TRAFFIC_LOAD threshold
1.276

l 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%)
l Traffic_load(n) is always equal to indefinite if cell n is
external to BSC
l HIGH_TRAFFIC_LOAD ≥ IND_TRAFFIC_LOAD ≥
LOW_TRAFFIC_LOAD
1.277

▼ Example with N_TRAFFIC_LOAD = 3
1.278

Cell TCH radio resource evaluation usage
Back
Cause 12
Back
Cause 26
1.279

ANNEXES
Annex.4 Training exercises solutions
1.280
Erlang B law

S1. Typical Radio Problems
Unbalanced Bad Coverage I nterferences TCH

Power Budget Congestion
High ratio of UL QUAL HO
cause
Good RXLEV and
Bad RXQUAL
Alarm VW SR (OMC-R)
(Voltage Standing W ave Ratio)
Bad RXLEV and
Bad RXQUAL
High Path-loss difference DL> UL
between UL and DL
Low incoming HO success TCH Congestion
rate rate
OMC QOS indicators: Path loss No netw ork Low HO success rate
% TCH failure high VWSR Low prop Better cell DL/UL Qual HO
UL Qual HO High % DL Qual HO Interference HO
% call drop high
% QUAL HO Adjacent
% call drop Co-channel
% call failure
1.281
Action:
▼ 1/ Qualification team:
l Before sending a team: check if the problem is specific to one TRX or to the whole cell
è If the whole BTS is concerned: Problems on aerial, TMA, diversity chain...
è If only one TRX is concerned: RF cable (badly screwed), ROS problem
▼ 2/ Planning team
l Identify the interference source
l Use a joker (often kept by the planning team for punctual problem) or change the frequency plan (use Synthesised FH...)
l If there is nothing to do with the planning (too tight frequency plan), use SW solution (artificial and dangerous): Concentric Cells,
modify the serving areas with the parameters (HO_Margin, Link_Factor...)
▼ 3/ Qualification team
l Alarm problem (detected by the fault management team)
l Send a team on the field to solve this material problem
▼ 4/ Planning team and/or deployment team
l If the coverage hole is visible on the RNP prediction, ask deployment team to add a site at the right place (detect the traffic location:
hotspot detector, RACH catcher, Dummy BTS...)
l If the coverage hole has not been predicted, check if the aerials configuration, the power BTS configuration match the planned
configuration (if not, send a team to adjust azimuth, tilt... On the field)
▼ 5/ Qualification team
l Obviously a problem to be solved on the BTS (aerials, cable... cf.n°1)
▼ 6/ Traffic team
l Check if TRX extension is considered quickly, or a densification policy planned in the area.
l If nothing is planned, activate SW solutions: Forced Directed Retry, Traffic Handover. BUT, be careful because this is an artificial
solution, the RADIO always takes its revenge!!
▼ 7/ Investigate to deduce the real problem (PBGT, Coverage, Interf...)
l Cf. N° 1, 2 or 4
▼ 8/ Planning team
l BUT, be sure that it is really an interference problem (it might be a BSS problem, a deficient DT16, TCU card, switch card...)
l Then report to n°2

S2.2 Measurements principles
The risk is that the correspondence table implemented at OMC is

wrong and a distant cell with the same (BSIC, BCCH) couple can
be seen as the cell associated to the measurement results.
The BSC can trigger a HO toward this cell whereas the
measurements are not the target cell measurements.
OR 2 (BSIC, BCCH) couple are identical or similar : (BSICn,

BCCHn) = (BSICm, BCCHm). The BSC can decode (BSICn,
BCCHn) as (LACm, CIm) and trigger an HO toward the wrong
cell.
Back
1.282

S2.3 - Measurements averaging
Back
1.283
▼ Fill up the table with average function.

▼ The chart will be automatically processed

S2.4 - Radio Link Supervision
Back
1.284
▼ RLR happens once. Parameters

N_NSTXPWR_MAX 13
▼ RFL never happens. RLTO_BS 18
BFI S Action
0 18
0 18
1 17
0 18
0 18
0 18
1 17
0 18
1 17
1 16
1 15
1 14
1 13 RADIO LINK RECOVERY
1 12
1 11
0 13
1 12
1 11
1 10
0 12
1 11
1 10
1 9
1 8
1 7
1 6
1 5
0 7
1 6
0 8
1 7
1 6
1 5
1 4
1 3

S2.4 - Power Control
RxQual
2 3
1
2
5
3
6
4
-90 -86 -75 Lev
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 -90
Power control
MS_P_INC or RED 10dB 4dB 6dB 6dB - 6dB
Back
1.285
▼ Target_RXLEV_value= -90-75/2= -82,5 dB
▼ 1/ Too bad Level and sufficient quality:

l MS_P_INC = roundup[ POW_INC_FACTOR* (TARGET_RXLEV_UL -AV_RXLEV_UL_PC)] = 0,6*(-82,5+98)
= roundup(9,3 dB)=10dB
l Check with MAX_POW_INC : as MAX_POW_INC =8dB, increase is 8 dB
▼ 2/ Too good quality and sufficient level

l MS_P_RED = POW_RED_STEP_SIZE = 4 dB
▼ 3/ Too good level and sufficient quality

l MS_P_RED = roundup[ MAX(POW_RED_FACTOR* (AV_RXLEV_UL_PC- TARGET_RXLEV_UL)), 2dB]
= roundup(5,7)= 6 dB
▼ 4/ Problem of quality and high level

l MS_P_INC = POW_INC_STEP_SIZE = 6dB
▼ 5/ No PC triggered
▼ 6/ Problem of quality and high level (no level pb, level =-90dBm)
l MS_P_INC = POW_INC_STEP_SIZE = 6dB

S2.4 - Power Control
l Using the Trace Abis Excel file, find each parameter value :
POW_INC_STEP_SIZE = 6 dB BS_P_CON_INT = 1s
POW_RED_STEP_SIZE = 2 dB OFFSET_RXQUAL_FH = 1
l Which phenomenon can you observe as regards the successive
PC commands ?
è We can observe a PC ping-pong effect
ü A increase PC command is triggered because of
bad quality and just after a decrease PC command
is triggered because of too good level
è Most of samples present bad RxQual with good RxLev
è Solution : tune L_RXLEV_DL_P and U_RXLEV_DL_P
Back
1.286

S2.5 - HO Detection
HO Cause 2 Recall :
èAV_RXQUAL_UL_HO > L_RXQUAL_UL_H +

OFFSET_RXQUAL_FH
è and AV_RXLEV_UL_HO <= RXLEV_UL_IH
èand MS_TXPWR = min (P, MS_TXPWR_MAX)
1.287

S2.5 - HO Detection
Complete the diagram then fill in the chart:
N b o f c a se - - - > 1 2 3 4 5 6
A V _R XQ U A L_U L_H O 4 1 3 4 4 4
QUAL
A V _R XLEV _U L_H O - 81 - 79 - 75 - 70 - 69 - 72
3
Pow er m ax of M S 33 33 33 33 33 29
(0 ,8 w )
H O ca u se 2 : Y ES/N O ? YES NO NO YES NO W A IT PC
LEV
-70
Back
1.288

S2.5 - HO Detection
▼ Better condition causes

Recall
PBGT(n) = AV_RXLEV_NCELL(n) - AV_RXLEV_PBGT_HO a

- (BS_TXPWR_MAX – AV_BS_TXPWR_HO) b
- (MS_TXPWR_MAX(n) – MS_TXPWR_MAX) c
- PING_PONG_MARGIN(n, call_ref) d
1.289

S2.5 - HO Detection
▼ Better condition causes (simple case)

è What does it mean if there is only 2W cells c=0
è What happens if DL_PWC is disabled b=0
è No Ping-Pong margin d=0 Ncell
è HO_MARGIN(0,n)=5 dbm
Serving cell
Fill in the chart:
Nb of case ---> 1 2 3 4 5 6
MS
AV_RXLEV_NCELL(n) - 70 - 70 - 80 - 70 - 70 - 75
AV_RXLEV_PBGT_HO - 80 - 70 - 75 - 75 - 79 - 96
PBGT(n) « a » only 10 0 -5 5 6 21
PBGT > HO margin
Back
1.290

S2.5 - HO Detection
▼ Better condition causes (ping-pong case)

è Ping-Pong margin PING_PONG_HCP=15db
T_HCP =10s
è HO_MARGIN(0,n)=5 dB A_PBGT_HO = 8 SACCH Ncell
A n to 0 HO has been triggered, what happens after 4s?

Serving cell
MS
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) « a » only 10 0 -5 5 9 21
PBGT > HO margin
PING_PONG_HCP=15 -5 -15 -20 -10 -6 6
HO cause 12: YES/NO ? NO NO NO NO NO YES
Back
1.291

S2.5 - HO Detection
▼ Better condition causes (traffic case)

Fill in the chart:
Number 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: tr low 0: tr high 0: tr high 0: tr low

N: tr high N: tr low N: tr low N: tr low
PBGT(n) 9 dB 9dB 4dB 9dB
DELTA_HO_MARGIN(0, 5dB -5dB -5dB 0dB

n)
Cause 12 HO: YES/NO? NO YES NO YES
Cause 23 HO: YES/NO? NO YES YES NO
Back
1.292
▼ In case 2, the cell n will be present in the candidate list for cause 12 or cause 23 ?
▼ CAUSE 12

S2.5 - HO Detection

l Find the thresholds and offsets for normal and high load :
THR_RXQUAL_CA_NORMAL = 0 OFFSET_CA_NORMAL = 0
THR_RXQUAL_CA_HIGH = 2 OFFSET_CA_HIGH = 1
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 0,5 1,5 2,5 3 2 1 0,5 0 0,5
AV_RXQUAL_DL_CA_HR_FR 0 0,5 1 1 0,5 0 1 3 3,5
AV_RXQUAL_UL_CA_FR_HR 1,5 2,3 2,3 2 1,3 0,5 0,5
AV_RXQUAL_DL_CA_FR_HR 0,5 0,8 0,8 0,5 0,8 1,5 2,3
CHANNEL TYPE FR FR FR FR HR HR HR FR
Back
1.293
▼ It is recommended to have A_QUAL_CA_FR_HR ≥ A_QUAL_CA_HR_FR because A_QUAL_CA_HR_FR refers to an

emergency HO however A_QUAL_CA_HR_FR refers to a better conditions HO.

S2.5 - HO Detection
▼ Fast Traffic HO (cause 28)

Find the appropriate candidate MS for this queued request :
Neighbors 1 2 3
MS
1 -82 -85 -78
2 -79 -86 -92
3 -90 -82 -89
Back
1.294
▼ MS1 is not appropriate because it is in FR, however HR is the channel rate required.
▼ MS2 can’t be candidate anymore because only the AV_RXLEV_NCELL(1) > L_RXLEV_NCELL_DR(1) ; but for this neighbor
cell t(1) > FREElevel_DR(1).
▼ Finally, only MS3 with candidate neighbor cell 2 fulfill all the conditions for HO cause 28.

S2.5 - HO Detection

l FORCE_TFO_HR_WHEN_LOADED = TFO_HR_NOT_FORCED
After call set-up TCH = HR TCH = EFR

TFO ON
After TFO negociation TCH = EFR TCH = EFR Back
EFR MS can use EFR/FR EFR

1.295

S2.5 - HO Detection


TFO OFF
After TFO negociation TCH = HR TCH = EFR Back
MS can use HR
HR MS can use EFR/FR EFR

1.296

S2.5 - HO Detection

l FORCE_TFO_HR_WHEN_LOADED = TFO_HR_PREFERRED

TFO ON
After TFO negociation TCH = EFR TCH = EFR
Back
MS can use HR
MS can use EFR/FR
EFR MS can use HR/EFR/FR EFR
1.297

S2.5 - HO Detection


TFO ON
After TFO negociation TCH = HR TCH = HR
Back
MS can use HR
HR MS can use HR/EFR/FR HR

1.298

S2.5 - HO Detection

Unloaded cell
Unloaded cell MS / cell cap : HR/EFR/FR
KEEP_CODEC_HO = disable
MS2
MS2 HO
Loaded cell call set-up EFR then HR
MS / cell cap : HR/EFR/FR + TFO negociation with TFO negociation
HR
TFO ON
HR
MS1 TFO ON
1.299

S2.5 - HO Detection

Unloaded cell
Unloaded cell MS / cell cap : HR/EFR/FR
KEEP_CODEC_HO = enable
MS2
MS2 HO
Loaded cell call set-up HR without TFO negociation
HR
TFO ON
HR
Back
MS1 TFO ON
1.300

S2.5 - HO Detection

l KEEP_CODEC_HO = enable Unloaded cell
Loaded cell MS / cell cap : HR/EFR/FR
EN_TFO_OPT
EN_TFO_OPT == disable
enable
MS2
MS2 HO
Unloaded cell call set-up EFR after
HRTFO
afteroptimisation
HO
HR
TFO ON
EFR
HR
Back
MS1 TFO ON
1.301

S2.6 - Handover Candidate Evaluation
l With the “Candidate
evaluation.xls” excel
sheet...
è Filtering simulation for a
è Ranking simulation for a
1- Book-keeping list
1.302

S2.6 - Handover Candidate Evaluation
Averaging
2- measurement
3- PBGT Filtering
4- GRADE evaluation process
5- Target Cell
Back
1.303

S2.8 - MS Re-selection Algorithms
▼ Important Parameters
è RXLEV_ACCESS_MIN [dBm]
ü -103dBm for G3 CI=1823
è MS_TXPWR_MAX_CCH [dBm]
CI=6271
Cell (8557, 1823)

GSM900
GSM900
ü 33dBm CI=6270
GSM900
è CELL_RESELECT_OFFSET
ü 0 dB
è TEMPORARY_OFFSET
ü 0 dB
è PENALTY_TIME CI=6169
ü0s
GSM900
Cell (8564,6169) CI=1964
è CELL_RESELECT_HYSTERESIS
GSM900
Cell (8564, 1964)

ü 6dB
Back
1.304

S2.8- MS Re-selection Algorithms
▼ Find the selected cell by MS?
CI=1823
GSM900 CI=6271
Cell 3
(8557, 1823)
GSM900
CI=6270
GSM900
Measurements RxLev (1) RxLev (2) RxLev (3)
1 -80 -96 -104

2 -84 -90 -100
3 -88 -90 -87 CI=6169
GSM900
4 -88 -87 -82

LU Cell 2 CI=1964
5 -89 -85 -78

GSM900
(8564,6169) Cell 1
(8564, 1964)
Back
1.305
▼ Case 5:
▼ LU because cell_reselect_hysteresis = 6dB
▼ C2=-78dB > -85 + 6 = -79 dB
▼ (the best one!)

S3.2 - Guide for ‘Default Radio Parameters’ document
▼ Check with the ‘Default Radio Parameters’ document if the Default

Radio
Parameters
values implemented at OMC are correct: B7
Parameter Value at OMC-R Default value? If NO, what is the

right value
POW_RED_STEP_SIZE 5 dB NO 2dB
A_LEV_HO for rural 8 YES
HO_MARGIN_LEV(0,n) 4dB NO 2dB
U_RXLEV_DL_P -75dBm YES
CELL_RESELECT_OFFSET 10 dB NO 0dB
Cause_margin_G3 -3dB No more in B7 !
A_RANGE_HO for urban 6
A_PBGT_DR 4 YES
L_RXQUAL_UL_H 2 NO because =4
YES
Back
1.306

S3.2 - Guide for ‘Default Radio Parameters’ document
Default
Radio
▼ Check if the parameters listed below are OMC-R Parameters

B7
parameters or internal system parameters :

Parameters OMC-R Internal System
EN_CAUSE_28 ü
EN_FAST_TRAFFIC_HO ü
THR_RXQUAL_CAUSE_15 ü
L_RXQUAL_UL_H_AMR ü
EN_CAUSE_16 ü
EN_INTRA_DL_AMR ü
THR_RXQUAL_CA ü
OFFSET_CA_HIGH ü
THR_RXQUAL_CA_NORMAL ü
OFFSET_CA ü
Back
1.307

S4.2 - Examples and exercises
▼ According to the Abis results and some parameters already set,

l tune qualitatively the sliding averaging windows:
è A_QUAL_HO
è A_LEV_HO
Level at RxQual=3 -80dBm -96dBm -90dBm
L_RXLEV_DL_H -85dBm -90dBm -90dBm
A_QUAL_HO 6 4 6
A_LEV_HO 2 6 4
Back
1.308
▼ 1st Case:
l The DL level HO is triggered whereas the quality is already bad (at –80dB, rxQual=3!)
l If the sliding averaging window has been set to 6 for quality causes, the sliding averaging window for level causes has
to be accelerated;
l So, A_LEV_HO = 2. BUT A_QUAL_HO and L_RXLEV_DL_H are very badly tuned !
▼ 2nd Case:
l The DL level HO is triggered whereas the quality is good
l If the sliding averaging window has been set to 4 for quality causes, the sliding averaging window for level causes can
be slowed down;
l So, A_LEV_HO = 6.
▼ 3rd Case:
l The DL level HO is triggered whereas the quality starts being degraded
l If the sliding averaging window has been set to 4 for level causes, the sliding averaging window for quality causes can
not be slowed down anyway. The purpose is not to perform a level handover in place of quality one. Aim is to avoid
bad quality calls.
l So, A_QUAL_HO = 4 or 6

▼ Training exercise (1)

l Solution
Cause 12 Cause 23 Cause 12

PBGT(n) = -1
PBGT(0) = 9
New traffic
for cell n EN_TRAFFIC_HO = 1
PBGT(0) = 5 PBGT(n) = 5
Back
1.309

S4;2 - Examples and exercises

l HO Ping-Pong effect
Unloaded cell n
PBGT(0)=PBGT(n)=0
Cause 28
Queued Ass Req Av_Rxlev_Ncell(0) = -74dBm

Av_Rxlev_Ncell(n) = -82dBm
Cause 12 L_RLEV_NCELL_DR(n) = -85dBm
PBGT(0) = 5 PBGT(n) = 5
Back
1.310
▼ First, a HO cause 28 is triggered from cell 0 to cell n because :

▼ - AV_RxLev_Ncell(n) > L_RXLEV_NCELL_DR(n)
▼ -82dBm > -85dBm
▼ - and because cell n is unloaded, we assume that t(n) > FREE_LEVEL_DR(n)
▼ Just after, a HO cause 12 is triggered from cell n to cell 0 because :

▼ - PBGT(0) > HO_MARGIN(n,0)
▼ AV_Rxlev_Ncell(0) – AV_Rxlev_PBGT_HO > HO_MARGIN(n,0)
▼ -74dBm - -82dBm > 5dB
▼ 8dB > 5dB


l When FAST_TRAFFIC_HO is enabled, activate HO CAUSE
23, it represents a good means to avoid ping-pong effect
Queued Ass Req

Cause 28
Av_Rxlev_Ncell(n) = -82
Av_Rxlev(0) = -74
PBGT(n) = -1
PBGT(0) = 9
Back
PBGT(0) = 5
1.311
▼ In this case, no ping-pong effect because : PBGT(0) = 8dB is not higher than HO_MARGIN(n,0) + DELTA_INC_HO_MARGIN
(=5dB + 4dB).
▼ The triggering of HO cause 12 from cell n to cell 0 is delayed because the cell 0 is loaded and the cell n is unloaded.

Acatel Case Study

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Acatel Case Study

Hochgeladen von

Copyright:

Verfügbare Formate

B7

TYPICAL MODULE STRUCTURE

© Alcatel University - 8AS902000421vhzza2 Page 1.1

1 TYPICAL RADIO PROBLEMS

© Alcatel University - 8AS902000421vhzza2 Page 1.2

1 TYPICAL RADIO PROBLEMS

© Alcatel University - 8AS902000421vhzza2 Page 1.3

▼ Objective : to be able to characterize typical radio problems in

S1 : TYPICAL RADIO PROBLEMS

© Alcatel University - 8AS902000421vhzza2 Page 1.4

1.1 Theoretical presentation

© Alcatel University - 8AS902000421vhzza2 Page 1.5

▼ Several sources of information can alert RFTM

▼ As many symptoms are common to several

© Alcatel University - 8AS902000421vhzza2 Page 1.6

1 TYPICAL RADIO PROBLEMS

1.2 Coverage problem

© Alcatel University - 8AS902000421vhzza2 Page 1.7

▼ Definition : Bad coverage

© Alcatel University - 8AS902000421vhzza2 Page 1.8

▼ Depending on the information sources you have:

▼ RMS : new PM type in B7

l NPA can save up to 15 days of RMS for the complete network

© Alcatel University - 8AS902000421vhzza2 Page 1.9

▼ If actual coverage is not the one predicted by RNP tools

▼ If actual coverage OK compared to predicted ones

© Alcatel University - 8AS902000421vhzza2 Page 1.10

▼ Example of an Abis trace analysis

DISTRIBUTION OF UPLINK QUALITY

DISTRIBUTION OF DOW NLINK QUALITY

© Alcatel University - 8AS902000421vhzza2 Page 1.11

▼ Example of an Abis trace analysis

▼ By the way, if the cell is mono TRX, this is a coverage pb

© Alcatel University - 8AS902000421vhzza2 Page 1.12

▼ Suspecting a cell coverage problem

l Distribution of samples per RxLev band

© Alcatel University - 8AS902000421vhzza2 Page 1.13

▼ Suspecting a cell coverage problem

% of TA value over TA threshold

© Alcatel University - 8AS902000421vhzza2 Page 1.14

1 TYPICAL RADIO PROBLEMS

1.3 Interference problem

© Alcatel University - 8AS902000421vhzza2 Page 1.15

▼ DL/UL depends on which way the interference is present

© Alcatel University - 8AS902000421vhzza2 Page 1.16

▼ RMS (Radio Measurement Statistics) – New feature in B7

© Alcatel University - 8AS902000421vhzza2 Page 1.17

▼ Suspecting a cell interference problem

Average DL RxQuality = 2.81

Quality problems are obvious at

© Alcatel University - 8AS902000421vhzza2 Page 1.18

▼ Suspecting a Voice Quality problem

RxQual to be compared with

© Alcatel University - 8AS902000421vhzza2 Page 1.19

▼ Non GSM interference

© Alcatel University - 8AS902000421vhzza2 Page 1.20

▼ Adjacent channel interference

© Alcatel University - 8AS902000421vhzza2 Page 1.21

▼ Adjacent channel interference : usually 20% of GSM interferences

© Alcatel University - 8AS902000421vhzza2 Page 1.22

© Alcatel University - 8AS902000421vhzza2 Page 1.23

© Alcatel University - 8AS902000421vhzza2 Page 1.24