: Internal only

AuthorGao BoStaff Number40827

DepartmentUMTS RNPProduct Family:Wireless Performance & RNP & RNO

Update Time2010-06-01Product Vension:RNC R10B061

Approver

TitleAnalysis for Call Drop due to SRB Reset & TRB Reset

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

Alarm InformationNone

Cause AnalysisFor 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.

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

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

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.

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

2) Downlink badFor 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. 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.

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

Suggestions and summary

Attachments

Related document link

2015-5-81, 8