Professional Documents
Culture Documents
SCOPE:
2G performance monitoring and analysis
CONVENTION:
Raw counters are marked in BLUE
Formulas are marked in GRAY
Parameters are marked in RED
MML commands are marked in GREEN
The following analysis contains a list of the most common KPIs used in Huawei networks. These KPIs are
monitored constantly. When the value of a KPI goes below the defined threshold, then detailed analysis
should be performed in order to identify the reasons of this deterioration. Once the reasons are found, proper
solutions will be proposed and implemented.
This document focuses more in the analysis of failure causes rather than the KPI monitoring itself.
The most common use cases for monitoring and analysis of bad values are presented for 2G BSS.
CS:
1.High SDCCH Blocking
2.High SDCCH Drop rate
3.CSSR
4.High TCH blocking
5.High TCH Drop call rate
6.High HO fail
7.Low Coverage – how to identify coverage problems (e.g. TA vs. cell radius, Rxlevel measurements, HO
distribution…)
8.High Interference – how to identify interference problem in cell (idle UL interference, Rxlevel & Quality
distributions, TA measurements)
PS:
9.High Signaling Failures Before TBF Establishment
10.High TBF Establishment Failures
11.High TBF Drops
12.Low Throughput (Um, Abis, PCU, Gb)
1. Define BSS KPI class required (Accessibility, Retainability, Mobility, Resource Usage).
2. Define KPI per service (Voice, Packet Service).
3. Define KPI formulas.
4. Define target or guaranteed KPI values.
5. Assess weekly average PLMN/BSC KPI performance in order to identify KPIs below target.
6. Assess BSC/Area level performance in order to check if bad performance occurs across network or only in
specific areas.
7. Analyze bad performing KPIs in cell level in order to identify failure causes. (this point is the focus of
this document)
8. Use TopN cell approach to identify the worst performers. Identify top 20 worst cells.
9. Look at failure distribution in network topology (urban, rural, motorway, RNC border, etc.).
10. Propose solution to improve KPI value.
Analysis process:
1.High SDCCH blocking is due to congestion on the SDCCH channel. Check what causes the high SDCCH
usage. Then appropriate actions can be taken:
•Check amount of SMS. Check and verify with Core engineers SMS Center parameterization.
- A3030B: CELL_ESTB_IND_MOC_SMS_SD: Number of Call Setup Indications for SMS on
SDCCH
- CA3340: CELL_Pt_to_Pt_SMS_SD: Number of Point-to-Point Short Messages on SDCCH
(includes
UL+DL)
• Check if the problem is caused by roamers that do not have access to the network, thus causing big
amount of failed LAUs/RAUs.
• Check if cell is in LA border: if yes, then we can increase CRH parameter value
- CRH: Cell Reselect Hysteresis Parameters (Cell reselection hysteresis. This is one of the parameters
used for deciding whether to reselect cells in different location areas.)
• Check LA border planning. Verify LA borders by checking HO statistics between cells in LA border:
- H380:CELLCELL_INCELL_HO_REQ: Incoming Inter-Cell Handover Requests between 2 cells
• Check whether moving LA borders (if possible to move) could help relieving the congestion.
• Check the pattern of LAU requests. Check hours and duration of high number of such requests.
Check whether the problem is constant throughout the day or it occurs only during 1 hour for example.
If the problem occurs only on specific hour of day check if it is worth acting to solve it (costs vs.
benefits).
4. Activate SDCCH dynamic conversion feature: Dynamic SDCCH conversion can be triggered if the
SDCCH resource is insufficient or the SDCCH allocation fails during the channel assignment
- SDDYN: SDCCH Dynamic Allocation Allowed (Whether to allow SDCCH dynamic allocation, that is,
whether to allow dynamic conversion between TCHs and SDCCHs.)
- IDLESDTHRES: Idle SDCCH Threshold N1 (When the number of idle SDCCH channels in a cell is
smaller than this parameter, the system searches for available TCHs and transforms them into SDCCH
channels)
- CELLMAXSD: Cell SDCCH Channel Maximum (Maximum number of SDCCHs in the cell. Before
converting a TCH into an SDCCH, the BSC compares the number of SDCCHs after the conversion in
the cell with "Cell SDCCH Channel Maximum". If the number of SDCCHs after the conversion in the cell
exceeds this parameter, the BSC does not convert the TCH into an SDCCH.)
6. Add TRX
Analysis process:
1.Identify the route cause of SDCHH drops by checking the following counters. The total number of
SDCCH drops is given by:
Call Drops on SDCCH = [Call Drops on Radio Interface (SDCCH)]+[Call Drops due to No MRs from MS for a
Long Time (SDCCH)]+[Call Drops due to Abis Terrestrial Link Failure (SDCCH)]+[Call Drops Due to
Equipment Failure (SDCCH)]+[Call Drops due to Forced Handover (SDCCH)]:
•Call Drops on Radio Interface (SDCCH): the drop is due to radio. Check for missing neighbours. Check
radio environment/signal strength at drop points. Adjust antenna parameters appropriately to improve
coverage if this is the problem. Check whether the drops are during handover. Check interference.
•Call Drops due to No MRs from MS for a Long Time (SDCCH): After seizing an SDCCH, the MS sends a
measurement report to the BSC every 470 ms. When the BSC does not receive a measurement report
within a certain period of time, the BSC sends a CLEAR REQUEST message to the MSC to release the call,
and this counter is incremented by one. Check UL coverage and quality (interference). Check for possible
MS problem.
•Call Drops due to Abis Terrestrial Link Failure (SDCCH): transmission problem on Abis. Check relative
alarms.
•Call Drops Due to Equipment Failure (SDCCH): BSC hardware or software failure. Check alarms to
discover the exact cause.
For internal use
12 © Nokia Siemens Networks Presentation / Author / Date
2. High SDCCH Drop Rate (2)
• Call Drops due to Forced Handover (SDCCH): After an MS seizes a channel, if the system initiates a
forced handover and the handover fails, the BSC may initiate a call release procedure. Check why the
handover failed: Timer expired? Check whether the emergency handover is due to preemption, or
blocking of cell/TRX/channel.
Analysis process:
1.Each of the 3 component-KPIs will affect CSSR:
- Low Immediate Assignment Success Rate will decrease CSSR
- Low TCH Assignment Success Rate will decrease CSSR
- High SDCCH Drop Rate will decrease CSSR
2.Examine at which point most of the failures appear by checking thoroughly the 3 component-KPIs.
Find out the corresponding failure causes for Immediate Assignment, Assignment and SDCCH Drops.
• If Immediate Assignment failures are due to channel activation failure or channel activation timeout (points
B, C in Figure 2) check hardware/software alarms.
(1) Failures due to mismatch between the state machine of the BSC and the ASS REQ message or due to
the abnormality of the ASS REQ message:
- A3129I: CELL_ASS_FAIL_INVALID_STATE: This counter provides the number of ASS FAIL messages sent
by the BSC to the MSC when the BSC receives an ASS REQ message that is not expected by the internal
state machine of the BSC (for example, the state machine is in release status).
- A3129E: CELL_ASS_FAIL_NO_CIC: This counter provides the number of ASS FAIL messages sent by the
BSC to the MSC when the BSC receives an ASS REQ message that carries an unavailable A interface CIC.
- A3129F: CELL_ASS_FAIL_CIC_ALLOC: This counter provides the number of ASS FAIL messages sent by
the BSC to the MSC when the BSC receives an ASS REQ message that carries an A interface CIC that is
already occupied by another call.
- A312A: CELL_ASS_FAIL_Frst_ASS_NO_CH: This counter provides the number of ASS FAIL messages
sent by the BSC to the MSC when the cell does not have available channels and the directed retry
procedure fails to be initiated or the directed retry is prohibited by the data configuration in the first air
interface assignment procedure.
- A312K: CELL_ASS_FAIL_Frst_DR_NO_CH: This counter provides the number of ASS FAIL messages
sent by the BSC to the MSC when the cell does not have available channels and the directed retry
procedure is successfully initiated but failed due to no available channel in the first air interface assignment
procedure.
- A3129S: CELL_ASS_FAIL_NO_SPEECH_VER: This counter provides the number of ASS FAIL messages
sent by the BSC to the MSC when the assignment fails because the intersection between the speech
version set carried in the ASS REQ message from the MSC and the speech version set supported by the
current cell of the MS does not have available speech versions.
- A3129C: CELL_ASS_FAIL_Frst_ASS_EXP: This counter provides the number of ASS FAIL messages sent
by the BSC to the MSC when the timer for the BSC to wait for an ASS CMP message expires after the BSC
sends an ASS CMD message to the MS in the first air interface assignment procedure.
- A3129G: CELL_ASS_FAIL_A_INTERF_FAIL: This counter provides the number of times that the BSC
locally releases the call when the BSC receives an SS7 link abnormality indication in the assignment
procedure.
- A3129H: CELL_ASS_FAIL_MSC_CLR_CMD: This counter provides the number of times that the BSC
releases the call after receiving a CLEAR CMD message from the MSC in the assignment procedure.
In case high SDCHH Drop Rate causes deterioration of CSSR, refer to Case 2 of present document for
handling.
- CIC No.
For internal use
The values of CICs must be Presentation
22 consistent
© Nokia Siemens Networks with
/ Author / Datethat on the MSC side.
3. CSSR (10)
7. Network functions that affect CSSR
- Directed retry
When TCHs in a cell are insufficient, TCHs in other cells can be assigned through directed retry, thus
increasing the BSS CSSR. By default, this function is enabled.
- TCH reassignment
When this function is enabled, the BSC initiates a re-assignment procedure after receiving the failure
indication of the TCH assignment on the Um interface. This function can be used to increase the
success
rate of TCH assignment, thus increasing the BSS CSSR. By default, this function is enabled.
- Flex Abis
This function is implemented in the BSC6000V900R003 and later versions. This function enables dynamic
assignment of Abis timeslots to more efficiently utilize the Abis link resources; however, assignment may
fail because of congestion on the Abis links. This function may decrease the BSS CSSR.
Analysis process:
1.High TCH blocking means congestion on the Traffic Channel: there are not enough free TCHs to accept
new service requests.
2.Check cell traffic channel availability in order to verify that congestion is not due to availability issue. Check
cell alarms.
3.Check availability of neighboring sites. If neighboring cells are unavailable this will cause big amount of
HOs directed to our current cell thus leading to congestion.
4.Check cell traffic channel configuration. Check if all HR resources are in use before TCH congestion
occurs. Verify that HR is enabled. In case AMR is supported by the operator, verify that is enabled.
5.Load balancing between cells: certain features can be activated to manage the traffic sharing between
cells:
- Enable LO handover algorithm: LoadHoEn: Load Handover Support
- Enable Directed Retry due to load: DIRECTRYEN: Directed Retry
7. Check if additional capacity related features can be activated in the network in order to improve the
utilisation of TCH resources:
- BCCH Dense Frequency Multiplexing: enables the BCCHs to reuse frequencies more tightly to free
more frequencies for non-BCCH TRXs, thus increasing the system capacity.
TIGHTBCCHSWITCH: TIGHT BCCH Switch (Whether to enable the BCCH aggressive frequency reuse
algorithm)
- Interference Based Channel Allocation (IBCA): The IBCA algorithm requires the BSC to estimate the
C/I ratio of the new call in every channel assignment procedure; it also requires the BSC to estimate the
interference caused to the established calls on the network when an idle channel is assigned to a new
call. In this way, the optimal channel, that is, the one that meets the C/I ratio requirement of the new call
and causes the least interference to the established calls after being occupied, is assigned to the new
call to alleviate the interference and ensure the full use of the frequency resources.
IBCAALLOWED: IBCA Allowed (Whether to enable the IBCA algorithm)
- Flex MAIO: BSC dynamically adjusts the MAIO according to the current interference level of a channel
when assigning an MAIO to the channel .
FLEXMAIO: Start Flex MAIO Switch (Whether to enable the function of Flex Mobile Allocation Index
Offset)
- Check coverage: maybe network layout should be changed in traffic hot spots
- We can use TA distribution in order to identify traffic distribution among cells. In some cases
overshooting can be detected, so we can check the possibility to reduce service area of the
overshooting cell. Before doing so, we need, of course, to make sure that there is clear dominance in
the area that we are going to shrink serving cell’s coverage.
- Implement physical network changes where necessary and feasible: tilt, azimuth, antenna type, etc.
- Add TRX
- Long term monitoring (e.g. one month) can be used to identify whether we have constant growth in
traffic in a site and area close by. If traffic increases in area level and we have already high HR/AMR HR
utilization then there are not too many other options than implement a new site.
- Add Site
Analysis process:
1.Identify the route cause of the call drops by checking the Call Drops on TCH counter:
•Call Drops on Radio Interface in Stable State (Traffic Channel): indicates RF issue. Check coverage at drop
points; check interference in the cell; check for missing neighbours.
•Call Drops on Radio Interface in Handover State (Traffic Channel): drops during handover procedure; check
the handover failure counters to get more details for the handover failure cause.
Check and tune appropriately, if needed, the values of the following parameters:
Analysis process:
1.Identify the possible cause of the handover failures by checking the following counters:
A. Internal HO (intra-BSC):
Basic intra-BSC inter-cell handover signalling procedure:
3) Abnormal causes
- The BSC fails to activate the allocated channel.
- A fault occurs on the A interface.
In the outgoing internal inter-cell handover procedure, the BSC sends an HO CMD message to the MS
through the originating cell and initiates a timer (T3103) to wait for a HO CMP message. If the MS
reconnects to the old channel and sends a HO FAIL message on the old channel before the timer expires,
the following counters are measured in the originating cell based on the failure cause value:
- H312Da:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_UNS:
Abnormal Release, Unspecified
- H312Db:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_CHN:
Abnormal Release, Channel Unacceptable
- H312Dc:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_EXP:
Abnormal Release, Timer Expired
- H312Dd:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_NO_ACT:
Abnormal Release, No Activity on the Radio Path
- H312De:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_PREEMPT: Preemptive
Release
- H312Df:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_HO_TA: Timing Advance
out of Range
- H312Dg:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_CH_MODE: Channel
Mode Unavailable
- H312Dh:CELL_INTRABSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_FREQ: Frequency
Unavailable
In directed retry procedure, the BSC sends an HO CMD message to the MS through the originating cell and
starts timer T3103 to wait for an HO CMP message. If no HO CMP is received by the BSC before T8
expires, the following counter is measured:
- H3121C:CELL_INTRABSC_OUTCELL_HO_FAIL_EXP_DR
After the BSC successfully performs channel allocation and speech version confirmation in the target cell, it
sends a CH ACT message to the BTS for activating the channel, and starts the corresponding timer to wait
for the response. If the BSC receives a CH ACT NACK or no response from the BTS before the timer
expires, the following counter is measured:
- H312I:CELL_INTRABSC_OUTCELL_HO_FAIL_CHACT_FAIL
If an outgoing internal intra-cell handover fails because the BSC locally releases the call after receiving an
SS7 link abnormality indication, the following counter is measured:
- H312G:CELL_INTRABSC_OUTCELL_HO_FAIL_A_INTERF_FAIL
In the outgoing external inter-cell handover (excluding directed retry) procedure, the following counters are
measured when T7 expires based on the channel type:
- H3320L:CELL_INTERBSC_OUTCELL_HO_FAIL_T7_EXP_SD_NOT_INCLUDE_DR
- H3327Lb:CELL_INTERBSC_OUTCELL_HO_FAIL_T7_EXP_TCHF_SIG
- H3328Lb:CELL_INTERBSC_OUTCELL_HO_FAIL_T7_EXP_TCHH_SIG
- H3327La:CELL_INTERBSC_OUTCELL_HO_FAIL_T7_EXP_TCHF_TRAF_CH
- H3328La:CELL_INTERBSC_OUTCELL_HO_FAIL_T7_EXP_TCHH_TRAF_CH
In the outgoing external inter-cell handover (directed retry) procedure, the following counter is measured:
- H3321L:CELL_INTERBSC_OUTCELL_HO_FAIL_T7_EXP_DR
- H332Ka:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_OM_INTERVENTION: OM Intervention
- H332Kb:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_EQUIP_FAIL: Equipment Failure
- H332Kc:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_NO_RADIO_RES: No Radio Resource Available
- H332Kd:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_REQ_NO_TER_RES: Requested Terrestrial
Resource Unavailable
- H332Ke:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_BSS_NOT_EQUIP: BSS not Equipped
- H332Kf:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_INVALID_CELL: Invalid Cell
- H332Kg:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_REQ_TRANS_NO_ADAPT: Requested
Transcoding/Rate Adaption Unavailable
- H332Kh:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_CIRCUIT_POOL_MISMATCH: Circuit Pool
Mismatch
- H332Ki:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_REQ_NO_SV: Requested Speech Version
Unavailable
- H332Kj:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_CIPH_ALG_NOT_SUPPORT: Ciphering Algorithm
not Supported
- H332Kk:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_TER_CIR_ALLOC: Terrestrial Circuit Already
Allocated
- H332Kl:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_INVALID_MSG: Invalid Message
- H332Km:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_PROTOCOL_ERR: Protocol Error between BSS
and MSC
- H332Kn:CELL_INTERBSC_OUTCELL_HO_REQ_REJ_OTHER: Other Causes
For internal use
39 © Nokia Siemens Networks Presentation / Author / Date
6. High HO fail (11)
(3) In the outgoing external inter-cell handover procedure, the BSC sends a HO CMD message to the MS
through the originating cell and initiates timer T8 to wait for a CLEAR CMD message from the MSC which
will indicate Successful Handover. If the MS reconnects to the old channel and sends an HO FAIL message
on the old channel before T8 expires, the specific one of the following counters is measured in the target cell
based on the cause value in the HO FAIL message.
- H332Da:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_UNS:
Abnormal Release, Unspecified
- H332Db:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_CHN:
Abnormal Release, Channel Unacceptable
- H332Dc:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_EXP:
Abnormal Release, Timer Expired
- H332Dd:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_ABNORM_REL_NO_ACT:
No Activity on the Radio Path
- H332De:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_PREEMPT: Preemptive
Release
- H332Df:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_HO_TA: Timing Advance
out of Range
- H332Dg:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_CH_MODE: Channel
Mode Unavailable
- H332Dh:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_FREQ: Frequency
Unavailable
- H332Di:CELL_INTERBSC_OUTCELL_HO_FAIL_RECONN_SUCC_MS_RPT_CALL_CLR: Call Already
Cleared
In the outgoing external inter-cell handover (excluding directed retry) procedure, the following counters are
measured when T8 expires based on the channel type:
- H3320C:CELL_INTERBSC_OUTCELL_HO_FAIL_T8_EXP_SD_NOT_INCLUDE_DR
- H3327Cb:CELL_INTERBSC_OUTCELL_HO_FAIL_T8_EXP_TCHF_SIG
- H3328Cb:CELL_INTERBSC_OUTCELL_HO_FAIL_T8_EXP_TCHH_SIG
- H3327Ca:CELL_INTERBSC_OUTCELL_HO_FAIL_T8_EXP_TCHF_TRAF_CH
- H3328Ca:CELL_INTERBSC_OUTCELL_HO_FAIL_T8_EXP_TCHH_TRAF_CH
In the outgoing external inter-cell handover (directed retry) procedure, the following counter is measured:
- H3321C:CELL_INTERBSC_OUTCELL_HO_FAIL_T8_EXP_DR
(6) The following counter provides the number of failed outgoing external inter-cell handovers when the BSC
detects an SS7 link failure on the A interface and releases the call:
- H332G:CELL_INTERBSC_OUTCELL_HO_FAIL_MSC_CLR_A_INTF_FAIL
3. Check whether ping-pong handover occurs due to no dominant server in the area. Ping-pong may lead
to HO failures.
- T3103A: Timer started after the BSC delivers a HANDOVER COMMAND in an intra-BSC inter-cell
handover. If the BSC receives a HANDOVER COMPLETE message before this timer expires, the timer
stops. If this timer expires, the BSC considers the handover as failed. Recommended value: 10000 ms
- T7: Timer is started after the BSC sends the HO RQD to the MSC and waits for the HO CMD command
from the MSC in an inter-BSC inter-cell handover procedure. Recommended value: 10000 ms
- T8: After sending the HO CMD message to the MS, the BSC starts this timer to wait for the CLEAR CMD
message from the MSC in an inter-BSC inter-cell handover procedure. Recommended value: 10000 ms
The following counters provide TA distribution per TRX in the cell. The measurements can be checked
versus cell radius to identify possible coverage problems.
- S4400A:TRX_MR_NUM_BY_TA_0 - S4420A:TRX_MR_NUM_BY_TA_20
- S4401A:TRX_MR_NUM_BY_TA_1 - S4421A:TRX_MR_NUM_BY_TA_21
- S4402A:TRX_MR_NUM_BY_TA_2 - S4422A:TRX_MR_NUM_BY_TA_22
- S4403A:TRX_MR_NUM_BY_TA_3 - S4423A:TRX_MR_NUM_BY_TA_23
- S4404A:TRX_MR_NUM_BY_TA_4 - S4424A:TRX_MR_NUM_BY_TA_24
- S4405A:TRX_MR_NUM_BY_TA_5 - S4425A:TRX_MR_NUM_BY_TA_25
- S4406A:TRX_MR_NUM_BY_TA_6 - S4426A:TRX_MR_NUM_BY_TA_26
- S4407A:TRX_MR_NUM_BY_TA_7 - S4427A:TRX_MR_NUM_BY_TA_27
- S4408A:TRX_MR_NUM_BY_TA_8 - S4428A:TRX_MR_NUM_BY_TA_28
- S4409A:TRX_MR_NUM_BY_TA_9 - S4429A:TRX_MR_NUM_BY_TA_29
- S4410A:TRX_MR_NUM_BY_TA_10 - S4430A:TRX_MR_NUM_BY_TA_30_TO_31
- S4411A:TRX_MR_NUM_BY_TA_11 - S4432A:TRX_MR_NUM_BY_TA_32_TO_33
- S4412A:TRX_MR_NUM_BY_TA_12 - S4434A:TRX_MR_NUM_BY_TA_34_TO_35
- S4413A:TRX_MR_NUM_BY_TA_13 - S4436A:TRX_MR_NUM_BY_TA_36_TO_37
- S4414A:TRX_MR_NUM_BY_TA_14 - S4438A:TRX_MR_NUM_BY_TA_38_TO_39
- S4415A:TRX_MR_NUM_BY_TA_15 - S4440A:TRX_MR_NUM_BY_TA_40_TO_44
- S4416A:TRX_MR_NUM_BY_TA_16 - S4445A:TRX_MR_NUM_BY_TA_45_TO_49
- S4417A:TRX_MR_NUM_BY_TA_17 - S4450A:TRX_MR_NUM_BY_TA_50_TO_54
- S4418A:TRX_MR_NUM_BY_TA_18 - S4455A:TRX_MR_NUM_BY_TA_55_TO_63
- S4419A:TRX_MR_NUM_BY_TA_19 - S4463A:TRX_MR_NUM_BY_TA_GT_63
For internal use
45 © Nokia Siemens Networks Presentation / Author / Date
7. Low Coverage (2)
2. Rxlevel & Rxquality measurements
BSC receives reports that contain the uplink and downlink receive level rank and the uplink and downlink
receive quality rank.
- The receive level ranges from rank 0 to rank 7. Each rank corresponds to a receive level range.
- The receive quality ranges from rank 0 to rank 7. Each rank corresponds to a bit error rate range.
Receive Level Rank Receive Level (dBm) Receive Quality Rank Bit Error Rate
0 ≤ -100 0 < 0.2%
1 (-100,-95] 1 0.2%-0.4%
2 (-95,-90] 2 0.4 %-0.8%
3 (-90,-85] 3 0.8%-1.6%
4 (-85,-80] 4 1.6%-3.2%
5 (-80,-75] 5 3.2%-6.4%
6 (-75,-70] 6 6.4%-12.8%
7 > -70 7 > 12.8%
Receive Level Measurement, together with Receive Quality Measurement per TRX, reflects the radio signal
coverage and interference of a cell. For example, a high ratio of high level and low quality suggests possible
interference; a high ratio of low level and low quality suggests poor coverage.
- S4100A:TRX_FR_UP_LEV_0_RX_QLTY_0 - S4100B:TRX_FR_DOWN_LEV_0_RX_QLTY_0
- S4101A:TRX_FR_UP_LEV_0_RX_QLTY_1 - S4101B:TRX_FR_DOWN_LEV_0_RX_QLTY_1
- S4102A:TRX_FR_UP_LEV_0_RX_QLTY_2 - S4102B:TRX_FR_DOWN_LEV_0_RX_QLTY_2
…………………………………………………... ………………………………………………………..
Saaaaa:TRX_FR_UP_LEV_x_RX_QLTY_y Saaaaa:TRX_FR_UP_LEV_x_RX_QLTY_y
where: aaaaa=counter ID, x=receive level rank (0~7), y=receive quality rank (0~7)
• TCHH Receive Level Measurement per TRX refers to the measurement of the sampled receive level
ranks and receive quality ranks in the MRs on the TCHH. TCHH receive level and quality measurements for
UL and DL are given by following counters:
- S4100C:TRX_HR_UP_LEV_0_RX_QLTY_0 - S4100D:TRX_HR_DOWN_LEV_0_RX_QLTY_0
- S4101C:TRX_HR_UP_LEV_0_RX_QLTY_1 - S4101D:TRX_HR_DOWN_LEV_0_RX_QLTY_1
- S4102C:TRX_HR_UP_LEV_0_RX_QLTY_2 - S4102D:TRX_HR_DOWN_LEV_0_RX_QLTY_2
…………………………………………………… …………………………………………………………
Saaaaa:TRX_HR_UP_LEV_x_RX_QLTY_y Saaaaa:TRX_FR_UP_LEV_x_RX_QLTY_y
where: aaaaa=counter ID, x=receive level rank (0~7), y=receive quality rank (0~7)
The interference band is the uplink interference level of a channel reported by the BTS to the BSC in the RF
RESOURCE INDICATION message when the channel is idle. There are five levels of interference
bands. The threshold of each interference band can be configured:
- AS4200A:TRX_CH_IN_INTFR1_AVR_NUM_SD
- AS4200B:TRX_CH_IN_INTFR2_AVR_NUM_SD
- AS4200C:TRX_CH_IN_INTFR3_AVR_NUM_SD
- AS4200D:TRX_CH_IN_INTFR4_AVR_NUM_SD
- AS4200E:TRX_CH_IN_INTFR5_AVR_NUM_SD
- AS4207A:TRX_CH_IN_INTFR1_AVR_NUM_FR
- AS4207B:TRX_CH_IN_INTFR2_AVR_NUM_FR
- AS4207C:TRX_CH_IN_INTFR3_AVR_NUM_FR
- AS4207D:TRX_CH_IN_INTFR4_AVR_NUM_FR
- AS4207E:TRX_CH_IN_INTFR5_AVR_NUM_FR
- AS4208A:TRX_CH_IN_INTFR1_AVR_NUM_HR
- AS4208B:TRX_CH_IN_INTFR2_AVR_NUM_HR
- AS4208C:TRX_CH_IN_INTFR3_AVR_NUM_HR
- AS4208D:TRX_CH_IN_INTFR4_AVR_NUM_HR
- AS4208E:TRX_CH_IN_INTFR5_AVR_NUM_HR
2. Rxlevel & Quality distributions can be used to identify interference in a cell. Refer to Case 7 of present
document for details.
3. TA measurements can be used to identify interference in a cell. Refer to Case 7 of present document for
details.
For internal use
49 © Nokia Siemens Networks Presentation / Author / Date
9. High Signalling Failures Before TBF Establishment (1)
- KPI formula:
Success Rate of Random Access (Packet Service) =
[A301H:CELL_IMM_ASS_CMD_PS]/[A300H:CELL_CH_REQ_PACKET_CALL]
Paging Overload Rate PS = ([PACKET CCCH LOAD IND Messages Sent on Abis Interface])/([Delivered
Paging Messages for PS Service])*{100}
Analysis process:
1.High signalling failures before TBF establishment refers to failures on the CCCH. During one-phase
access or two-phase access on the CCCH, the MS fails to proceed to TBF establishment process due to
failures on the CCCH channel: AGCH or PCH. The failures most likely will be due to CCCH congestion.
3.Check relative alarms on the BSC/BTS in order to locate any hardware/software fault.
4.If blocking is the problem, proceed to the following steps in order to relieve congestion on the CCCH.
6. Check if Flow Control feature is enabled. Recommendation is that Flow Control is always enabled. Flow
Control, controls the arrival of paging messages on the A interface (MSC-BSC) and on the LAPD links
(BSC-BTS).
9. Consider splitting cells in the paging overload area. This will grow CCCH capacity.
Fig.1 One-phase packet access on the uplink CCCH Fig.2 Two-phase packet access on the uplink CCCH
Analysis process:
1.Identify the possible cause of the TBF establishment failures by checking the following counters:
1. If TBF establishment failure is due to congestion in TCH, refer to Case 4 of present document for handling
suggestions. In brief:
- Check availability of current and neighbouring sites in order to make sure that TCH congestion is not due to
unavailability issues.
- Check FR/HR parameterization (including AMR if enabled in the network). Check usage of HR resources.
- Check Load balancing configuration between cells.
- Add TRX.
3. If TBF establishment failure is due to equipment fault, check relative BSS alarms (hardware and software
alarms) in order to identify the faulty part. Repair or replace the faulty equipment once found.
Uplink EGPRS TBF Drop Rate = (([Number of Uplink EGPRS TBF Abnormal Releases due to N3101
Overflow (MS No Response)]+[Number of Uplink EGPRS TBF Abnormal Releases due to N3103 Overflow
(MS No Response)])/[Number of Successful Uplink EGPRS TBF Establishment])*{100}
Downlink GPRS TBF Drop Rate = ([Number of Downlink GPRS intermit transfers]/[Number of Successful
Downlink GPRS TBF Establishments])*{100}
Downlink EGPRS TBF Drop Rate = ([Number of Downlink EGPRS intermit transfers]/[Number of Successful
Downlink EGPRS TBF Establishments])*{100}
Analysis process:
1.Identify the possible cause of the TBF drops by checking the following counters:
Average Throughput of Uplink GPRS TBF (kbit/s) = [Average Payload of Single Uplink GPRS TBF
(KB)]*{1024}*{8}/[Average Duration of Uplink GPRS TBF (s)]
Average Throughput of Uplink EGPRS TBF (kbit/s) = [Average Payload of Single Uplink EGPRS TBF
(KB)]*{1024}*{8}/[Average Duration of Uplink EGPRS TBF (s)]
Average Throughput of Downlink GPRS TBF (kbit/s) = [Average Payload of Single Downlink GPRS TBF
(KB)]*{1024}*{8}/[Average Duration of Downlink GPRS TBF (s)]
Average Throughput of Downlink EGPRS TBF (kbit/s) = [Average Payload of Single Downlink EGPRS TBF
(KB)]*{1024}*{8}/[Average Duration of Downlink EGPRS TBF (s)]
Analysis process:
1.Low throughput may be due to problems across the packet service transmission path. Thorough checks
should be done in Gb, Abis, Um interfaces. Also in SGSN, PCU, BSC systems.
2.Gb interface:
- Check usage of Gb links. Expand Gb capacity if congestion appears.
Gb usage can be checked through Real Time Monitoring function of BSC LMT: On the Trace & Monitor tab
page, choose Monitor > Monitor GPRS Flux.
Also Gb utilization can be checked through following counters:
- RL9608:BC_TRAN_UP_UTILIZATION_RATE: Uplink Utilization Rate on BC (%)
- RL9610:BC_TRAN_DOWN_UTILIZATION_RATE: Downlink Utilization Rate on BC (%)
Both counters above provide the ratio of actually used bandwidth over configured bandwidth on a BC of Gb.
For internal use
66 © Nokia Siemens Networks Presentation / Author / Date
12. Low Throughput (4)
- Check alarms on GDPUP board (BSC6000) or DPUd board (BSC6900) which are the boards that provide
PCU functionality in BSC (internal PCU).
3.Abis interface:
- Check for congestion on Abis interface. Congestion will lower the throughput.
- Higher CS and MCS coding schemes will occupy higher number of Abis timeslots. Check relative
parameters for CS transition:
- UPTHDCSUPGRADE1: Uplink TBF Threshold from CS1 to CS2
- UPTHDCSUPGRADE2: Uplink TBF Threshold from CS2 to CS3
- UPTHDCSUPGRADE3: Uplink TBF Threshold from CS3 to CS4
- UPTHDCSDEGRADE1: Uplink TBF Threshold from CS2 to CS1
- UPTHDCSDEGRADE2: Uplink TBF Threshold from CS3 to CS2
- UPTHDCSDEGRADE3: Uplink TBF Threshold from CS4 to CS3
Note: For more details on how to cope with Abis interface congestion refer to
“HUA_2G_Capacity_Optimization_v1.0.pptx” document from Multivendor Team in IMS.
https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D420911578