Nokia 2G_KPI Optimization

Ritesh Thakur
NPO_RoB
/
 Pre requisite Information
• One BSC=6 BCSU (Base control signaling unit).
• One BCSU = support 110 TRX.
• 1 TRX= 8 time slots.
• Total no. of TRX = 110 *6=660 TRX in single BSC
• One BCF means= one site of three or four sector
• BCF= Base control function.
• BTS= Base transceiver system.
• NSEI= network service entity identifier (NSEI) identifies each NSE that has end-to-end significance
across the Gb interface
• One NSEI= supports 64 BTS and 128 TRX if any one of them is full then we can assign second NSEI
port in same BSC
• 1TRX=117 subscriber(based on TCH configured)
• 1 TRX=2.94 erlang(2% GOS )
• 2 TRX=8.2 erlang(2% GOS )
• 3 TRX=14.6 erlang(2% GOS )
• 4 TRX=21.2 erlang(2% GOS )
• If BSC 3VI, OSS is 4 and System is S11 then max capacity of BSC is 660 TRXs.
• If OSS 4.2 and system S12 is using then max capacity of BSC will be 2000TRXs
 To Start with…

• How do we need to start Optimization

• KPI Analysis with All Raw Counters
• Root Cause
• Hardware Alarms
• Core Optimization ( Alarm Description & Analysis)

For escalating the Transmission and Hardware related issue we

should clear why alarm persisting and what unit is faulty and we
also first try with TRX Lock & reset etc so that we can force to
customer to replace it ASAP and For Transmission we also need to
know which KPI is affecting due to which alarm as so many alarm
persists on the BSC but only some affects the KPI and This is called
Root Cause analysis

/
 Consistency Parameter Check
• Check cells in MSC vs cells in BSC
• Check external adjacencies in MSC
• Cells with co-channel frequencies
• Cells with adj-channel frequencies
• Non symmetrical adjacencies
• Neighbors with co-channel frequencies
• Neighbors with adj-channel frequencies
• Neighbors of a same cell with co-BSIC, co-BCCH
• Check BCCH-BSIC reuse distance
• Check BCCH reuse distance
• Check site with same MA List in different sectors and different HSN
• Check site with same MA List in different sectors and MAIO collision
• Synchronized HO
/
 Parameter Audit
• Some major parameters might have big impact to KPI. We briefly review those
parameter to make sure at least we are not optimizing at the unreachable value.

TCH Drop
• RX diversity (RDIV) : enable/disable
• Radio Link Timeout (RLT) : higher value  less drop but more bad quality.
• Radio Link Timeout AMR (ARLT) : higher value less drop but more bad quality

SDCCH Drop and SDCCH Success Rate

• RxLev Access Minimum (RXP) : higher value  less drop and less traffic.
• C2 parameter
• Cell reselection parameter Index (PI) – enable/disable
• Cell barring qualify (QUA)
• Cell reselect offset (REO) : less value  less drop and less traffic.
• Temporary offset (TEO)
• Penalty time (PET)
/
•RX lev min cell (SL)
With this parameter you define the minimum signal level of an adjacent
cell, when a handover is allowed to one of them.

•HO margin level (LMRG)

Must consider HOC parameters
•threshold level downlink Rx level (LDR)
•threshold level uplink Rx level (LUR)

•HO margin qual (QMRG)

Must consider HOC parameters
•threshold qual downlink Rx qual (QDR)
•threshold qual uplink Rx qual (QUR)

Warning! You can reduce the LMRG and QMRG to allow quickly handover
but make sure the target cell signal strength and quality is good enough to
avoid handover failure and drop call.

/
Design default sets Consistency Checks
1. Compare network design against network configuration
•Default Parameter Check
•Specific Parameter Check

2. Database check
•Check inconsistencies between TRX, BTS table with ADCE table:
•Check Adjacencies to non-existing cells
•Consistency parameter checking

3. Neighbour cells with co-BSIC, co-BCCH ...

• Review Neighbour Plan
• Review Frequency Plan

/
 Examples of wrong parameter set with impact on
network operation/performance – call setup, qual, bands
• No calls happening in a cell
1. Cell Barred
2. Non existent (LAC, Cell ID) in MSC
3. DMAX = 0

• Very few calls happening in a cell

1. RxLevAccesMin
2. Wrong MNC, MCC, LAC declaration

• Very low traffic in a cell

1. msTxPwrMax = 0, bsTxPwrMax = 30

• Bad quality in UL after rehoming because of RDIV parameter is not set YES anymore.

• Few traffic in 1800 layer of a dual band 900/1800 network :-Idle Mode: C2 parameters not set properly
(temporaryOffset, penaltyTime)

/
Examples of wrong parameter set with impact on
network operation/performance – frequencies

1. Drop call rate increase after new frequency plan implementation

- Double BA List activated

2. Impossibility to unlock some BTS after a RF-frequency hopping

implementation

3. Impossibility to unlock some BTS after a frequency retune

- NON-EDGE TRX, with GTRX = Y
- TRX, with GTRX = Y, not attached to any EDAP pool

• No handover happening after frequency retune between 2 cells from different

BSCs
• ADCE table has not been updated for other BSC
 Example of Wrong Parameter Settings
1. No handover from a cell towards all its neighbours
• PLMN permitted = No
2. High Handover failures after implementation of new adjacency plan
SYNC = YES
3. No handover happening from an interfered cell
hoMarginQual set to 0
4. 100% of handover failures in an adjacency relation
Co-BSIC co-BCCH declaration
5. High number of handovers
hoThresholdsLevUL = hoThresholdsLevDL
6. Handover not happening when DL signal level of neighbour much greater than serving
cell
POC DL activated

/
 Examples of wrong parameter set with impact on
network operation/performance – Background Plan
1. Few handovers after implementation of new adjacency plan
- Only half of the plan has been downloaded. Half of the adjacencies missing.
2. High drop call rate in some sites after frequency hopping activation
- Some sites did not hop as some frequencies were not correctly set!

✓ Important to verify network parameters through MML command!

✓ In case not all parameters were changed correctly, use MML to implement the
changes!

RF COMMANDS:--
ZEFO---BCF PARAMETER
ZEQO---PARAMETER
ZEUO---POC
ZEHO—HOC
ZERO—TRX
ZEAO--NBR
ZESI;--DAP
ZEBO—BA LIST
ZEBI—MAL LIST
ZEBP-RA LIST
/
 Conclusion
Before suspecting anything, check the parameters active in the network!!!

- Do consistency checks: verify network parameters are as planned.

- Check configuration!
- Verify differences between OSS template and BSC default parameters!
- In some cases recommended values should be used instead of default values (e.g.
msPeriodicLocationUpdate: 0.5 -> 6)
- Verify value of sensitive parameters (e.g. DMAX, RxLevAccessMin)
- Adjust parameters to balance traffic (e.g. C2 in idle mode)
- Inter-related parameters (e.g. New Frequency Plan + BA List)

/
 ND Reports

61 report is related to one way HO

67 report for Syn . In the same BCF that is yes otherwise no
111 related to current BCCH
130 related to SD congestion
135 related to TCH congestion , threshold is 120 sec.

150, 153 , 154 related to HO in which u see which cell having max. no. of HO failure with their reasons

163 for TCH drop , in which u see actual reason for drop may be RF , LAPD, Transcoder failure, link fluctuate
190, 196 for interference n quality

232 report for overshooting acc. To tell. Theort more than 95 % samples within 3.3 km

208 for link balance if the diff . b/w ul n dl is grater tha 5 dbm then there is some hardware problem.
216 that is analyzer report for cell, site n BSC

204 Report is for bechmark statistics report in which you will get every KPI with reasons.
Logical Channels
Call Establishment
 Call Setup-Mobile Terminating Call
MS BTS BSC MSC
1>Paging(LAI+IMSI/TMSI)
PCH 2>Paging Command
3>Paging Req(Imsi on PCH) Imsi/Tmsi+PG+TRX+CG+TN

RACH
4>Channel Req(On RACH) 5>Channel Reqd (Access Delay)

6>Channel Actn (MSPwr,BSPwr,TA)

7>Channel Activation Ack

AGCH 8>Imm Assign Cmd(On AGCH , Freq

8>Immediate Assign
+TS+ SDCCH SubChannel No+TA
SABM (Paging Resp:IMSI/MS Class)

UA(Paging Resp) Unnumbered Ack 9>Estblish Ind (Paging Resp)

9>Conn Req (Paging Resp: BSC
Frame which confirms only 1 MS is IMSI+MS Class add CGI)
using Sig Channel
SDCCH 10>Auth Req (128 bit RAND+
10>Auth Req (128 bit 10>Auth Req (128 bit RAND+3bitCKSN) 3bit CKSN)
RAND+3bitCKSN)

SDCCH
11>Auth Response (MS Calculate 11>Auth Response (SRES)
SRES & Kc with its own Ki stored in 11>Auth Response (SRES)
SIM by appling algorithm A3&A8)

Nov 17, 2003

 Call Setup-Mobile Terminating Call
MS BTS BSC MSC
14>Setup (Req for Services I.e.
SDCCH 14>Setup
14>Setup Speech/Data/Fax etc)
SDCCH
15>Call Confirmed 15>Call Confirmed 15>Call Confirmed
17>Channel Activation 16>Assignment Req
(BSC Allocated Idle TS for Traffic) (MSC send CIC to BSC)
18>Channel Activation Ack
SDCCH 19>Assignment Cmnd (BSC send 19>Assignment Cmnd (BSC send
message on SDCCH to MS telling to message on SDCCH to MS telling to go
go TCH) TCH)

TCH
20>Assign Comp (MS tune to TCH
and send Ind that Chan is Seized)
TCH
22>Alert (MS Send Alert to MSC as
soon as the ringing is started in MS)
TCH
23>Connect (When MS Sub Answer
the Conn message sent to MSC)
TCH
24>Connect Ack
20>Assign Comp (MS tune to TCH
20>Assign Comp (MS tune to TCH
and send Ind that Chan is Seized) and send Ind that Chan is Seized)
21>RF Chann Realease
21>RF Chann Realease Ack
22>Alert (MS Send Alert to MSC as
22>Alert (MS Send Alert to MSC as
soon as the ringing is started in MS) soon as the ringing is started in MS)
23>Connect (When MS Sub Answer
23>Connect (When MS Sub Answer
the Conn message sent to MSC) the Conn message sent to MSC)
24>Connect Ack
24>Connect Ack

Nov 17, 2003

 MS KPI THRESHOLD
KPI’s to be monitored
Parameter TOP-50 Showcase Non-Showcase
Threshold Threshold
SD Blocking 0.25/98 0.25/98 0.25/97.5

SD Drop 1.75/95 1.75/95 2/92

TCH Blocking 0.5/97.5 0.5/97.5 0.5/97

TCH Assignment 97/97 97/97 96/95

TCH Drop 2.25/95 2.25/95 2.5/92

HOSR 93.5/95 93.5/95 92/93

 Reasons for SD Blocking:
• Insufficient SD defined.(min=No of trx-1)
• High no of SD attempts -LAC boundary.
• Nearby site outages.
• Extreme end-user behaviors: Sport event ending, festivals or celebrations.
• HW Problems.
• Congestion on Air-interface leads to delay in communication to the MS. Can give timeout in BSC
during Imm Ass.Increases SDCCH mean hold time with more than 2 seconds.

• Congestion on Abis leads to delay in communication with BTS and MS. Can give timeout in BSC
during channel activation (TCHACTIVE). Increase SDCCH mean hold time with more than 5
seconds..

• Congestion on the A-interface will lead to increased mean hold time on SDCCH. Increase is
unknown.

• High load in MSC/VLR and/or HLR will lead to increased mean hold time on SDCCH. Increase is
unknown.
 Usage of SDCCH

The SDCCH are used in some different ways in the GSM network:

• Registrations: Periodic Location Updates, IMSI Attach/Detach

• Call Setup: Immediate Assignment -> Assignment.
• SMS point-to-point: SMS messages to/from MS in Idle mode.
• Fax Setup
• Optional: USSD (Unstructured Supplementary Service Data) data transfer. MS<->Network. Similar to
SMS. Controlled by the MSC.
 SDCCH Holding Time

• Normal Location Updating = 3.5 Sec

• Periodic Registration = 3.5 Sec
• IMSI Attach = 3.5 Sec
• IMSI Detach = 2.9 Sec (IMSI detach Indication message sent to
• NW, no authentication is performed (which normally takes
0.6Sec) & no ack is sent to MS.)

• Call Setup = 2.7 Sec (MOC)

• = 2.9 Sec (MTC)
• Short Message Service(SMS) = 6.2 Sec (Vary depending the length of SMS)

• Fax Transmission = 2.7 Sec (MOC)

• = 2.9 Sec (MTC)
• False Access = 1.8 Sec (when Channel req is rec’d by system ,as SDCCH is
allocated by sending Imm Ass message, and the system waits a certain time before
performing disconnection.)
 SDCCH Dimensioning
Recommended SDCCH Configurations
 Solutions for removal of SD Blocking:
• Check the No. of SDCCH channel Available, Change No of SD channel through TSL
optimization.
• Check LAC boundary, If location update is High then change the LAC of that site and set C2 and
HYS.
• Use of Dynamic SDCCH (It is a BSC parameter and will be applied on whole BTS).
• Hardware check / shift SD to new time slot(healthy Trx).
• Some times BMA and HYS parameters are useful to remove SD Blocking.
• Also check for BTS signaling definitions.

Following reports can be used for SD Block analysis

• 182 to analyses SD Blocking reasons.
• 130 for SD congestion.
 SD Drop

• If an assigned SD is not received by MO/BTS and which SD loss occurs, it is called as SD Drop.
• It occurs between allocation of SD and before TCH allocation. Sometimes SD drop occurs
because queuing is not activated in the system.
• If SD drop is high plz look on parameters like- overshooting , shift the SD time slot , may be
hardware issue, interference, change the values of RXP, PMAX, may be issue of uplink or
downlink issue in that cells for UL put a TMA in that cell and for DL provide tilt ,re orient that
antenna
 Reasons of SD Drop:
• Hardware Fault.
• Interference.
• MAIO mismatch.
• Bad Coverage.
• High TR Fail.
• Outage.
• Overshooting.
• Abis Drop.
• High Path Loss.
• Wrong Parameter Planning.
• Due to ICM Band(CDMA)
• High LAPD Utilization
• Heavy blocking and DR feature being used extensively
SDCCH Drop Rate Analysis Based on Several Reasons

• If SDCCH_Radio_fail counter value is high it means drops going may be due to

Overshooting, interference , Phantom RACH etc.

• If 7745 Channel Failure Rate Alarm persist on SDCCH then Shift the SDCCH
from that TRX to another TRX.

• If SD Drop is high we can also change some parameters RXP, PMAX, DMAX (For
international boundary facing) etc.

• SD Drop can also be high due to high UL or DL issue in that cell. For UL we can
put TMA and for DL we can provide tilt or re orient that antenna.

• For Extra SDCCH we need to check the SD Configuration as per Nokia system 1
SDCCH can take 5000 SDCCH attempts, for this don’t consider the daily KPI,
please see the next slide for better explanation of this.

/
 Solutions for removal of SD Drop:
Interference:
• Check the BCCH Plan (C/I or C/A).
• Co-BSIC & Co BCCH.
• Use latest ND 111 and MapInfo to find out proper frequency to reduce interference.
Arrange Drive Test:
• The best way to find the real issues for Interference makes DT.
• Check interference by Interference scanning.
• Check clean BCCH by frequency scanning.
High TR Fail:
• Check and clear TR fail from OSS end.
Bad Coverage:
• If the drop call is due to low signal strength uplink, check the receive path of this particular TRX.
Check receiver sensitivity, VSWR, feeder connection and etc. Drops due to Low Signal Strength.
• If the drop call reason is due to low signal strength downlink, then, check the transmit path.
Check cards, feeder and etc.
• Use MapInfo or Google Earth to find location of sites.
 Cont..
High LAPD Utilization:
• Check LAPD util report from OSS, and define 32 kbps signaling instead of 16kbps
Hardware Fault:
• Check Alarms.
• TRX condition.
• Check Path Imbalance.
• VSWR of the Cell.
• Connector Connection.
• Some times you will find issues on BCCH TRX.In this case BCCH shift from one to
other TRX will reduce SD drop.
Due to ICM Band(CDMA):
• Some time SD drops takes place due to near sites of CDMA.
• Check the ICM band value of that site.
• Use BPF (Band pass filter).
• Use the spectrum analyzer.
Check for parameter:
• Check the Timer T 3101
• Check the Timer T 200(20ms)
• T11 Expired(10 s)
• MAIO check.
 Useful Reports for SD Drop:
• Use report ZEOL to find the alarms.
• Use 208 for Path loss analysis.
• Use 196 for UL-DL Interference.
• Use 163 report for SD drop.
• Use report 216 for detail SD Drop.
• 232 report for TA report.
• 62 for Adj cell having same or adj freq.
• ND 111 for freq plan.
• 204 for BTS and cell report.
 TCH Blocking:
• When TCH is not allocated to the user after SD allocation ,it is TCH Blocking.
• It is the failed call attempts which the MS user can notice.
• It takes place due to lack of TCH Resource.

Reasons for TCH Blocking:

• High Utilization of TCH

• Time slot faulty.
• Lock TRXs.
• HW Problem.
 Optimization TCH Blocking
• If hardware problem exist then need to escalate to the concerned person
• Increase dual Rate for reduce the TCH Blocking ( TCHF TCHD,
• TCHH TCHD)
• Check FRL & FRU setting ( BTS Level)
• Check HRL & HRU setting ( BSC Level)
• Check HRI ( TCH in handover) setting ( BSC Level) ( it should be 5 and it means TCH has to
be primarily allocated from the best BTS of the handover candidate list)
• Directed Retry Enable
• Remove Extra SDCCH Channel and convert in to TCHD in case of high TCH Traffic to
reduce the blocking
• In case of Overshooting check RXP setting
• In case of very high traffic in clusters then we can reduce the power
• Traffic Sharing
• Add Extra TRX
• Add New Site
• Optimize the cell boundaries to share the traffic with surrounding cells
• Traffic Reason Handover enable
• BLT (BTS Load Threshold) can also be increased from 70 to 90 value.
/
 TCH Assignment:

• It’s a process of by which TCH is assigned to the MS.

• After the SD request MS gets TCH successfully and the call transfers to TCH it means
TCH assignment is successful.
• For the best KPI TCH assignment should tend to 100%.
• It degrades due to HW problems.
 Reasons for TCH Assignment failure:

• Hardware Fault(TRXs,Combiner,Duplexer,Cables)
• VSWR
• High Path Loss.
• Faulty TMA.
• High TCH Blocking.
• Loose connections.
• DR being used extensively
• Timer T10 Expired ( BSC Level)
• Queuing not Allowed
• Queue Full
• Due to Radio Problem
• Due to Hardware Issue
 Solutions for removal of TCH Assignment:
• Clear VSWR
• IF TRXs are faulty lock them and try to replace them soon to avoid blocking
• Path Imbalance clear.
• Connection from BTS to Antenna
• Connector connection
• Check TMA.
• Check Duplexer,Combiner,TRXs connections,Multicuppler etc.
• Check BOIA card.
• Check BB2F Card.

Reports for TCH Assignment:

• ZEOL to check alarms
• 208 for path imbalance
• 196 for UL-DL interference
• ZAHP for Flick report
 What is Dropped Call?
• A dropped call is call disconnection post Tch Assignment. This could be caused by
software errors, congestion, C7 link failures,HW problems or many other reasons.
• If a call is abnormally disconnected, a Clear Request is sent to the MSC .If the Call is
disconnected in a normal way then Clear Message with cause code Call Control is
sent. It is important to establish what types of calls are failing, and over what
percentage of the network it is occurring.
• Major reasons are poor Rx lev(<-110db),Rx qual(>6), shadow area, Abis fluctuations,
Ater fluctuations, Hardware malfunction.
• Based on last 4 SACCH frame MR we can get the failure code report generated.

TCH Drop:
• Drop during conversation is known as TCH drop. It takes place after connect ACK
msg on TCH.TCH drop occurring.
• For TCH drop first cross check the BCCH of that cell, hardware issue may be, change
RXP and RLT value. Find out there is any interference ,neighbor defined.
 Reasons for TCH Drop:
• Wrong Parameter Planning.
• BAD HOSR.
• Hardware Fault.
• High TR Fail.
• Overshoot.
• Outage.
• Due to Low Coverage.
• Due to ICM Band(CDMA)
 Solutions for removal of TCH Drop:
Check Parameter:
• Check the BCCH Plan (C/I or C/A).
• Co-BSIC & Co BCCH.
• Check the Timer T 100(should be 20 ms)
• Check Overshooting:
• If a cell is picking call from long distance, Check the sample log according to TA..
Site Orientation.
• Effective tilt should be check.
• Mount position should be check
Improve HOSR:
• Check the Hopping plan.
• Check the Neighbor Plan
• High TR Fail:
• Check and clear TR fail from oss end
 Optimization-Drop Call Rate
• If hardware problem exist then need to escalate to the concerned person.
• If tch_Radio_fail counter value is high it means drops because of RF Issue for which there
issue like Overshooting, interference , Neighbor relation etc.
• To improve TCH drop we can parameters like:- RLT (Radio Link Time Out) , RXP etc.
• If tch_rf_old_ho is high then check neighbor relation and do tuning according to
conditions.
• If tch_lapd_fail and tch_tr_fail is suddenly increased or its increasing then this problem
occurs due to Transmission issue i.e for this we have to check ND report 522 and ZAHP
Alarm history for Transmission problem.
• ND Report 160 and 163 used for analysis of drop call rate.

/
 Reports for TCH Drop:

• 166 for TCH Drop

• ZEOL for alarms.
• ZAHP for Flicks.
• 232 for TA report.
• 208 Path Imbalance report.
• 204 for BTS report.
• 216 for all parameter.
• 196 for UL-DL Qul.
• 62 for Adj cell having same or adj freq.
 HOSR:
• Hand over success rate:
• If HOSR will be good TCH drop will also be good.
• If Handover success rate degrades call drop rate will take place.

Reasons for Poor HOSR:

• Improper Neighbor planning.
• CO-BCCH-BSIC issues in Neigh.
• Parameter Check.
• HSN clash.
• SL value.
• LAC boundary.
• DAC value mismatch.
• Syn mismatch.
• Overshoot.
• HW Issues.
• Low Coverage
 Worse Hand over Cell

Hardware issue Yes

Is Blocking High? suspected Check Alarm

No No
RF Issues suspected Check TRX
Configuration

Check 154 HO Report to find out UL and DL quality, UL interference band

Check 153 HO report to find out majority failures

towards which cells?

Possible reasons: Target cell has co-channel/Adj channel interference, coverage gaps, neighbor BCCH/BSIC
frequency not updated, wrong CGI format in MSC, wrong HO number in MSC, Non-symmetric HO relations, synchronization
problem, excessive UL interference, site too high, Direct Retry traffic cause high HO Failures.
.

Check LAC in the case of Inter BSC and MSC HO

 HARDWARE ALARMS
There are several hardware alarms in NOKIA system which are badly affecting the KPI
• BCCH Missing ( Site Down, Please refer Outage Report ND-023)
• BTS Faulty ( BTS Down)
• BTS Operation Degraded
• BCF Operation Degraded
• TRF Faulty ( Faulty TRX shows as BL-TRX Automatically)
• TRX Operation Degraded
• BTS With NO Transaction
• Channel Failure Rate Above Defined Threshold
• Mean Holding Time Below Defined Threshold
• Traffic Channel Activation Failure
• Transcoder Channel Failure
• BTS O&M Link Failure (OMU Block)
• CH Congestion In Cell Above Defined Threshold
• LAPD Failure
• PCM Failure
• Some alarm I have explained in the next slides, please see the given below slides
Channel Failure Rate Above Defined Threshold

Please see the given below core analysis for the 7745 Alarm time slot with the highest
failure rate

02 01 01 00 00 00 00 00 00 01 04 100d

01 means Faulty Timeslot

02 represents Alarm on
8 Time Slots
SDCCH Channel

Shift the SDCCH channel from that TRX or remove SDCCH if there is extra SDCCH timeslots
The same scenario start for TCH but at the starts there is 01 in place of 02 and for that is any timeslot is faulty then we can
go for Locking Timeslot & Locking TRX and after Lock we can check the Performance in Hourly KPI

/
BTS O&M Link Failure

• Regarding this Alarm we just need to remember one thing if this alarm persists the
OMU of the site blocked and at the same case don’t reset the BCF, if we do this
reset BCF than after lock the BCF it will not be unlocked until OMU is not UP and if
OMU up then also site will be down because BCF is Locked so better when this alarm
comes don’t Reset the BCF.

• This above point is the main point regarding this Alarm, please remember it always.

/
BTS With NO Transaction

• The BTS has had no successfully terminated calls or SDCCH transactions during the
supervision period.
The alarm is used for supervising the BTS traffic capacity.

• Reason for the alarm

1 = no successful SDCCH seizures
2 = no successful TCH seizures
3 = no successful SDCCH nor TCH seizures

/
 PCM Failure

• Alarm 7704 is BCF-specific. It is used by the RNW recovery part of the BSS system. This
alarm (and cancel) will cause radio network recovery actions concerning objects
connected through the faulty
PCM (ET). Alarm 7704 does not occur alone. There are always some other alarms ( 7767,
2900, 2915, 7706, 7704) active at the same time.

• 7767 : BCCH Missing

• 2900: Incoming Signal Missing
• 2915: Fault Rate Monitoring ( the trunk network circuit supervision clears the calls that
come through the ET(S) in question and directs new calls through trunk circuits which are
in order )
• 7706: BTS O&M LINK FAILURE
•

/
TRX NOTIFICATION ALARM STATUS (Synchronization changed to Holdover mode)

From this alarm only Common ABIS Cells are affected and major alarm description is SYNCHRONIZATION
CHANGED due to HOLDOVER MODE and this alarm persists after software upgrade

• This alarm persists when BTS is not able to synchronize with the BSC / Core Network and due to this alarm
persist synchronization changed due to holdover mode.
• May be this alarm persists sue to some error in Software upgrade for COMMON ABIS sites.
• We can check the BTS configuration setting as after software upgraded may be some setting change.
• Check the heater working properly or not if equipped.

Action Proposed to remove this alarm and you can try these given below steps also.
▪ check the sync with MGW and BSC, MGW and MSS.
▪ Just make the SYNC disconnect by the command ZDRD
▪ After disconnect SYNC remove the punching cable or optical path cord as per your connection
▪ After this run ZDRI and then state will be pleisochronous mode
▪ After 10-15 min just punch the cable or connect the fiber and connect the 2M1 or 2M2 by ZDRC and then make the
state to hierarchal SYNC
▪ After above all steps just restart the system

/
Transmission Alarm

• There are lot of major alarms persists in the BSC but some of them are not affecting
the KPI’s but some really affecting the KPI’s, please see the given below alarm status

• BTS & TC Unsynchronisation Clear calls due to A interface ( Affecting Drop Call Rate)
• BTS & TC Unsynchronisation Clear calls due to ABIS interface ( Affecting Drop Call
Rate)
• Abnormal A interface Circuit Release ( Affecting Drop Call Rate)
• SCCP Disturbance ( Affecting SDCCH Drop Rate)
• AIS Received ( Site Fluctuates)
• Fault Rate Monitoring ( Site fluctuates)
• Telecom Link Overload
• Signaling Link Load Over threshold
• Adjacent Cell IDENTIFIER configuration error

/
Adjacent Cell IDENTIFIER configuration error

• adjacent cell information has been defined incorrectly in the BSDATA (BSS Radio Network
configuration Database). Either the MSC or the source BSC can detect the error during an external
handover. When the error has been detected, the handover attempt is interrupted

1182 : BTS ID
0 : the MSC has detected an error in the adjacent cell definitions
1 : the BSC has detected an error in the adjacent cell definitions
0-FF: BCC (Base Station Color Code). The target cell where handover has been attempted. The
value is set by the MSC
FF information is not available
0-FF: NCC (Network Color Code). The target cell where handover has been attempted. The value is
set by the MSC
FFFF identification of the target cell (BCCH)
/
65535: No information of BCCH
 Solutions for removal of HOSR:
• Arrange Drive Test:
• The best way to find the real issues for HO fail make DT and check layer 3 msg for
HO fail . By DT it is very easy to find the fail between cells.
• Neighbor Tuning:
• Check for Missing Neighbors.
• Avoid CO-BCCH-BSIC neighbors.
• Avoid excess neighs.
• Delete long distance neighs.
• There should be no one Way Neighbors.
• If there are high fail delete and recreate neighs.
 Cont..
• Parameter Check:
• Retune SL.It can change bw -90,-95,-105.
• Check HSN.
• Check SYN.
• Retune LDR, LUR, IDR, IUR.
• Retune LMRG, QMRG, PMRG.
• DAC value Check:
• Check DAC value. If DAC value is high or low tune it at the TH value. It should be
~2048.
 Cont..

• Overshoot:
• When neighs are far away then chances of HO fail increases. In this case ping-pong HI
takes place by which fail takes place. So it the inter distance is high its batter to del
that kind of neigh.
• LAC Boundary-
• Check LAC boundry.
• High fail takes place there will be Inter BSC cells.
• High fail takes place there will be Inter MSC cells.
• Define proper LAC in neigh cells.
 Cont..

• HW Issues:
• Clear HW issues.
• Check TRXs.
• Check outages.
• Check BOIA Card. Because if it is faulty incoming and outgoing HO will be fail.
• Clear Reports:
• Clear ZEAT.
• Clear 60.
• Clear 67.
• Clear 61.
 Reports for HOSR :

• 153 reports for HO fail bw two cells.

• 154 HO analyses.
• 60 for discrepancy.
• 67 for Sync report.
• 61 for one way neigh.
• ZEAT for CO-BCCH-BSIC neighs
• 74 for HO definition report.
• ZELO for inter MSC HO report.
• 150 for high HO fail.
• 157 for high HO attempt and call ratio.
• 158 for intra BSS HO observation.
• 62 for Adj cell having same or adj freq.
 High RACH Failures:

• Other reasons look for Random access statistics, if there is a lot of random access
failures try to check hardware too. It includes thorough hardware audit including CF
Reloading, IDB Setting and reloading, Software synchronization, filter check etc)
 Alarms Impacting KPIs
• BTS Operation Degraded (7604) - It shows VSWR on cell.
• TRX Operation Degraded (7607)-It shows critical alarm on TRXs.
• Channel Fail Rate (7745)-It shows faulty TS on TRXs.
• BCF Operation degradation ()-It shows DAC value alarm.
• Ex-TCH Interference (7744)-TRXs faulty or back plan problem.
• Mean Holding Time(7743)-to detect faulty channels.
• Working SD Ratio Below TH level (7712)- .Its for the ratio of SDs.
• LAPD Fail-TX link fail.
• Antenna Connection Faulty (7606)-Shows faulty in cable connections.
• High Temp Alarm-TRXs begins fluctuating.
THANK YOU