case analysis congestion issue1 4

8/13/2019 Case Analysis Congestion ISSUE1 4

1/77

OMF000405 Case Study -

Congestion ISSUE1.4

Wireless Training Department


2/77

TCH congestion

SDCCH congestion

Course Contents


3/77

TCH congestion

TCH congestion

Basic principle

Causes for high TCH congestion

Case study of TCH congestion


4/77

TCH congestion

Basic principle of TCH congestion

Definition of TCH congestion rate

Measurement point for TCH congestion and analysis


5/77

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%


6/77

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)


7/77

TCH congestion

TrafficMeasurement

Pointof

TCHCong

estionrate

Channel_Active

Channel_Active_Ack

IMMEDIATE ASSIGN COMMAND

BTS BSC MSCMS

Channel_Req

first SABMEstablish_IND( CM Service Req)

CR(Complete_l3_information)

CC

Setup

Call Proceeding

Assignment_Req

ASSIGNMENT COMMAND

first SABM Establish_IND

ASSIGNMENT CMP Assignment_CMP

Alerting

Connect

Connect Ack

Communication

Disconnect

Release

Release Complete

Clear_CMD

Clear_CMP

CM Service Accepted

Channel_Active

Channel_Active_Ack

UA

SDCCH

SDCCH

SACCH(TCH)

SACCH(TCH)

MS call flow as the caller


8/77

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)


9/77

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


10/77

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


11/77

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


12/77

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


13/77

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 handovermeasurement point:

When interBSC incoming cell handover failure message is sent

because there is no TCH channel


14/77

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.


15/77

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


16/77

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 interference

4. SDCCH and TCH belong to different TRX board which have

different coverage.

TCH congestion


17/77

Causes for high TCH congestion

Troubleshooting for high TCH congestion

Causes for High TCH Congestion


18/77

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


19/77

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


20/77

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


21/77

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


22/77

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


23/77

Remote analysis 4: Abis interface message analysis.

Trace Abis interface message of the congested BTS, analyze

Assignment CMD sent 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


24/77

TCH Congestion


25/77

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.

TCH Congestion


26/77

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


27/77

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


28/77

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.

A-interface Data Configuration Mistake


29/77

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.



30/77

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.



31/77

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.



32/77

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 TCHseizure failures for call (no

radio resource)is 0.

Observe the channel status in cell 1, all of channels are Idle.

TRX Board Fault


33/77

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.


34/77

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.


35/77

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.


36/77

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.

Uplink Hardware Problem


37/77

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.



38/77


Register traffic statistics Receiving Level Measurement

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



39/77

Case 3

14258222

16646294

293105655

501

303

702

Times of uplink

receiving level

rank 0 and

receiving

quality rank 0

Times of uplink

receiving level

rank 0 and

receiving quality

rank 1

Times of Uplink

receiving level rank

0 and receiving

quality rank 2

30 minutes starting from

11:00 18-3-2001

Module ID 1, Cell ID 5,

TRX No. 12


TRX No. 13


TRX No. 14


TRX No. 15


TRX No. 16


TRX No. 17



40/77

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 ReceivingLevel Measurement Function.



41/77


In a S6/6/5 BTS, one cell has high congestion rate one day. No

adjustment has been performed in this period.

Downlink Hardware Problem


42/77

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.



43/77


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.



44/77

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.



45/77


When an O2 BTS is expanded to O4, high congestion rate

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

Effect from Repeater in the Cell


46/77

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



47/77


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.



48/77

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.



49/77


In network optimization, the congestion rate (including handover)

on busy hours of the two cells is as high as 10%. TCHseizure

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 MOCis 0.

The traffic volume is a little lower than that before optimization.

The interference band is normal.

Congestion rate is normal before optimization.

Other Data Configuration Mistake


50/77

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.



51/77


Register IncomingInter 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.



52/77

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.



53/77


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.

Isolated Site and Complicated Topography


54/77


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.


55/77


Check CallDrop Measurementand 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.


Si C i


56/77

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.


C C


57/77

TCH congestion

SDCCH congestion

Course Contents

SDCCH C i


58/77

SDCCH Congestion

SDCCH congestion

Basic principle

Causes for SDCCH congestion and solutions

Case study of SDCCH congestion

SDCCH C ti


59/77

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 C ti


60/77

SDCCH Congestion

MS BTS BSC MSC

BSC random access immediate assignment

Cell SDCCH seizure request times

Channel RequiredChannel Request (RACH)

Cell immediate assignment request times

Cell SDCCH seizure failure BTSS008015

Attempted SDCCH seizures meeting a SDCCH blocked state

(No SDCCH available)

Immediate Assignment Command

Immediate Assignment Reject

C f SDCCH C ti d S l ti


61/77

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

Causes for SDCCH Congestion and Solutions

SDCCH C ti


62/77

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

SDCCH Congestion

C St d f SDCCH C ti


63/77

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

T M Ti f L ti U d t


64/77


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.

Too Many Times of Location Update

Too Man Times of Location Update


65/77

Case 1 analysis:

Since only a few BTS are congested, register SDCCH

Measurement Functionand analyze the ratio of SDCCH seizure

for different causes, then we can find the real reason for SDCCH

congestion.




66/77

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




67/77

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


68/77


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




69/77

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.




70/77

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




71/77

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


72/77


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 Iwithin several seconds.

Operator engineer said that BTS-A was attached with BTS-B, BTS-

C and BTS-D, these 4 BTSs used a primary combiner (a

transmission timeslot multiplexer) and shared one EI .

Transmission Timeslot Multiplexer Problem



73/77

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.




74/77


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.




75/77


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.




76/77

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.



77/77

case analysis congestion issue1 4

Documents