:

Internal only

Autho
r
Depar
tment
Updat
e
Time
Appro
ver
Title
Pheno
menon
Descri
ption:
Alarm
Inform
ation
Cause
Analysi
s

Gao Bo

Staff Number

40827

UMTS RNP

Product Family:

Wireless Performance &

RNP & RNO

2010-06-01

Product Vension:

RNC R10B061

Analysis for Call Drop due to SRB Reset & TRB Reset

The problem is that there are many sites have the problem of SRB reset
and TRB reset increased.
None

For this problem, we choose the top cells of the RNC 12 and RNC 21 to
analyze the reason of SRB & TRB reset.

From the analyses of the cell CDT and IOS, We can know that UE was
doing HSDPA traffic .It did hard handover from one cell to another cell. But
after hard handover completed, imminently, UE did hard handover back, this
is the ping-pong phenomena. It is easy to result in radio link lost and the
increase of TRB/SRB Reset.For the downlink quality changed so fast, it is
abnormal. And this is usually because that the CELLs parameter or cells
coverage is unreasonable. And the same phenomena also can find in the cells
with ID 19945 ,19871, 10424 ,10484,10926 10987.
From the trace, we can see that the UE hand over from cell 19945 to
cell 19874 , but after 2 seconds, it delete the link of 19874. It is so
fast, and the RL was out of synchronization, then the call drop occurred.

2015-5-8

1 , 8

 :
Internal only

From
the
measure
report,
we
can
see
that
the
cell
19874(PSCRAMBCODE=434) has a better EC/NO, then the 1A event happened
successfully.

2015-5-8

2 , 8

 :
Internal only

But after 2 seconds, the EC/NO changed so fast and the RL of the cell
19874 was deleted.

2015-5-8

3 , 8

 :
Internal only

Then the RL was out of synchronization. And the SIR-Error value of the
Uplink is so bad. The call drop occurred.

And there are many ping-pong phenomena as below: From the trace we
know that the UE hand over from 19944 to19945, then immediately, hand over
back to 19944.It cost only 1 or two seconds. This is unreasonable. It is
easy to result in radio link lost.
2015-5-8

4 , 8

 :
Internal only

From the CDT and IOS, we can find the other problem caused the call
drop, for example, the bad downlink quality and the neighbor cell not
configured. If in some position the downlink quality is bad, and the
neighbor cell has not been configured, the call drop will occurred easily.
1) Neighbor cell not configured
For cell 19945, from the IOS trace, we can see that it has the problem
of neighbor cell not configured. Just as the cell 11063 we analyzed before.
From the IOS, the uplink has been out of synchronization, and from the
RRC_MEAS_RPRT, we can see that the downlink of cell 19945(PSCRAMBCODE=490) is
bad, and the UE has reported the event of 1A, but from the RNC configuration file, we
cant find the neighbor cell of 19945 whose PSCRAMBCODE is 216. And if the cell the
UE detected (PSCRAMBCODE=216) is configured as the neighbor cell of 19945, this
call drop will not occurred. This is a coverage problem, and we need to solve it.

2015-5-8

5 , 8

 :
Internal only

2) Downlink bad
For the cell 10994, it has many times of TRB reset and UU No reply,
we have collected the logs to analyze the reason.
There are many call drop procedures as below: After the UE goes to FACH
then call drop occurred.

We can see that the UE want to go to the DCH, but From the RRC_MEAS_RPRT
we can find the EC/NO is bad now which means the downlink is bad, and the UE
would not receive the message of RRC_RB_RECFG. Then the Call Drop occurred.
2015-5-8

6 , 8

 :
Internal only

And from the RRC_MEAS_RPRT, we cant see any other cells that the UE can
detected.

And we can see as below: If the downlink is good, the UE will go to DCH
successfully.

It can be solved by optimizing the parameter and the coverage of the

network.
Handli
ng
Process

Sugges
tions
and
summa
ry

The ping-pong phenomena is abnormal, and the logs shows that the
call drops were due to the coverage of cells and the parameters configured.

2015-5-8

7 , 8

 :
Internal only

Attach
ments

Relate
d
docum
ent
link

2015-5-8

8 , 8