Nokia KPI & Core Optimization
1
© Nokia Siemens Networks
BASIC KPI Target
 KPI basic for new site has been agreed, Introduce new “Lock Value”
SD Drop less than 2 %
SD Blocking less than 1 %
TCH drop less than 2%
TCH assignment Success greater than 95 %
HOSR is greater that 95 %
CSSR greater than 98%
TCH Blocking less thank 1%
2
© Nokia Siemens Networks
/
Topics Covered
•
•
•
•
•
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
3
© Nokia Siemens Networks
/
Consistency Parameter Check
•
•
•
•
•
•
•
•
•
•
•
•
•
4
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
Neighbours with co-channel frequencies
Neighbours with adj-channel frequencies
Neighbours 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
© Nokia Siemens Networks
/
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)
5
© Nokia Siemens Networks
/
•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.
6
© Nokia Siemens Networks
/
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
7
© Nokia Siemens Networks
/
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)
8
© Nokia Siemens Networks
/
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
4. No handover happening after frequency retune between 2 cells from different
BSCs
• ADCE table has not been updated for other BSC
9
© Nokia Siemens Networks
/
Set with impact on network operation/performance– Handover
• Example of Wrong Parameter Settings
10
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
© Nokia Siemens Networks
/
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!
11
© Nokia Siemens Networks
/
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)
12
© Nokia Siemens Networks
/
KPI Evaluation Process
13
© Nokia Siemens Networks
/
HOW DO WE NEED TO START OPTIMIZATION
• Firstly we need to check the KPI of Cluster Level & BSC level
• After that Check the KPI of which BSC is going down and then find the
cells due to which KPI’s going worst
• Now check the Cells KPI ( Preferably CSSR, DCR & HOSR ) why it is
going worst
• If CSSR KPI is worst then we need to check all the components of the
CSSR ( TCH Blocking, SDCCH Blocking, SDCCH Drop, TCH Assignment
success Rate) & if DCR KPI worst check all the Raw counters also
according to the formula and same procedures for the HOSR.
We need no check all the counters
also for the respective KPI’s not just
like high Blocking or high Drops as it
is also plays the very important role
in Core-optimization
14
© Nokia Siemens Networks
/
CSSR KPI
• As we know CSSR depends on the 4 Components (TCH Blocking,
SDCCH Blocking, SDCCH Drop, TCH Assignment success Rate )
and if any of the components KPI’s going worst than CSSR will be the
worst.
• I will discuss these cases one by one
• For CSSR check we use ND Report 250 i.e for Cell by call Success ratio.
ND Report250
• For Hardware we will discuss later
15
© Nokia Siemens Networks
/
CASE-1 CSSR BAD Due To High SDCCH Drop Rate
SDCCH Drop rate may be
high due to many
reasons as given below
Hardware Problem in a
Cell
Overshooting
Co-channel Interference
Transmission issue
Phantom RACH
Extra SDCCH
As the above KPI shows that CSSR is going
worst due to high SDCCH Drop Rate and No we
have to find out the reason for High SDCCH
Drop Rate
16
© Nokia Siemens Networks
/
ND Report 166 SD
Drop Report
SDCCH Drop Call Rate (%)
No. of SD transaction failures due to
the radio failure of the former channel
during SD-SD or SD-TCH HO. (1004)
No. of SD transaction
failures due to the radio
failure (1003)
•
•
•
•
Formula:
100 * (traffic.sdcch_radio_fail + traffic.sdcch_rf_old_ho +
No. of SD transaction
traffic.sdcch_user_act + traffic.sdcch_bcsu_reset +
failures due to BTS
failure. (1036)
traffic.sdcch_netw_act + traffic.sdcch_bts_fail + sdcch_lapd_fail+
sdcch_a_if_fail_call+sdcch_a_if_fail_old) /
Number of SDCCH transactions ended
• (traffic.sdcch_assign + traffic.sdcch_ho_seiz)
because of a failure in the A interface on
the source channel during an SDCCHSDCCH or SDCCH-TCH HO
No. of successful
SDCCH seizures for
a handover. (1006)
No. of SDCCH
assignments. (57021)
No. of SD transaction failures due
to radio N/W reconfiguration
actions. (1039)
No. of SD transaction
failures due to user
action. (1037)
•
17
Number of SDCCH transactions ended
because of a failure in the A interface
during a call attempt.
No. of SD transaction
failures due to BCSU
reset. (1038)
Counter from table: p_nbsc_traffic (Traffic Measurements)
© Nokia Siemens Networks
SDCCH Drop Rate KPI Analysis
ND Report 166
Please make sure SDCCH_ABIS_FAIL_CALL counter we don’t
include in the KPI’s formula of SDCCH Drop Rate as this is not
the customer satisfactory.
Now in the above KPI we can see the SDCCH drop rate is high due to
SDCCH A interface fail call is high as major drops are going only on this
counter and it is suspected due to Transmission issue so for root cause
we need to check the all counters.
18
© Nokia Siemens Networks
/
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.
19
© Nokia Siemens Networks
/
Extra SDCCH Analysis
According to KPI there should be only one
SDCCH timeslot but if I check the Database
configuration it has 4 SDCCH so we need to
remove the extra SDCCH from the TRX’s
20
© Nokia Siemens Networks
/
CASE-2 CSSR BAD DUE TO BAD TASR
TASR Bad due to Several Reasons
Hardware Faulty
Timer T10 Expired ( BSC Level)
Queuing not Allowed
Queue Full
Due to Radio Problem
Due to Hardware Issue
21
© Nokia Siemens Networks
/
TASR FORMULA
•
•
•
•
•
•
•
•
•
•
•
•
22
[sum(a.tch_radio_fail+ a.tch_abis_fail_call + a.tch_a_if_fail_call + a.tch_tr_fail +
a.tch_user_act + a.tch_bcsu_reset + a.tch_netw_act+ a.tch_act_fail_call + a.tch_lapd_fail+
a.tch_bts_fail)]
- [sum(a.spare057044) - sum(a.tch_rf_old_ho + a.tch_abis_fail_old + a.tch_a_if_fail_old +
a.tch_tr_fail_old)]
100%( * ----------------------------------------------------------------------------------------------------) %
Number of successful incoming SDCCH ;
sum(a.tch_norm_seiz)
to TCH HOs controlled by the MSC
(normal calls)
+ sum(c.msc_i_sdcch_tch + c.bsc_i_sdcch_tch + c.cell_sdcch_tch)
;(DR calls)
- sum(a.tch_succ_seiz_for_dir_acc)
;ref.2
+ sum(a.tch_seiz_due_sdcch_con)
;(FACCH call
setup
Counters from table(s):
a = p_nbsc_traffic
c = p_nbsc_ho
© Nokia Siemens Networks
/
TASR Analysis Counters
As in the above given counters shows that suddenly some the counters
value ( ABIS interface fail, Radio fail etc) increased . Radio fail may be
due to some Radio problems as interference, overshooting etc and if
ABIS fail call increased it may be increased due to some Transmission
alarm.
23
© Nokia Siemens Networks
/
CASE-3 CSSR Bad Due TO Blocking
CSSR is worst due to high
SDCCH & TCH blocking
ND135 Report TCH
Congestion
24
© Nokia Siemens Networks
/
What is TCH Blocking ?
BUSY
BUSY
BUSY
BUSY
BUSY
BUSY
BUSY
BUSY
All Timeslots are busy
When all timeslots ( 8 TS) are busy then it is called congestion
and when at the time of congestion any call come through that
busy timeslot then it is called blocking.
25
© Nokia Siemens Networks
/
TCH Blocking Formula (%)
• Formula:
• 100 * [sum(a.tch_call_req - a.tch_norm_seiz) - sum(b.msc_o_sdcch_tch +
•
•
26
b.bsc_o_sdcch_tch + b.cell_sdcch_tch) + sum(a.tch_succ_seiz_for_dir_acc) –
sum {a.tch_rej_due_req_ch_a_if_crc -(b.bsc_i_unsucc_a_int_circ_type +
b.msc_controlled_in_ho + b.ho_unsucc_a_int_circ_type)} ]
______________________________________________________
[sum(a.tch_call_req) – sum {a.tch_rej_due_req_ch_a_if_crc (b.bsc_i_unsucc_a_int_circ_type + b.msc_controlled_in_ho +
b.ho_unsucc_a_int_circ_type) } ]
© Nokia Siemens Networks
TCH Blocking (%)
No. of TCH requests
for normal
assignment. (1026)
• Formula: (Nom)
• 100 * [sum(a.tch_call_req - a.tch_norm_seiz) –
•
•
No. successful SDTCH HO. (Intra-cell)
(4074)
sum(b.msc_o_sdcch_tch + b.bsc_o_sdcch_tch + b.cell_sdcch_tch) +
sum(a.tch_succ_seiz_for_dir_acc) –
No. successful SDTCH HO. (BSC
Controlled) (4065)
sum {a.tch_rej_due_req_ch_a_if_crc -(b.bsc_i_unsucc_a_int_circ_type +
b.msc_controlled_in_ho + b.ho_unsucc_a_int_circ_type)} ]
Number of unsuccessful
handovers due to wrong Ainterface circuit type. (4097)
Number of unsuccessful
handovers due to wrong Ainterface circuit type.
(4101)
No. successful SD-TCH
HO. (4050)
Number of successful TCH
seizures in direct accesses to
a super-reuse TRX during the
call set-up phase. (1165)
27
No. of successful TCH
requests for a normal
assignment. (1009)
© Nokia Siemens Networks
Number of rejected TCH
requests due to mismatch
between the requested
channel type and the Ainterface circuit type (1122)
Number of unsuccessful
handover due to wrong Ainterface circuit type. (4098)
TCH Blocking (%)
• Formula: (Denom)
•
Number of rejected TCH
requests due to mismatch
between the requested
channel type and the Ainterface circuit type (1122)
sum(a.tch_call_req) – sum {a.tch_rej_due_req_ch_a_if_crc (b.bsc_i_unsucc_a_int_circ_type + b.msc_controlled_in_ho +
b.ho_unsucc_a_int_circ_type) }
Number of unsuccessful
handovers due to wrong Ainterface circuit type. (4097)
28
No. of TCH requests
for normal
assignment. (1026)
© Nokia Siemens Networks
Number of unsuccessful
handover due to wrong Ainterface circuit type. (4098)
Number of unsuccessful
handovers due to wrong Ainterface circuit type. (4101)
TCH Blocking Reasons
• TCH availability
Check alarms (are TRXs & TSLs in Working State? ), check availability
report and RxQuality report to verify whether there is a badly functioning
TRX. Make Loop Tests on TRX. Fix hardware problem.
• TCH capacity
Bad TCH capacity dimensioning. Check number of TRXs.
29
© Nokia Siemens Networks
/
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.
30
© Nokia Siemens Networks
/
SDCCH Blocking (%)
Unsuccessful SDCCH seizure
attempts, due to nonavailability of SDCCH (1001)
• Formula:
• 100 * (traffic.sdcch_busy_att - traffic.tch_seiz_due_sdcch_con)/
traffic.sdcch_seiz_att
Successful seizures of
TCH due to SDCCH
congestion (1099)
Total no. of SDCCH
seizure attempt (1000)
•
31
Counter from table: p_nbsc_traffic (Traffic Measurements)
© Nokia Siemens Networks
SDCCH BLOCKING REASONS
 Too much SDCCH “normal” traffic for cell SDCCH design
- Logical cell design, extra TRX, new site
 LA border at crowded area ( Check HYS Setting)
 Abnormal SDCCH traffic
- “phantom” channel requests
- Inadequate LAC design, causing too much LU
- Redesign LAC
- Problem with neighbor cells belong to other LAC
32
© Nokia Siemens Networks
/
SDCCH blocking
• SDCCH avalability
– Check alarms (are TRXs & TSLs in Working State? ), check availability report
and RxQuality report to verify whether there is a badly functioning TRX. Fix
hardware problem.
• SDCCH capacity
– Check actual SDCCH configuration ( e.g. Combined BCCH/SDCCH, Number of
SDCCH channels). If there is insuficient SDCCH capacity and enough TCH
capacity, add SDCCH TSL. Other solution e.g. are to add TRX, activate
Dynamic SDCCH, activate FACCH Call Setup.
• SDCCH traffic
– Verify traffic distribution (LU, SMS and MOC in %);
– Cell is covering a region greater than planned. Verify TA statistics. May need to
change DMAX, or downtilt.
33
© Nokia Siemens Networks
/
• SDCCH traffic due to location updates
– Bad location area setting (Check MCC, MNC and LAC
parameters)
– Bad Location area geographical configuration. Too small LA
definition will cause many LA updates. Border of LA in a
busy avenue will cause many LUs in both location areas!
– Low value for CellReselectHysteresis
– Verify if downtilt is needed or an increase in SDCCH
capacity (air and Abis interfaces).
• SDCCH traffic due to SMS
– Increase SDCCH capacity (air and Abis interfaces).
34
© Nokia Siemens Networks
/
SDCCH BLOCKING ANALYSIS
35
© Nokia Siemens Networks
/
DCR FORMULA
•
sum(tch_radio_fail+ tch_rf_old_ho+ tch_abis_fail_call+ tch_abis_fail_old+
tch_a_if_fail_call+ tch_a_if_fail_old+ tch_tr_fail+ tch_tr_fail_old+ tch_lapd_fail
+ tch_bts_fail+ tch_user_act+ tch_bcsu_reset+ tch_netw_act+ tch_act_fail_call)
100 * ------------------------------------------------------------------- %
sum(a.tch_norm_seiz) ;(normal calls) + sum(c.msc_i_sdcch_tch +
c.bsc_i_sdcch_tch) ;(calls started via DR) + sum(a.tch_seiz_due_sdcch_con)
;calls started as FACCH call setup
•
•
•
Counters from table(s):
a = p_nbsc_traffic
b = p_nbsc_res_access
36
© Nokia Siemens Networks
/
DCR ANALYSIS
As by the above counters you can directly say from what reasons drop call rate is high as it may be due to RF reasons or
may be due to Transmission Issues so we need to know about all the counters
37
© Nokia Siemens Networks
/
Optimization of 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
•
•
•
•
38
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.
© Nokia Siemens Networks
/
TCH Drop
Radio Fails
Check alarms and RxQuality report to verify whether there is a badly functioning TRX.
Fix hardware problem. Check antenna line.
Coverage. Verify TA report and planning tool.
Interference. Check Frequency Plan. Solution e.g. add sites, downtilt antennas, increase
RxLevAccessMin.
Lack of neighbours
Bad neighbour declaration
Transcoder Failure
Due to synchronisation problem. Synchronisation source set in BTS clock. Change to
BSC.
AIF Failure:
Interface failures: problem with ET cards. Solution: block the circuits connected to this
card and then change ET card when available.
39
© Nokia Siemens Networks
/
Handover Success Rate
HO failures
HO attempts - successful HOs
100* --------------- % = 100 * --------------------------------- %
HO attempts
HO attempts
successful HOs
= 100 * (1- -------------------------) %
HO attempts
ND153 Report
ND154 Report
sum(msc_o_succ_ho + bsc_o_succ_ho + cell_succ_ho)
= 100 * (1------------------------------------------------------------------------------------------------------ )%
sum(msc_o_tch_tch_at + msc_o_sdcch_tch_at + msc_o_sdcch_at
+ bsc_o_tch_tch_at + bsc_o_sdcch_tch_at + bsc_o_sdcch_at + cell_tch_tch_at +
cell_sdcch_tch_at + cell_sdcch_at)
Counters from table(s): p_nbsc_ho
Known problems:
1) Blocking is included. Blocking makes this indicator show high values especially in
the case of IUO, but it does not necessarily mean that there are some technical
problems.
2) Calls that are cleared by MS user during the HO process increment the attemptcounters but can not be compensated in numerator.
3) HO that is interrupted due to other procedure (e.g. assignment) increments
attempt-counters but can not be compensated in numerator.
40
© Nokia Siemens Networks
Worse Hand over Cell
Is Blocking High?
Yes
Hardware issue
suspected
No
Check Alarm
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
41
© Nokia Siemens Networks
41
© 2005 Nokia
V1-Filename.ppt / yyyy-mm-dd / Initials
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
42
© Nokia Siemens Networks
/
Channel Failure Rate Above Defined Threshold
Please see the given below core analysis for the 7745 Alarm
02
01 01 00 00 00 00 00 00
01
04
time slot with the highest
failure rate
100d
01 means Faulty Timeslot
02 represents Alarm on
SDCCH Channel
8 Time Slots
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
43
© Nokia Siemens Networks
/
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.
44
© Nokia Siemens Networks
/
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
45
© Nokia Siemens Networks
/
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
•
46
© Nokia Siemens Networks
/
TRX NOTIFICATION ALARM STATUS SOUTH SUMATRA
(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
47
© Nokia Siemens Networks
/
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
48
© Nokia Siemens Networks
/
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
49
© Nokia Siemens Networks
/
SDCCH Drop Analysis With Respect To Transmission
50
© Nokia Siemens Networks
/
SCCP Disturbance
0B 08 0000188D FE 0000177B FE 0000
0B means Sending Message to MTP has Failed
08 Means National Network 0
51
© Nokia Siemens Networks
/
SDCCH Drop Rate Affects By Transmission Alarm
52
© Nokia Siemens Networks
/
BTS & TC Unsynchronisation Clear calls due to ABIS
interface
2993 ( BTS & TC UNSYNCHRONIZATION DUE TO CLEAR CALLS ON ABIS INTERFACE)
Calls have been cleared three successive times on the same ABIS interface channel due to BTS and Transcoder unsynchronisation
Supplementary Information filed

BTS Id on which calls are getting dropped

TRX id of the above BTS id on which calls are getting dropped.

Radio Timeslot number on which calls are getting dropped. This is Air Interface Timeslot number

ET Number on which calls are getting dropped.

ET Timeslot on which calls are getting dropped

Sub Timeslot of ET on which calls are getting dropped
This alarm tells us the calls are getting cleared through the ABIS interface due to non Availability of the transmission on ABIS
interface and please make sure when this alarm is triggered means calls are getting thorough on the Air interface but gets dropped
on ABIS interface.
ZAHP : 643d 9d 04 1080d 10d 1d
It means BTS ID=643, TRX ID=9, Timeslot Number=04 , ET ID=1080, TRX ID=10, Sub Timeslot of ET=1
First identify the ABIS (ET) Timeslots on which calls are getting dropped. If calls are getting dropped on all the Timeslots of TRX
this means either they are mapped differently on BSC & BTS or Timeslots are not bypassed correctly.
If calls are getting dropped on particular Timeslot only lock that Timeslot and recheck alarms after sometime.
SOLUTION:
•
If calls are getting cleared by all the timeslot for the particular TRX firstly please lock the TRX and check the alarm after
sometime.
•
We can try to change the Channel TSL also if there is any free mapping given.
53
© Nokia Siemens Networks
/
Telecom Link Overload
•
The alarm is used to supervise the traffic load of LAPD links and BCSU units and to detect the possible
overload situations. The alarm may also be caused by short breaks in the Abis interface.
Supplementary information fields
00: BCSU unit overloaded
01: LAPD link overloaded
54
© Nokia Siemens Networks
/
ZYMO Command Check For Transmission flicker
•
By this command we can check which ET is fluctuating , and by this command we can see trunk circuit
disturbance statistics please see given below analysis
NOINSGN
incoming signal missing
AIS AIS state has been detected in the incoming line signal
(continuous "1-state")
FALOST - frame alignment has been lost
REMOTE - alarms from remote end
TOTAL TIME - measured total time
AVAIL TIME - time of availability
UNVAIL TIME - time of unavailability
EFS - seconds without errors
ES - seconds with errors
SES - seconds with a great number of errors
DM - deteriorated minutes
55
© Nokia Siemens Networks
/
ND Report Analysis
56
© Nokia Siemens Networks
/
Adjacency definition(061)
Find all non symmetrical adjacencies : One Way Adjancies
• cell B is neighbor of Cell A
• cell A is not neighbor of Cell B
Cell A
57
© Nokia Siemens Networks
Cell B
ZEAT Check
Co channel discrepancies , or
LAC discrepancies etc
Co channel discrepancies
58
© Nokia Siemens Networks
/
Adjacency Discrepancies (060) –
Example
=================================================================================
=
ADJACENCY DISCREPANCIES
=
Network:
PLMN
=
Area:
All BTSs selected
=
Sorting key:
source BSC name, source BTS ID
=================================================================================
This report lists the discrepancies of various parameters between the source cell adjacency parameters and target cell
parameters.
Impact of discrepancies:
Any difference between two identical parameters of the target BTS and the same parameter of adjacency usually results in
handover failures between the source and the target BTSs.
The first of each pair of lines indicates the adjacency of a source cell.
The second line indicates the target cell.
Parameters in the first line show the values in the adjacency (ADJ) of a source cell defined in c_adjacent_cell table.
Parameters in the second line (TGT) show the values of the target cell in c_bts table.
The checked parameters are: Location Area Code (LAC), Cell Identity (CI),Frequency (FREQ), Maximum power of MS (PMAX),
Network Colour Code (NCC) and Base Station Colour Code (BCC). These should be the same in the adjacency and in the
target cell.
In case there is any kind of discrepancy indicated by the report, do the following:
1) Upload adjacency data from the network for the claimed BTSs.
2) Run this check again.
3) If discrepancies are still found, check and correct them via MML.
================================================================================
Adjacency discrepancies in PLMN network
LAC CI
FREQ PMAX NCC BCC
=== ===
=== ==== === ===
Source BSC (BTSid)
Source BCF/BTS
ADJ ADJ
ADJ ADJ ADJ ADJ
Target BSC (BTSid)
Target BCF/BTS
TGT TGT
TGT TGT TGT TGT
------------------ ---------------------------- ------ ------ ---- ---- --- --BSC1KUTOJA(6)
SUOSAA004 / SUOSAA1006
1
10010 600 30 7
2
BSC1KUTOJA(10)
LAAJAL010 /LAAJAL1010
1
10010 773 30 7
2
BSC1KUTOJA(7)
SUOSAA004 / SUOSAA1007
1
10010 600 30 7
2
BSC1KUTOJA(10)
LAAJAL010 /LAAJAL1010
1
10010 773 30 7
2
BSC1KUTOJA(9)
LAAJAL009 / LAAJAL1009
1
10010 600 30 7
2
BSC1KUTOJA(10)
LAAJAL010 /LAAJAL1010
1
10010 773 30 7
2
BSC1KUTOJA(9)
LAAJAL009 / LAAJAL1009
2
20003 594 30 7
7
BSC2UPS1(3) 3UPS001 /3UPSULTRA2003
2
20003 764 30 7
7
BSC1KUTOJA(9)
LAAJAL009 / LAAJAL1009
2
20002 600 30 7
7
BSC2UPS1(2) 3UPS001 /3UPSULTRA2002
2
20002 762 30 7
7
BSC2UPS1(1) 3UPS001 /3UPSULTRA2001
2
20001 776 30 7
7
BSC2UPS1(10) 5KOM005 / 5KOM2010
1
10009 605 30 7
2
59
© Nokia Siemens Networks
Undefined Adjacent Cell Measurement
- Network Doctor Script 073 -
Number of samples for calculating the
average DL signal strength
Average strength of the downlink signal
received from an undefined adjacent cell
BCCH, NCC, BCC of adjacent cell
60
© Nokia Siemens Networks
ND-51 ( GPRS Parameter Settings)
61
© Nokia Siemens Networks
/
ND-074
62
© Nokia Siemens Networks
/
ND-130 Cells Having SDCCH Congestion
63
© Nokia Siemens Networks
/
ND-135 Cells Having TCH Congestion
64
© Nokia Siemens Networks
/
ND-208 Analysis
Case1: Jumper from TRX 4 to combiner loose (check
connectors at both ends)
Case2: Jumper from Duplexer to TRX 4 (check
connectors at both ends)
Case3: Check common feederline from Top of cabinet
to Antenna port ( loose connector’s at either end or High
VSWR problem, TRX 2&4 in this case use the same
feeder)
In this case, the Path imbalance (DL-UL) varies between
+1.6 to -4dB which doesn’t tell much
BUT DL pathloss variations between TRX’s is from 112.8
to 136dB
& UL pathloss variations between TRX’s is from 111.2 to
140dB
DEFINITELY A PROBLEM!
65
65
© 2005 Nokia
V1-Filename.ppt / yyyy-mm-dd / Initials
© Nokia Siemens Networks
66
ND Report 196
© 2005 Nokia
V1-Filename.ppt / yyyy-mm-dd / Initials
66
© Nokia Siemens Networks
ND Reports
ND196 Report
ND061 Report
ND 067 Report
060 ND Report
ND166 Report
ND163 Report
ND135 Report
ND150 Report
ND250 Report
ND154 Report
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 seee 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.
67
67
© 2005 Nokia
V1-Filename.ppt / yyyy-mm-dd / Initials
© Nokia Siemens Networks
ND208 Report
ND153 Report
ND 074 Report
ND204 Report
Alarm Description
Internal Alarms with
Meaning
68
68
© 2005 Nokia
V1-Filename.ppt / yyyy-mm-dd / Initials
© Nokia Siemens Networks
THANKS
69
© Nokia Siemens Networks
/