Professional Documents
Culture Documents
OMF000405 Case Analysis-Congestion ISSUE1.4
OMF000405 Case Analysis-Congestion ISSUE1.4
Congestion ISSUE1.4
TCH congestion
SDCCH congestion
TCH congestion
! TCH congestion
" Basic principle
" Causes for high TCH congestion
" Case study of TCH congestion
TCH congestion
! Case 1 analysis:
" Since the frequency had not been changed, Um interface
problem is excluded.
" Congestion rate is abnormal for most BTS. In this case, we can
search in a smaller range to see whether the congestion
problem is related to a certain module or data modification.
" Analyze the main cause of TCH seizure failure through traffic
statistic and finally locate the problem caused by data or
hardware.
Case Study of TCH Congestion
! Case 1 Troubleshooting:
" 1.Analyze traffic statistics. The problem occurs after BSC data
modified and reloaded. Maybe it is related to BSC reloading.
# Analyze traffic statistics and find that the highly congested cells are
all on module 1 of BSC, so the problem should related to module 1.
# Check TCH seizure failures (requested terrestrial resource
unavailable), It shows that unavailability of terrestrial resource is the
main cause of high congestion rate in module 1.
# The cause of terrestrial resources unavailability is mainly on Abis
interface or A interface. It is quite unlikely that Abis interface is
faulty for many cells in module 1 at the same time. Therefore, the
cause should be the hardware or data at A interface.
Case Study of TCH Congestion
! Case 1 Troubleshooting:
" 2.Check the hardware of A interface and find that the hardware
is normal. A interface hardware problem is excluded.
" 3. Check the data configuration of A interface trunk circuit and
find that the CIC code of the first 32 timeslots of group 0, module
1 is “65535”. But group 0 of module 1 in the trunk group table
corresponds to the circuit from BSC to MSC. Obviously this CIC
number is wrong. Change it to “0~31”, and then the congestion
rate becomes normal.
Case Study of TCH Congestion
! Case 1 conclusion:
" 1. In trunk circuit data configuration at A interface, CIC must be
correct, otherwise, TCH assignment will fail and the congestion
rate will be high.
" 2. In the meantime, if the CIC of two FTC boards (multiple trunk
circuits) are the same, this problem will also happen.
TRX Board Fault
! Case 2 analysis:
" 1. No data has been adjusted and there is no hopping in the cell
and 6 TRXs use different frequencies, it is unlikely that they are
subject to external interference at the same time. Therefore, it
can not be Um interface interference or data problem.
" 2. Check hardware specifically. Since the problem only occurs
to cell 1, we can block TRX one by one to determine which TRX
causes the assignment failure.
" 3.Find whether there is hardware fault in the TRX for
assignment failure. Confirm the fault TRX by means of resetting
and replacing.
TRX Board Fault
! Case 2 troubleshooting:
" 1. Check BT channel status on OMC and find that there is
possibility of TCH seizure failure in BT4 of cell 1.
" 2. Block TRX4, there is no TCH congestion all the day. It
indicate problem is on TRX4.
" 3. Unblock TRX4 and reset them, congestion appear again.
" 4. Go to BTS site and make a dial test on TRX4, TCH seizure
failure still occurs. Interchange the slots of TRX4 and TRX5,
make the dial test again on TRX5. The TCH seizure failure
persists.
" 5. Replace TRX4 and make dial test, there is no TCH
congestion.
TRX Board Fault
! Case 2 conclusion:
" 1.Faulty TCH TRX board causes TCH seizure failures and high
congestion rate.
" 2. Usually, the fault of TRX board can not be found on the BTS
maintenance console. The problem can be confirmed by
blocking TRXs in turn.
Uplink Hardware Problem
! Case 3 analysis:
" There is no interference but congestion always exists after the
BTS on service in every cell. Check hardware of the BTS first.
# Hardware fault: communication is normal for every cell, so it is
unlikely that there is fault in the hardware of every cell.
# Hardware connection: Analyze the traffic statistics for uplink or
downlink and then check the hardware connection of uplink or
downlink.
Uplink Hardware Problem
! Case 3 troubleshooting:
" Register traffic statistics “Receiving Level Measurement
Function” and query the result by time. It is found that when the
receiving level and quality of different TRX boards in the same
cell are the same, the number of downlink measurement reports
is equivalent, but the number of uplink measurement reports is
not equivalent.
" Check hardware and find that the connection of TRX and CDU
in the same cell is incorrect. After correction, the problem is
solved.
Uplink Hardware Problem
Case 3
Times of uplink Times of uplink Times of Uplink
receiving level receiving level receiving level rank
rank 0 and rank 0 and 0 and receiving
receiving receiving quality quality rank 2
quality rank 0 rank 1
30 minutes starting from
11:00 18-3-2001
Module ID 1, Cell ID 5, 2 0 7
TRX No. 12
Module ID 1, Cell ID 5, 3 0 3
TRX No. 13
Module ID 1, Cell ID 5, 1 0 5
TRX No. 14
Module ID 1, Cell ID 5, 655 105 293
TRX No. 15
Module ID 1, Cell ID 5, 294 46 166
TRX No. 16
Module ID 1, Cell ID 5, 222 58 142
TRX No. 17
Uplink Hardware Problem
! Case 3 conclusion:
" Incorrect hardware connection will cause TCH seizure failure.
The problem can be located accurately by analyzing traffic
statistics. In this case, uplink hardware receiver problem is
located through “Receiving Level Measurement Function”.
Downlink Hardware Problem
! Case 4 analysis:
" There is no parameter adjustment before the fault, so we should
focus on the hardware, to see whether there is any fault or alarm.
Downlink Hardware Problem
! Case 4 troubleshooting:
" Trace Abis interface message of the BTS and analyze the
signaling and find that in process of TCH seizure failure, the
uplink signal in the measurement report from MS is good, after
BSC sends ASSIGNMENT CMD, the downlink channel can not
be seized. So the signal levels of uplink and downlink are not
balanced, then ASSI FAILURE message is appeared. It is also
found that the failure related to the last TRX board of the cell.
" Block TRX board and congestion rate of the cell is less than 1%.
There is problem in TRX board of downlink hardware.
" Check and find that the VSWR of TX antenna and feeder
connected with this TRX board is higher than 2.5. Process the
antenna& feeder VSWR alarm, problem solved.
Downlink Hardware Problem
! Case 4 conclusion:
" Antenna VSWR alarm results in larger loss, less coverage and
assignment failure. When MS is in BCCH TRX coverage, signal
level is good enough, but after assignment a TCH in the board
where VSWR alarm occurs, MS TCH seizure fails and the
congestion rate is increased.
Effect from Repeater in the Cell
! Case 5 analysis:
" Since congestion rate is abnormal after expansion
# Check whether the congestion occurs to all TRX. If yes, re-check
the connection of newly added hardware of the BTS to see whether
there is any fault.
# If congestion occurs to one or a few TRXs, check the hardware of
these TRXs.
# When hardware problem is excluded, consider external causes. For
example, the repeater is not expanded, which results in assignment
failure.
Effect from Repeater in the Cell
! Case 5 troubleshooting:
" Block TRX of the last two newly added TRX on OMC and find that the
congestion rate is lowered to normal status. Perhaps, the problem is
related to newly added boards.
" Analyze Abis interface signaling, the assignment failure occurs on
the two newly added TRXs. And SDCCH measurement report
analysis shows that the level on SDCCH is normal and TA value is
large. However, there is no measurement report on SACCH (TCH).
Because sometimes the assignment of the two TRXs succeed, so it is
impossible that these tow newly added TRXs are both faulty.
" Operator told that there is a repeater in the cell. When expansion,
the repeater did not lock on the two newly added TRXs. Confirm and
reconfigure repeater, problem solved.
Effect from Repeater in the Cell
! Case 5 conclusion:
" Because of the repeater, the actual coverage areas of the
existing two TRX and the expanded two TRX are different,
which results in the assignment failure.
Other Data Configuration Mistake
! Case 6 analysis:
" When the network parameters are modified, the congestion rate
of the two cells is higher and only the congestion rate (including
handover) is higher, therefore, radio interference or hardware
fault can be excluded. Mainly analyze whether the handover is
abnormal or not.
Other Data Configuration Mistake
! Case 6 troubleshooting:
" Register “Incoming Inter Cell Handover Measurement Function”
for 15 minutes, and find that all the handovers from cell A
(CGI=*********1768) to these two cells all fail, and the handover
failure cause is not congestion.
" Failures of all handovers mean that there is problem with the
handover data. Check the handover data of the two cells and
find that there is co-frequency and co-BSIC as supposed, the
two cells are adjacent cell of cell A, therefore the handover from
the cell A to the two cells will fail.
" Change the BCCH and BSIC of one cell, and then the handover
problem disappears and congestion rate become normal.
Other Data Configuration Mistake
! Case 6 conclusion:
" Two cells (both adjacent to cell A) with co-frequency and co-
BSIC will result in result in low incoming cell handover
successful rate, but also high TCH congestion rate (including
handover).
" The case indicates that TCH congestion rate (including
handover) and TCH congestion rate (excluding handover) are
different.
Isolated Site and Complicated Topography
! Case 7 analysis:
" 1. Since the congestion rate is not very high, the problem may
not be on the data or hardware.
" 2. The interference band is normal, so the interference at the
Um interface is unlikely.
" 3. Analyze the cause of assignment failure. Take call trop rate
into consideration and analyze the receiving performance of
uplink or downlink, including level and quality.
Isolated Site and Complicated Topography
! Case 7 troubleshooting:
" Check “Call Drop Measurement” and find that TA value is large
when call drop, the distance is about 25.6Km~31.1Km away
from the BTS.
" View “Receiving Level Measurement Function” and find that
there are many measurement reports of low signal level.
" Analyze Abis signaling and find that the uplink level is very low
(about -98dBm) when the assignment fails.
" Drive test on-site and find the site is isolated, with large
coverage and complicated topography. When the MS is more
than 25 Km away from the BTS, it can receive -90dBm downlink
signal. But the uplink signal is not enough, so TCH assignment
fails.
Isolated Site and Complicated Topography
! Case 7 conclusion:
" Poor uplink coverage causes the high congestion rate. Adding
BTS can help to obtain a continuous coverage. Change the
omni site into directional site or add TMA can improve uplink
strength and avoid over shooting of downlink.
Course Contents
TCH congestion
SDCCH congestion
SDCCH Congestion
! SDCCH congestion
" Basic principle
" Causes for SDCCH congestion and solutions
" Case study of SDCCH congestion
SDCCH Congestion
! Case 1 analysis:
" Since only a few BTS are congested, register “SDCCH
Measurement Function” and analyze the ratio of SDCCH seizure
for different causes, then we can find the real reason for SDCCH
congestion.
Too Many Times of Location Update
! Case 1 troubleshooting :
" 1. Register “SDCCH Measurement Function”
# In congested cell, SDCCH is attempted about 300-400 times in a
certain hour. The configuration are all S1/1/1. Each cell is
configured with SDCCH/8 channels. Normally, they are enough to
support 300-400 times seizure, but there are dozens of SDCCH
congestion for each cell in busy hour.
# It is found that most of SDCCH seizures are for location update.
Analyze the cell locations and find that the congested BTS are at
the border of two location area crossed by railway, most of location
update are in a specific 5 minutes. Query the train timetable and
find that 4 or 5 trains pass there within this period. When the trains
pass by, a large amount of location update requests from MS.
! Case 1 conclusion:
" For SDCCH congestion due to location update, check whether it
is caused by improper setting of location area. Add SDCCH
channel or enable dynamic allocation function to solve the
problem.
Transmission Equipment Board Fault
! Case 2 analysis:
" Since SDCCH is congested after BTS is on service, but
communication is normal.
# First check data and hardware. Because the whole site suffers from
congestion problem, interchange Abis link with another BTS (which
has the same site configuration) to confirm whether there is any
data or hardware problem in Abis interface.
# If there is no problem with data or hardware, we should analyze the
Abis interface transmission system.
Transmission Equipment Board Fault
! Case 2 troubleshooting:
" Check alarm and find there are LAPD link fault alarm and recovery
alarm (within one second). The alarms appear once per ten minutes.
" Check the data and then interchange Abis link with another BTS
which is in the same configuration, the other site work normally. But
problem of this site persists. So data and BSC hardware have no
problem.
" Replace TMU and TRX board in the BTS and the problem persists.
" Measure the transmission and self-loop BIE, then It is found that
there is high BER for transmission. Test the line section by section
and find that one 2M transmission board is faulty. Replace the board
and the problem is solved.
Transmission Equipment Board Fault
! Case 2 conclusion:
" In this case, due to transmission high BER there is too much
SDCCH assignment message but missed, then SDCCH
assignment message re-sent, these cause high congestion rate.
Transmission Timeslot Multiplexer Problem
! Case 3 analysis:
" The locate information is helpful to judge that the problem is on
the hardware or the transmission. But it is unlikely that faults
occur to hardware of the 4 BTSs. The transmission lines of the 4
BTSs are related, therefore, check the transmission carefully.
Case Study of SDCCH Congestion
! Case 3 troubleshooting:
" 1. Observe BIE, there is BER indication for transmission. But there are no
abnormal indication in microwave and optical transceiver.
" 2. Check Abis interface signaling and find there are a large number of
PAGING_CMD messages, but only one RF_RESOURCE_INDICATION
message appears occasionally. There is no CHAN_ACTIV,
CHAN_ACTIV_ACK or IMMEDIATE_ASSIGN_COMMAND message. It
indicates that SDCCH channel is not activated.
" 3. Check data O&M log, no data modified within a few days.
" 4. Reload and activate BTS software, and find that system response is
slow even communication timeout. SDCCH is still congested after
software reloaded.
Case Study of SDCCH Congestion
! Case 3 troubleshooting:
" 5. Reset the primary combiner and initialize the 4 BTSs, SDCCH
are all seized and TCH can be seized successfully. Trace Abis
interface signaling, CHAN_ACTIV, CHAN_ACTIV_ACK or
IMMEDIATE_ASSIGN_COMMAND message appears. SDCCH
is no longer congested because MS can make a call
successfully.
" 6. To avoid the same problem occurring again, it is suggested
that the operator remove the combiner for transmission timeslots
multiplexer.
Case Study of SDCCH Congestion
! Case 3 conclusion:
" The transmission problem causes SDCCH congestion by MS
channel request repeatedly. Transmission problem can be
caused by different reasons. In this case, the fault on the
primary combiner leads SDCCH can not be activated, so all BTS
connected with this transmission equipment have the same
problem. In handling this type of problems, try to find the
similarity of the problem and finally locate the problem with the
exclusive method.