Professional Documents
Culture Documents
2G Huawei Performance Monitoring & Analysis
2G Huawei Performance Monitoring & Analysis
Contents
1. Overview
2. 2G Performance Monitoring and Analysis
Document Information
Document Version: 1.0
Issue Date: September 8, 2010
Document Owner: Ville Salomaa
SOFTWARE RELEASE: GBSS9.0
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
Contents
1. Overview
2. 2G Performance Monitoring and Analysis
Overview
The purpose of this document is to describe the BSS KPI performance monitoring and analysis of problems
that bad KPI values indicate.
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.
General Methodology
General Methodology:
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.
Contents
1. Overview
2. 2G Performance Monitoring and Analysis
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.)
5.
6.
Add TRX
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
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.
3. CSSR (1)
- KPI formula:
BSS Call Setup Success Rate = (([Immediate Assignment Success Rate]*[TCH Assignment Success
Rate])*(1-[SDCCH Drop Rate]))*{100}
The CSSR combines 3 other KPIs:
- Immediate Assignment Success Rate = ([Call Setup Indications (Circuit Service)]/[Channel Requests
(Circuit Service)])*{100}
- TCH Assignment Success Rate = ([Successful Assignments]/[Assignment Requests])*{100}
- SDCCH Drop Rate = ([Call Drops on SDCCH]/[Successful SDCCH Seizures])*{100}
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.
3. CSSR (2)
3.
3. CSSR (3)
If Immediate Assignment failures are due to no channel available (point A in Figure 2), this means that
there is SDCCH congestion. Refer to Case 1 of present document for handling.
If Immediate Assignment failures are due to channel activation failure or channel activation timeout
(points B, C in Figure 2) check hardware/software alarms.
4.
3. CSSR (4)
(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).
- A3129J: CELL_ASS_FAIL_INVALID_MSG_CONTENTS: This counter provides the number of ASS FAIL
messages sent by the BSC to the MSC when the BSC receives an ASS REQ message but the ASS REQ
message fails to be decoded (for example, an error occurs during the decoding of an IE, such as CHANNEL
TYPE, CIC, or Layer 3 header information).
- 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.
3. CSSR (5)
(2) Failures due to abnormal radio resource allocation:
- 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.
- A312L: CELL_ASS_FAIL_RECONN_SUCC_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 air
interface assignment procedure except for 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.
- A312M: CELL_ASS_FAIL_RECONN_SUCC_DR_NO_CH: This counter provides the number of ASS FAIL
messages sent by the BSC to the MSC when the BSC attempts to make a directed retry but the directed
retry failed because the target cell does not have available channels in the air interface assignment
procedure except for the first air interface assignment procedure.
3. CSSR (6)
- A312F: CELL_ASS_FAIL_NO_IDLE_ABIS: This counter provides the number of ASS FAIL messages sent
by the BSC to the MSC when the dynamic allocation of Abis resources is enabled on the BSC but the
assignment fails due to no available Abis resources.
- 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.
(3) Failures due to abnormal air interface access:
- 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.
- A3129P: CELL_ASS_FAIL_RECONN_SUCC_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 air interface assignment procedure
except for the first air interface assignment procedure.
3. CSSR (7)
- A3129O: CELL_ASS_FAIL_Frst_DR_EXP: 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 the expiry of the timer for waiting for an HO CMP message in the first
air interface assignment procedure.
- A3129Q: CELL_ASS_FAIL_RECONN_SUCC_DR_EXP: This counter provides the number of ASS FAIL
messages sent by the BSC to the MSC when the timer for waiting for an ASS CMP message expires after
the BSC sends an HO CMD message to the MS in the air interface assignment procedure except for the
first air interface assignment procedure.
- A3129D: CELL_ASS_FAIL_RECONN_SUCC_ASS_RECONN_SUCC: This counter provides the number
of ASS FAIL or RR STATUS messages reported by the MS to the BSC when the MS attempts but fails to
access the new channel and then successfully reconnects to the old channel after receiving an ASS CMD
message.
- A3129R: CELL_ASS_FAIL_RECONN_SUCC_DR_RECONN_SUCC: This counter provides the number of
HO FAIL or RR STATUS messages reported by the MS to the BSC when the MS attempts but fails to
access the new channel and then successfully reconnects to the old channel after receiving an HO CMD
message.
3. CSSR (8)
(4) Failures due to the abnormality of terrestrial resources or the call clearing performed by the MSC.
- A3129B: CELL_ASS_FAIL_Frst_APPLY_TRSL_FAIL: This counter provides the number of ASS FAIL
messages sent by the BSC to the MSC when the MS drops from the connection to the air interface, or a
circuit fails to be obtained for the call, or the obtained circuit is faulty during the circuit connection of the
BSC in the first air interface assignment procedure.
- A3129N: CELL_ASS_FAIL_RECONN_SUCC_APPLY_TRSL_FAIL: This counter provides the number of
ASS FAIL messages sent by the BSC to the MSC when the MS drops from the connection to the air
interface, or a circuit fails to be obtained for the call, or the obtained circuit is faulty during the circuit
connection of the BSC in the air interface assignment procedure except for 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.
3. CSSR (9)
5.
In case high SDCHH Drop Rate causes deterioration of CSSR, refer to Case 2 of present document for
handling.
6.
3. CSSR (10)
7.
- 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.
- SDCCH dynamic adjustment
When SDCCHs are insufficient, this function can be enabled to convert some TCHs into SDCCHs to
increase the success rate of immediate assignment, 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.
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)
If congestion is still present although the previous described fine tuning and features activation, then:
- Check Interference in the network (C/I); check frequency plan
- 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 cells 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
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.
Call Drops due to No MRs from MS for a Long Time (Traffic Channel): After seizing a TCH, the MS
sends a measurement report to the BSC every 480 ms. If the BSC does not receive any measurement
report within a certain period, call drop occurs on the Um interface. Check UL coverage/UL interference
at drop points. Check for possible MS problem.
Call Drops due to Abis Terrestrial Link Failure (Traffic Channel): indicates Abis transmission problem.
Check relative alarms.
Call Drops due to Equipment Failure (Traffic Channel): indicates BSS hardware or software problem.
Check relative alarms.
Call Drops due to Forced Handover (Traffic Channel): After the MS seizes a traffic channel, the BSC
initiates forced handover in the case of channel preemption, channel failure, or channel blocking. If the
handover of the MS fails, the BSC releases the call.
Call Drops Due to Loopback Start Failure: After seizing a channel, the MS starts the local switching.
This measurement provides the number of call drops due to the failure in starting the local switching
caused by different reasons. The cause value can be Terrestrial Resource Request Failure, Failures on
the BTS Side, or Timer Expired.
Call Drops Due to Failures to Return to Normal Call from Loopback: After a call is in the BSC/BTS local
switch state, it incurs a handover. The local switch, however, cannot be continued because the target
cell of the handover may not support local switch, the outgoing BSC handover fails, the TRX that
carries the target channel of the handover may not support local switch, or the specified handover fails.
The BSC attempts to restore the call to a normal one. The restoration may fail due to various reasons.
If the restoration fails, the MS incurs call drop.
Check and tune appropriately, if needed, the values of the following parameters:
- RLT: Radio Link Timeout; recommended value: 52
- SAMULFRM: SACCH Multi-Frames; recommended value: 32
Check interference in source and target cells. High interference can cause handover failure.
3.
Check whether ping-pong handover occurs due to no dominant server in the area. Ping-pong may lead
to HO failures.
4.
- 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
- S4401A:TRX_MR_NUM_BY_TA_1
- S4402A:TRX_MR_NUM_BY_TA_2
- S4403A:TRX_MR_NUM_BY_TA_3
- S4404A:TRX_MR_NUM_BY_TA_4
- S4405A:TRX_MR_NUM_BY_TA_5
- S4406A:TRX_MR_NUM_BY_TA_6
- S4407A:TRX_MR_NUM_BY_TA_7
- S4408A:TRX_MR_NUM_BY_TA_8
- S4409A:TRX_MR_NUM_BY_TA_9
- S4410A:TRX_MR_NUM_BY_TA_10
- S4411A:TRX_MR_NUM_BY_TA_11
- S4412A:TRX_MR_NUM_BY_TA_12
- S4413A:TRX_MR_NUM_BY_TA_13
- S4414A:TRX_MR_NUM_BY_TA_14
- S4415A:TRX_MR_NUM_BY_TA_15
- S4416A:TRX_MR_NUM_BY_TA_16
- S4417A:TRX_MR_NUM_BY_TA_17
- S4418A:TRX_MR_NUM_BY_TA_18
- S4419A:TRX_MR_NUM_BY_TA_19
For internal use
45
Nokia Siemens Networks
- S4420A:TRX_MR_NUM_BY_TA_20
- S4421A:TRX_MR_NUM_BY_TA_21
- S4422A:TRX_MR_NUM_BY_TA_22
- S4423A:TRX_MR_NUM_BY_TA_23
- S4424A:TRX_MR_NUM_BY_TA_24
- S4425A:TRX_MR_NUM_BY_TA_25
- S4426A:TRX_MR_NUM_BY_TA_26
- S4427A:TRX_MR_NUM_BY_TA_27
- S4428A:TRX_MR_NUM_BY_TA_28
- S4429A:TRX_MR_NUM_BY_TA_29
- S4430A:TRX_MR_NUM_BY_TA_30_TO_31
- S4432A:TRX_MR_NUM_BY_TA_32_TO_33
- S4434A:TRX_MR_NUM_BY_TA_34_TO_35
- S4436A:TRX_MR_NUM_BY_TA_36_TO_37
- S4438A:TRX_MR_NUM_BY_TA_38_TO_39
- S4440A:TRX_MR_NUM_BY_TA_40_TO_44
- S4445A:TRX_MR_NUM_BY_TA_45_TO_49
- S4450A:TRX_MR_NUM_BY_TA_50_TO_54
- S4455A:TRX_MR_NUM_BY_TA_55_TO_63
- S4463A:TRX_MR_NUM_BY_TA_GT_63
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)
-100
< 0.2%
(-100,-95]
0.2%-0.4%
(-95,-90]
0.4 %-0.8%
(-90,-85]
0.8%-1.6%
(-85,-80]
1.6%-3.2%
(-80,-75]
3.2%-6.4%
(-75,-70]
6.4%-12.8%
> -70
> 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.
For internal use
46
Nokia Siemens Networks
TCHF Receive Level Measurement per TRX provides the number of measurement reports from the
TCHF that contain receive level rank and receive quality rank. TCHF receive level and quality
measurements
for UL and DL are given by following counters:
- S4100B:TRX_FR_DOWN_LEV_0_RX_QLTY_0
- S4100A:TRX_FR_UP_LEV_0_RX_QLTY_0
- S4101B:TRX_FR_DOWN_LEV_0_RX_QLTY_1
- S4101A:TRX_FR_UP_LEV_0_RX_QLTY_1
- S4102B:TRX_FR_DOWN_LEV_0_RX_QLTY_2
- S4102A:TRX_FR_UP_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:
- S4100D:TRX_HR_DOWN_LEV_0_RX_QLTY_0
- S4100C:TRX_HR_UP_LEV_0_RX_QLTY_0
- S4101D:TRX_HR_DOWN_LEV_0_RX_QLTY_1
- S4101C:TRX_HR_UP_LEV_0_RX_QLTY_1
- S4102D:TRX_HR_DOWN_LEV_0_RX_QLTY_2
- S4102C:TRX_HR_UP_LEV_0_RX_QLTY_2
Saaaaa:TRX_FR_UP_LEV_x_RX_QLTY_y
Saaaaa:TRX_HR_UP_LEV_x_RX_QLTY_y
where: aaaaa=counter ID, x=receive level rank (0~7), y=receive quality rank (0~7)
For internal use
47
Nokia Siemens Networks
Idle UL Interference
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:
Parameter ID
INTERFTHRES1 1
-105
INTERFTHRES2 2
-98
INTERFTHRES3 3
-92
INTERFTHRES4 4
-87
INTERFTHRES5 5
-85
TA measurements can be used to identify interference in a cell. Refer to Case 7 of present document
for
details.
For internal use
49
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).
7.
8.
9.
Consider splitting cells in the paging overload area. This will grow CCCH capacity.
MS
BTS
BSC
Channel Request
Immediate Assignment
RLC data block(with TLLI)
Packet Uplink Ack/Nack(with TLLI)
MS
BTS
Channel Request
Immediate Assignment
Packet Resource Request(with TLLI)
Packet Uplink Assignment(with TLLI)
BSC
References
https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D420911578
THANK YOU