ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL

EDITION1.2EFFECTIVEDATE:01January2011

KPI 0ptimization Piocess

AppenuixS
iefeis to page 1S of Netwoik Peifoimance Nonitoiing & 0ptimization Piocess
Buwaei











ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for SDCCH Assignment Success Rate Optimization:

Definition: When From the MS SDCCH Request is sent to Base Station and if MS
successfully gets the SDCCH in response SDCCH Assignment has done successfully.
PROCESS for Optimization:
1. Identify the Bad performing Cells for SDCCH Assignment Success Rate
2. Take the detailed report showing (Ex. Total SDCCH Assignment Request, Total SDCCH
Assignment Successful)
3. Follow the below mentioned Process after Analyzing detailed report...
4. From Report Check whether you have Idle SDCCH available in cell or not for SDCCH
Assignment; because the Main factor for lowering SDCCH Assignment success rate is
SDCCH congestion.
5. SDCCH Congestion:

a. Check The SDCCH Requests (Immediate Assignment Measurement Per Cell
Report form M200)
b. Ex. Call purpose, SMS, Location Update
c. If you find High SDCCH Request and low TCH utilization Check SDCCH
Dynamic Allocation Allow feature is enabled or not? if not enable this feature.
d. If you have very High SDCCH Request for Location Updating; optimize the LAC
boundary.
e. Only For some exceptional cases you can increase the Static SDCCH Time Slots.

6. Check Hardware/Transmission alarms; Resolve if find any.
7. Audit for any parameters related discrepancies and define as per standard parameters set.
8. RF and Environmental Factors:

a. Low Coverage Areas (Try to reduce low coverage patches with physical
optimization; New sites)
b. Interference/ Bad quality/ UL-DL Imbalance;
c. Check the states for TRx on which SDCCH is configured can be issue of TRx
also; Change TRx if you found random behavior of TRx.
9. After all rectification observe the subsequent days report if you still find the problem
repeat the same process with due care to Pin Point the actual cause.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

FishbonediagramfortherootcauseanalysishighSDCCHcongestionrate








PROCESS for SDCCH DROP Rate Optimization:
Definition: When MS is already on SDCCH and in-between communication with Base
station SDCCH channel got disconnected abruptly then SDCCH Drop has occurred.
PROCESS for Optimization:
1. Identify the Bad performing Cells for SDCCH Drop Rate
2. Take the detailed report showing (Ex. Total SDCCH Assignment Successful, Total
SDCCH Dropped)
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

3. Follow the below mentioned Process after Analyzing detailed report...

4. The Main Reasons for High SDCCH Drop Rate are improper Parameters Configuration
and Bad RF & Environmental factors.
5. First Audit for any parameters related discrepancies and define as per standard
parameters set.
6. Check for Neighbor Relations and correct if it is not proper.
7. For counter level analysis refer Call Drop Measurement per Cell report from M2000.
8. Low Coverage: Through Drive Test Find out the low coverage patched and try to
improve with physical optimization; New site; coverage enhancement features for some
cases(Ex. Power Boost Tech, No Combining, TMA/TMB)
9. Interference: Check for interference from repeaters, Intra-Network interference due to
aggressive reuse or improper Freq., Inter-Network can also be the case. Find out the
actual cause and rectify it.
10. Antenna System: High VSWR due to feeders, Improper antenna configuration(Ex. Sector
cable Swap)
11. Check for Hardware Issue and rectify if you found any.
12. After the activity check the subsequent days report and repeat the procedure for pin
pointing the actual cause.

FishbonediagramfortherootcauseanalysisforhighSDCCHdroprate


ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for RACH (Random Access Channel) Success Rate
Optimization:
Definition: Random Access Channel (RACH) is used by the MS on the uplink to request
for allocation of an SDCCH. This request from the MS on the uplink could either be as a page
response (MS being paged by the BSS in response to an incoming call) or due to user trying to
access the network to establish a call. For all services there will CH REQ (Channel Request)
from MS and in the response of CH REQ if MS will get the IMM ASS CMD (Signaling Ch)
Access to system is successful. Nature of this Access REQ is random so it is call Random Access
Channel Request.
PROCESS for Optimization:
1. Identify the Bad performing Cells for RACH Success Rate
2. Take detailed report and analyze for no of failure of Request and failures.
3. The main reasons for bad RACH success rate could be access from very distant place
with very low coverage; Parameters Configuration discrepancies.
4. First Check for Parameters Configuration discrepancies and correct as per standard
parameter set.
5. The main parameters to look for Huawei
a. MS MAX Retrans can set depending upon Traffic and Clutter.
b. Tx-Interger will reduce the RACH collision and can improve RACH success
rate.
c. T3122 waiting time for next network access.
d. RACH Min.Access Level(dbm) very important parameter for low coverage
rural areas.
e. CCCH conf & BS_AG_BLKS_RES check properly defined or not? Because
if you have overload with AGCH IMM ASS cant be send in the response of
CH REQ.

6. Check for Hardware Issues (Ex. BTS sensitivity has very crucial role to play here)
7. Check for Uplink Interference and quality.
8. Check for UL-DL imbalance and correct if any problem.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

9. After the activity check the subsequent days report and repeat the procedure for pin
pointing the actual cause.

FishBonediagramfortherootcauseanalysisofpoorRandomAccessSuccess















ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for TCH Assignment Success Rate Optimization:

Definition: When From the MS TCH Request is sent to Base Station and if MS successfully
gets the TCH in response TCH Assignment has done successfully.
PROCESS for Optimization:
1. Identify the Bad performing Cells for TASR( TCH Assignment Success Rate)
2. Take the detailed report showing (Ex. Total Assignment Request, Total Assignment
Successful)
3. Follow the below mentioned Process after Analyzing detailed report...
4. From Report Check whether you have Idle TCH available in cell or not for Assignment
and follow the below process.


ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

A & B in above Flow chart are measurement Points for TCH Assignment Failures...
5. As per the Above Process If you have already used Re-Assignment, Directed Retry
and Queuing features and still you are having issue with TCH Congestion (No Idle
TCH)... Try to Decrease Half Rate Triggering Thresholds...
6. Ex. Below Parameters for Huawei System
TCH Busy Traffic Threshold (%)
AMR TCH/H Prior Allowed
AMR TCH/H Prior Cell Load Threshold
7. Check for discrepancies with Parameter Configuration and set as per Standard Parameters
set available.
8. If you find Issue is not with High Traffic and Congestion... Check Hardware Issue (Ex.
BTS/BSC/MSC hardware / UL-DL Imbalance due to VSWR) resolve if you find any.
9. Transmission Issues at A-bis/A-ter/A links
10. If Hardware is Ok check for Bad RF Environment... (Very low Coverage, High
Interference, Bad Quality, Call from Distant Place (TA).
11. Follow below Process for Above Points... You can check the counters Report for Pin
pointing the actual cause. (Ex. Assignment Per Cell Report from M2000)


ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

12. Correct the affected area (Ex. If call is getting originated from High TA and getting failed
due improper strength ; Optimize the Site Coverage with Physical Optimization) and
check the subsequent days Report; If you still find the issue follow the same flow right
from the starting with due care to PIN Point the Actual cause..
13. TBF Success Rate
14. Average GPRS RLC throughput & Average EDGE RLC Throughput
15. Downlink Multislot Assignment Success Rate
16. SDCCH Assignment Success Rate
17. SDCCH DROP Rate
18. ACH (Random Access Channel) Success Rate
19. Assignment Success Rate











ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for Rx Quality Optimization:

Definition : Rx Quality is measure of BER of radio link between MS and BTS
Poor Speech Quality could be due to
Patchy Coverage ( holes)
No Target cell for Handover
Echo , Audio holes, Voice Clipping
Interference ---:
Co-channel
Adjacent channel
External
Multipath
Noise
Speech Quality Parameters
RxQUAL: Measured on the midamble.
Indicates poor speech quality due to radio interface impairments
FER : Measured on the basis of BFI ( Ping -Pong effect on speech )
Preferred under Frequency Hopping situation
Audio holes: Blank period of speech, due to malfunctioning of Transcoder boards or
PCM circuits.
Mean Opinion Score (MOS) : ITU standard for estimating speech quality
PROCESS for Optimization:
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

1) Physical optimization
2) New cell dependency
3) Overshooting
4) Neighbor list tuning
5) BCCH tuning (Freq plan)

From M2
Quality.






ALUMSO
EDITION1.2
2000 extract
OMPL2014ALU
2EFFECTIV
Rx Quality
UMSOPERATIO
VEDATE:01Janu
measuremen
ONALPROCESSM
uary2011
nt distributio
MANUAL
on Counters to know Trx

x cell wise

Rx
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for HOSR Optimization:

Definition: HO activity is performaed to maintain Call continuity and call quality .The
inputs that the BSC uses for making a handover decision, from the received MRs from the MS is
the DL signal strength, DL quality, and the signal strength of the six best reported neighbours.
From the serving BTS, for the same MS the BSC will use UL signal strength, UL quality and
TA.
Handover Process:
The GSM handover process uses a mobile assisted technique for accurate and fast
handovers, in order to:
- Maintain the user connection link quality.
- Manage traffic distribution
The overall handover process is implemented in the MS,BSS & MSC.
Measurement of radio subsystem downlink performance and signal strengths received
from surrounding cells, is made in the MS.
These measurements are sent to the BSS for assessment.
The BSS measures the uplink performance for the MS being served and also assesses
the signal strength of interference on its idle traffic channels.
Initial assessment of the measurements in conjunction with defined thresholds and
handover strategy may be performed in the BSS. Assessment requiring measurement
results from other BSS or other information resident in the MSC, may be perform. in
the MSC.
The MS assists the handover decision process by performing certain measurements.
When the MS is engaged in a speech conversation, a portion of the TDMA frame is idle
while the rest of the frame is used for uplink (BTS receive) and downlink (BTS transmit)
timeslots.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

During the idle time period of the frame, the MS changes radio channel frequency and
monitors and measures the signal level of the six best neighbor cells.
Measurements which feed the handover decision algorithm are made at both ends of the
radio link.
Classification By Reason:
Emergency HO
Timing advance (TA) Emergency HO
Bad quality (BQ) Emergency HO
Rx Level Drop Emergency HO
Interference emergency HO
load HO
Normal HO
Edge HO
Layer HO
Power budget (PBGT) HO
Fast moving MS HO (Speed-sensitive HO )
PROCESS for Optimization:
10. Identify the Bad performing Cells for HOSR
11. Take the detailed report showing cause & target cell
12. Check congestion; hardware Alarm; Quality; Rx level
13. Late Handover Handover margin (like Rx level-Rx Qual etc )need to define properly.
14. Ping-Pong Handover A proper Hysteresis is used to prevent the Ping Pong effect. This
can be caused by fading
15. Unnecessary Handover more number of handovers, higher risk of facing quality
problem and even in call drop
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

16. Missing neighbor Best server is not in there in neighbor list

17. BCCH Missing
18. Same BCCH & BSIC combination
19. one way neighbor handover
20. Neighbor cell in other BSC- need to define correct CGI,BCCHNO,BSIC
21. Congestion on other cell





Fishbonediagramfortherootcauseanalysisforhighhandoverfailurerate



PROCESS for TCH drop Optimization:
Definition: TCH drop (or a dropped call) could be broadly classified into 3 sub classes:
1. Degradation of the links (Uplink and Downlink): either degradation of Signal Strength
which falls near or lower than the sensitivity of the base station (around to -110 dBm) or
that of the mobile (around -104dBm) or degradation of quality of the links (Uplink and
Downlink) often due to interference.
2. Excess TA (TA>63 or excess path imbalance due to high TA).
3. Other Reasons.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for Optimization:
Call drops are identified through SACCH messages. A Radio Link Failure Counter value
is broadcast on the BCH. The counter value may vary from network to network. At the
establishment of a dedicated channel, the counter is set to the broadcast value (which will
be the maximum allowable for the connection). The mobile decrements the counter by 1
for every FER (unrecoverable block of data) detected on the SACCH and increases the
counter by 2 for every data block that is correctly received (up to the initial maximum
value). If this counter reaches zero, a radio link failure is declared by the mobile and it
returns back to the idle mode.
If the counter reaches zero when the mobile is on a SDCCH then it is an SDCCH Drop.
If it happens on a TCH, it is a TCH drop.
Sometimes an attempted handover, which may in itself have been an attempt to prevent a
drop, can result in a dropped call.
When the quality drops, a mobile is usually commanded to perform a handover.
Sometimes however, when it attempts to handover, it finds that the target cell is not
suitable. When this happens it jumps back to the old cell and sends a Handover Failure
message to the old cell. At this stage, if the handover was attempted at the survival
threshold, the call may get dropped anyway. If on the other hand the thresholds were
somewhat higher, the network can attempt another handover.












1 2
C h a n n e l R e q u e s t C h a n n e l R e q u e s t
I m m A s s i g n m e n t I m m A s s i g n m e n t
S e r v i c e R e q u e s t S e r v i c e R e q u e s t
S i g n a l l i n g S D C C H S i g n a l l i n g
: :
S i g n a l l i n g S p e e c h
T C H
R L T = 0 ; D R O P S R L T = 0 ; D R O P S
S D C C H D R O P ! T C H D R O P !
3 S D C C H / T C H
H a n d o v e r C o m m a n d
H a n d A c c e s s
H a n d o v e r F a i l u r e

From M2


ALUMSO
EDITION1.2
2000 extract
OMPL2014ALU
2EFFECTIV
Call Drop M
UMSOPERATIO
VEDATE:01Janu
Measuremen
ONALPROCESSM
uary2011

nt counters to
MANUAL
o know cause.

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

8.3.1 Fish bone diagram for the root cause analysis for high TCH Drop Rate

Figure 1: Fish bone diagram for the root cause analysis for high TCH Drop Rate

Figure 2: Fish bone diagram for the root cause analysis for high TCH Drop Rate
T C H D r o p R a t e
L o w S i g n a l S t r e n g t h D L L o w S i g n a l S t r e n g t h U L
B a d Q u a l i t y D L B a d Q u a l i t y U L H i g h T A / R F S p i l l a g e / P a t h I m b a l e n c e
E x t e r n a l I n t e r f e r e n c e
TCH Drop Rate
Hardware Faults Drops due to Other Reason
Power Control Sudden Lost Connection Handover Failures
HCS CLS
Assignment to another cell
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for SCR:
Definition: SCR = ((Total Call - INTERNAL_FAILURES)/TOTAL CALLS) x 100%...
Total Call = BSS Originate Call->2G ORG CALL ATTEMPT TIMES
+ Trunk Office Direction Incoming Office Traffic->SEIZURE TIMES
INTERNAL_FAILURES = Failure Reason Traffic-> CAUSE013_switch equipment congestion
+ CAUSE016_temporary failure
+ CAUSE027_switch equipment failure
+ CAUSE061_no CR resource
+ CAUSE062_no CCB resource
+ CAUSE166_network error
+ CAUSE169_temporary error
+ CAUSE170_device congestion
+ CAUSE201_IWF resource unavailable
PROCESS for Optimization:

1. Identify the Failure reasons count for each internal failure reason.
2. Check detailed explanation of cause values those contributing the major factor.


ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for Paging Success Rate:

Definition: Paging Success rate is the percentage of valid page responses received by the
system
PSR = ( CC service first paging response number + CC service repeat paging response number+
SMS service first paging response number + SMS service repeat paging response number) / (CC
service first send paging number + SMS service first send paging number)*100
PROCESS for Optimization:
1. Removal of non existing Cell site database created in BSCs
2. Correcting the number of LACs per BSC (Minimizing the number of LAC per BSC)
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

3. Standard template of Cell site database in each BSC.

1 Fish bone diagram for the root cause analysis of poor Paging Success Rate

Figure 1 : Root Cause for Poor Paging Succ Rate (1)


Figure 2 : Root Cause for Poor Paging Succ Rate (2)

P o o r P a g in g S u c c R a te
1 . In c o rre c t C e ll P a ra me te rs
4 . P o o r R F 2 . E x c e s s p a g in g D is c a rd s
3 . In c o rre c t MS C P a ra me te rs
5 . Po o r P a g in g S tra te g y

Poor Paging Succ Rate
8. incorrect LAC Dimension 6. SDCCH Congestion
9. ABIS , A interface Congestion 7. Combined BCCH
10. ABIS , A interface fluctuations, Errors
11. decrease signalling load on CCCH
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for SS7 Signaling Load:

Definition:

1. TRANSMITT LINK OCCUPANCY (%)= ((( NO. OF SIGNALLING OCTETS
TRANSMITTED + 6 *(MSU TRANSMITTED + MSU RETRANSMITTED) ) /
(248000 * 3600 * 0.2) ) * 100) -----> HSL
2. TRANSMITT LINK OCCUPANCY (%)= ((( NO. OF SIGNALLING
OCTETSTRANSMITTED + 6 *(MSU TRANSMITTED + MSU RETRANSMITTED) )
/ (8000 * 3600 * 0.4) ) * 100) -----> OTHER THAN HSL
3. RECEIVE LINK OCCUPANCY (%)= ((( NO. OF SIGNALLING OCTETS RECEIVED
+ 6 *(MSU RECEIVED) ) / (248000 * 3600 * 0.2) ) * 100) -----> HSL
4. RECEIVE LINK OCCUPANCY (%)= ((( NO. OF SIGNALLING OCTETS RECEIVED
+ 6 *(MSU RECEIVED) ) / (8000 * 3600 * 0.4) ) * 100) -----> OTHER THAN HSL

PROCESS for Optimization:
1. Identify the signaling links whose utilization is going above 80%.
2. Prepared Plan for additional signaling links as per requirement










ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

PROCESS for TBF Success Rate Optimization:

Definition: Temporary Block Flow (TBF) is a physical connection used by the two Radio
Resource entities to support the unidirectional transfer of PDUs on packet data physical
channels. The TBF is allocated radio resource on one or more PDCHs and comprises a number
of RLC/MAC blocks carrying one or more LLC PDU. TBF Success Rate is when during a
data session, TBFs are successfully established on UL and DL.
PROCESS for Optimization:
22. Identify the Bad performing Cells for TBF Success Rate.
23. Identify the bifurcation of Poor TBF Success Rate: whether UL or DL is poor or it is poor
in both directions.
24. Take the detailed report showing (Ex. Total TBF Requests, Total TBF Success, Failure
reasons)
25. Identify the failure reasons after analyzing detailed report and follow the below
mentioned process. Failure is mainly due to TBF Congestion or MS No response.
26. TBF Congestion:

a. Check The Static and Dynamic PDCH definition from BSC Configuration data)
b. If you find Zero Static or Dynamic PDCH, define the same.
c. If PDCH definition is sufficient as per the guidelines, then check whether the TBF
requests are high. If requests are high, then we need to define more PDCHs in the
cell. But before defining more PDCHs, check whether the Voice Utilization is not
high and there is no TCH Congestion in the cell..

27. Check Hardware/TRX alarms; Resolve if find any.
28. Audit for any parameters related discrepancies and define as per standard parameters set.
29. MS No Response: RF and Environmental Factors:

a. Low Coverage Areas (Try to reduce low coverage patches with physical
optimization; New sites)
b. Interference/ Bad quality/ UL-DL Imbalance;
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

c. Check the states for TRx on which PDCH is configured can be issue of TRx also;
Change TRx if you found random behavior of TRx.
After all rectification observe the subsequent days report if you still find the problem repeat the
same process with due care to Pin Point the actual cause.
PROCESS for Optimization of Average GPRS RLC throughput and
Average EDGE RLC Throughput:
Definition: Throughput is the amount of data uploaded/downloaded per unit of time.
PROCESS for Optimization:
1. Identify the Bad performing Cells for Poor GPRS/EDGE Throughput.
2. Identify the bifurcation of Poor Throughput: whether UL or DL is poor or it is poor in
both directions.
3. Take the detailed report showing (Ex. Total TBF Requests, Coding Scheme Utilization)
4. Identify the cells after analyzing detailed report and follow the below mentioned process.
5. Take the configuration dump of the poor cells:

a. Check The Static and Dynamic PDCH definition from BSC Configuration data)
b. If you find Zero Static or Dynamic PDCH, define the same.
c. If PDCH definition is sufficient as per the guidelines, then check whether the TBF
requests are high. If requests are high, then we need to define more PDCHs in the
cell. But before defining more PDCHs, check whether the Voice Utilization is not
high and there is no TCH Congestion in the cell.
d. Check whether there are enough Idle TS defined at the site. If not, definition to be
done.

6. Check whether it is due to poor radio conditions/interference; check C/I. Perform a drive
test to analyze the cell in more detail.

7. Check Gb Congestion/Utilization at the BSC/PCU.
8. Check Hardware/TRX alarms; Resolve if find any.
9. Audit for any parameters related discrepancies and define as per standard parameters set.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

After all rectification observe the subsequent days report if you still find the problem repeat the
same process with due care to Pin Point the actual cause.




PROCESS for Optimization of Downlink Multislot Assignment
Success Rate:
Definition: User timeslot request based on traffic types and MS multi-timeslot capability
and the actual timeslot allocated by the system which can also be termed as Downlink Multislot
Assignment Success rate.
PROCESS for Optimization:
1. Identify the Bad performing Cells for Poor DL Multislot Assignment.
2. Take the detailed report showing (Ex. Total TBF Requests, Failure in terms of TS
requests)
3. Identify the cells after analyzing detailed report and follow the below mentioned process.
4. Take the configuration dump of the poor cells:

a. Check The Static and Dynamic PDCH definition from BSC Configuration data)
b. If you find Zero Static or Dynamic PDCH, define the same.
c. If PDCH definition is sufficient as per the guidelines, then check whether the TBF
requests are high. If requests are high, then we need to define more PDCHs in the
cell. But before defining more PDCHs, check whether the Voice Utilization is not
high and there is no TCH Congestion in the cell.
d. Check the multiplexing thresholds and upgrade/downgrade reports.

5. Check whether it is due to poor radio conditions/interference; check C/I. Perform a drive
test to analyze the cell in more detail.

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

6. Check Gb Congestion/PCU-DSP Utilization.

7. Check Hardware/TRX alarms; Resolve if find any.
8. Audit for any parameters related discrepancies and define as per standard parameters set.
After all rectification observe the subsequent days report if you still find the problem repeat the
same process with due care to Pin Point the actual cause.



















ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

KPI 0ptimization Piocess
AppenuixS (contu..)
iefeis to page 1S of Netwoik Peifoimance Nonitoiing & 0ptimization Piocess
Alcatel&ZTE

ThedocumentcoverstheTCHAssignmentSuccessrate&SDCCHCongestionoptimizationprocessfor
Alcatel&ZTEGSMRadioNetworkstobecomplaintbyAlcatelLucentManagedSolutionsIndiaPvt.Ltd
RadioOptimizationEngineers&associatedstaff.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Contents
1.PURPOSE.4
2.SCOPE4
3.INTRODUCTION.4
4.DEFINITION..5
4.1TCHASSIGNMENTSUCCESSRATE(TASR)
4.2SDCCHCONGESTION(SDCONG)
5.VENDORWISECOUNTERBASEDDESCRIPTION
5.1TCHASSIGNMENTSUCCESSRATE(TASR)
5.1.1ALCATELTASRDESCRIPTION
5.1.2ZTETASRDESCRIPTION
5.2SDCCHCONGESTION(SDCONG)
5.2.1ALCATELSDCONGDESCRIPTION
5.2.2ZTESDCONGDESCRIPTION
6.VENDORWISEROOTCAUSEANALYSIS&OPTIMIZATIONSTEPS
6.1TCHASSIGNMENTSUCCESSRATE(TASR)
6.1.1ALCATELTASRANALYSIS
6.1.2ZTETASRANALYSIS
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

6.2SDCCHCONGESTION(SDCONG)
6.2.1ALCATELSDCONGANALYSIS
6.2.2ZTESDCONGANALYSIS
7.APPENDIX
7.1SDCCHDIMENSIONING
7.1.1ALCATELSDDIMENSIONINGMETHOD
7.1.2ZTESDDIMENSIONINGMETHOD

8.OptimizationProcessforotherRadioKPIs

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

1. PURPOSE
Thisdocumentservesasaprocessguidelineforkeyperformanceindicator(KPI)
optimization such as TCH Assignment Success Rate (TASR) and SDCCH (SD)
Congestion in advanced wireless GSM 2G networks in multivendor scenario
comprisingofAlcatel(B10version)&ZTE(ZXG102.97)Radiosystems.

2. SCOPE
Thisdocumentismeantforexperiencedwireless2GGSMprofessionalsinvolved
inkeyperformanceindicator(KPI)optimizationspecificallyTCHAssignmentSuccess
Rate (TASR) and SDCCH (SD) Congestion in multivendor scenario comprising of
Alcatel(B10version)&ZTE(ZXG102.97)Radiosystems.
Also, the document targets the internal customers of ALUMS with sufficient
backgroundinGSM.
3. INTRODUCTION
Dynamic network configuration changes, operation & maintenance activities
with exponentially rising curve of subscriber density for wireless services prompts
theradioengineerstobequick&effectivetoretaintheQualityofServices(QoS)in
currentscenario.
TCH Assignment Success Rate (TASR) and SDCCH congestion are two critical
pointers to quality of network accessibility during busy hours & non busy hours for
thesubscribers.
Ideally, cells in the network needs to be designed for 0% SDCCH congestion &
100% TASR to ensure 100 % errorfree subscriber services initiated from the MS to
the MSC. Practically, the real timeradio environment (changing clutters), high level
of faults/outages in network elements (MSC/BSC/TRAU/BTS) and higher subscriber
services (Voice/Data) demands destabilizes the designed network capacity to result
indegradationofTASR&SDCCHcongestion.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

In order to achieve sustainable demand, the network resources are re

dimensionedperiodicallywithcoverage/capacity/KPIoptimizationaswhenrequired
basisandTASR/SDCongestionstandsprimefocusareaastobediscussed.

4. DEFINITION
4.1 TCHASSIGNMENTSUCCESSRATE(TASR)
In general, TASR is defined as percentage ratio of successful TCH
Attempts to TCH Attempts over an observed period of time. It measures how
often setup message sent from MS for Mobile Originating Call (MOC)or Mobile
TerminatingCall(MTC)issuccessfulduringTCHallocationprocedurefromMSC.
GeneralEquation:
TASR(%)=(TCHAttemptseizures/TCHAttempts)*100
GSMLayer3Equation:
TASR(%)=(No.ofAssignmentCompletemsg./AssignRequests.)*100
Figure1SuccessfulTCHAssignmentphase

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Although,TASRindicatessuccessfulTCHseizuresforMSconnectivitywith
the network during call phase. Better way to approach TASR improvement is to
focusonTCHAssignmentfailureratewhichisequallyimportant.

HighTCHAssignmentfailurescanbeobservedforunderreasons:
HardwarefaultsinNetworkelements(BTS/BSC/MSC)
Software&Networkconfigurationdatabasediscrepancy
LowCoveragezone
Pathlossissue
HighInterferencefrominternal/externalsources
TransmissionissuesinAbis/Aterlinks
CICmismatchesbetweenBSCMSC
BTSwiringdiagramissue
IncorrectFeature,Parameters&Timerusages
MismatchinTRXradiotimeslotsmappingonRSL
Sectorblockingduetoclutterissues
TCHCongestion
HighTrafficUtilization
TCH
ASSIGN
MENT
PHASE
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Wrongantennatypedeploymentsforrequiredclutters
Invalidcounterpegging
Incorrectcounterselectionforfailuremonitoring
TASR improvement based on above mentioned causes is covered in
Vendor wise root cause analysis & Optimization steps section. Many internal
system reports based on measurable counters are required to cocorrelate to
arrive at certain conclusion for improvement action and are covered in up
comingsections.Assignmentfailurecausepointsareshowninfigureasunder:
Figure2TCHAssignmentfailurecausepoints
MS BTSBSC TRAU MSC
Um Abis A Ater

Legend:
Assignmentfailurecausepoint:
4.2 SDCCHCONGESTION(SDCONG)
Ingeneral,SDCCHCongestionisdefinedasthepercentageratioofSDCCH
Blocks to total SDCCH Attempts over an observed period of time. It measures
how often Mobile Station (MS) is unable to access the network for various
signaling(MM/CC)procedurestoensuresubscriberserviceestablishment.
GeneralEquation:
SDCONG(%)=(SDBlocks/SDAttempts)*100
GSMLayer3Equation:
SDCONG(%)=(ImmediateAssign.Rejects/ChannelRequired)*100

Figure3SDCCHAssignmentphase

IncaseofSDCCH
Congestion,
IMMEDIATE
ASSIGNMENT
REJECTmessage
flowsfromBTSto
MSonAGCH
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Various Mobility Management (MM) sublayer and Connection

Management (CM) sublayer procedures require usage of SDCCH channel
betweenMSandMSC.Someofthecommonlyobservedsignalingprocedures
onSDCCHareasunder:
NormalLocationUpdate(LU)
PeriodicRegistration
IMSIAttach/Detach
CallSetup(MOC/MTC)
SMSpointtopoint(MO/MT)
FaxSetup
Supplementaryservices(USSD)
MostoftherootcausesforSDCong%arelistedunder:
ImproperSDCCHDimensioning
Incorrectusageofavailablefeatures,parameters&timers
HighTCHUtilization
NonoptimizedLACBorders(Intercell/InterBSC/InterMSC)
ConfiguredbutoutofserviceSDCCHs
PhantomRACHs(CoBCCH/BSIC)
SDCCH
ASSIGN
MENT
PHASE
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Overshootingcellsinsidetheclutter
Equipmentfailure(Cell/TRE/BSC)
Increased mean hold time of SDCCH due to large no. of Layer 3
messageflowsbetweenMSMSC
LAPDcongestioninAbisinterface

SDCCHCongestioncausepointsareshowninfigureasunder:
Figure4SDCCHCongestioncausepoints
MS BTSBSC TRAU MSC
Um Abis A Ater

Legend:
SDCCHCongestioncausepoint:
SDCCH Congestion cause points are the locations where probable event
failuresareobservedduetovariousreasonsmentionedabove.
SDCCH Congestion improvement based on above mentioned causes is
coveredinVendorwiserootcauseanalysis&Optimizationstepssection.Many
internal system reports based on measurable counters are required to co
correlatetoarriveatcertainconclusionforimprovementactionandarecovered
inupcomingsections.

5. VENDORWISECOUNTERBASEDDESCRIPTION
5.1TCHASSIGNMENTSUCCESSRATE(TASR)
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

5.1.1ALCATELTASRDESCRIPTION
AlcatelBSSsystem(B10)evaluatestheTASRbasedoncertainmeasurable
countersfromNPOwithbelowrelation:
TASR(%)=MC718/[MC140a(MC142e+MC142f)*100.
Also,MC142e=C142a+C142c&MC142f=C142b+C142d.
Countersincrementordecrementbasedonvariousfactorsgoverningthe
networkoperatorsettingsandrealtimeoperationalstatus.Itisimportanttobe
aware of TASR % value on cell basis to visualize the impact & validity of these
counters.

5.1.2ZTETASRDESCRIPTION
ZTE BSS system (ZXG10V2.97) evaluates the TASR based on certain
measurablecountersfromOMCRwithbelowrelation:
TASR % = {(C11609C11696) (C11610+C11654+C11658C11697
C116101C116133)}*100/(C11609C11696)
Counter description & details can be found in Appendix section or on
clicktorespectivecounterinquickerway.

5.2SDCCHCONGESTION(SDCONG)
5.2.1ALCATELSDCONGDESCRIPTION
Alcatel BSS system (B10) evaluates the SD CONG based on certain
measurablecountersfromNPOwithbelowrelation:
SDCONG(%)=[MC04]/[MC04+MC148]*100
Counter description & details can be found in Appendix section or on
clicktorespectivecounterinquickerway.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

5.2.2ZTESDCONGDESCRIPTION
ZTE BSS system (ZXG10V2.97) evaluates the SD CONG based on certain
measurablecountersfromOMCRwithbelowrelation:
SDCONG%=(C11625C11626+C11697)*100/(C11625+C11696)

6. VENDORWISEROOTCAUSEANALYSIS&OPTIMIZATIONSTEPS

6.1TCHASSIGNMENTSUCCESSRATE(TASR)
6.1.1ALCATELTASRANALYSIS
Alcatel(BSS10release)TASRanalysisrequiresmonitoringoftheKPIfrom
BBHreportcirculatedfromlocal\centralMISteamondailybasisatcelllevel.
It involves clear understanding of associated counter based internal
systemreportsfromNPO/OMCserverasunderwhichreflecttherootcausesfor
poor TASR % values and needs study of these reports in following sequence
basedondegradationseverity:
Activealarmsreport
Pathbalancereport
RTCHAssignmentreport
Quality/Levelreport
TimingAdvance(TA)report
Networkparameterchecks
ReferAppendixSampleReportssectionforscreenshot.
FlowdiagramforTASRimprovementreportchecks:

TASRCYCLE
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Below Flowchart 1 represents the TASR% improvement cycle based on

triggerconditionandrootcauses:

YesNo

START
Identify&filterTASR
%fromBBHreport
foranalysis
TASR%
<98.75%
Nofurther
investigationreqd.
Check&clear
activealarms
CheckforTRE
Pathbal.>5dB
withoutTMA
Verifythe
Tx/Rxpath&
rectifyit
ActiveAlarms
PathBalance
RTCHAssign
Quality/Level
Timingadvance
N/wparameter
BSSproblem,checkAbis
mediastabilitywithany
CICmismatchatAter
front(GTCNAAFLCPMR)
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

No

Yes

Yes

STOP
Checkfailure
phaseinRTCH
Assignreport
CheckBBH report
forTASR%value
afterproblem
correction
TASR%
>=98.75
ActiveAlarms
PathBalance
IOI
BER(U/LD/L)
Timingadvance
N/wparameter
GTCNAFLRR
>GTCNAFLBR
Radioproblem,check
Quality/Level/TARMS
reportswithanyTCH
congestion(GTCNACGR)
Revisitthe
improvement
cycletoSTART
MSC/BSC/Cell
Parameters,Timers&
Featuresauditforfine
tuningpurpose
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Below Flowchart 2 represents the TASR% improvement cycle based on

triggerconditionandrootcauses:

YesNo

No

START
Identify&filterTASR
%fromBBHreport
foranalysis
TASR%
<98.75%
Nofurther
investigationreqd.
Check&clear
activealarms
CheckRTFs
Pathloss<105
&>115noTMA
CheckBBH report
forTASR%value
afterproblem
correction
Verifythe
Tx/Rxpath&
rectifyit
CheckIOI
reportfor
UplinkIntrf.
BSSproblem,checkAbis
mediastabilitywithany
CICmismatchatAter
front(GTCNAAFLCPMR)
MSC/BSC/Cell
Parameters,Timers&
Featuresauditforfine
tuningpurpose
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Yes

Yes

6.1.2ZTETASRANALYSIS
ZTE(ZXG10V2.97)TASRanalysisrequiresmonitoringoftheKPIfromBBH
reportcirculatedfromlocal\centralMISteamondailybasisatcelllevel.
It involves clear understanding of associated counter based internal
systemreportsfromOMCRasunderwhichreflecttherootcausesforpoorTASR
% values and needs study of these reports in following sequence based on
degradationseverity:
Activealarmsreport
PathBalancereport
BasicMeasurementreport
TimingAdvance(TA)report
Networkparameterchecks
ReferAppendixSampleReportssectionforscreenshot.
FlowdiagramforTASRimprovementreportchecks:

ActiveAlarms
TASRCYCLE
PathBalance
IOI
STOP
TASR%
>=98.75
Radioproblem,check
Quality/Level/TARMS
reportswithanyTCH
congestion(GTCNACGR)
Revisitthe
improvement
cycletoSTART
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

Below Flowchart 3 represents the TASR% improvement cycle based on

triggerconditionandrootcauses:

YesNo

BER(U/LD/L)
Timingadvance
N/wparameter
START
Identify&filterTASR
%fromBBHreport
foranalysis
TASR%
<98.75%
Nofurther
investigationreqd.
Check&clear
activealarms
CheckforTRE
Pathbal.>5dB
withoutTMA
Verifythe
Tx/Rxpath&
rectifyit
BSSproblem,checkAbis
mediastabilitywithany
CICmismatchatAter
front(GTCNAAFLCPMR)
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

No

Yes

Yes

6.2SDCCHCONGESTION(SDCONG)
6.2.1ALCATELSDCONGANALYSIS
Alcatel(BSS10release)SDCONGanalysisrequiresmonitoringoftheKPI
fromBBHreportcirculatedfromlocal\centralMISteamondailybasisatcelllevel.
It is highly critical to understand the radio network configuration & spatial location of cells
basedonwhichcertainimplicationscanbemadeforhighSDCong%.
STOP
Checkfailure
phaseinRTCH
Assignreport
CheckBBH report
forTASR%value
afterproblem
correction
TASR%
>=98.75
GTCNAFLRR
>GTCNAFLBR
Radioproblem,check
Quality/Level/TARMS
reportswithanyTCH
congestion(GTCNACGR)
Revisitthe
improvement
cycletoSTART
MSC/BSC/Cell
Parameters,Timers&
Featuresauditforfine
tuningpurpose
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

It is advised not to confuse with OMCR Counters & NPO Indicators in

Alcatel(BSS10release).NPOIndicatorscanbedirectOMCRCountersorIndirect
Countersbasedoncomputation.
Below Flowchart 4 represents the SD CONG% improvement cycle based
ontriggerconditionandrootcauses:

NoYes

START
Identify&filterSD
CONG%fromBBH
reportforanalysis
SDCONG
%!=0.00
CheckHWavailability

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

7.APPENDIX
7.1SDCCHDIMENSIONING
SDCCH Dimensioning is the need for signaling resource optimization
based on carried SDCCH & TCH traffic in a cell. Different vendors provide various
solutions for dimensioning based on network settings & traffic requirements. Two
methodsavailableforSDdimensioningare:
Automatic(Loadbasedincrease/decreaseofSDCCH/8)
Manual(TrafficEstimationsandCellStatistics)
AutomaticSDdimensioningisdependentonfeatureavailabilityinthesystem
although most of systems have dynamic SDCCH configuration feature to control SD
traffic in peak hours. Dynamic SDCCH feature activation is network operator
dependent & is highly recommended when flow monitoring of LAPD layer 2
messagesisavailable.
ManualSDCCHdimensioningisbasedontwofollowingmethods
TrafficEstimations:
Various Layer3 events (LU/IMSI ATTACHDETACH/Call set
up/SMS/FAX etc require average mean holding time (seconds)
based on which SDCCH traffic estimation is done. This method is
largely ignored in real networks due to varying probability of
meanholdingtimesofLayer3(MM/CM)messagesandSDtraffic
estimation.

STOP
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

CellStatistics:
Cell Statistics based SD dimensioning is highly recommended in
current real time dynamic networks due to high demand for
SDCCHresourcesandformsvalidpartofdiscussioninthemanual.

Cell statistic based approach considers maximum SDCCH channel

occupancyin24hoursorpeakSDtrafficforSDdimensioningasa
critical input besides configured total SDCCH channels including
(SDCCH/4, SDCCH/8) with or without CBCH. SD carried traffic or
busy channels must be average of minimum 3 weeks to capture
cellbehavioronlongtermbasisforeffectivedimensioning.

As a Thumb rule, Designed SDCCH Grade of Service (G.O.S) can be

calculatedasunder:
SDCCHG.O.S(%)=*TCHG.O.S(%)
GSM wireless networks consider TCH capacity dimensioning at 2
%G.O.S,henceSDcapacityisdimensionedat0.5%G.O.S.
Common flowchart 5 for SD dimensioning based on cell statistic
approach is as under and same is applicable in
Alcatel/Motorola/ZTEvendorsaswell.

YesNo

SD
Dimensioning
reqd.
CheckforCounter
withmaxSDtraffic
orbusychannels
START
MaxSD
traffic
available
MaxSDbusy
subchannels
available
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

NoNo

YesYes

Note:8SDCCHsubchannelscorrespondtoonehardcodedSDCCH/8
7.1.1ALCATELSDDIMENSIONINGMETHOD
Alcatel (B10 release) SD Dimensioning is done using NPO
indicatorGSDTREwhichgivesSDErlanghourlybasisforaday.Minimum
3 weeks data average with maximum SD Erlang observed in daily busy
hourmustbetakenintoaccountbeforefurtheranalysis.
ReferstepsasmentionedinFlowchart5forSDdimensioning.

7.1.2ZTESDDIMENSIONINGMETHOD
ZTE (ZXG10V2.97) SD Dimensioning is done using Basic
Measurement report.xls available in OMCR with counter C11627
(Maximum Number of Busy SDCCH). Minimum 3 weeks data average(If
available) with maximum SD busy channels in 24 hours must be taken
intoaccountbeforefurtheranalysis.
STOP
Computechannels
frmcarriedSDtraffic
using0.5%G.O.S
fromErlangBtable
Checkforconfigured
&requiredSDCCH
subchannelwith
40%excessaddition
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

ReferstepsasmentionedinFlowchart5forSDdimensioning.

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

8.OptimizationProcessforotherRadioKPIs

SDCCHDropRate

Definition:SDCCHCallDropRateindicatestheprobabilityofcalldropsthatoccurwhenMSs
occupySDCCHs.ThisKPIreflectstheseizureconditionofsignalingchannels.Ifthevalueofthis
KPIishigh,userexperienceisadverselyaffected.

SDCCHCallDropRate=CallDropsonSDCCH/SuccessfulSDCCHseizures

Causes:
30. DuetoBlindspot,lowcoveragelevel,orcrosscoverage.
31. HighVSWRduetofeedersleadstothereductioninthetransmitpowerandinthe
receiversensitivity.
32. PoortransmissionqualityandunstabletransmissionlinksovertheAbisinterface
33. Unavoidableinternetworkinterference,interferencefromrepeaters,orhighand
unavoidableintranetworkinterferencecausedbyaggressivefrequencyreuse
Interference
34. unavailableterrestrialresourcesorfaultydevices

Action:
1. ReduceCoveragehole,Blindspotsbyphysicallyoptimization.
2. BymaintainingbalancebetweenUplinkDownlinkpathbyachievinglessVSWRvalue,
propertuningofRxLevAccessMinandRachLevAccessMinParameter.
3. StableTransmissionMinimumLapDfailures
4. ProperFrequencyplantoreduceInferencelevelbyretuningfrequency,Maio,HSN,
reducingOvershooting.
5. ReshufflingofSDCCHTimeslotasperTRXefficiency.RectificationofFaultyTRXs.
6. TimerT200canbeoptimizedaspertransmissionefficiency.

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

HandoverSuccessRate

Definition:Thepurposeofhandoveristoensurethecallcontinuity,improvethespeech
quality,andreducethecrossinterferenceinthenetwork,thusprovidingbetterservicesforthe
subscribers.Successratioofhandoveristheratioofthetotalnumberofsuccessfulhandovers
tothetotalnumberofhandoverrequests.

SuccessRateofHandover=SuccessfulHandovers/HandoverRequests

HSRisimpacteddueto
1. Blindspot,lowcoveragelevel,orcrosscoverage.
2. Unavoidableinterferencecanbetheinternetworkinterference,interferencefrom
repeaters,orintranetworkinterferenceresultingfromaggressivefrequencyreuse.
3. PoortransmissionqualityandunstabletransmissionlinksovertheAbisinterface
4. Faultydevices,orasynchronousclocks
5. Imbalanceddistributionoftrafficvolumeinthenetwork.Ifthenetworkiscongested
badly,thehandoverfailuresincreasebecauseofnoavailableTCHsandthehandover
successratedecreases.Thenetworkcongestiondoesnotaffectthesuccessrateofradio
handover.
Action
1. Properneighbordefinition(1
st
tiermandatoryand2
nd
tierdefinitionasperrequirement)
2. Maintainingproperfootprintbyphysicaloptimization.
3. ReducingInterferencelevelbysmoothfrequencyplan
4. Stableerrorfreetransmissionlinks
5. AvoidingPingpongHObydefiningproperHOmarginparameterwhichmaybedue
LevelorQuality.
6. ProvidingappropriatetimeframeforclearmsgorEstablishmsgbetweenBTSsbyT8
timer
7. ForintraBscHO,timetoreceivesHOcompletemsgfromBSCshouldbeoptimizedby
T3103timer
8. MaximizingtheHOcauseduetoPowerbudget.
9. Maintainingpropertrafficdistributionbyphysically,DR,queuingparameterstoavoid
HOfailureduetoneighborcellscongestion
10. Clockdriftshouldbeavoided.

ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

TCHCallDropRate

CallDropRatioonTCHindicatestheratioofthenumberofcalldropstothenumberof
successfulTCHseizuresaftertheBSCsuccessfullyassignsTCHstoMSs.

TCHCalldropsdueto
1. Blindspot,lowcoveragelevel,orcrosscoverage.
2. Unavoidableinterferencecanbetheinternetworkinterference,interferencefrom
repeaters,orintranetworkinterferenceresultingfromaggressivefrequencyreuse.
3. PoortransmissionqualityandunstabletransmissionlinksovertheAbisinterface
4. FaultydevicesandhighVSWR
5. IfthetargetcellinvolvedintheDirectedRetryprocedureisunderanotherBSC
6. DuringintraBschandover
7. IfpreemptionisusedinMSCthenlowerpriorityMSwillfacecalldrop.

Action
1. Cleanfrequencyplanviz.achieveminimuminterferencelevelbycleanBCCH(CO/ADJ),
MAL,MAIO,MSPlan.
2. Minimizingcoverageholesbyphysicaloptimization(Orientation,Height,E.Tilt,M.Tilt).
3. SettingRadiolinktimeoutparameterasperintersitedistanceviz.forruralsitesRLTcan
beofhighervalue.
4. SimilarforRuralsitewhereuplinkqualityispoor,RxlevAccessmin,RachAccessmin
parametercanbesetappropriately.Properbalanceshouldbemaintainedforthis
parameterelsepathimbalancewillresultandTCHdropwillincrease.TMA/TMBcanbe
plannedappropriately.
5. MinimizeAterAbisfluctuationLinkstabilityplaysveryvitalrole.
6. AterCongestionfurtherresultsinTCHcalldrops.SufficientAterargumentshouldbe
maintained.
7. PowercontrolusedforHOshouldbeproperlydesignedtoavoiddropwhereeverthere
issuddenRxLevdrop.
8. DuringHOtoneighborcellsshouldbehavingfreeTCHresourceselsecalldropmay
increase.Forthisproperhalfratethresholdsshouldbedefinedaspertrafficpattern,
decongestionofthesecellsbycapacityargument.
9. Queuinglengthshouldnotmadetoolong/short.
10. DropduetointraBscHO,congestionfreeAterargumentshouldbemaintained
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

11. TimerT305andT308intervalshouldbewellenoughtoreceivetheDisconnectand
ReleasemessagefromMscandBscrespectively.
12. ProperNeighbordefinitionshouldbemaintainedsomehandoverscannotbe
performedandthuscalldrops.
13. BymaximizingPowercontrolHOsreducestheinterferenceslevel,whichfurther
reducesTCHdroprate.
14. ByDTXfeaturefurtherInterferencelevelsarereduced,reducingTCHdrop.

RACHSuccessrate

Def:Random Access Channel (RACH) is used by the MS on the uplink to request for
allocation of an SDCCH. This request from the MS on the uplink could either be as a page
response (MS being paged by the BSS in response to an incoming call) or due to user trying
to access the network to establish a call.

RACHFailurecanbedueto:
1.AGCHOverloadatBaseStation
2.RACHCollisions
3.MSoutofRange
4.PoorUplinkquality
5.BTSReceiverProblem

Action
1. Appropriateno.ofCCCHblocksshouldbedesignedasperTrafficpattern.Signalinglink
shouldbeincreasedfrom16kto32kasperrequirementtoavoidoverloading.
2. MinimumCoverageholeisfirstrequirementforgreaterRACHsuccessrate.
3. UseofDTXmodeinUplinkreducestheinterferencelevelmakinglessprobabilityfor
RACHcollision
4. Hardwarealarmlikedifferenceinuplinkanddownlinkpathbalanceheavilyimpacts
RACHsuccessrate.H/Walarmshouldbeminimized
5. Max.NoOfRetransmissionparameterallowstheMStoretransmitagainforAGCHby
notincrementingtheRACHaccessfailurecounter.
6. RACHAccessminandRACHBusyThresholdparametercanbetunedtorestricttheMS
inoutofrange.Ifthisparameterissettoahighervalue,theactualcoverageareaofthe
networkbecomessmall;ifthisparameterissettoalowervalue;alldropsarelikelyto
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

occurbecauseofinvalidaccessortooweakaccesssignals,thusdecreasingthesuccess
rate.
7. Fluctuationintransmissionmediafurtherdecreasesthesuccessrate.Stablemedianeed
tobemaintained.
8. UplinkqualitycanbefurtherboostedbyTMA/TMB.

RxQuality

Samplescarriedwithin0to4Levelbysumofsamplescarriedwithin0to7Levels,istermedas
RxQualityfortheTRX/cell.

PoorSpeechQualitycouldbebaddueto
1. Coverageholes
2. NoTargetcellforHandover
3. Interference
Cochannel
Adjacentchannel
External
Multipath
Noise
4. E1fluctuationpoorFER
5. Pathbalance,VSWR,HardwareissueatBTS
6. Poorpowerbudgetthresholds
7. Halfratepenetration
8. Repeaterusedbroadband/narrow/manual

Action

1. BothUplinkandDownlinkgoodquality,properuniformcoveragepatternsare
prerequisite.
2. Cleanfrequencyplanviz.achieveminimuminterferencelevelbycleanBCCH(CO/ADJ),
MAL,MAIO,MSPlan
3. OvershootingshouldbeavoidedbyE/Mtilt,heightreductionandreorientatione.g.cells
fromhighaltitude(mountain)aretendingtoovershootevenwithmaximumtiltand
height.Sectorfacingtowardswater(sea,pond)causesreflectionandfurther
interferenceinthesurrounding.Properorientationorisolatedfrequencyplanneedto
beconsideredforthesesites.
ALUMSOMPL2014ALUMSOPERATIONALPROCESSMANUAL
EDITION1.2EFFECTIVEDATE:01January2011

4. MissingneighborsfurthercausesHOduetointerference.Proper1
st
tierneighbor
shouldbedefined
5. PoorFERfurtherdegradesthequality,bymakingMStogotolowestcodecsupported.
ErrorfreeE1linkshouldbemaintained.
6. Differenceinuplinkanddownlinkpathcausesfurtherqualityinuplinkanddownlink
respectively.Callservedbyfaulty/alarmedtimeslot/TRXcausesqualitydegradation.
MinimumHardwarealarmsshouldbemaintained.
7. AggressiveHalfrateutilizationmakesMStouselowestEFRorAMRcodecmaximum
timesmakingsubscribertoputtheireffortstounderstandabouttheclearlyof
conversation.
8. RepeatersfrequenciesarenotupdatedautomaticwheneveranRFengg.changes
frequencyplanofservingmacrositesincemaximumrepeatersaremanuallytuned
repeaters.
9. Qualityisfoundpooreratplaceswhereexternalinterferencesarepresentviz.closeby
CDMAsites,restrictedzonesduetojammers/frequenciesusedbythem.Notchfilters
canbeproposedtoreduceCDMAfrequencyeffects.
10. TMA/TMBcanbeusedatHighwaysitestoachievegooduplinkpath.
11. MSshouldaccessnetworkwithproperuplinkanddownlinklevwhicharesetby
RxlevaccessminandRachaccesminparameter.