Inter-RAT Failure with Cause: Physical Channel Failure

Well, I have seen this more than enough. Tried to dig left and right in 3gpp and read more than thoroughly in 25.331 hoping to find a clue. What on earth is a "Physical Channel Failure" that causes the 3G-2G Inter-System handover to fail? Even worse, at such bad conditions of UTRA FDD carrier, when the handover fails, UE will go back to 3G, which apparently has very bad quality and strength hence the handover originally, and drop the call. After digging in 3rd party documents, it turns out that with more UMTS Measurement Reports within the compressed mode, RNC will be sending UE more Measurement Control messages to inform UE which new 2G neighbors should be measured. Poor UE, startled with a huge list of neighbor modification by addition or removal stops measuring old GSM list and starts new GSM list. Even more, UE in one stage maybe referring to measurement for inter-RAT neighbor [2] for example, which is no longer neighbor [2] at the RNC side (UE was too slow to cope up with the continuous update of the neighbor list). Here only would you see the Handover Command from UTRAN Failure message with such a cause. In order to fix this issue, the solution is this: 1- Go easy with your 2G neighbor list, do not put a list of 32 neighbors. That would be huge. Put your first tier 2G neighbors and that should be enough. 2- Try to make sure UE does not send any intra-frequency measurement events during the compressed mode. Things I tried were to make sure that the Weight is 0 so you always measure with respect to your best cell. Minimize the compressed mode window, not more than 3 dB. Make sure that your event 3a time to trigger is 0. You can also try to delay event 1b time to trigger and change event 1a time to trigger to 0.

//////////////////////////////////////////////////////////////////////////////////////////////////////////
Webmaster, The reason why sending intrafreq measurements would case this is because your active set cells will keep changing. Therefore, a new IRAT neighbor list modification will be requested from the RNC (by means of RRC Measurement Control). As you know, a measurement control message will enumerate all the neighbors in an ordered fashion. Say for example that when you were in UMTS cell A, your GSM neighbors were: [0] Cell_X: NCC 0; BCC 1; ARFCN 128 [1] Cell_Y: NCC 2; BCC 3; ARFCN 138 [2] Cell_Z: NCC 0; BCC 5; ARFCN 129 You are in compressed mode and hence you will be sending in your RRC Measurement Report Message something like: Event 3a. BSIC[0]. GSM RSSI = -100 dBm.

But, unluckily, you come across a new UMTS cell B, whose GSM neighbors are different from the list above, then the RNC would send a new Measurement Control message informing the UE of a new list of cells to measure. This is almost guaranteed that this list will have different NCC, BCC, ARFCN for the same enumeration, e.g.: [0] Cell_T: NCC 7; BCC 2; ARFCN 28 [1] Cell_Y: NCC 5; BCC 5; ARFCN 38 [2] Cell_Z: NCC 2; BCC 2; ARFCN 29 So from a UE standing point, the physical channel on GSM is now different than what it ought to measure. Consequently, when the UE sent its measurement report: Event 3a. BSIC[0]. GSM RSSI = -100dBm. When the RRC Handover Command from UTRAN is sent to the UE with the "incorrect" NCC, BCC, and ARFCN of cell [0]obviously due to the frequent changes of inter-RAT neighbor list due to the frequent changes of intrafrequency neighbors, then UE complains with the RRC Physical Channel Failure after its failing attempt to sync up with GSM. That is the answer in a nutshell. It should be clear by now.

EJEMPLO NQDI

La lista de vecinos varia constantemente el UE es lento para procesar y enva informacin desactualizada, al final el HO Falla