OMF000405 Case - Ysis-Congestion ISSUE1.4

Internal
OMF000405
Case Study -Congestion
ISSUE1.4 www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved

References
 31160978-BSC Traffic Statistic

Manual Volume I
 31033203-BSS Troubleshooting
Manual
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 2

Upon completion of this course, you are
supposed to be able to:
 Understand the principles of congestion
 Analyze and solve congestion problems

Chapter 1 TCH congestion
Chapter 2 SDCCH congestion

TCH congestion
 TCH congestion
 Basic principle
 Causes for high TCH congestion
 Case study of TCH congestion

TCH congestion
 Basic principle of TCH congestion
 Definition of TCH congestion rate

 Measurement point for TCH congestion and analysis

TCH congestion
 Definition of TCH congestion rate
 TCH congestion rate (excluding handover)
=(TCH seizure failures for call + TCH seizure failures for

very early assignment) / (Attempted TCH seizures +
Attempted TCH seizures for very early assignment) *100%

TCH congestion
 Definition of TCH Congestion rate
 TCH congestion rate (including handover)
=(TCH seizure failures for call + TCH seizure failures for very
early assignment + TCH seizure failures for intra BSC incoming
cell handover (no radio resource) + TCH seizure failures for
inter BSC incoming cell handover (no radio resource) ) /
(Attempted TCH seizures (all) + Attempted TCH seizures for
very early assignment + Attempted TCH seizures for intra BSC
incoming cell handover + Attempted TCH seizures for inter
BSC incoming cell handover)

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

TCH congestion
 Attempted TCH seizures measurement point
 Attempted TCH seizures for call
− Receive the MSC assignment request message

 Attempted TCH seizures for very early assignment
− When there is no resource for SDCCH allocation and very early assignment
is permitted
− When channel required is received and channel type is TCH
 Attempted TCH seizures for intraBSC incoming cell handover
− When intraBSC incoming cell handover request message is received (non-

SDCCH handover request).
 Attempted TCH seizures for interBSC incoming cell handover
− When interBSC incoming handover request message is received (handover

type is non-SDCCH)

TCH congestion
 TCH seizure failures:
 TCH seizure failures for call,

 TCH seizure failures for very early assignment,
 TCH seizure failures for interBSC incoming cell handover,
 TCH seizure failures for intraBSC incoming cell handover,
 TCH seizure failures for intracell handover.

TCH congestion
 TCH seizure failures for call measurement point:
 (1)CONN_FAIL message is received in process of assignment.

 (2)CLEAR_CMD is received in process of outgoing 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 outgoing 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 outgoing BSC
handover (direct retry).

TCH congestion
 TCH seizure failures for call measurement point:
 (7) HO_FAIL is received in outgoing 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 (outgoing BSC handover
request)
 (11)TN_T8 (direct retry) timeout (outgoing BSC handover
complete)

TCH congestion
 TCH seizure failures for very early assignment measurement point:
 (1)CH_ACT_NACK is received in the very early TCH assignment

process. (CH_ACT_NACK is received in WAIT_RR_EST status in
satellite transmission BTS)
 (2)In very early TCH assignment process, the returned cause is
(internal error) CVI_INTERNAL_ERR when channel is being allocated.
 (3)In very early TCH assignment process, the returned cause is
(channel request illegal) CVI_NO_ACCEPT when channel is being
allocated.
 (4)In very early TCH assignment process, no channel is allocated.
 (5)TN_WAIT_CH_ACT timeout in very early TCH assignment process.

TCH congestion
 TCH seizure failures for intraBSC incoming cell handover

measurement point:
 TCH channel allocation fails at intraBSC incoming cell
handover
 TCH seizure failure for interBSC incoming cell handover
measurement point:
 When interBSC incoming cell handover failure message is sent
because there is no TCH channel

TCH congestion
 TCH seizure failure for intracell handover measurement point:
 In the new TCH activation procedure, this item is measured when

the serving cell receives the CHANNEL ACTIVATION NEGATIVE
ACKNOWLEDGE message from the BTS.
 This item is measured if the implementation of intracell handover
procedure fails because the encryption algorithm in Intracell
Handover Request message does not support.
 No response after the timer (internal timer, 5 seconds) timeout
when the serving cell activates the new TCH.
 In intracell handover procedure, When TCH requested but there is
no TCH available in the serving cell, and this leads to the handover
failure. In this case, this item is measured.

TCH congestion
 TCH seizure failures due to A-interface failures measurement

point:
 A interface
− After MSC sends Assignment_Req, if trunk circuit at A-

interface is fault, BSC will return Assignment_Failure
directly.
− In this case, the usually cause is incorrect CIC data
configuration of trunk circuit.

TCH congestion
 TCH seizure failures due to Abis interface and Um interface failures
 Abis interface and Um interface
− 1. TRX board is faulty or performance unstable

− 2. Unbalance of uplink/downlink level for BTS
− 3. Poor quality of uplink/downlink signal caused by interferenc
e
− 4. SDCCH and TCH belong to different TRX board which have
different coverage.

Causes for High TCH Congestion
 Causes for high TCH congestion
 Troubleshooting for high TCH congestion

Causes for High TCH Congestion
 Causes of high TCH congestion rate
 Incorrect configuration of trunk circuit data at A interface

 Co-frequency and co-BSIC lead to TCH assignment failure in handover
 Board fault or unstable performance causes the high congestion rate
 BTS hardware is not properly installed, which causes uplink/downlink
signal level unbalance and TCH congestion.
 The transmitting power of BCCH TRX is too much higher than that of
TCH TRX in the same cell.
 Interference causes the congestion
 TCH assignment failure due to isolated site and complicated topography
result in the high congestion rate

TCH Congestion
 How to locate the causes of high TCH congestion rate
 Analyze the causes of congestion remotely
− 1. Traffic statistics
− 2. Alarm information
− 3. BTS remote maintenance on OMC
− 4. Abis interface message analysis
 Check BTS on-site

TCH Congestion
 Remote analysis 1: traffic statistics
 In “TCH Measurement Function”, check the channels are all busy or not
− If yes, perform load handover or suggest capacity expansion.

− If not, check interference bands 1~5. if the cause is interference, the
call drop rate of the cell will also be high.
 Register “Receiving Level Measurement Function”
− 1. Check the result by object to see whether the numbers of uplink

and downlink reports on the same TRX board are balanced. So we
can know the uplink and downlink are balanced or not.
− 2. Check the result by time to see whether TRX measurement
reports are excessive. So we can know the congestion is related to
TRX board or not .

TCH Congestion
 Remote analysis 2: alarm information
 Check alarms of the site which has high congestion rate.

 Check whether there is any abnormal alarm, such as
voltage standing wave rate alarm, PCM out of frame alarm
and uplink data bus alarm. Judge whether the congestion
rate is associated with alarms in traffic statistics .

TCH Congestion
 Remote analysis 3: BTS remote maintenance on OMC
 On the BTS remote maintenance console, block TCH board

in turn. Observe whether the congestion rate is related to
the TRX board.

TCH Congestion
 Remote analysis 4: Abis interface message analysis.
 Trace Abis interface message of the congested BTS, analyze Assignment CMD s
ent on SDCCH
− If the assignment always fails on a specific TRX board, the cause may be one
of the following:
▪ TRX board faulty or performance unstable.
▪ Uplink/downlink unbalance, hardware problem in uplink or downlink.
▪ Bad quality of uplink or downlink signal. Analyze TA value of MS to locate
interference.
− If the assignment fails on the boards of the whole cell randomly, analyze the
measurement reports. The causes may be the following:
▪ The topography in the cell coverage is quite complicated.
▪ There is interference in the whole cell, such as interference from repeater.

TCH Congestion

TCH Congestion
 Check BTS on-site
 Check antenna and feeder for any problem of uplink or

downlink.
 Dial test at the same place to see whether the assignment
failure always occurs in a certain TRX or in the cell
randomly.
 Make driving test to see whether there is abnormal
handover relationship and downlink interference, so as to
find the cause of the congestion rate.
 Search the interference source with a spectrum analyzer.
 Observe whether the topography in the cell coverage is
complex.

Case Study of TCH Congestion
 Cases of TCH congestion
 Case 1: A interface data configuration mistake

 Case 2: TRX board fault
 Case 3: Uplink hardware problem
 Case 4: Downlink hardware problem
 Case 5: Effect from repeater in the cell
 Case 6: Other data configuration mistake
 Case 7: Isolated site and complicated topography

A-interface Data Configuration Mistake
 Case 1 fault description :
 There is one BSC in the local network. From one day, TCH
congestion rate (excluding handover) of the whole network
increase to 4%, and most of cells are highly congested.

A-interface Data Configuration Mistake
 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 1 Troubleshooting:
 1.Analyze traffic statistics. The problem occurs after BSC data modifi
ed and reloaded. Maybe it is related to BSC reloading.
− Analyze traffic statistics and find that the highly congested cells ar
e all on module 1 of BSC, so the problem should related to modul
e 1.
− Check TCH seizure failures (requested terrestrial resource unavai
lable), It shows that unavailability of terrestrial resource is the mai
n cause of high congestion rate in module 1.
− The cause of terrestrial resources unavailability is mainly on Abis i
nterface or A interface. It is quite unlikely that Abis interface is faul
ty for many cells in module 1 at the same time. Therefore, the cau
se should be the hardware or data at A interface.

 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 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 fault description :
 The configuration of a BTS is S6/4/2 and it had been on

service successfully. One day, the result of traffic statistics
shows that TCH channel in cell 1 (6 TRX) congestion rate
comes to 20%.
 The traffic volume of the cell is very low, it is about 0.8Erl in
busy hour.
 At the same time, the times of “TCH seizure failures for call
(no radio resource)” is 0.
 Observe the channel status in cell 1, all of channels are
“Idle”.

TRX Board Fault
 1. No data has been adjusted and there is no hopping in the

cell and 6 TRXs use different frequencies, it is unlikely that t
hey are subject to external interference at the same time. T
herefore, it can not be Um interface interference or data pro
blem.
 2. Check hardware specifically. Since the problem only occ
urs to cell 1, we can block TRX one by one to determine wh
ich TRX causes the assignment failure.
 3.Find whether there is hardware fault in the TRX for assign
ment failure. Confirm the fault TRX by means of resetting a
nd 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
 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 B
TS maintenance console. The problem can be confirmed by
blocking TRXs in turn.

Uplink Hardware Problem
 Case 3 fault description:
 A certain BTS configuration is S6/6/6, the congestion rate of

the 3 cells are all high since the BTS on service. Having
checked and confirmed that there is no interference.

 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.

 Register traffic statistics “Receiving Level Measurement Fu

nction” and query the result by time. It is found that when th
e receiving level and quality of different TRX boards in the s
ame cell are the same, the number of downlink measureme
nt reports is equivalent, but the number of uplink measurem
ent reports is not equivalent.
 Check hardware and find that the connection of TRX and C
DU in the same cell is incorrect. After correction, the proble
m is solved.

Case 3
Times of uplink Times of uplink Times of Uplink
receiving level receiving level receiving level rank
rank 0 and rank 0 and
receiving receiving quality 0 and receiving
quality rank 0 rank 1 quality rank 2
30 minutes starting from
11:00 18-3-2001
Module ID 1, Cell ID 5, 2 0 7
TRX No. 12
TRX No. 13
TRX No. 14
TRX No. 15
Module ID 1, Cell ID 5, 294 46
TRX No. 16 166
Module ID 1, Cell ID 5, 142
TRX No. 17 222 58

 Incorrect hardware connection will cause TCH seizure failur

e. The problem can be located accurately by analyzing traffi
c statistics. In this case, uplink hardware receiver problem i
s located through “Receiving Level Measurement Function”.

Downlink Hardware Problem
 In a S6/6/5 BTS, one cell has high congestion rate one day.
No adjustment has been performed in this period.

 There is no parameter adjustment before the fault, so we

should focus on the hardware, to see whether there is any
fault or alarm.

 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.

 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
 When an O2 BTS is expanded to O4, high congestion rate

occurs. The peak value of congestion rate is as high as
40%.

 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.

 Block TRX of the last two newly added TRX on OMC and find that the co
ngestion 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 tha
t the level on SDCCH is normal and TA value is large. However, there is
no measurement report on SACCH (TCH). Because sometimes the assig
nment 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 rep
eater did not lock on the two newly added TRXs. Confirm and reconfigure
repeater, problem solved.

 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
 In network optimization, the congestion rate (including

handover) on busy hours of the two cells is as high as 10%.
“TCH seizure failures excluding handover” and “TCH
seizure failures for call (no radio resource)” are normal.
Here, “TCH seizure failures (all)” is very high, 89 times and
61 times respectively, but “TCH seizure failures for MOC” is
0”.
 The traffic volume is a little lower than that before
optimization.
 The interference band is normal.
 Congestion rate is normal before optimization.

 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.

 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.

 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
 An O2 site in a suburban county has suffered from high

congestion rate (excluding handover), from 3% to 10% (in
proportion to traffic volume). But the “TCH seizure failures
for call (no radio resource)” is 0%.
− 1. Block 2 TRX in turn, the congestion rate is serious as
before.
− 2. Other indexes: call drop rate is high (about 5%).
Interference band is normal.

 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.

 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.

 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.

Chapter 1 TCH congestion
Chapter 2 SDCCH congestion

SDCCH Congestion
 SDCCH congestion
 Basic principle
 Causes for SDCCH congestion and solutions
 Case study of SDCCH congestion

SDCCH Congestion
Formula for SDCCH congestion rate:
SDCCH congestion rate=Attempted SDCCH seizures meeting a

SDCCH blocked state /Attempted SDCCH seizures (all)
Causes of SDCCH seizure:
SDCCH assignment for MOC

SDCCH assignment for MTC
Location update
SDCCH handover
Short message
IMSI attach and detach

SDCCH Congestion
MS BTS BSC MSC
Channel Request (RACH)

Channel Required
BSC random access – immediate assignment
Cell SDCCH seizure request times
Cell immediate assignment request times
Attempted SDCCH seizures meeting a SDCCH blocked

state (No SDCCH available)
Cell SDCCH seizure failure BTSS008015
Immediate Assignment Command
Immediate Assignment Reject

Causes for SDCCH Congestion and Solutions
 Location area border results in excessive location update and

SDCCH attempt
 Optimize for location area design
 Modify CRH (Cell Reselect Hysteresis)
 Modify T3212 for BSC period location update
 Solve frequent handover problem between dual-band
network
 Excessive short messages
 Add SDCCH channel

 Enable dynamic SDCCH allocation function

SDCCH Congestion
 Insufficient system capacity, lack of SDCCH channels
 Expansion for more TCH and SDCCH channels

 More SDCCH should be added
 Improper configuration of system parameters, RACH system
parameter.
 Increase RACH access threshold (overcoming
interference).
 Decrease maximum re-transmitting times and increase
extended transmission timeslots
 Board (TRX) fault and transmission fault result in SDCCH
congestion

Case Study of SDCCH Congestion
 SDCCH congestion cases
 Case 1: Too many times of location update

 Case 2: Transmission equipment board fault
 Case 3: Transmission timeslot multiplexer problem

Too Many Times of Location Update
 In a network, the radio link call setup successful rate is low.

Analyze the traffic statistics and find that SDCCHs congest
in a few sites.

 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.

 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.
 2. Add SDCCH or enable SDCCH dynamic allocation function, problem
solved.

 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
 After a new BTS30 is on service, SDCCH channels are all

in status “A”, TCH channels are in “I” or “A”. When the call
is connected, the communication is normal. Observe the
traffic statistics and find that SDCCH seizure failure times
are more than 1000 (in busy hour).

 Since SDCCH is congested after BTS is on service, but communicatio
n is normal.
− First check data and hardware. Because the whole site suffers fro
m congestion problem, interchange Abis link with another BTS (whi
ch 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.

 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.

 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

 Many complaints from subscribers it is difficult to make a call through
4 sites (ABCD), but there are no related alarm information.
− Check the 4 sites, the board status are all normal. Almost no TCH
channel is seized successfully. Sometimes one TCH status is “A”,
but return to “I” within several seconds.
− Operator engineer said that BTS-A was attached with BTS-B, BT
S-C and BTS-D, these 4 BTSs used a primary combiner (a trans
mission timeslot multiplexer) and shared one EI .

 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.

 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.

 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.

 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.

Thank You
www.huawei.com

OMF000405 Case - Ysis-Congestion ISSUE1.4

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

OMF000405 Case - Ysis-Congestion ISSUE1.4

Uploaded by

Copyright:

Available Formats

Internal

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved

 31160978-BSC Traffic Statistic

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 2

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 3

Chapter 2 SDCCH congestion

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 4

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 5

 Basic principle of TCH congestion

 Definition of TCH congestion rate

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 6

 Definition of TCH congestion rate

 TCH congestion rate (excluding handover)

=(TCH seizure failures for call + TCH seizure failures for

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 7

 Definition of TCH Congestion rate

 TCH congestion rate (including handover)

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 8

MS call flow as the caller

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 9

 Attempted TCH seizures for call

− Receive the MSC assignment request message

− When intraBSC incoming cell handover request message is received (non-

− When interBSC incoming handover request message is received (handover

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 10

 TCH seizure failures:

 TCH seizure failures for call,

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 11

 TCH seizure failures for call measurement point:

 (1)CONN_FAIL message is received in process of assignment.

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 12

 TCH seizure failures for call measurement point:

 (7) HO_FAIL is received in outgoing BSC handover (direct

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 13

 TCH seizure failures for very early assignment measurement point:

 (1)CH_ACT_NACK is received in the very early TCH assignment

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 14

 TCH seizure failures for intraBSC incoming cell handover

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 15

 TCH seizure failure for intracell handover measurement point:

 In the new TCH activation procedure, this item is measured when

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 16

 TCH seizure failures due to A-interface failures measurement

− After MSC sends Assignment_Req, if trunk circuit at A-

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 17

 TCH seizure failures due to Abis interface and Um interface failures

 Abis interface and Um interface

− 1. TRX board is faulty or performance unstable

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 18

 Causes for high TCH congestion

 Troubleshooting for high TCH congestion

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 19

 Causes of high TCH congestion rate

 Incorrect configuration of trunk circuit data at A interface

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 20

 How to locate the causes of high TCH congestion rate

 Analyze the causes of congestion remotely

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 21

− If yes, perform load handover or suggest capacity expansion.

− 1. Check the result by object to see whether the numbers of uplink

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 22

 Remote analysis 2: alarm information

 Check alarms of the site which has high congestion rate.