RNP Case Analysis Congestion: Huawei Wireless Training Department

RNP Case Analysis
Congestion
Huawei Wireless Training Department

Summary
TCH Congestion Ratio

BasicPrinciple
Cause and Locating the Cause
Cases
SDCCH Congestion
Ratio
Cause and Locating the Cause
Cases
TCH congestion ratio
TCH congestion ratio

Basic principle
Cause and locating method
Cases
TCH Congestion Ratio
Basic Principle of TCH

congestion ratio
Definition of TCH congestion

ratio
Traffic statistics measurement
point of TCH congestion ratio
and analysis
Basic Principle of TCH Congestion Ratio
Definition of TCH congestion ratio
 TCH congestion ratio (not including handover)
=TCH occupation failure times (not including handover)/TCH occupation

request times (not including handover)*100%
=(TCH call occupation failure times+very early assigned TCH occupation

failure times)/(TCH call occupation request times+very early assigned
TCH occupation request times)*100%.
Definition of TCH Congestion Ratio
 TCH congestion ratio (including handover)

=TCH occupation failure times (including handover)/TCH occupation
request times (including handover)*100%
=(TCH call occupation failure times+very early assigned TCH occupation
failure times+TCH occupation failure times for in-cell handover inside
BSC (due to congestion)+TCH occupation failure times for in-cell
handover between BSCs (due to congestion)/(TCH call occupation
request times + very early assigned TCH occupation request times +
TCH occupation request times for in-cell handover inside BSC + TCH
occupation request times for in-cell handover between BSCs)
 TCH congestion ratio (congestion on all busy)

MS BTS BSC MSC
of TCH Congestion Ratio
Traffic Measurement Point
Channel_req
Channel_Active
Channel_Active_Ack
IMMEDIATE ASSIGN COMMAND
first SABM
Establish_IND( CM Service Req)
CR(Complete_l3_information)
CC
CM Service Accepted
Setup
Call Proceeding
Channel_Active Assignment_Req
Channel_Active_Ack
ASSIGNMENT COMMAND
SDCCH first SABM
Establish_IND
SDCCH
UA
SACCH(TCH)
ASSIGNMENT CMP
SACCH(TCH) Assignment_CMP
Alerting
Connect
Connect Ack
communication
Disconnect
Release
Release Complete
Clear_CMD
Clear_CMP
MS call flow as the caller

Request Times Statistic Point of TCH Congestion Ratio
TCH call occupation request times

(1) Receive the MSC assignment request message
Early assigned TCH occupation request times:
(1) When there is no resource for SDCCH allocation and
instant assignment is permitted
(2) When channel request is received and channel type is
TCH
TCH occupation request times for in-cell handover inside BSC
(1) When in-cell handover request message between cells
inside BSC is received (non-SDCCH handover).
TCH occupation request times for in-cell handover between
BSCs:
(1) When incoming handover request message is received
(handover type is non-SDCCH)
Failure Statistic Points of TCH Congestion Ratio
TCH call occupation failure times:
(1) CONN_FAIL message is received in process of assignment.
(2) CLEAR_CMD is received in process of out-BSC handover. The
cause of handover is direct retry.
(3) CLEAR_CMD is received in process of assignment
(4) RR_ABORT_REQ is received in process of out-BSC handover and
the cause of handover is direct retry.
(5) RR_ABORT_REQ is received in process of assignment.
(6) MSG_HO_REQ_REJ is received in process of out-BTSC handover
(direct retry).
(7) HO_FAIL is received in out-BSC handover (direct retry)
(8) ERR_IND is received in process of assignment.
(9) When assignment failure message is sent.
(10) TN_T7 (direct retry) timeout (out-BSC handover request)
(11) TN_T8 (direct retry) timeout (out-BSC handover complete)
Failure Statistic Point of TCH Congestion Ratio
Early assigned TCH occupation failure times:

(1) CH_ACT_NACK is received in the very early assigned process.
(CH_ACT_NACK is received in WAIT_RR_EST status in satellite
transmission)
(2) In very early assigned process, the returned cause is (internal
error) CVI_INTERNAL_ERR when channel is being allocated.
(3) In very early assigned process, the returned cause is (channel
request illegal) CVI_NO_ACCEPT when channel is being allocated.
(4) In very early assigned process, no channel is allocated.
(5) TN_WAIT_CH_ACT timeout in very early assigned process.
Failure Statistic Point of TCH Congestion Ratio
TCH Occupation Failure Times for in-cell handover

inside BSC (due to congestion):
Allocation to TCH channel fails at in-cell handover
between cells in BSC
TCH Occupation Failure Times for in-cell handover
between BSCs (due to congestion)
When in-cell handover between BSCs occurs,
handover failure message is sent because it is not
allocated to TCH channel.
Analysis of failure statistic point of TCH congestion ratio
A interface
After MSC sends Asignment_req, If trunk circuit at A interface
is faulty, BSC will return Assignment_refuse directly.
In this case, the cause is usually incorrect CIC data
configuration of trunk circuit.
Analysis of failure statistic point of TCH congestion

ratio
ABIS interface and UM interface

1. RC board faulty or performance unstable
2. Unbalance of uplink/downlink level in BTS
3. Poor quality of uplink/downlink signal due to interference
4. SDCCH and SACCH (TCH) do not belong to the same
TRX board, i.e. the two RC boards cover different areas or
SACCH (TCH) RC board is faulty.
The Cause of High TCH Congestion Ratio and Locating

Method
 Thecause of high TCH congestion ratio

 How to locate the cause of TCH congestion ratio
Cause of High TCH Congestion Ratio and Locating
Method
Causes of High TCH Congestion Ratio
Incorrect configuration of trunk circuit data at A interface

TSC and BCC of hopping cells are different
Co-channel and co-BSIC results in TCH assignment failure in handover
Board fault or unstable performance causes the high congestion ratio
BTS hardware is not properly installed, which causes uplink/downlink
unbalance and TCH congestion.
The cell is attached with a booster. After the cell expansion, the booster is not
expanded.
The transmitting power of BCCH TRX is higher than that of TCH TRX in the same
cell.
Interference causes the congestion
Isolated site, complicated topography and TCH assignment failure result in the
high congestion ratio
Cause of High TCH Congestion Ratio and Locating
Method
How to Locate the Causes of High TCH Congestion Ratio
Analyze the cause of congestion remotely

1. Preliminary analysis through traffic measurement
2. Check alarms
3. BTS remote maintenance console
4. Test and analyze ABIS interface message with a
signaling analyzer.
Check the BTS locally

Cause of High TCH Congestion Ratio and
Locating Method
Remote analysis 1: Preliminary Analysis Through Traffic Statistics
 Through the traffic statistic “Cell TCH Performance Measurement”, check

whether TCH congestion is attributed to all busy status. If yes, perform traffic
equalization or suggest the equipment buyer to expand the capacity.
 If the congestion is not due to all busy status, analyze whether it is caused by
interference. Check interference bands 1~5. In the cell affected by interference,
the dropout ratio will be high.
 Register “Receiving Performance Measurement” traffic statistic task:
1. Check the measurement result by object to see whether the numbers of
uplink/downlink reports on the same TRX board are balanced. Thus you can
know whether the uplink/downlink hardware tributaries on the board are
balanced.
2. Check the measurement result by time to see whether TRX measurement reports
are excessive in a cell. Thus you can know whether the congestion is related to
the board.
Locating Method
Remote analysis 2: View alarm
 Check alarms of the site in the cell where there is high

congestion ratio. Check whether there is any abnormal
alarm, such as standing wave ratio alarm, PCM OOF alarm
and uplink data bus alarm. Judge whether the congestion
ratio is associated with alarms with traffic measurement .
Locating Method
Remote analysis 3: BTS remote maintenance

console
 Check whether the board software versions in the BTS

are consistent. Refer to the version notice of SUPPORT
website and upgrade when necessary.
 On the BTS remote maintenance console, block in

turns TCH channels of cell RC board with high
congestion ratio. Observe whether the congestion ratio
is related to the cell RC board.
Locating Method
Remote analysis 4: Test and analyze ABIS port message with a
signaling analyzer
Trace ABIS message of the congested BTS, analyze Assignment CMD sent by
SDCCH and judge whether the assignment always fails on a specific TRX board.
 If the assignment always fails on a specific TRX board, the cause may be one of
the following:
1) TRX board faulty or performance unstable

2) Uplink/downlink level difference, hardware problem in uplink tributary or downlink
tributary.
3) Low quality of uplink/downlink signal. Analyze TA value of the MS to locate

interference.
 If the assignment fails on the RC boards of the whole cell randomly, analyze the
measurement reports. The causes may be the following:
1) The topography in the cell coverage is quite complicated.
2) There is band interference in the whole cell, such as booster interference.

Locating Method
Locating Method
Check BTS locally
Perform local maintenance and check to see if there are abnormal alarms. If
yes, process it promptly.
Check whether there is any hardware problem in uplink/downlink

antenna/feeder tributary, such as loose connector, antenna connection, half-
rigid cable connection error and loose backplane wiring.
Perform a dial test with the test mobile phone in the same place to see
whether the assignment failure always occurs in one band or is randomly
distributed.
Make driving test with ANT-PLOT, the network optimization software, to see
whether there is abnormal handover relation due to downlink interference, so
as to find the real cause of the congestion ratio.
Search the interference source with a spectrum analyzer.
Observe whether the topography in the cell coverage is complicated.

Cases of TCH Congestion Ratio

Cases of TCH Congestion Ratio Problem
Data configuration problem at A interface ----------------------- Case 1
TRX board faulty or performance unstable, causing high congestion ratio ------------
Case 2
Uplink hardware problem --------------------------------------- Cases 3, 4
Downlink hardware problem ------------------------------------ Cases 5, 6
Effect from booster attached to the cell -------------------------- Case 7
Other data configuration --------------——————----------- Cases 8, 9
Isolated
site and complicated topography causing the high congestion ---------——
—————----- Case 10
Case 1
Fault description: There is one BSC in the local network. One day, TCH
congestion ratio of the whole network begins to rise (frequency planning was
not changed). TCH congestion ratio of the whole network (not including
handover) is 4%(the congestion ratio on all busy is very low). In addition,
many cells but not a few cells are highly congested.
Case 1
Analysis:
1. Since the frequency plan is not adjusted, radio port
problem is ruled out.
2. Congestion ratio is abnormal in most BTSs. In this case,
search in a smaller range to see whether the congestion
problem is related to module or data modification.
3. Analyze the main cause of TCH occupation failure
through traffic statistic and finally locate the problem as
data or hardware fault.
Case 1
Troubleshooting:
1. View the traffic statistics . The problem occurs after BSC data are modified and loaded. Maybe it is
related to BSC loading.
2. Analyze traffic statistics to find that the highly congested cells are focused on module 1 of BSC.
Then the problem should be with module 1.
3. Check the module to find that TCH occupation failure is mainly attributed to unavailability of
terrestrial resources. It shows that unavailability of terrestrial resource is the main cause of high
congestion ratio in module 1.
4. The cause of terrestrial resources unavailability is mainly on the circuit of Abis interface or A
interface. This problem occurs to many cells in module 1. However, it is quite unlikely that Abis
interface is faulty in many cells at the same time. Therefore, the cause should be the hardware or data
at A interface.
5. Check the hardware of A interface to find that the hardware is normal. A interface hardware problem
is ruled out.
6. Check the data configuration of the trunk circuit of A interface to 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 set
dynamically, and then the congestion ratio is lowered to normal.
Case 1
Conclusion:
1. In trunk circuit data configuration at A interface, CIC must be
correct, otherwise, TCH assignment will fail and the congestion
ratio will be high.
2. In the meantime, if the CICs of two FTC boards (multiple trunk
circuits) are the same, this problem will also happen.
Case 2
Fault description: The configuration of a specific BTS is S6/4/2 and it had

been running normally. One day, the result of traffic statistics shows that
TCH channel in cell 1 (6 TRX) overflows very seriously and the congestion
ratio comes to 20%.
1. The traffic of the cell is very low, which is about 0.8Erl in busy hours.
2. At the same time, the times of TCH occupation on all busy is 0.
3. Observe the channel status of all base bands in cell 1. It is all “Idle”.
Case 2
Analysis:
1. No data have been adjusted and there is no hopping in the cell. 6
TRXs use different bands. It is unlikely that they are subject to
external interference at the same time. Therefore, it can not be radio
port interference or data problem.
2. Check hardware specifically. Since the problem only occurs to cell
1, we can block TRXs in turn to determine which TRX causes the
assignment failure.
3. Find out whether there is hardware fault in the TRX for assignment
failure. Check them one by one by means of resetting and replacing.
Case 2
Troubleshooting:
1. Check BT channel status through remote maintenance and find that there is
possibility of TCH occupation failure in BT4, BT5 in cell 1.
2. Block BT4 and BT5 as well as RC4 and RC5 at the same time and find that there is
no TCH congestion all the day. It indicates that the problem is on RC4 and RC5.
3. Unblock BT4, BT5, RC4, RC5, and reset RC4(TRX4), RC5(TRX5) and high congestion
arise again.
4. Go to the BTS site to plug/unplug TRX4, TRX5 and make a dial test with the
frequency locked (on TRX4, TRX5), TCH occupation failure still occurs. Exchange the
slots of TRX4 and TRX5 and make the dial test again (TRX4, TRX5). The TCH
occupation failure persists.
5. Replace TRX4, TRX5 and make dial test with the frequency locked (on TRX4, TRX5),
TCH occupation is successful and there is no TCH congestion. The problem is solved.
Case 2
Conclusion:
1. The faulty TCH TRX board causes TCH assignment failure and
high congestion ratio.
2. Usually, the fault of TRX board can not be found on the BTS
maintenance console and TCH availability is normal. The problem
can be confirmed by blocking in turn.
Case 3
Fault description: A specific BTS is configured as S6/6/6. Since

the BTS deployment, the congestion ratio of the 3 cells has been
high. Check and confirm that there is no interference.
Case 3
Analysis: There is no interference and congestion always exists after the BTS is in
service, in every cell. But other BTSs has no such problem, therefore, check hardware
of the BTS.
1. Hardware fault: communication is normal in every cell, so it is unlikely that there is
fault in the hardware of every cell.
2. Hardware connection: Check hardware connection carefully. Analyze the traffic
measurement to locate whether the fault is in the uplink or the downlink and then
check the hardware connection of the uplink or the downlink.
Case 3
Troubleshooting:
1. Register traffic statistics “Receiving Level Performance Measurement” and
query the result of traffic statistics by time. It is found that when the receiving
level and receiving quality of different TRX boards in the same cell are the
same, the number of downlink measurement reports is balanced but the
number of uplink measurement reports is not, regularly unbalanced.
2. Check and find that the connection of two SPLs in the same cell cascaded
to half-rigid cable is incorrect. After correction, the problem is solved.
Case 3
Times of uplink receiving Times of uplink receiving Times of Uplink receiving level
level grade 0 and level grade 0 and receiving grade 0 and receiving quality
receiving quality level 0 quality level 1 level 2
30 minutes starting from 11:00 18-3-2001

Module ID 1, Cell ID 5, TRX No. 12 2 0 7
Case 3
Set-top connector (connected with Set-top connector (connected with
receiver antenna receiver antenna
Level 1 SPL Level 2 SPL Level 1 SPL Level 2 SPL
IN IN IN IN
TRX TRX TRX TRX

Incorrect splitter cascading Correct splitter cascading
connection connection
Case 3
Conclusion:
Incorrect hardware connection will cause TCH assignment
failure. The problem can be located accurately by analyzing
different traffic statistics tasks.
In this case, uplink hardware receiver problem is located
through “Receiving Level Performance Measurement”.
Case 4
Fault description: After A BTS (configuration S6/6/6, BTS20) runs normally for a
while, it is found that the congestion ratio of cells (not including handover) goes
up to 20%. Perform blocking in turns to find that TCH assignment on the third
TRX board fails. When the corresponding board is replaced, it makes no
difference.
Case 4
Analysis: There is no parameter adjustment before/after the fault and only the TRX
assignment on the third TCH fails, therefore attention should be focused on the
hardware related to the third TRX board, to see whether there is any fault or alarm.
Case 4
Troubleshooting:
1. Query the alarm. The local maintenance console shows that TRX alarm information is CUI link alarm. This
type of alarms are usually caused by hardware fault. Replace TRX3 and FPU3 board, but the problem
persists.
2. Swap the board in the slot with the one in a normal slot, this slot is still faulty, but the replacement board
in the slot in doubt works normally. It shows that the board is not defective but the slot is faulty.
3. It is found that FPU alarm in slot 3 is uplink link alarm. Maybe the board is not well contacted with the slot
or the backplane is faulty. Dismount the cabinet, plug/unplug all the communication cable and power on
again. It is found that FPU alarm disappears. After 20 minutes, the fault does not appear any longer and the
congestion ratio is lowered. It is believed that the fault has been cleared.
4. In the next day, observe the traffic statistics and the fault re-appears two hours after the cabinet is re-
installed. Replace the backplanes in the base band frame and RC frame, but the problem persists.
5. Replace the communication cables in the cabinet and observe for two days. The fault does not appear any
longer and the problem is solved.
Case 4
Conclusion:
The hardware fault can be on TRX boards,
backplanes, internal communication cables, or
slots. Any such fault will result in TCH assignment
failure.
Case 5
Fault description: In a BTS S6/6/5, one cell has high congestion

one day. No adjustment has been made in this period.
Case 5
Analysis: There is no parameter adjustment before/after the fault,

therefore attention should be focused on the hardware, to see
whether there is any fault or alarm.
Case 5
Troubleshooting:
1. Trace ABIS interface message of the BTS with a signaling analyzer MA10 and analyze the
signaling to find that in process of TCH assignment failure, the uplink signal in the
measurement report from the MS is of high quality after BSC sends ASSIGNMENT CMD, but
the downlink signal level can not be resolved, i.e. the levels of uplink/downlink signals are
not balanced. Then ASSI FAILURE message is returned. It is also found that the assignment
is directed to the last TRX board in the cell.
2. Block the TRX board channel temporarily and congestion ratio of the cell is lowered to 1%.
Perhaps there is problem in TRX board and the downlink hardware.
3. Check and find that the Transmitting antenna&feeder VSWR is over 2.5 alarm on the
combiner connected with TRX board. Process the antenna&feeder VSWR alarm and the
problem is solved.
Case 5
Conclusion: Antenna VSWR alarm results in large loss, small

coverage and assignment failure. When the MS is in the cell BCCH
coverage, but not in the coverage area of the board where VSWR alarm
occurs, assignment to this TRX board is easy to fail and the
congestion ratio in the cell goes up as a result.
Case 6
Fault description: In a site S6/6/6, the first two cells have high
congestion ratio and the third cell has normal congestion ratio after
the site is in service. It is confirmed that there is no interference.
Case 6
Analysis: The congestion ratio is abnormal right after the site

is in service and one cell is normal, therefore, attention should
be focused on the data and hardware.
Case 6
Troubleshooting:
1. Trace ABIS interface message of the two cells with a signaling analyzer to find that the
assignment always fail on the last two TRXs. When assignment goes to the last two TRX
boards of each cell with ASSIGNMENT CMD, the uplink/downlink signals are not balanced
and the assignment fails.
2. In a distance 50m away from the BTS, make a dial test to each timeslot of the last two TRX
boards. Assignment no long fails.
3. Re-trace and analyze ABIS interface messages again to find that the MS is normal at TA=2
(1.1Km) when the assignment fails. Then make a dial test 1~2Km away from the BTS to find
that the BTS downlink level is lowered substantially after the assignment to the TCH of the
last two TRX boards. The transmitting spur track of the last two TRX may be faulty.
4. Check downlink transmit tributary TRX—>HPA—>COMBINER—>LIGHTNING ARRESTER —
> ANTENNA one by one and find that the feeder of transmitting tributary of the last TRX
boards in the two cells is installed improperly. After correction, the problem is solved.
Case 6
Conclusion:
The transmitting direction of master BCCH TRX is
different from the direction of the last two TRX
boards in the same cell, therefore their coverage
areas are different, which causes the assignment
failure.
Case 7
Fault description: When a BTS O2 is expanded to O4, high

congestion ratio occurs, with the peak of 40%.
Case 7
Analysis: Since congestion ratio is abnormal after expansion,

we can
1. Check whether the congestion occurs to all TRXs. If yes,

re-check the connection of newly added hardware of the BTS
to see whether there is any fault.
2. If congestion occurs to one or a few TRXs, check the

hardware of these TRXs.
3. When hardware problem is ruled out, consider external

cause. For example, the booster is not expanded, which
results in assignment failure.
Case 7
Troubleshooting:
1. Block TRX of the last two newly added TRXs on the remote BTS maintenance console to find that
the congestion ratio is lowered to normal status. Perhaps, the problem is related to the two boards.
2. Trace and analyze ABIS interface signaling to find that the assignment failure occurs to the two
newly added TRXs. When the assignment fails, SDCCH measurement report analysis shows that the
level on SDCCH is normal and TA value is large and the assignment takes place in a distant area.
However, there is no measurement report on SACCH (TCH). Perhaps the two boards have hardware
problem in uplink/downlink tributaries. Sometimes the assignment of the two boards succeeds, so
the boards could not be faulty.
3. A 4 in 1 combiner and a 1 to 4 splitter are used in the cell, the antenna & feeder part can not have a
hardware fault. Check the half-rigid cable from TRX board to the combiner/splitter and no hardware
problem is found. Basically it can not be a hardware problem.
4. It is told that this cell is attached with a booster. After the expansion, the booster did not lock the
two newly added TRXs, which causes the assignment failure. When the booster band problem is
solved, the congestion problem is also solved.
Case 7
Conclusion:
Because of the booster, the coverage areas of the first two
TRXs and the last two TRXs in the same area are different,
which results in the assignment failure.
Case 8
Fault description: A prefecture is making its network planning. The

BSC version is G30MC32.00400.06.0520B. After some network planning
parameters are modified, observe the traffic statistic index and find that
the TCH assignment success ratio of one BTS is low.
Case 8
Analysis: After the network planning parameters are

modified, indexes of the two cells are worsened. Check the
modified data carefully to see whether the modification
affects TCH assignment.
Case 8
Troubleshooting:
1. Observe traffic statistics to find other indexes are normal. The failure times of instant
assignment and handover assignment are both high. The indexes of other sites after the
planning are normal.
2. Check network planning topography graph to find that there is no co-channel and side
channel interference between this site and other sites after the network planning.
3. Check the BTS for interference and no serious interference is found. The traffics of the
cells in the site are normal. Congestion on all busy problem is not found.
4. Check the updated data table, hopping data table and band number. No error is found.
5. Check BSC cell table and hopping data table to find that the BCC and hopping training
sequence code are not identical. Modify the data so that the two are identical. Set the
table dynamically and observe the traffic measurement , to find the fault is cleared.
Case 8
Conclusion:
In the hopping cell, TSC and BCC must be
identical, otherwise, SDCCH and TCH assignment
would fail. The traffic measurement indexes will
be: TCH congestion ratio is higher, SDCCH
occupation failure times is increased.
Case 9
Fault description: In the optimization of a local network, the congestion

ratio (including handover) on busy hours of the two cells is as high as 10%.
“Congestion Ratio Excluding Handover” and “Congestion Ratio of
Occupation on All Busy” are normal. Here, “Failure Times of Assignment
Occupation (all)” is very high, 89 times and 61 times respectively. But
“Failure Times of TCH Call Occupation” is 0”.
The traffic is a little lower than that before optimization.
The interference band is normal.
Congestion ratio was normal before optimization.
Case 9
Analysis: When the network planning parameters are optimized and

modified, the congestion ratio of the two cells is higher and only the
congestion ratio including handover is higher, therefore, radio
interference or hardware fault can be ruled out. Analyze whether the
handover is abnormal.
Case 9
Troubleshooting:
1. Register “In-cell Handover Performance Measurement” for 15 minutes in the
two cells to find that all the handovers from a specific cell (CGI=*********1768) to
these two cells fail, and the handover is not the actual cause of congestion.
2. Failure of all handovers means that there is problem with the handover data.
Check the handover data of the two cells to find that there is co-channel and co-
BSIC as expected. The two cells are adjacent to the specific cell, therefore the
handover from the specific cell to any other cell will fail. The failure occurs when
TCH channel is assigned.
3. Modify the BCCH and BTSIC of the two cells, and then the handover is
recovered and congestion ratio is normal.
Case 9
Conclusion:
1. Two cells (both adjacent to a specific cell) with co-channel and co-
BTSIC will not only result in low in-cell handover success ratio, but
also high TCH congestion ratio (including handover).
2. The case indicates that TCH congestion ratio (including handover)
and TCH congestion ratio (not including handover) are different.
Case 10
Fault description: Site O2 of a suburban county has suffered from high

congestion ratio (not including handover), from 3% to 10% (in proportion to
traffic). But the congestion ratio on all busy is 0%.
1. Block 2 TRXs in turn, the congestion ratio remains serious as before.
2. Other indexes: dropout ratio is high (about 5%). Interference band is
normal.
Case 10
Analysis:
1. Since the congestion ratio 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 radio port
is unlikely.
3. Reanalyze the cause of assignment failure. Take dropout ratio into
consideration and analyze the receiving performance of uplink/downlink,
including level, quality.
Case 10
Troubleshooting:
1. View “Dropout Performance Measurement” to find that TA value is large upon
dropout, at a distance of 25.6km~31.1km away from the BTS.
2. View “Receiving Level Performance Measurement” to find that there are many
measurement reports of low level grades.
3. Analyze ABIS signaling to find that the uplink level is very low (about –98dbm)
when the assignment fails.
4. Make a driving test on the site to find that the site is isolated, with large
coverage and complicated topography. When the MS is more than 25 kilometers
away from the BTS, it can receive –90dbm downlink signal. But the uplink signal
is not enough, so TCH assignment fails.
Case 10
Conclusion:
1. Poor uplink coverage causes the high congestion ratio.
Adding BTSs can help form a continuous coverage.
Change the omni-directional site into a directional site
by adjusting the antenna angle. Intensify the transmitting
level and BTS receiver sensitivity. Avoid cross-cell
coverage.
2. Trace Abis port message on the BTS maintenance
console to analyze the assignment status.
SDCCH Congestion Ratio
SDCCH congestion ratio

Basic principle
Cause and locating method
Cases
Basic Principle of SDCCH Congestion Ratio
Calculation formula:
SDCCH congestion ratio=SDCCH
occupation on all busy times/SDCCH
occupation request times
SDCCH occupation on all busy times:
SDCCH occupation failure due to all busy
The cause of SDCCH occupation:
1) The caller assignment command is sent to channels
2) The called paging response is sent reported to
channels
3) Location updating
4) Short message
5) IMSI detachment and attachment process
Basic Principle of SDCCH Congestion Ratio
MS BTS BTS MSC
C
Channel Request (RACH)
Channel Required
BTSC random access – immediate assignment 000008,

000012
Cell SDCCH occupation request times 008000
Cell instant assignment request times 008137
SDCCH Channel No Resource
Cell SDCCH occupation on all busy 008014
Cell SDCCH occupation failure BTSS008015
Immediate Assignment Command
Immediate Assignment Reject

Cause of SDCCH Congestion and Locating the Cause
 Location area boundary results in excessive

SDCCH location updating
Policy: Modify location area selection
Modify CRH (Cell Reselect Hysteresis)
Modify the parameters of periodical area updating.
Modify the frequent handover problem of the dual-frequency
network.
Excessive short messages, antenna forecast
Policy: coordinate related party and tell them not to make

centralized transmission.
Add SDCCH channel
Cause of SDCCH Congestion and Locating the
Cause
Insufficient system capacity: more SDCCHs should be

configured
Policy: expansion
Improper setting of system parameters. RACH system

parameter. Actually multiple SDCCHs are assigned.
Policy: Increase RACH access threshold (for coping with

interference).
Decrease maximum resend times and increase extended
transmission timeslots appropriately
Dynamic SDCCH allocation
Board (TRX/FPU) fault and transmission fault result in SDCCH

congestion
Cases of SDCCH Congestion Ratio Problem
SDCCH Congestion Cases

Case 1:
In a local network, the radio call complete ratio is low.
Analyze the traffic statistics to find that SDCCH
congestion only occurs to a few sites.

Case 1
【Analysis】: Since only a few BTSs are congested,

please register “SDCCH Performance Measurement” and
analyze the shares of respective causes for SDCCH
occupation. Solve the problems accordingly.
Case 1
【Troubleshooting】:
1. Analyze traffic measurement : in the congested cell, SDCCH is occupied for 300-400 times in
busy hours. They are all S1/1/1 BTSs. Each cell is configured with SDCCH/8 channels. Normally,
they are capable of coping with 300-400 SDCCH occupations. But it is strange enough that there
are only dozens of SDCCH occupations in each cell is busy hours.
2. Register “SDCCH Performance Measurement” to find that most SDCCH occupations are
attributed to location updating. Analyze the cell locations and find that the above congested BTSs
are at the cross points of two railway lines. This gives us a hint that maybe sudden location
updating results in SDCCH congestion.
3. Register “SDCCH Performance Measurement” for five minutes to find that locations are always
updated in a specific 5 minutes. Query the train timetable to find that 4 or 5 trains pass by the point
in this period. When the trains pass by, a large amount of location updating occur in a short, which
results in the congestion.
4. Add SDCCH or enable SDCCH dynamic allocation function.
Case 1
【Conclusion】:
For SDCCH congestion due to location updating, check
whether it is caused by improper setting of location area.
This case is a special one. Add SD or enable dynamic
allocation function to solve the problem.
Case 2
【Fault description】
A BTS is modified from O2 to S2/1/1 site (BTS20). For a period of time,
users complain that the communication is always interrupted and the voice
is not clear. In recent two days, SDCCH congestion in two cells of the site
turn serious suddenly. In busy hours, SDCCH congestion times amounts to
35000/hour. The congestion ratio comes to 60% and there are user
complaints that the voice is interrupted from time to time.
Case 2
【Analysis】:
After the expansion, not only SDCCH is congested, the
communication is interrupted from time to time. Interference
cause is ruled out first. Check hardware carefully. Locate the
cause by alarm querying, resetting and board replacing.
Case 2
【Troubleshooting】
1. When the user complaint of voice interruption problem is received, check the BTS
remotely and there is no alarm.
2. After SDCCH is seriously congested, reset the base band remotely, but it is of no use.
SDCCH congestion remains 30000 times/hour. Perform level-4 resetting of the BTS, and
SDCCH abnormal congestion is lowered to about 5%, but there are still user complaints
that voice is interrupted and distorted. Sometimes, there is OMU active/standby
communication fault or FPU board communication alarm, but the alarm only lasts 3-4
seconds.
3. Go to the BTS site for maintenance and find there is no alarm indicator on the cabinet
panel. Perform local maintenance, and there is no alarm. The board status is all normal.
4. Go to the site to make dial test with the frequency locked, and it is found that the call
is hard to be connected sometimes. When the call is connected, the communication is of
low quality and interrupted from time to time. The voice is intermittent.
Case 2
5. Check and confirm that there is no interference inside/outside the network.
6. Check the antenna/feeder system. Is the VSWR is normal? Is there
uplink/downlink unbalance problem due to incorrect installation of cell feeder? Are
uplink/downlink power control and DTX enabled? Find out whether the signal
quality affects the communication quality. They turn out to be normal.
7. Replace the FPU of TRX in two cells. Swap it with another FPU working normally
beside it and find that the voice quality becomes clear immediately. But the TRX
board at its side gives distorted and discontinuous voice.
8. Replace the faulty FPU and the problem is solved. SDCCH congestion ratio is
lowered to 0.1% as well.
Case 2
【Conclusion】:
1. The causes of serious SDCCH congestion usually are FPU fault, transmission interruption with power
control enabled, transient interruption of transmission and abnormal software operation. If it is confirmed
that there is no transmission problem, check boards and base band software to see whether they are
working normally. In this case, no transient interruption of transmission is found, so the cause should be a
fault on the board or SCP software. Board fault or software running abnormally could make SCP report
much false SDCCH occupation information. Resetting FPU board or BTS software can solve the software
running problem.
2. Intermittent voice should result from voice path problem. An MS path is: MS---air interface---BTS
antenna& feeder---TRX---FPU---42BIE (BTSMU)--- DDF frame at both sides and transmission line---32BIE---
BNET---OPT-FBI---CTN---E3M---TCSM-MSC. In this case, other two cells in the BTS share a couple of
transmissions with cell 2, so the part above ABIS interface should be normal (if there is error in NET board
switching, voice problem will occur to the three cells or even the whole BM module. In addition, A interface
is also shared. Although HW cable of BM module can be a suspect, the cell only occupied 8 timeslots, it is
quite unlikely that HW cable would causes the problem). Since interference and antenna & feeder problems
are ruled out, the problem must be on the board.
Case 3
Deploy a BTS30 base station. After the deployment, SDCCH channel is
always in all busy status (A). TCH channel is in (I) or (A) status. When
the call is connected, the communication is normal. Observe the traffic
statistics and find that the SDCCH assignment of traffic statistics fails
about 1000 times (in busy hours).
Case 3
【Analysis】:
1. Since SDCCH is congested after the BTS deployment, but TCH and
communication are normal. First check data and hardware. The whole site
suffers from congestion problem. Swap ports with other sites of the same
type to confirm whether there is data problem or hardware problem under
Abis interface. Check section by section.
2. If data problem and hardware problem are ruled out, attention should be
focused on the transmission problem.
Case 3
1. Check alarm: LAPD link fault alarm and recovery alarm (within one second). The alarm
appears once per ten minutes.
2. Check the data to find no problem. At night, exchange with 32BIE port of other BTS of
the same type, other sites work normally but problem of this site persists. Data problem
and BSC side hardware problem are ruled out.
3. Since the BTS is far from the city proper, first register the transmission related traffic
measurement . Observe the result (related to transmission) and find no problem, but
SDCCH traffic measurement remains abnormal.
4. Replace TMU and TRX board in the BTS and the problem persists.
5. Measure the transmission and self-loop 32BIE, then the port indicator flashes
sometimes. It is found that there is bit error in the transmission. Test the line section by
section and find that in a segment of access network from a county to the BTS, one 2M
transmission board is faulty. Replace the board and the problem is solved (the two BTSs
are on the same board).
Case 3
【Conclusion】:
The causes of SDCCH congestion can be :
1. Data configuration error
2. SDCCH channels insufficient
3. Radio port problem (interference, low level, uplink/downlink unbalance)
4. Hardware fault
5. Transmission quality problem
In this case, the cause is item 5 mentioned above. Due to transmission bit error, large
number of data are lost at SDCCH assignment or data are resent many times to
timeout after the data loss. This causes the occupation failure and hence the high
congestion.
Case 4
A complaint is received that mobile subscribers near 4 sites (ABCD) of a local
network can not make calls, but there no related alarm information on the alarm
maintenance console.
1. Check the 4 BTSs, the board status is all normal. Almost no TCH channel is
occupied. Sometimes one TCH is occupied, it becomes idle in several seconds. All
SDCCH channels are in A status.
2. It is learnt that Site A is S2/1 BTS30, B,C are O2BTS312, and D is S1/1BTS312. The
software version of the 4 BTSs is all 3.02R003.20000529 .BTS-A is attached under it
with BTS-B and BTS-C. BTS-D, using a primary combiner (a transmission timeslot
multiplexer), shares a 2M transmission line with BTS-A.
Case 4
【Analysis】
The symptom can help judge whether the problem is on the hardware or
on 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 4
1. Carefully observe 32BIE indicator to find that the indicator flashes every 12 seconds. It indicates
that there is bit error in the transmission. Check the microwave and optical transceiver and no
abnormal indication is found.
2. Check ABIS interface signaling to find that a large number of PAGING_CMD messages are
generated. Among them, one RF_RESORCE_INDICATION message is generated 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, and find no data modification has been done in a few days in the past.
Therefore data problem is ruled out.
4. Check the indicator of corresponding ports of 32BIE and find that the indicator is off. It seems
that the transmission is normal.
5. Reload and activate the board software of BTS-ABCD, and find that the system response is slow,
even with communication timeout prompt. When the board is loaded and activated, SDCCH is still
congested. Users still complain that they can hardly call out. Since the 4 sites share one 2M
transmission line and SDCCH occupation is abnormal at the same time, it is concluded that it is
transmission problem.
Case 4
6. The only transmission equipment in doubt after the resetting --- primary
combiner (resetting causes the re-initialization of ABCD). After ABCD
initialization is complete, and it is found that SDCCHs are fully occupied and
TCH can be occupied normally. Trace ABIS interface signaling, CHAN_ACTIV,
CHAN_ACTIV_ACK or IMMEDIATE_ASSIGN_COMMAND message appears.
SDCCH is no longer congested. Users on the site say that they can make calls
normally.
7. The same problem may occur to the primary combiner, therefore the operator
is recommended to use optical transmission circuit. After the modification, the 4
BTSs have been running normally.
Case 4
【Conclusion】:
The same as Case 3, the transmission problem causes SDCCH congestion. But
transmission problem is attributed to different causes. In this case, the fault on the primary
combiner results in the transmission problem. All BTSs 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.
Case 5
Telephone call near a site (BTS20, S2/2) is difficult. Make a dial test
on the site and find that 2 of 10 call attempts are successful.
Sometimes the call completion ratio is lower.
In two cells of this BTS, the traffic of one cell is 9~10Erl and another
is 3~4Erl. Their problem is similar: hard to get calls connected.
Case 5
【Analysis】
The symptom shows that the traffic is normal. That means TCH channel
is normal. But the call is difficult, which perhaps is related to the problem
with SDCCH assignment. Register the traffic statistics for “SDCCH
Performance Measurement” and analyze. Or trace Abis interface
message to see whether there is anything abnormal.
Case 5
1. Check the traffic measurement and find that SDCCH traffics of the two cells are 7Erl. While in
other cells with high traffics in the system, the highest traffic of SDCCH is less than 2Erl.
Obviously, the traffic is abnormal.
2. View the channel configuration of the BTS to find that the two cells are both configured with
3 timeslots as SDCCH channels. There are totally 24 SDCCH timeslots and SDCCH dynamic
allocation is enabled. However, when SDCCH traffic is very low, SDCCH timeslots do not
change back to TCH.
3. Check SDCCH occupation to find that in SDCCH occupation, the whole timeslot (8 SDCCH
channels) is occupied or released at the same time. Sometimes 4~8 SDCCH channels are
occupied/released at the same time. The channel occupation is obviously abnormal.
4. Trace Abis interface signaling on a specific SDCCH timeslot in the cell to find a situation
similar to item 3. There appear multiple chan_activ/chan_deactive signalings continuously and
the numbers of SDCCH channels occupied/released are consecutive. Obviously, this is an
abnormal channel allocation.
5. Perhaps it is caused by SDCCH dynamic allocation. Disable SDCCH dynamic allocation of
the two cells and the BTS is recovered. In cells of low traffic, the dial test is normal, while in
cells of high traffic, congestion occurs sometimes (due to the high traffic).
Case 5
【Conclusion】:
SDCCH dynamic allocation function is related to BSC and BTS

versions. In this case, abnormal SDCCH dynamic allocation
results in SDCCH congestion.
Thanks

RNP Case Analysis Congestion: Huawei Wireless Training Department

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RNP Case Analysis Congestion: Huawei Wireless Training Department

Uploaded by

Copyright:

Available Formats

RNP Case Analysis

Huawei Wireless Training Department

TCH Congestion Ratio

TCH congestion ratio

Basic Principle of TCH

Definition of TCH congestion

Definition of TCH congestion ratio

 TCH congestion ratio (not including handover)

=TCH occupation failure times (not including handover)/TCH occupation

=(TCH call occupation failure times+very early assigned TCH occupation

Definition of TCH Congestion Ratio

 TCH congestion ratio (including handover)

 TCH congestion ratio (congestion on all busy)

IMMEDIATE ASSIGN COMMAND

MS call flow as the caller

Request Times Statistic Point of TCH Congestion Ratio

TCH call occupation request times

Failure Statistic Point of TCH Congestion Ratio

Early assigned TCH occupation failure times:

Failure Statistic Point of TCH Congestion Ratio

TCH Occupation Failure Times for in-cell handover

Analysis of failure statistic point of TCH congestion ratio

Analysis of failure statistic point of TCH congestion

ABIS interface and UM interface

The Cause of High TCH Congestion Ratio and Locating

 Thecause of high TCH congestion ratio

Causes of High TCH Congestion Ratio

Incorrect configuration of trunk circuit data at A interface

Analyze the cause of congestion remotely

Check the BTS locally

 Through the traffic statistic “Cell TCH Performance Measurement”, check

Remote analysis 2: View alarm

 Check alarms of the site in the cell where there is high

Remote analysis 3: BTS remote maintenance

 Check whether the board software versions in the BTS

 On the BTS remote maintenance console, block in

1) TRX board faulty or performance unstable

3) Low quality of uplink/downlink signal. Analyze TA value of the MS to locate

2) There is band interference in the whole cell, such as booster interference.

Check whether there is any hardware problem in uplink/downlink

Search the interference source with a spectrum analyzer.

Observe whether the topography in the cell coverage is complicated.

Cases of TCH Congestion Ratio

Data configuration problem at A interface ----------------------- Case 1

Uplink hardware problem --------------------------------------- Cases 3, 4

Downlink hardware problem ------------------------------------ Cases 5, 6

Effect from booster attached to the cell -------------------------- Case 7

Other data configuration --------------——————----------- Cases 8, 9

Fault description: The configuration of a specific BTS is S6/4/2 and it had

Fault description: A specific BTS is configured as S6/6/6. Since

30 minutes starting from 11:00 18-3-2001

Level 1 SPL Level 2 SPL Level 1 SPL Level 2 SPL

TRX TRX TRX TRX

Fault description: In a BTS S6/6/5, one cell has high congestion

Analysis: There is no parameter adjustment before/after the fault,

Conclusion: Antenna VSWR alarm results in large loss, small

Analysis: The congestion ratio is abnormal right after the site

Fault description: When a BTS O2 is expanded to O4, high

Analysis: Since congestion ratio is abnormal after expansion,

1. Check whether the congestion occurs to all TRXs. If yes,

2. If congestion occurs to one or a few TRXs, check the

3. When hardware problem is ruled out, consider external

Fault description: A prefecture is making its network planning. The