Radio Optimisation GSM

Radio Optimization
Syed Irtiqa Ali
Agenda
GSM Networks RF Optimization , Related
Stats and Parameters
DAY 1 - 27th July
Network Performance related stats.
Network Performance related parameters.
DAY 2 28th July

KPI monitoring and flow charts to rectify KPI issues.
Coverage Optimization.
DAY 3 29th July

Interference.
Drive Test Analysis.
Make your own optimization tool.
Motorola Internal Use Only MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. Motorola, Inc. 2004.
Overview
During Optimization all activities go Hand
in Hand, just like a jigsaw puzzle until all
pieces fit together you wont get the desired
picture.
Drive
Test
STATS
Physical
Activities
Param
eters
Physical
PARAMETERS
activities
Drive Tests
Stats
Need For Optimization

Optimization objective is to extract the best performance
from the network, at any given phase of the lifecycle of the
network
Cellular systems continuously changing:
new radio sites introduced
old sites enhanced and assigned additional frequencies
omni-directional sites being sectorised etc
Throughout this evolution, it is important to maintain &
constantly optimise performance of radio network, hence the
need for this fine-tuning or optimization process.
Note :- Optimization is a continuous process
Optimization Flow Chart
Monitor
network
KPIs
Implement
Changes
Analyze
data
Yes
QOS
Targets
Met?
No
Identify
problems
Optimisation Process
INTRODUCTION TO NETWORK
PERFORMANCE STATS
Performance Statistics
ALLOC_SDCCH
ALLOC_SDCCH_FAIL
ALLOC_TCH
ALLOC_TCH_FAIL
AVAILABLE_SDCCH
AVAILABLE_TCH
BUSY_SDCCH
BUSY_TCH
C_SETUP_SUCCESS_RATE
C_SETUP_TCH_BLOCKIN_RATE
C_SUCCESS_RATE
C_VOLUME
CHAN_REQ_CAUSE_ATMPT
CHAN_REQ_MS_BLK
CHAN_REQ_MS_FAIL
RF loss on TCH
RF loss on SDCCH
HANDOVERS_PER_C (H)
CONGEST_EXIST_HO_ATMPT
CONN_REFUSED
CONN_REQ_TO_MSC
HANDOVER_FAILURE_RATE
HANDOVER_SUCCESS_RATE
TCH_RF_LOSS_RATE
SDCCH_BLOCKING_RATE
MAX_TCH_BUSY
PAGE_REQ_FROM_MSC
PAGE_RESPONSE
PAGING_SUCCESS_RATE
TCH_BLOCKING_RATE
Att_U/L_qual
Att_D/L_qual
SDCCH_RF_LOSS_RATE
TCH_BLOCKING_RATE
TCH_MEAN_HOLDING_TIME
TCH_TRAFFIC_CARRIED
CHAN_REQ_MS_FAIL_ROLL
MA_FAIL_FROM_MS
DROP_CALL_RATE
Carrier Statistics
IOI (mean/max/min)
BER (u/l & d/l)
PATH_BALANCE
RF_LOSSES (Carrier wise)
ROC (Range of Carrier)
Neighbor Stats
OUT_HO_NC_CAUSE_ATMPT.
UPQUAL
Handovers due to uplink quality.
UPLEVEL
Handovers due to uplink level.
DOWNQUAL
Handovers due to downlink quality.
DOWNLEVEL
Handovers due to downlink level.
DISTANCE Handovers due to distance.
UPINTERF Handovers due to uplink interference.
DOWNINTERF
Handovers due to downlink interference.
POWERBDGT
Handovers due to power budget.
CONGESTION
Handovers due to congestion.
ADJ_CHAN_INTF
Handovers due to adjacent channel
interference.
OUT_HO_NC_SUCC
IN_INTRA_BSS_NC_ATMPT
IN_INTRA_BSS_NC_SUC
NETWORK PERFORMANCE
RELATED PARAMETERS
1) Rolling averages.
2) Cell selection/reselection parameters.
3) Power Control
4) Handovers
5) Case Study ( Effect of Qual. Handovers)
6) Radio Link Loss
ROLLING AVERAGES
MS Measurement Cycle
BSS Rolling Averages
N and P Voting Mechanism
HREQAVE/HREQT and N/P

Relationship
CELL SELECTION / RESELECTION

AND
CHANNEL RECONFIGURATIONS
MS Access Power Output

ms_txpwr_max_cch = <*>
* for GSM900/EGSM/GSM850
* GSM1800/PCS1900
2 = 39 dBm
0 = 30 dBm
1 = 28 dBm
2 = 26 dBm
.
19 = 5 dBm
.
.
.
15 = 0 dBm
Cell Selection/Reselection
C1: = (A Max (B, 0))
p2 = ms_txpwr_max_cch = <
* for GSM900
B: = p2 Max RF Power of MS
2 = 39 dBm
p1 = rxlev_access_min = <*>3 = 37 dBm
.
* 0 = -110 dBm
.
1 = -109 dBm
19 = 5 dBm
For DCS1800
2 = -108 dBm
0 = 30 dBm
.
1 = 28 dBm
.
.
.
.
63 = -47 dBm
15 = 0 dBm
A: = (Rxlev Average p1)
Cell Reselection C2
C2 = C1 + cell_reselect_offset - temporary_offset*H
H = 0 if T > penalty_time
cell_reselect_offset = <*>
H = 1 if T penalty_time
* Integer code for dB offset
(for penalty_time database value 0 30)
0 = 0 dB
1 = 2 dB
C2 = C1 cell_reselect_offset
(for penalty_time = 31)
2 = 4 dB
.
.
cell_reselect_param_ind = <*>
63 = 126 dB
* 1 C2 parameters are to be broadcasted

0 C2 parameters are not to be broadcasted
Cell Reselection C2
C2 = C1 + cell_reselect_offset - temporary_offset*H
H = 0 if T > penalty_time
penalty_time = <*>
H = 1 if T penalty_time
* Integer code for 20 sec periods
(for penalty_time database value 0 30)

C2 = C1 cell_reselect_offset
(for penalty_time = 31)
temporary_offset = <*>
* Integer code for 10s of dBs offset
0 = 0 sec
1 = 20 sec
.
.
.
0 = 0 dB
30 = 620 sec
1 = 10 dB
31 = Temporary_offset ignored,
cell_reselect_offset is negative
2 = 20 dB
3 = 30 dB
.
cell_bar_qualify = <*>
.
.
0 - Normal
7 = infinity
1 - Low
Cell Reselection Example
Serving Cell Database Parameters Best Neighbour Cell Database Para

Cell Identity = 234 10 262 042
Cell Identity = 234 10
rxlev_access_min
= 20
rxlev_access_min = 20
255
038
ms_txpwr_max_cch = 5
ms_txpwr_max_cch = 5
cell_reselect_param_ind = 1
cell_reselect_param_ind = 1
cell_reselect_offset = 3
cell_reselect_offset = 2
Temporary_offset = 3
Temporary_offset = 1
Penalty_time = 5
Penalty_time = 12
Rxlev
Average
Serving = -70 dBm
Best neighbour = -63 dBm
cell_reselect_hysteresis = 2
Mobile power class = 2 (8w 39 dBm)
Channel Reconfiguration
channel_reconfiguration_switch = <*>
* 0 = Reconfiguration not permitted
1 = Reconfiguration permitted
number_sdcchs_preferred = <*>
* Number of SDCCHs
Combined Multiframe 4, 12, 20, 28 44
Non-combined Multiframe 8, 16, 24 48
max_number_of_sdcchs
=*<*>
Number of SDCCHs
Combined Multiframe 4, 12, 20, 28 44
Non-combined Multiframe 8, 16, 24 48
SDCCH Reconfiguration
sdcch_need_high_water_mark = <*> (default 2) 1 - 39
sdcch_need_low_water_mark = <*> (default 12) 10 - 4

* Number of SDCCHs free
tch_full_need_low_water_mark = <*> (default 255) 0 -
SDCCH Reconfiguration TCH to SDCCH

High water mark = 2
High water mark = 2
Carrier 2
Carrier 1
TS1
TS2
TS1
TS2
reconfiguration
not started
SDCCH preferred = 16
ccch_conf = 0
Max no SDCCH = 24
trigger reconfiguration
SDCCH Reconfiguration SDCCH to TCH
Carrier 2
Carrier 1
TS1
TS2
TS1
TS2
SDCCH preferred = 16
Max no SDCCH = 24
Low water mark = 18
Trigger reconfiguration
ccch_conf = 0
POWER CONTROL
Signal Strength Measurements
MS Measurements
Idle Mode
Dedicated
Mode
BSIC
BCCH
SERVER
-----------NBRS
-------
BCCH
BSIC
30sec
30sec
------5min
10sec
Quality Measurements
BSS Processing and Threshold

Companions
Reported by MS
Downlink Received Signal Strength

Downlink Quality
Downlink Surrounding Cell RXLEV
Performed by RSS
Uplink Received Signal Strength
Uplink Quality
MS BS Distance
Interference levels in idle timeslot
Processed Value every 480 ms
MS/BSS Power Control
Standard Power Control

decision_alg_num = 0
bts_p_con_ack and ms_p_con_ack timers are not used.
decision_alg_num = 1
bts_p_con_ack and ms_p_con_ack timers are used.
Quality takes precedence!
Decision_alg_number = 1
INCREASE
RxQual > l_rxqual_ul_p
&
RxLev > u_rxlev_ul_p
Power Control Parameters (1)

decision_alg_number = 0
Timing ...
we
o
P
ma
m
Co
nd
ma
ge
d
m
e
Co
wl
r
o
e
w
kn
ac
Po
nd
we
o
P
ma
m
Co
p_con_interval
p_
t
_i n
n
co
we
o
P
ma
m
Co
p_con_interval
al
er v
p_
Command Acknowledged
nd
v
t er
n
i
_
con
al
Command Not Acknowledged
nd

Timing ...
w
Po
er
mm
o
C
d
an
ac
ge
ed
l
ow
kn
w
Po
er
mm
o
C
p_con_interval
ck
a
val
_
r
n
e
t
o
_i n
p_c
n
o
p_c
Command Acknowledged
d
an
w
Po
er
mm
o
C
d
an
p_
p_con_ack
k
_ac
n
o
p_c
p_
a
n_
o
c
ke
i re
xp
s
we
o
P
ma
m
Co
p_con_interval
r
nte
i
_
con
val
Command Not Acknowledged
nd
Timing ...
ms/bts_p_con_ack: waiting period for power command

acknowledge
ms/bts_p_con_interval: waiting period for new power
command
ms_p_con_ack = 2
bts_p_con_ack = 1
Timing ...
-75
-73
-68
HREQAVE = 4
HREQT = 1
-62
-61
PC initiated
POWER CONTROL OPTIMISATION

DL RxLev
UL RxLev
u_rxlev_dl_p = 35
u_rxlev_ul_p = 30
-80
dBm
-90
dBm
hreqave = 2
hreqt = 2
l_rxlev_ul_p = 20
-75
n1 = 2 dBm
p1 = 1
-85
n2 = 2 dBm
1
3
5
l_rxqual_ul_p = 114
l_rxqual_ul_p_hopping = 450
l_rxlev_dl_p = 25
2 p2 = 2
UL RxQual
u_rxqual_ul_p = 40
hreqave = 2
hreqt = 2
DL RxQual
4 n3 = 2
p3 = 1
n4 = 2
2 p4 = 2
1
3
5
u_rxqual_dl_p = 40
l_rxqual_dl_p = 114
l_rxqual_dl_p_hopping = 450
hreqave = 2 ; hreqt = 2
Separate uplink & downlink step sizes
SEPARATE increment/decrement step sizes for uplink and down

link
pow_inc_step_size
pow_inc_step_size_ul
pow_inc_step_size_dl
2,4,6,8,10,
12,14 dB
2,4dB
pow_red_step_size
pow_red_step_size_ul
pow_red_step_size_dl
* The increment step size must be >= the decrement step size
Power Control - BSS

Threshold
l_rxlev_dl_p = <*>
u_rxlev_dl_p = <*>
* Range 0 63 (-110 to -47 dBm)
Comparison
decision_1_n1 = <*>
decision_1_p1 = <*>
decision_1_n2 = <*>
decision_1_p2 = <*>
* 1 31 Averages
n1, p1 = power increase
n2, p2 = power decrease
p out of n averages must exceed threshold
BTS Power Control

bts_power_control_allowed = <*>
* 0 - disabled
1 enabled
bts_p_con_interval = <*> max_tx_bts = <*>

* 21 steps of 2 dBs of attenuation from 43
0 = 0 SACCH
in GSM900/EGSM/GSM850, or 39 dBm i
1
= 2 SACCH multiframes
multiframes
.
the case of DCS1800
.
.
31 = 62 SACCH multiframes * 6 steps of 2 dBs for M-Cellmicro, Horizon
Horizonmicro
Default =2
bts_p_con_ack = <*>
0 = 0 SACCH multiframes
.
.
.
Default = 2
Power Control - MS
Power Control - MS
Threshold
l_rxlev_ul_p = <*>
u_rxlev_ul_p = <*>
* Range 0 63 (-110 to -47 dBm)
Comparison
decision_1_n1 = <*>
decision_1_p1 = <*>
decision_1_n2 = <*>
decision_1_p2 = <*>
* 1 31 Averages
n1, p1 = power increase
n2, p2 = power decrease
p out of n averages must exceed threshold
MS Power Control
decision_alg_type = <*>
ms_p_con_ack = <*>
* 0 Motorola alg
* 0 = 0 SACCH multiframes
1 Alternate alg
Default = 0
ms_power_control_allowed = <*>
* 0 Power Control Disabled
1 Power Control Enabled
ms_p_con_interval = <*>
.
.
.
Default = 2
Default = 2
2 = 2 dB, 4 = 4 dB . . . . . . 12 = 12 dB, 14 = 14 dB
Default = 2
pow_red_step_size_ul
2 = 2 dB, 4 = 4 dB
Default = 2
alt_qual_proc
Power Control - RXQUAL
Oscillation Prevention for MS

Power Control
Oscillation Prevention for BTS Power

Control
Dynamic Power Control

(But Why)
Optimised/Dynamic Power
Control
dyn_step_adj = <*>
Used to determine whether the dynamic step adjust algorithm
Enabled or disabled
* 0 - disabled (default 0)
1 enabled (excludes power reduction)
2 enabled (includes power reduction)
dyn_step_adj_fmpr = <*>
Used to control the rapidity of a dynamic power reduction
* 0 10 (default 10)
Dynamic step size
IF ENABLED , increment / decrement step size can be

changed dynamically based on :
current power levels
proximity to upper / lower power thresholds
To ENABLE, set per cell element dyn_step_adj to 1:
chg_element dyn_step_adj 1 10 cell_number=0 0 1 0 1 1 1
RAPID_POWER_DOWN feature can work with Optimised

Power Control at the same time.
When rapid power trigger point is reached, the feature
OVERRIDES
any Optimised Power Control dynamic
adjustment decision
Dynamic step size
4 types of dynamic step size adjustments
1. Dynamic power step size increase due to poor RXQUAL

2. Dynamic power step size increase due to poor RXLEV
3. Dynamic power step size reduction due to good RXQUAL
4. Dynamic power step size reduction due to good Rxlev.
Optimised/Dynamic Power
Control
Dynamic power increase due to poor quality
DYN_POW_INCR_XX_Q =
max (pow_inc_step_size_xx, fhigh (l_rxlev_xx_p av_rxlev_xx +
pow_inc_step_size_xx)
Where:
fhigh = an indication of the rounding up of a
value to the nearest multiple of 2 dB
xx = UL/DL
occurs when rxqual falls below the lower rxqual

threshold
l_rxqual_ul/dl_p
Dynamic power increase due to poor RXQUAL
If current power is below lower power threshold, dynamic step size will
increase power to a standard step size above the lower power
threshold. Otherwise dynamic step size will be by the standard step
size.
e.g. If poor rxqual AND power level is below lower power threshold...
Power level
Power
Window
Dynamic
step size
Current power level
u_rxlev_ul_p
l_rxlev_ul_p
Standard step size

current_rxlev_ul
Optimised Power Control

Dynamic power increase due to low level
DYN_POW_INCR_XX_L =
fhigh (l_rxlev_xx_p av_rxlev_xx + pow_inc_step_size_xx)
Where:
fhigh = an indication of the rounding up of a
xx = UL/DL
Dynamic power decrease due to high level

DYN_POW_RED_XX_L =
fhigh (av_rxlev_xx u_rxlev_xx_p + pow_red_step_size_xx)

Dynamic power reduction due to good quality
DYN_POW_RED_XX_Q =
max (pow_red_step_size_xx, flow(
(av_rxlev_xx u_rxlev_xx_p))
dyn_step_adj_fmpr
10
Where:
Flow = an indication of the rounding down of a
xx = UL/DL
occurs when rxqual is above the upper rxqual threshold

u_rxqual_ul/dl_p
Dynamic power reduction due to

good RXQUAL
where valid range for dyn_step_adj_fmpr is 0 - 10
chg_element dyn_step_adj_fmpr 10 1 cell_number=0
010111
The rate of power reduction bringing power back to the top
of the power box is proportional to dyn_step_adj_fmpr (with
a minimum required reduction of pow_red_step_size_xx)
Dynamic power reduction due to good RXQUAL

e.g. If good rxqual AND current power level is above the upper
threshold AND dyn_step_adj_fmpr is 10 / 5.
Dynamic
step size 100%
Dynamic
step size 50%
Power level
current_rxlev_ul
Current power level
Power
Window
u_rxlev_ul_p
l_rxlev_ul_p
BTS power downlink oscillations

Defined as a rxqual based power reduction resulting in
an immediate rxlev based power increase
If the following condition is true, a RXQUAL based power
reduction will NOT be performed:
current_rxlev_dl < l_rxlev_dl_p +

pow_red_step_size_dl + 2dB
BTS power downlink oscillations
Power level
Is current_rxlev_dl
less than this level??
u_rxlev_dl_p
Standard step size
pow_red_step_size_dl
l_rxlev_dl_p
2dB
HANDOVERS
Handover Procedure
Purpose is to completely modify the channel allocated to the MS and is
only used when in RR connected mode i.e. cell changed, change in
channel configuration
The handover procedure is always initiated from the network
Suspension of normal operation except for RR management (layer 3)
Disconnection of main signalling link and other links via local end
release (layer 2) and disconnection of TCHs, if any
Disconnection and deactivation of previously assigned chans. and their
release (layer1)
Activation of new channels, and their connection
Triggering of the establishment of data link connection for SAPI=0 on
the new channels
Successful Handover
Handover Command
Characteristics of new channels and exact ACCH channel to be
used
Characteristics of new cell, necessary for communication i.e. arfcn,
ncc, bcc
Indication of physical channel establishment procedure with
channel details e.g. type, timeslot, TSC, frequency and if hopping
MAIO, HSN
Power command and handover reference (access id)
Optionally timing advance, cipher mode setting
Handover Command
HANDOVER ACCESS
HANDOVER COMPLETE
Handover Cause Priority

UL RXQUAL
(UL INTERFERENCE)
DL RXQUAL
(DL INTERFERENCE)
UL RXLEV
DL RXLEV
DISTANCE
POWER BUDGET
First Criterion
Second Criterion
Pbgt(n) ho_margin(n) >

0
Handover Decision Procedure

HO
RXLEV_NCELL(n) > RXLEV_MIN(n) + Max(0,Pa)

Evaluate criterion 1
for all neighbours
num_ho_cand = number
of neighbours passing
Evaluate criterion 2
for all neighbours
passing criteria 1
where : Pa = ms_txpwr_max(n) - P
P = max power of mobile
PBGT(n) Ho_margin
Execute the
appropriate
Motorola handover
procedure
Separate Rxqual Thresholds
Optimize quality handovers and power control for

both situations simultaneously on the same cell
Yes
RxQual
Thresholds
for Hopping
Hopping
Call ?
No
RxQual
Thresholds
for NonHopping
HANDOVER &
POWER
CONTROL
PROCESSES
Quality HO/PC Thresholds for

Hopping
hop_qual_enabled: Enable/Disable alternative thresholds
Prompts for the following parameters:
l_rxqual_dl_h_hopping
l_rxqual_ul_h_hopping
l_rxqual_dl_p_hopping
l_rxqual_ul_p_hopping
Quality thresholds can be set in:
BER: 0 - 1810 (1 step = 0.01% BER)
RxQual: 0 7
Depending on the value of alt_qual_proc (0 / 1)
Handover Decision Procedure Qual & Interference
Uplink/Downlink Qual H/O Processing
Handover Decision UL Qual/Int

Procedure
Activity
Quality Handover
Link
Up
Down
Enable
ul_rxqual_ho_allowed
dl_rxqual_ho_allowed
Averaging
rxqual_ul_ho
rxqual_dl_ho
Decision
decision_1_ul_rxqual_av_h
decision_1_dl_rxqual_av_h
Threshold
l_rxqual_ul_h
l_rxqual_dl_h
Voting
P6, N6
P6, N6
Level Handover
Up
Down
ul_rxlev_ho_allowed
dl_rxlev_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
decision_1_ul_rxlev_av_h
decision_1_dl_rxlev_av_h
l_rxlev_ul_h
l_rxlev_dl_h
P5, N5
P5, N5
Interference
Handover
Up
Down
interfer_ho_allowed
interfer_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
decision_1_ul_rxlev_av_ih
decision_1_dl_rxlev_av_ih
u_rxlev_ul_ih
u_rxlev_dl_ih
P7, N7
P7, N7
ms_distance_allowed
rel_tim_adv
decision_1_tim_adv_av_alg
ms_max_range
P8, N8
Distance Handover
Power Budget
Handover
--
Source
pwr_handover_allowed
Neighbor
Up
Power Control due
to Level
Down
Power Control due

to Quality
Up
Down
Criteria 1
--
Criteria 2
--
rxlev_dl_ho
decision_1_pbgt_rxlev_av_h
surround_cell/p
er neighbor
l_rxlev_ul_p
u_rxlev_ul_p
UL RxQual
HO
l_rxlev_dl_p
bts_power_control_allowed rxlev_dl_pc
decision_1_dl_rxlev_av_p
u_rxlev_dl_p
l_rxqual_ul_p
ms_power_control_allowed rxqual_ul_pc
decision_1_ul_rxqual_av_p
u_rxqual_ul_p
l_rxqual_dl_p
bts_power_control_allowed rxqual_dl_pc
decision_1_dl_rxqual_av_p
u_rxqual_dl_p
UL Interference
HO
-surround_cell
decision_1_ncell_rxlev_av_calc
-ms_power_control_allowed rxlev_ul_pc
--
rxlev_dl_ho
surround_cell
decision_1_ul_rxlev_av_p
--
handover_margin
P1, N1
(increase)
P2, N2
(decrease)
P3, N3
(increase)
P4, N4
(decrease)
--
--
--
Notes
Used by
interference
handover as
well
-Relevant
quality
handover must
trigger first
Uplink only
No voting as
lastest hreqt
used
--
--
---
Handover Decision DL Qual/Int

Procedure
Activity
Quality Handover
Link
Up
Down
Enable
Averaging
rxqual_ul_ho
rxqual_dl_ho
Decision
Threshold
l_rxqual_ul_h
l_rxqual_dl_h
Voting
P6, N6
P6, N6
Level Handover
Up
Down
ul_rxlev_ho_allowed
dl_rxlev_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
l_rxlev_ul_h
l_rxlev_dl_h
P5, N5
P5, N5
Interference
Handover
Up
Down
interfer_ho_allowed
interfer_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
u_rxlev_ul_ih
u_rxlev_dl_ih
P7, N7
P7, N7
ms_distance_allowed
rel_tim_adv
ms_max_range
P8, N8
Distance Handover
Power Budget
Handover
--
Source
Neighbor
Up
Power Control due
to Level
Down
Power Control due

to Quality
Up
Down
Criteria 1
--
Criteria 2
--
rxlev_dl_ho
surround_cell/p
er neighbor
l_rxlev_ul_p
u_rxlev_ul_p
DL
RxQual
HO
l_rxlev_dl_p
u_rxlev_dl_p
l_rxqual_ul_p
u_rxqual_ul_p
l_rxqual_dl_p
u_rxqual_dl_p
DL
Interference
HO
-surround_cell decision_1_ncell_rxlev_av_calc
--
rxlev_dl_ho
surround_cell
--
handover_margin
P1, N1
(increase)
P2, N2
(decrease)
P3, N3
(increase)
P4, N4
(decrease)
--
--
--
Notes
Used by
interference
handover as
well
-Relevant
quality
handover must
trigger first
Uplink only
No voting as
lastest hreqt
used
--
--
---
Uplink Level Handover Procedure
Downlink Level Handover Procedure
Handover Decision UL Level

Procedure
Activity
Quality Handover
Link
Up
Down
Enable
Averaging
rxqual_ul_ho
rxqual_dl_ho
Decision
Threshold
l_rxqual_ul_h
l_rxqual_dl_h
Voting
P6, N6
P6, N6
Level Handover
Up
Down
ul_rxlev_ho_allowed
dl_rxlev_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
l_rxlev_ul_h
l_rxlev_dl_h
P5, N5
P5, N5
Interference
Handover
Up
Down
interfer_ho_allowed
interfer_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
u_rxlev_ul_ih
u_rxlev_dl_ih
P7, N7
P7, N7
ms_distance_allowed
rel_tim_adv
ms_max_range
P8, N8
Distance Handover
Power Budget
Handover
--
Source
Neighbor
Up
Power Control due
to Level
Down
Power Control due

to Quality
rxlev_dl_ho
surround_cell/p
er neighbor
ms_power_control_allowed rxlev_ul_pc
UL
Up
Down
Criteria 1
--
--
surround_cell
Criteria 2
--
--
rxlev_dl_ho
surround_cell
l_rxlev_ul_p
u_rxlev_ul_p
RxLev
HO
l_rxlev_dl_p
u_rxlev_dl_p
l_rxqual_ul_p
u_rxqual_ul_p
l_rxqual_dl_p
u_rxqual_dl_p
-decision_1_ul_rxlev_av_p
--
handover_margin
P1, N1
(increase)
P2, N2
(decrease)
P3, N3
(increase)
P4, N4
(decrease)
--
--
--
Notes
Used by
interference
handover as
well
-Relevant
quality
handover must
trigger first
Uplink only
No voting as
lastest hreqt
used
--
--
---
Handover Decision DL Level

Procedure
Activity
Quality Handover
Link
Up
Down
Enable
Averaging
rxqual_ul_ho
rxqual_dl_ho
Decision
Threshold
l_rxqual_ul_h
l_rxqual_dl_h
Voting
P6, N6
P6, N6
Level Handover
Up
Down
ul_rxlev_ho_allowed
dl_rxlev_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
l_rxlev_ul_h
l_rxlev_dl_h
P5, N5
P5, N5
Interference
Handover
Up
Down
interfer_ho_allowed
interfer_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
u_rxlev_ul_ih
u_rxlev_dl_ih
P7, N7
P7, N7
ms_distance_allowed
rel_tim_adv
ms_max_range
P8, N8
Distance Handover
Power Budget
Handover
--
Source
Neighbor
Up
Power Control due
to Level
Down
Power Control due

to Quality
rxlev_dl_ho
surround_cell/p
er neighbor
ms_power_control_allowed rxlev_ul_pc
DL
Up
Down
Criteria 1
--
--
surround_cell
Criteria 2
--
--
rxlev_dl_ho
surround_cell
l_rxlev_ul_p
u_rxlev_ul_p
RxLev
HO
l_rxlev_dl_p
u_rxlev_dl_p
l_rxqual_ul_p
u_rxqual_ul_p
l_rxqual_dl_p
u_rxqual_dl_p
-decision_1_ul_rxlev_av_p
--
handover_margin
P1, N1
(increase)
P2, N2
(decrease)
P3, N3
(increase)
P4, N4
(decrease)
--
--
--
Notes
Used by
interference
handover as
well
-Relevant
quality
handover must
trigger first
Uplink only
No voting as
lastest hreqt
used
--
--
---
Handover MS Maximum Range

ms_distance_allowed = <*>
* 0 = disabled
Threshold
1 = enabled
Default = 0
ms_max_range = <*>
0 to 63 bit periods
Default = 0
Comparison
decision_1_n8 = <*>
decision_1_p8 = <*>
* 0 31 Averages
Distance Handover Procedure
Timing Advance MS Maximum

Range
timing_advance_period = <*>
.
.
.
.
.
.
Default = 4
Activity
Quality Handover
Link
Up
Down
Enable
Averaging
rxqual_ul_ho
rxqual_dl_ho
Decision
Threshold
l_rxqual_ul_h
l_rxqual_dl_h
Voting
P6, N6
P6, N6
Level Handover
Up
Down
ul_rxlev_ho_allowed
dl_rxlev_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
l_rxlev_ul_h
l_rxlev_dl_h
P5, N5
P5, N5
Interference
Handover
Up
Down
interfer_ho_allowed
interfer_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
u_rxlev_ul_ih
u_rxlev_dl_ih
P7, N7
P7, N7
ms_distance_allowed
rel_tim_adv
ms_max_range
P8, N8
Distance Handover
Power Budget
Handover
--
Source
Neighbor
Up
Power Control due
to Level
Down
Power Control due

to Quality
Up
Down
Criteria 1
--
Criteria 2
--
rxlev_dl_ho
surround_cell/p
er neighbor
l_rxlev_ul_p
u_rxlev_ul_p
l_rxlev_dl_p
u_rxlev_dl_p
l_rxqual_ul_p
u_rxqual_ul_p
Distance HO
l_rxqual_dl_p
u_rxqual_dl_p
--
rxlev_dl_ho
surround_cell
--
handover_margin
P1, N1
(increase)
P2, N2
(decrease)
P3, N3
(increase)
P4, N4
(decrease)
--
--
--
Notes
Used by
interference
handover as
well
-Relevant
quality
handover must
trigger first
Uplink only
No voting as
lastest hreqt
used
--
--
---
Power Budget Assessment
Considering RXLEV Only
Adapted Power Correction Factor
Uplink Consideration
Power Budget Example
Handover Decision Procedure Pwr Budget
Activity
Quality Handover
Link
Up
Down
Enable
Averaging
rxqual_ul_ho
rxqual_dl_ho
Decision
Threshold
l_rxqual_ul_h
l_rxqual_dl_h
Voting
P6, N6
P6, N6
Level Handover
Up
Down
ul_rxlev_ho_allowed
dl_rxlev_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
l_rxlev_ul_h
l_rxlev_dl_h
P5, N5
P5, N5
Interference
Handover
Up
Down
interfer_ho_allowed
interfer_ho_allowed
rxlev_ul_ho
rxlev_dl_ho
u_rxlev_ul_ih
u_rxlev_dl_ih
P7, N7
P7, N7
ms_distance_allowed
rel_tim_adv
ms_max_range
P8, N8
Distance Handover
Power Budget
Handover
--
Source
Neighbor
Up
Power Control due
to Level
Down
Power Control due

to Quality
Up
Down
Criteria 1
--
Criteria 2
--
rxlev_dl_ho
surround_cell/p
er neighbor
l_rxlev_ul_p
u_rxlev_ul_p
l_rxlev_dl_p
u_rxlev_dl_p
l_rxqual_ul_p
u_rxqual_ul_p
PBGT HO
l_rxqual_dl_p
u_rxqual_dl_p
--
rxlev_dl_ho
surround_cell
--
handover_margin
P1, N1
(increase)
P2, N2
(decrease)
P3, N3
(increase)
P4, N4
(decrease)
--
--
--
Notes
Used by
interference
handover as
well
-Relevant
quality
handover must
trigger first
Uplink only
No voting as
lastest hreqt
used
--
--
---
Bounce Protection
Intra-cell Handovers
intra_cell_handover_allowed = <*>
* 0 Not performed by BSS
1 Performed by BSS if applicable
2 Not permitted
Default = 1
Intra-Cell Handovers
intra_cell_handover_allowed
0: Not performed by BSS (controlled by the MSC). Handover required message may contain
server as potential candidate along with other targets
1: Performed by BSS if applicable. Intra-cell HO may be attempted only if ho_recognised
message specifies cause value quality or interference
Cause quality intra-cell attempt only if other targets are exhausted
Cause interference intra-cell first, if fails try other targets
2: Not permitted
Time Limitation for Excessive

If a cell has bad interference for all timeslots, intra-cell handovers
can be continuously done
This functionality will limit the number of intra-cell handovers due to
interference which can occur in a specified amount of time by
escalating the handover to an RXQUAL handover
This type of RXQUAL handover can be subjected to the re-ordering
described for Micro-Micro and Timed Offset
Time Limitation for Excessive

Intra-cell
Handovers
A per
cell parameter hop_count,
determines the number of intra-cell hops one mobile will
do before doing the inter-cell handover
When the first intra-cell handover occurs, start a timer for hop_count_timer SACCH
periods
If the number of intra-cell hops exceeds hop_count before hop_count_timer expires, a
RXQUAL handover will be done to another cell
Time Limitation for Excessive Intracell Handovers
CELL A
1
n+1
2
3
BCCH
TCH1
TCH2
Handovers Allowed
ul_rxqual_ho_allowed = <*>
dl_rxqual_ho_allowed = <*>
ul_rxlev_ho_allowed = <*>
dl_rxlev_ho_allowed = <*>
* 0 - disabled
1 - enabled
Handover RXLEV, RXQUAL

Threshold
l_rxlev_ul_h = <*>
l_rxlev_dl_h = <*>
* Range 0 63 (-110 to -47 dBm)
l_rxqual_ul_h = <*>
l_rxqual_dl_h = <*>
* 0 1810 steps of 0.01%
Comparison
decision_1_n5 = <*>
decision_1_p5 = <*>
decision_1_n6 = <*>
decision_1_p6 = <*>
* 1 31 Averages
n5, p5 = RXLEV
n6, p6 = RXQUAL
Handover RXLEV, RXQUAL
Considering a hopping carrier , the window for power control based on RX

qual should be set between 0 5 and for the Qual based handover this
should be set at 6 , since in hopping case the perceived voice becomes
unacceptable if the RxQual remains 6 continuously.
Handover Parameter Look-up
CASE STUDY
QUALITY HANDOVERS
Problem Faced Without Qual HOs

1) Higher Drop call rate.
2) Higher TCH loss rate.
3) Call getting dragged in a poor qual conditions of
cell for longer periods and dropping at last.
4) Frequent customer complaints.
DCR comparison Before/After Qual Ho
Tch Rf Loss comparison Before/After

Qual Ho
Incoming Handovers
en_incom_ho = <*>
* 0 incoming handovers are inhibited
1 incoming handovers are allowed
Default 1
Handover Reporting
Handover Evaluating
Handover Rejection
Handover_required_reject_switch
1: BSS expects to receive a "handover required reject" message from the MSC. Any
internal cells that are candidates for the handover will not be included in the
"Handover Required" message. On receipt of the "Handover Required Reject"
message the BSS will perform an internal handover if there are valid candidates.
0: BSS will not expect to receive a "Handover Required Reject" message from the
switch and will include internal candidates in the "HO Required" message.
Handover Power Level

handover_power_level = <*>
* = GSM900/GSM850
2 39 dBm
.
* = DCS1800 and PCS1900

0 30 dBm
1 28 dBm
2 26 dBm
.
19 5 dBm
.
.
15 0 dBm
*= DCS 1800 & PCS 1900 cells

Represents the maximum mobile power levels for DCS1800
& PCS1900 cells for class 3 mobiles
31 32 dBm
30 34 dBm
29 36 dBm
Calculated Handover Power Level

use_derived_ho_power = <*>
* 0 = use handover_power_level
1 = use calculated handover level
Default = 0
handover level = min (C + (A B), D, P)
Where A = max_tx_bts of target cell
B = rxlev_dl from target cell
C = u_rxlev_ul_p + l_rxlev_ul_p
2
centre of target cells uplink power window

D = max_tx_ms of target cell
P = power class of mobile
Handover Default Information

ms_txpwr_max_def = <*>
* 5 39 (GSM900/GSM850/EGSM) (odd)
0 36 (DCS1800) (even)
0 32 (PCS1900) (even & 33)
ho_margin_def = <*>
* -63 to +63 dB
Default = 8
rxlev_min_def = <*>
* 0 = -110 dBm
1 =-109 dBm
2 = -108 dBm
.
.
63 = -47 dBm
Default = 15 (-95dBm)
rr_t3103
Handover Channel Establishment
rr 3105
start
Handover Channel Establishment
rr_t3105 = <*>
* 0 to 200 (in 20 ms steps)
Default 60
rr_ny1_rep = <*>
* number of repetitions
0 to 200
Default 20
RADIO LINK LOSS
RSS Uplink Failure Detection

Link_fail => 3
This governs the number of missing uplink SACCH messages
which should occur before a radio-link-loss is determined.
The default value is 4 representing 20 SACCH periods,
which is 9.6s. This is value is long, since the loss of uplink
SACCH indicates that uplink audio is also lost, and so the
subscriber will certainly terminate the call within this
period.
The recommended value for link_fail is 3, which represents
16 SACCH periods (7.7s). This value is commonly used in the
networks.
The benefit of decreasing this value is that the holding time
of the channel following any radio loss will be reduced by
2.2s hence also resulting in the gain in terms of capacity.
link_fail = <*>
.
.
.
Default = 4 (20 SACCH multiframes)
Radio Link Timeout
radio_link_timeout = <*>
.
.
.
RSS Downlink failure timer

Radio_link_timeout => 3
This governs the number of missing downlink SACCH
messages which should occur before a radio-link-loss is
determined. The current setting is 4, representing 20
SACCH periods (9,6s). It is recommended that this be set to
3, to correspond with the suggested setting for link_fail.
Radio Link Timeout
Radio Link Revival
DL / UL
The full_pwr_rfloss field enables or disables the ability of the

RSS to instruct the MS and BSS to use maximum power when
loss of radio resource is detected.
Triggered when link_fail counter reaches the threshold of
link_about to_fail.
link_fail
link_about_to_fail
BTS & MS full power
Radio Link Revival

full_power_rfloss = <*>
* 0 = disabled
1 = enabled
Default = 0
link_about_to_fail = <*>
.
.
.
Link Failure
Normal Channel Release
Normal Channel Release

rr_t3109 = <*>
(valid range 0 to 1000000)
default value 14400
* milliseconds
rr_t3111_tch/sd = <*>
(valid range 0 to 1000000
default value 1500
* milliseconds
rr_t3111_tch/sd = rr_t3110
KPI Monitoring And Flow

Charts To Rectify KPI
Issues.
Why QoS is Important?

Customers churn for various reasons: coverage, price,
billing
and customer service.
However, call quality is a major source of churn for both
corporate and consumer users.
KPIs
For Optimizing a Network , we need to maintain the
following KPIs :
ASSIGNMENT RATE (Call Setup Success Rate)
SDCCH ASSIGNMENT
TCH ASSIGNMENT
CONGESTION
SDCCH CONGESTION
TCH CONGESTION
DROP RATES
SDCCH DROP RATE
TCH DROP RATE
HANDOVER PERFORMANCE
HANDOVER FAILURE RATE
HANDOVER SUCCESS RATE
QUALITY
DOWNLINK QUALITY
UPLINK QUALITY
Assignment Rate
Assignment rate is the measure of how efficient and
successful is a Network in allocating the resources.
We need to monitor & maintain the following two
assignment rate :
TCH assignment rate .
SDCCH assignment rate .

Possible Causes:
Interference.
Link Balance.
Congestion.
Access failure.
Hardware.
Others.
Call Establishment
pch_q_page_discar
d
access_per_pch
pch_agch_q_length
if
timer
expires
inv_est_cause_on_rac
h
chan_req_ms_fail
page_req_from_ms
c
MS
C
C
R
page_req_from_msc_fail
chan_req_cause_at
mpt:
0: originating_call
1: emergency_call
2:
cm_reestablishment
3: location_updating
4: paging_response
CONNECTION
ESTABLISHED
CC
CREF
conn_refused
if
timer
expires
alloc_sd_fa
il
chan_req_ms_blk
page_req_ms_fail
conn_req_to_msc
ms_access_by_type
0..7
ok_acc_proc
0..7
timer
- busy_sdcch+1
- ber/path_balance
- sdcch_congestion timer
start
(if last sdcch was
assigned)
sdcch_con
g
rr_t310
1
access_per_agc
h
alloc_sdcch
chan_req_cause_atmpt
0..4
MS
ok_acc_proc_suc_rac
h
access_per_rac
h
sms_init_on_sdcch
ok_acc_proc:
0:
cm_serv_req_emerg
1: cm_serv_req_call
2: cm_serv_req_sms
3:
cm_serv_req_supp
4: cm_reestablish
5: page_response
6: imsi_detach
7: location_updated
CONNECTION
REFUSED
ms_access_by_type:
0: ms_pgsm_only
1: ms_dcs1800_only
2: ms_pcs1900_only
3: ms_pgsm_egsm
4: ms_pgsm_dcs1800
5:
ms_pgsm_egsm_dcs1800
6: ms_pgsm_pcs1900
7:
ms_pgsm_egsm_pcs1900
Call Establishment 2
- total_calls
- zone_change_atmpt:
tch_assign_to_inner_zone
(Bin 3)
- busy_sdcch-1
sdcch_congestion
timer stop if
running
- alloc_tch
- zone_change_atmpt:
tch_assign_to_inner_zone
(Bin 3)
ma_complete_to_m
sc
CONNECTIO
N
ESTABLISHE
D
ma_cmd_to_ms
The following statistics are pegged here:

- tch_usage/ms_access_by_type
- ms_tch_usage_by_type/tch_usage_ext_range/tch_usage_inner_zone
- busy_tch+1
- ber/path_balance
- chan_dl_tx_pwr_lvl/chan_ul_tx_pwr_lvl/uplink_path_loss
- tch_congestion/tch_cong_inner_zone (if all tchs are now used)
alloc_tch_f
ail
ma_fail_from
_ms
ma_req_from_msc
ma_cmd_to_ms_b
lkd
clr_req_to_m
sc
(= lost
calls)
- busy_tch-1
- tch_usage/ms_access_by_type
- tch_congestion timer stop if
running
Call Setup failures for MOC

1. MSC rejections
2. SD RF losses
3. User initiated
4. SETUP/Proceeding
losses
5. Assignment failure
6. SD RF losses
CREF, CM Service Reject

Clear Requests (before assignment
request message)
CM Service Abort, Disconnect, IMSI
detach
Release Completes
TCH blocking and the failure of the mobile
station to access the target TCH channel with
subsequent successful re-establishment on the
SDCCH channel. The cause value is no radio
resource available and radio interface failure
Clear Request (after assignment request
message) TCH Assignment Failures (Lost MS)
due to the failure of the mobile to access the
target TCH channel and failure to re-establish on
the SDCCH channel
Causes of Poor Call Success Rate

C a ll S u c c e s s R a te
C a ll S e t u p S u c e s s R a t e
D r o p C a ll R a t e
M S C A s s ig n m e n t A t t e m p t R a t e
(M A _ R E Q _ F R O M _ M S C )
T C H R F L o s s R a te
GOOD
BAD
C O N N R e fu s e d
SD R F Loss
C ip h e r M o d e F a i l
( T S M I, I M S I)
T C H B lo c k in g
T C H A s s ig n m e n t S u c c e s s
H O L o s s R a te
In te r-B S S H O L o s s
In tra -B S S H O L o s s
I n t r a - c e ll H O L o s s
MSC access failure causes

MSC
Connection
Paging overflow
causing discard
Missing
Pages
Not enough
access grant
block reserved
SDCCH
Call Setup
Success
Block
SDCCH Access
Failure
SDCCH access failure (Blocking excluded)

Low SDCCH Access
Success Rate
Too small T3101
Phatom RACH, check

co-BCCH and co-BSIC
Path Balance issue

on SDCCH carrier,
but not on BCCH
carrier
Hardware problem.
Check per carrier
chan_req_ms_fail
and alarm
Overshooting
Link Balance, due to DB

setting.
ms_txpwr_max_cch,
ms_txpwr_max_cell,
ms_txpwr_max_def, max_tx_bts
A hardware failure may have occurred if a BSS has timed out before allowing an MS to establish a
call (when SDCCH resources are available for an immediate TCH assignment).
Utilising 3212 for SD access rate and

capacity optmisation
3212 : Timer is used for periodic location updates,

this timer can be very helpful for controlling higher
no.of location updates at border sites hence
utilization of SDs can be normalized.
Utilising Hystersis for SD access and

capacity optmisation
Low Call Setup Success Rate Cause

Call Setup
Success
SDCCH RF Loss
TCH Block
Improper setting on
ms_txpwr_max_cch &
ms_txpwr_max_def
Call Clearing Timer
t3109<<radio_link_timeout,
this causes unclear call
generating UL interference
Coverage Hole
Path Balance issue

on SDCCH carrier,
but not on BCCH
carrier
Cipher Mode Fail
Hardware problem.
Check per carrier
chan_req_ms_fail and
alarm
MSC send
CONNECTION
REFUSED
Overshooting
CM Service Abort
Link Balance, due to DB

setting.
ms_txpwr_max_cch,
ms_txpwr_max_cell,
ms_txpwr_max_def, max_tx_bts
Call Setup Parameters - MTC
Common Control Channel (CCCH) Configuration
Call Setup Parameters - MTC
Battery v/s MTC setup time

bs_pa_mfrms => 6
This controls the repetition rate of paging transmissions for
each Paging Group. A small value of bs_pa_mfrms minimises
MS-terminated call setup time, a larger value reduces idlemode power consumption in the MS.
In modern GSM handsets, which incorporate a low-power
chipset, idle-mode power consumption is almost directly
proportional to the value of bs_pa_mfrms. Thus if bs_pa_mfrms
is doubled, the idle-mode battery life of the MS is almost
doubled.
The current database setting of bs_pa_mfrms is set to 2. This
gives a Paging Group repetition period of 4 multiframes, which
is 940ms.
It is recommended that bs_pa_mfrms be increased to 6, giving a
repetition period of 8 multiframes (1880ms). This will increase
MS-terminated Call Setup time but will dramatically improve
the idle-mode battery life of the latest MSs by up to 2 times.
Paging Delay v/s Batt. Life
bs_pa_
mfrms
Paging
Group
Period (ms)
Mean
Paging
Delay (ms)
Paging
delay in
Seconds
Relative
Battery
Life (Idle
Mode)
470
235
0.24
1.0
705
353
0.35
1.4
1,175
588
0.59
1.9
1,410
705
0.71
2.1
1,645
823
0.82
2.3
1,880
940
0.94
2.5
2,115
1,058
1.06
2.6
SDCCH Blocking
High SDCCH
Blocking
BUSY_SD_MAX =
Equipped
SDs
Find Faulty TS
from BER
statistics or
alarm
NO
YES
SDCCH Mean Holding Time

coverges to T3101
Phantom RACH (BSS

Statistics
Application); Path
imbalance on SDCCH
carrier, but not on
BCCH carrier
YES
NO
lot of OUT_INTRA_BSS_HO_RETURN
& OUT_INTER_BSS_HO_RETURN
Check neighbor
IN_INTRA_BSS_H
O_RETURN &
IN_INTER_BSS_H
O_SEIZE, if
high, check
neighbor FP.
YES
NO
Lot
of
Location
Update
Resign the LAC

Border; check
the T3212
YES
Neighbor TX power
reduced
is
Neighbor Cell Outage or

own cell carrier outage
(Note: Each carrier can
have only 2 SDCCH/8)
Neighbor BCCH is
interfered, its BSIC
can't be decoded
Missing Neighbor or
Incorrect neighbor
database
Overshooting
NUMBER_SDCCH_PREFERRED
not enough
is
Inappropriate
C1,
C2
Timer rr_t3101
This timer is very useful where SD assignment rate is low

By increasing its value the time for L2 establishment will
increase. Very useful for cells with larger coverage radius for
users with relatively poor signal strength at edges.
SDCCH Capacity gain through T3101

T3101 => 1500
This timer is used during the establishment of the SDCCH, and is
used to guard against the situation where the MS fails to access
the SDCCH. When accessing the SDCCH, the MS can transmit up
to 6 SABMs at intervals of 235ms.
This means that T3101 only needs to be greater than 6*0.235s =
1.41s. Therefore it is recommended that T3101 be be reduced
from its current value of 2000 ms set to 1500ms.
Example: BTS SDCCH mean holding time = (busy_sdcch /
alloc_sdcch) * Interval length = (0.68/367) * 1800sec = 3.36 sec. In
this time the number of failed channel requests were 44
(chan_req_ms_fail). Mulitiplied by 2000 ms gives 88 sec. Reducing
this to 1500 ms gives 66 sec. The number of successful assigned
SDCCHs is 323 (alloc_sdcch - chan_req_ms_fail), times 3.36 sec
(mean holding time) is 1085 sec.
This number increased by 88 sec and compared by a increase of 66
sec gives 2 % (22/1085) SDCCH capacity gain with no adverse
effects !!
TCH Blocking
High TCH Blocking
BUSY_TCH_MAX =
TCHs Equipped
Coverage Hole, improper

downtilt & orientation
Neighbor TX power is
reduced
NO
Find Faulty TS
from BER
statistics or
alarm
Neighbor Cell Outage or

own cell carrier outage
GCLK Shift. Check Alaram

GCLK 4, 14, 230
Long Timer Setting

1. Intra-BSS HO: rr_t3103
2. Channel Release: rr_t3109
Any high OUT_INTRA/

INTER_BSS_HO_RETURN
Inappropriate
directed
retry, congestion HO
setting: congest_ho_margin
Add radio with adding a

new cabinet
Neighbors' BCCH
Interfered, BSIC can't
decoded
be
Overshooting
- Enable
POOR_INITIAL_ASSIGNMENT &
MS_MAX_RANGE
SDCCH is more than

required from Erlang
Table. Reconfigure number
of SDCCH is required. Or
enable Channel
Reconfiguration
YES
Shift
traffic between
layers
Site Reconfiguration. If
BUSY_TCH_MAX - 8 >
Equipped TCH
Find neighbor which has

high IN_INTRA_BSS_HO_RETURN
and IN_INTER_BSS_HO_SEIZE
Missing neighbor or
incorrect neighbor
database
Shift traffic between

BANDS
YES
Check neighbor
frequency plan
RF loss rate
SDCHC & TCH RF Loss
A lot of OUT_INTRA_BSS_HO_RETURN
YES
Check neighbor
IN_INTRA_BSS_HO_RETURN &
IN_INTER_BSS_HO_SEIZE, if
high, check neighbor FP.
NO
OUT_INTRA_BSS_HO_REQ OUT_INTRA_BSS_HO_ATTEMPT
&
OUT_INTER_BSS_REQ_TO_MSC OUT_INTER_BSS_HO_ATTEMPT
are LARGE
YES
Find blocking
neighbors by
HO_NO_RESOURC
ES
NO
Neighbors' BCCH
interfered, BSIC
can't be decoded
Path Balance
> 120; <100
Delay Handover
External
Interference
e.g. Wideband
Repeator
Neighbor Cell
Outage
Negative handover
Use inappropriate
ARFCNs
GCLK Shift, no
handover to
adjacent sites
No handover
Faulty radio, may

compare radios of a
cell
Missing neighbors
Incorrect external
neighbors
Poor HPDC setting
Coverage hole
Handover Fails
HO
Failure
No
lot of OUT_INTRA_BSS_HO_RETURN
HO
YES
Check neighbor
IN_INTRA_BSS_H
O_RETURN &
IN_INTER_BSS_H
O_SEIZE, if
high, check
neighbor FP.
HO
>
hreqt
Incorrect external
neighbor
Loss
Poor
For Ericsson MSC, if cells are neighbours in

the same LAC there is no need to declare
them
as neighbours in the switch. If they are
from different LAC's they have to be
declared as neighbours in both MSC's.
HDPC setting
In
Small
Alcatel 1240 MSC, for one LAC/CI, there

are two places in the database
to define it. One for call setup, another
for inter-MSC handovers. The MSC
should double check their LAC/CI setting on
both places.
rr_t3103
Poor frequency plan or

external interference
- check Ul/DL quality
handover %
If the A interface is Phase 2 and E

interface is Phase 1, then secondary
handover on one direction will have problem,
this problem occurs on Nortel-Siemens MSC
interface.
Small
handover_power_level
The handover number in Nokia MSC has been
used up, or an improper number of
available handover numbers is assigned. And
hence no inter-MSC handover is
possible.
Good qualified
neighbors have blocking
Diversity is enabled but no diversity

antenna is connected
- the Rx/Tx antenna was initially
connected to the port B on the SURF of
the Horizon, it has been moved to the
port A.
Late
Ho
Large
hreqave
X hreqt
Large HO_MARGIN
Improper setting of
handover_recognised
_period and bssmap_t7
Improper HO algorithm
(Type 1-7)
All qualified neighbors

have blocking
rr_t3103
Neighbor analysis
Neighbour lists are difficult to keep up-to-date. Often neighbours are never
deleted as new cells are commissioned and cells which were previously
neighbours should not be any more.
Also, the difficulty in predicting cell coverage areas means that often
mobiles are using cells in non expected areas and hence no neighbours were
planned.
By temporarily over-populating the neighbour list, all mobiles will report
back all neighbouring cells that they can detect, whether they are in the
neighbour list or not. Any neighbours that are found in this way could
represent a missing neighbour. Each missing neighbour represents a
potential dropped call due to the absence of handover when required. On the
other hand, there could be neighbours with no reports that should be deleted
or neighbours found in the measurement reports that should not be reported.
Note :
One should overpopulate the Neighbor list for any new site in the Network.
Once the site is on Air for around 3-4 days , the per neighbor stats can be
analyzed and corrective measures like deleting , changing margins and even
analyze overshoots can be taken care of.
Also one should remember to delete the unnecessary Neighbors which
sometimes remain there even after new sites have been added in the
Network. This can be done by enabling the Neighbor stats for cells initially
with >10 Neighbors and delete the unnecessary neighbors.
Neighbor analysis
Missing Neighbours
The problem of a cell having a missing neighbour could be
mainly due to a mistake in the neighbour list, or in either the
planning or deletion processes.
First step is to get information directly from the stats or CAT
tool about RF losses per carrier or per cell. If a cell presents a
high value for this statistic (perhaps combined with a high rate
of quality handovers and a high rate of handover failure) a
missing neighbour problem could be present.
Other way is by analysing the drivetest , during drive test one
can very easily identify the missing neighbor by correlating
Neighbor list and Geographic information.
CTP tool can also be utilised for the above purpose. In CTP
adding dummy neighbors and using CTP hot-spot neighbor
analyses can help us to find the strongest candidates which
have not been added as the neighbor or are missed during
updating the neighbor database.
Quality Issues
Quality
When a cell presents bad performance in the stats (drop call
rate, handover failure, etc.) it is necessary to analyse the
quality on it. A good indicator for the quality in one cell are
the handover per cause stats. There, it can be found the
percentage of quality handovers that are being performed in
the cell. The handover per cause distribution could show
(depending on the complexity of the system) around 45-50%
PBGT Ho and 20% uplink or downlink quality handovers on
average. Some systems could have better figures and others
a little bit worse, but the objective is to identify the cells that
are far away from the average values in the area under
revision.
Quality Handovers
Quality handovers should be very low in percentage w.r.t the
other handovers . Also These must be enabled.
Acceptable value of both combined is around 30-40% .
Which means around 20% of U/L and 20% D/L handovers
due to quality reasons.
One should not forget that quality though should be
minimum but they must be enabled in the network.
Quality Imbalance
It is always useful to verify if the system is unbalanced in
terms of quality, that means it is more sensitive to bad quality
in either the uplink or the downlink. This indicates which side
of the link must be paid more attention considering a more
aggressive power control, handover settings, link balance etc.
It also indicates if the network design is limited interference
wise in the uplink or downlink directions. In the figure below
it is clearly seen that uplink is worse than the downlink.
It is possible not to be affected by any interference or
equipment problem but handover speed problem. If there are
too many reports above the quality handover threshold an
increase of handover speed could be needed .
If there are other neighbours providing better quality, the
best thing is to handover the calls to them quicker.
It could be that it was a coverage problem and nothing can
be done but improve it.
Quality Imbalance
Bad U/L
where as
D/L is good
Quality Imbalance Analysis - CTP
Analysing CTP Trace Call-Distribution Analysis - Process Combined Current

Data checking the parameters RXQUAL_UP vs. NEIGHBOUR_MARGIN and
RXQUAL_DOWN vs. NEIGHBOUR_MARGIN, it should be checked if there is any
strong neighbour to handover the calls to when bad quality is observed. Then
handover speed should be increased. It could be that it was a coverage problem
and nothing can be done but improve it. Anyway it can not be seen the relation
among {bad_quality-neighbour_margin-server_level} at the same time. In the
graph below, it is drawn RXQUAL_DOWN vs. NEIGHBOUR_MARGIN.
COVERAGE OPTIMISATION
Coverage Issues
Coverage holes: Places with no coverage or low level coverage, where there is
no dominant server are potential spots of bad quality. In an environment with tight
reuse pattern, and hence higher noise (interference) level, a clear dominant server
cell needs to be identified everywhere. This points need to be identified and new
sites can be required to provide extra coverage.
Excessive Overlap: Cells covering an area bigger than the zone where they are
dominant and serving, are radiating useless power to areas where other cells are
serving. When the same frequencies are reused in all the sites (1x3 reuse) or even
in all the cells (1x1 pattern), this unnecessary overlap is directly translated into
interference.
Cell Over-shooting: Particularly harmful are the situations where the signal of a
cell reaches areas far away from the site with high level, causing downlink
interference, and receiving uplink interference from mobiles far away. In the cases
where the level is high enough to make this cell be the server, mobiles transmit
high power introducing very high uplink interference in the surrounding cells.
Umbrella Cells: Some particular sites placed in high areas, hills, etc. in the fist
stages of the network evolution, to make big coverage areas have become umbrella
cells as the network density has increased. They are creating areas with total
overlap between cells, and taking part of the traffic that should be carried by lower
and closer sites. The level of interference caused by this kind of cells is very high,
especially harmful in the uplink path because these cells receive the signal from a
big amount of mobiles
Coverage optimisation
Overshooting
Communication
Interference
Hole
Overlap
The objectives of this coverage adjustment plan are the
following ones:
Reduce the global interference level in the system and
permit tighter reuse patterns.
Improve the in-building penetration, focusing the power
radiated in a limited and well-defined area. The coverage in
these scenarios will improve at the same time that the quality.
Avoid undesired over-shooting effects.
Balance the carried traffic between neighbour cells because
the area to be covered between them is divided with the
same weight per cell.
Over Shooting Cell
After Height Reduction and Downtilt
Following activities can be carried out to meet
the above targets :
Tilting down/up site antennas.
Height reduction/increase of the sites.
Power reduction/increase of the sites.
Parameter optimisation (handover margins/access
parameters).
Containment of Coverage
The choice of the highest point in an area for a cell site would most
likely only work in low-density suburban or rural areas where the
overall number of sites needed to meet subscriber demands is small.
Frequency reuse would not be necessary and these sites could be
considered as broadcast sites.
Antenna Separation
Antenna Separation
Coverage Estimation
Containment of Coverage
Antenna Downtilt :
By tilting the entire radiation pattern of a particular
antenna, one can conceivably control its coverage pattern
within a specific area. Controlling the beam path will allow
the provider to focus the coverage area and, in some cases,
eliminate interference caused when the beam is allowed to
propagate beyond its desirable coverage area.
Downtilt can be achieved in two ways, through mechanical
as well as electrical downtilt.
Effects of these downtilts will be shown in the following
slides.
Mechanical Downtilt
Mechanical Downtilt
Electrical Downtilt
Electrical downtilt
Electrical downtilt
Downtilt angle
Utilizing CTP for Optimization

With the rapid expansion of networks, traditional
optimisation techniques are no longer suitable due to the
high number of dedicated people and time required by these
tasks. To ensure that good optimisation is feasible in large
networks it is necessary to:
Collect data with minimum site visits or drive tests.
Collect large amount of data for every cell in order to
ensure statistical validity.
Ensure that most of the tasks can be analysed and database
changes recommended using automated procedures.
A more optimised network
Less optimisation manpower required per cell, so the same
staffing level can cope with an expanded network.
Better information to allow the skilled optimisers to
concentrate on the most important/difficult areas.

The collection of call_trace data on a per cell basis and its
analysis with CTP
(and sometimes with a simple post-processing of this CTP output
with EXCEL
or similar tools) configure a powerful tool for optimisation and
troubleshooting.
It is a very critical issue, to have relevant data from the network
in order to have an accurate picture of it for optimisation.
Add dummy neighbours previously in all cells so that the mobile
scans all the BCCH frequencies. The following settings are
proposed as an example but they should be changed for each
network if processor performance is affected.
trace_call cell_name="?????????"
Enter trigger event: all
Enter additional data types (Basic is included): all
Enter Measurement Report interval (x480ms): 1
Enter call selector type and value: nth=10
Enter maximum simultaneous calls traced per LCF: 4
Trigger enabled time:
Enter total number of calls to be traced: 250
Trace calls beyond scope?: no
Enter destination for trace data: omc

Timing Advance graph in the CTP Trace Call-Distribution
Analysis - Process Current Data should be checked. A
distribution with a separate peak will indicate than the cell is
creating this kind of problems.

Moreover, it can be checked if this far away coverage is
causing problems by activating a drop-call filter (only shows
the timing advance distribution for the calls that dropped).
Below is shown the timing advance profile for the dropped
calls in one cell. It is clearly seen that a good number of
dropped calls are produced in the peak of high timing
advance values.
Link Unbalance Reason for Poor Qual

Path Balance / Tx & Rx problems
It is not advisable to have the link unbalanced to either the
mobile or the base station sides. Having the link unbalanced
several problems can be detected:
If a cell has the link unbalanced (as happens usually in
towns), to the mobile side, the cell is not giving coverage in its
optimum coverage area, so losses and bad quality will increase
in the downlink direction. The problem will be even higher
inside buildings .
In the opposite side, if the link is unbalanced to the base
station side, losses and bad quality in the uplink will appear.
The reuse pattern that can be implemented in the system will
not be as tight as it could be because of the cell radius, bigger
than necessary and the higher interference that is introduced
in the system then. Also since the U/Link losses will be higher
MSs will be generally transmitting at higher powers resulting
in increase Network interference levels.
Link Unbalance Reason for Poor Qual

This issue can be analysed by taking the Path Balance Mean
stats for the 2-3 peak hours and analysing them. If the value
is <=102 , then problem is with the downlink and if >= 118 ,
then problem is with the downlink.
To cater this kind of problem we need to analyse the Return
loss of the feeders. If the return loss is greater than
required , then by utilising the Distance to Fault graphs in the
Anritsu site master we can analyse where the fault lies.
For the Uplink path loss, Surf / Surf ports can also be the
issue. One of the ways to analyse this is by swapping the
Receive cables, If the path balance improves then either the
port or the Receive cable is faulty. To add to this sometimes if
the main receive cable is faulty but the diversity cable is ok
,path balance will be good and still there will be higher drops.
For this disable diversity and analyse the path balance stats ,
if it goes bad then straightway we can say there is something
wrong with the other feeder.
Link Unbalance Analyses - CTP

This problem can be analysed through the CTP Trace Call-Distribution Analysis Process Current Data option. Selecting the parameter path_balance (DL-UL) the
transmission path can be evaluated. This graph will show if there is any radio
path problem in the cell, feeders, cables etc. If the transmission and reception
are through the same antenna the distribution should be a gaussian curve
centred in zero, but if there is reception diversity the distribution will be shift to
the negative side. Because of the maximum transmission powers used in this
calculation is set to 43 dBm, if the equipment transmits at lower power
(microcell, pico...) or there is any attenuation set in the parameter max_tx_bts
the curve will shift to negative values.
Sometimes specific problems in the transmission or reception paths and/or
RCUs are behind this unbalance. In order to check any problem with
transmission / reception paths in a cell, it is required to analyse the trace_call
data collected trough Trace Call-Distribution Analysis - Process Current Data or
CTP Trace Call-Distribution Analysis - Process Combined Current Data.
Comparing different carriers in the same cell and looking for any differences in
rxlev and/or rxqual distributions among them, either in the uplink or downlink
directions, it is possible to detect damaged feeders, antennae or poor
calibration in a certain RCU. Obviously, it should be taken into account that the
same profile should be produced for the quality or level distribution when
comparing TCHs using fixed frequencies with other TCHs with fixed
frequencies or hopping TCHs.
Poor Downlink - CTP
Poor Uplink - CTP
INTERFERENCE
Interference in GSM
Co-channel
Adjacent channel
External
interference
Co-Channel Interference Source

These may be integral to the communications system related or totally external.
Transmitter spurious emissions will raise the noise floor in the receive band.
Insufficient transmit / receive isolation will cause receiver blocking.
Any non-linear device such as the output stage of a transmitter, front end of a
receiver, dissimilar metal junctions in antennas and the tower itself (the rusty-bolt
effect) will generate inter-modulation products. If they fall in the transmit band of the
base station, they will interfere with the mobile receive and if they fall in the receive
band of the base station, they will interfere with signals transmitted by the mobile.
Towers located close by exacerbate receiver blocking.
Competitors towers located far away cause mobile blocking, the near-far problem.
Co-locations increase the likelihood of intermodulation products.
Harmonic radiation, spurious emissions and intermodulation products can be
generated
from security devices, tv and radio stations, dc to dc converters, motors using pulse
width speed control etc.
Interfered Frequency Analysis -CTP

Interfered Frequency
The first clue for detecting if there is interference, is the quality distribution. If the quality
distribution of one carrier does not follow a normal quality distribution (assuming the
compared carriers have the same reuse pattern and they have hopping enabled if it is
enabled in the carrier under comparison), an interference problem can be present.
Below is shown the quality distribution of a carrier being interfered. This carrier is using
a fixed frequency and the quality samples do not decrease from 0 values to 7 values
exponentially.
Interfered Frequency Analysis -CTP

In CTP Trace Call-Distribution Analysis - Process Combined Current
Data it is possible to analyse the relationship between rxqual and rxlev
in both paths for every separated carrier, and in case that any of them
is reporting strong levels with bad BER values, interference problems
will be present.
If
most
MRs
lie
here
then
interf
erenc
e is
there
Mitigating Effects of Interference
Adjacent Channel Interference

Adjacent channel interference acceptable level is -9 db or
above.
C / I ad <= -9db
Drive Test Analysis
Drive Test Measurements

Statistical Parameters
Parameters
Attempted Calls
Dropped Calls
Blocked Calls
Handover Attempts
Successful HOs
Failed HOs
Measured
Best Server
Rxlev
Rxqual/FER/SQI
Neighbor Rxlev
TA
Tx Power
L3/L2 Messages
Test Phone Measurements Groups

Call Control
1.
Call Sequencing
2.
Coercive Testing
3.
Call Processing Stats
Phone Measurements
1.
Idle mode
2.
SACCH reports
3.
Frequency Hopping info
Displays
1.
Graphical
2.
Tabular
Protocol Messaging
1.
L3 / L2
Phone Measurements
IDLE Mode
Serving Cell
1. ARFCN
2. Rxlev
3. Cell ID
4. BSIC
5. C1 & C2
LAI
1. MNC,MCC,LAC
Neighbor Cell
1. ARFCN
2. Rxlev
3. BSIC
4. C1 & C2
Dedicated Mode
Phone State
MTX
TA
Rxlev ( Full and Sub)
Rxqual ( Full and Sub)
FER
RLTC
Log file Analysis
Below lists common problems which can be observed from Drive
Undecoded BSIC
No Handover
Delay Handover
Ping Pong Handover
Overshooting
High Overlapping
No Dominant Server
Poor Coverage
Unreasonable Serving Area
Interference
Handover Failure
Handover Loss
Drop Call
Undecoded BCCH (1)

Description:
BSICs cant be decoded in 5s
Usually consider 3 strongest neighbors
Reason:
GCLK shift, only decodes same site BSICs
Channel interference
Non-BCCH carrier, no dedicated spectrum for BCCH
Undecoded BCCH (2)
No Handover (1)
Description:
Neighbor BSIC is decoded and COMMON handover
requirement ( handover margin and min rx level ) is fulfilled
but there is never a handover
Reason:
Missing neighbor
No such neighbor in CM database
Incorrect external neighbor
Target cells LAC/BCCH/BSIC in add_neighbor is different
from those in equip_rtf
Never used OMC-R Proxy Cell to propagate external
neighbor information
Improper setting of hreqt , hreqave , N & P.
Serving cell overshoots/covers too far away
No Handover (2)
Delay Handover (1)

Description:
Neighbor BSIC is decoded but handover occurs in much
later time
Reason:
All possible neighbors suffer blocking
Large hreqt * hreqave
qual_power_flag is enabled, full BTS/MS power must be
reached before handover
Large handover_recognized_period and bssmap_t7 setting
Delay Handover (2)
Ping Pong Handover (1)

Description:
Lot of handovers between cells
Time between Handover is around hreqt*hreqave of
such HO cause
Reason:
Improper hardware calibration
Hardware fault
UL/DL interference
Negative handover
Different coverage footprint for antennas of a cell
Ping Pong Handover (2)
Negative Handover (1)

Description:
Serving cell hands over to a weaker neighbor
Reason:
ho_only_max_power is enabled
qual_margin_flag is disabled
ho_margin_usage_flag is enabled with negative
ho_margin_rxqual/rxlev
Negative HO_MARGIN
Micro-cellular algorithms are enabled, especially type 5
Negative Handover (2)
59dBm
before
HO
66dBm
after
HO
OverShooting (1)
Description:
Cell shoots at far distance but that location has closer
cells around
Reason:
Overshooting cell has small downtilt, 0 degree!
Overshooting cell has too high altitude
Closer cells have overshooting as well
BSIC of closer cells cant be decoded
OverShooting (2)
Over Shooting Cell
After Height Reduction and Downtilt
High Overlapping (1)

Description:
Cells have general rxlevel difference within 5dB
Reason:
Overshooting
Too many cells in that area
Poor antenna down tilt
Problem in Antenna Pattern.
High Overlapping (2)

-65dBm
-65dBm
Over Lapping Area
-65dBm
-65dBm
No Dominant Server (1)

Description:
Rxlevel of best neighbors are close to that of serving cell
Reason:
Poor antenna downtilt
Lack of near-by site
No Dominant Server (2)
Poor Coverage (1)

Description:
Low rxlevel with poor rxquality
In rural area, rxlevel is less than 15 (-95dBm)
In city center, rxlevel is less than 35 (-85dBm)
Different location has different threshold, noise level is
the key point
Reason:
Lack of cell site
BSIC of dominant server cant be decoded
Dominant server has blocking or cell-bar
Handover problem. E.g. missing & incorrect neighbor,
negative handover, no & delay handover
Poor Coverage (2)
Unreasonable Serving Area (1)

Description:
Coverage area of the cell is incoherent to the antenna
direction
Reason:
Wrong cable connection to antennas
Incorrect record of antenna orientation
Incorrect ANTENNA_SELECT
Unreasonable Serving Area (2)

Cell ID:101
BCCH: 35
Cell
ID:102
Cell
ID:103
BCCH: 40
BCCH: 45
Interference (1)
Description:
High rxlevel with poor rxquality
Reason:
Not using dominant server
No handover
Turn the corner with delay handover
Interference (2)
Handover Failure (1)

Description:
MS fails to reach target cell, so return to source cell
MS sends HO FAILURE and UL-SABM to source cell and a
response is received
Reason:
Poor coverage
Hardware issue
Poor Path balance
External interference at UL, like wideband repeator
Refer to GSM BSS Statistics Analysis Handbook
Handover Failure (2)
Handover Loss (1)

Description:
MS fails to reach target cell, but cant return to source
cell
MS sends HO FAILURE and UL-SABM to source cell but
no response
Reason:
Poor coverage
Poor Path Balance
Hardware issue
External interference at UL, like wideband repeater
Handover Loss (2)
UL Drop (1)
Description:
BSS doesnt receive UL SACCH for link_fail times
BSS stops transmitting DL power
Reason:
External interference
Poor Path Balance
Hardware issue
Different propagation pattern Tx/Rx antennas.
Faulty ancillary. UL path loss >>> DL path loss
UL Drop (2)
Drop Call (1)

Description:
DL case: Radio_link_timeout counter decreases to 0
UL case: link_fail counter decreases to 0
Layer 2: BSS/MS send SABM/DISC in every T200 for
N200+1 times, and no response from recipient
Reason:
All cases in this presentation
Drop Call (2)
Make Your Own Optimization Tool
Utilizing MS Access
MS access can be utilised to build a daily analysis tool
:
Import the cell stats daily basis
Import carrier stats at least weekly
Set threshold levels for each cell based on the past data.
Daily compare the threshold values for the cells.
Select around top 30 cells which are crossing thresholds ,
each for separate causes. e.g High Tch drop rate , High Sd
drop rate , Low total calls , Poor HO succ rate , Low
assignment rate
Following the above process around 150 worst performing
cells will be analyzed daily.
At least weekly do the Path Balance and High interference
analysis and take corrective measures as discussed
Summary
Network Performance related stats.
Network Performance related parameters.
Power Control and Handovers.
KPI monitoring and flow charts to rectify
KPI issues.
Coverage Optimization.
Interference.
Drive Test Analysis.
Where to Get More Information

Motorola Manuals :
Sys02 , Sys03 , Sys12 , NET03 , CP02 , CP15 , Sys04
Motorola internal site :
compass.mot.com

Radio Optimisation GSM

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Radio Optimisation GSM

Uploaded by

Copyright:

Available Formats

Radio Optimization

Syed Irtiqa Ali

DAY 2 28th July

DAY 3 29th July

Need For Optimization

Optimization Flow Chart

BSS Rolling Averages

N and P Voting Mechanism

HREQAVE/HREQT and N/P

CELL SELECTION / RESELECTION

MS Access Power Output

* Integer code for dB offset

(for penalty_time database value 0 30)

* 1 C2 parameters are to be broadcasted

* Integer code for 20 sec periods

(for penalty_time database value 0 30)

Cell Reselection Example

Serving Cell Database Parameters Best Neighbour Cell Database Para

sdcch_need_high_water_mark = <*> (default 2) 1 - 39

sdcch_need_low_water_mark = <*> (default 12) 10 - 4

tch_full_need_low_water_mark = <*> (default 255) 0 -

SDCCH Reconfiguration TCH to SDCCH

High water mark = 2

SDCCH Reconfiguration SDCCH to TCH

Low water mark = 18

Signal Strength Measurements

BSS Processing and Threshold

Downlink Received Signal Strength

MS/BSS Power Control

Standard Power Control

Power Control Parameters (1)

Command Not Acknowledged

Power Control Parameters (2)

Command Not Acknowledged

Power Control Parameters (3)

ms/bts_p_con_ack: waiting period for power command

Power Control Parameters (4)

POWER CONTROL OPTIMISATION

Separate uplink & downlink step sizes

SEPARATE increment/decrement step sizes for uplink and down

Power Control - BSS

BTS Power Control

bts_p_con_interval = <*> max_tx_bts = <*>

* 0 Power Control Disabled

1 Power Control Enabled

Power Control - RXQUAL

Oscillation Prevention for MS

Oscillation Prevention for BTS Power

Dynamic Power Control

Dynamic step size

IF ENABLED , increment / decrement step size can be

RAPID_POWER_DOWN feature can work with Optimised

Dynamic step size

4 types of dynamic step size adjustments

1. Dynamic power step size increase due to poor RXQUAL

occurs when rxqual falls below the lower rxqual

Dynamic power increase due to poor RXQUAL

Standard step size

Optimised Power Control

Optimised Power Control

Dynamic power decrease due to high level

Optimised Power Control

occurs when rxqual is above the upper rxqual threshold

Dynamic power reduction due to

bts_p_con_interval = <> max_tx_bts = <>