Rach attempt increase to millions times

[kentck86]

Hi Guys,

Kindly please advises if anybody expriencing Rach att ( small,large,dedicated messages) suddenly spike and back to normal? This happens to me in Nokia equipment RL60, with these spike causing Rach kpi fluctuating. Anybody have any idea whats the actual issue might be?

thank you

[webkasperl]

Hi,

if the RACH success rate goes down, this could be because the cell size is toobig, so either antenna tilt is not enough or cell range parameterization is too small for the big area, which is covered. You can try to increase the cell range.

Regards

[sak2e]

Hi kentck86,

It happen in whole network or several sites? If only few sites you can check consictency of all parameter related PRACH : PRACH freq offset, cyclic shift and configuration index. make sure also there is no overshooting issue & co-RSI near the worse cell.

BR
Yoyokdp


Hi Guys,

Kindly please advises if anybody expriencing Rach att ( small,large,dedicated messages) suddenly spike and back to normal? This happens to me in Nokia equipment RL60, with these spike causing Rach kpi fluctuating. Anybody have any idea whats the actual issue might be?

thank you

[marcengo]

I saw similar behavior once in an E// network. That time it was a maximum RRC_CONNECTED license limitation which was creating rejections, thus creating a tsunami of re-attempts and RACH messages.

In NOKIA, try to see the maxNumActUE, addAUeRrHo, addAUeTcHo, maxNumActDrb, etc..

[kentck86]

Hi Guys,

thanks for the feedback, there is no overshooting, no parameter discrepancies and it happens occassionally in some sites. checked some BTS founded there is some ghost rach detected, tried to change possible co-RSI in the detected TA range. will update if the performance gain better. Did you guys experience this?

thank you

[linhhy]

How about your result. I think Random access success rate (RASR) quite crazy. As analysis from Nokia: Only a single root cause (PDCCH Blocking) is specified although successful transmission of the Random Access Response (RAR) relies upon PDCCH, PDSCH and PUSCH scheduling. PDSCH and PUSCH scheduling are less likely to cause blocking of the RAR. The PDCCH is most likely to cause blocking for smaller channel bandwidths and when only a single symbol is allocated to the PDCCH (dynamic allocation of symbols is likely to allocate a single symbol during periods of low traffic).

In our network some cells having less traffic still have vary unstable RASR.

[marcengo]

I agree with you in all senses. I`m seeing the same bizarre behavior in a RL50 network. PRB utilization below 10% no average, but still bad RASR. I sill havent found any particular cause by counters (which are absolutely limited in RL50), the next step will be collecting logs.


How about your result. I think Random access success rate (RASR) quite crazy. As analysis from Nokia: Only a single root cause (PDCCH Blocking) is specified although successful transmission of the Random Access Response (RAR) relies upon PDCCH, PDSCH and PUSCH scheduling. PDSCH and PUSCH scheduling are less likely to cause blocking of the RAR. The PDCCH is most likely to cause blocking for smaller channel bandwidths and when only a single symbol is allocated to the PDCCH (dynamic allocation of symbols is likely to allocate a single symbol during periods of low traffic).

In our network some cells having less traffic still have vary unstable RASR.

[rosan]

Are you guys referring the KPI equivalent to msg3/msg1 or msg2/msg1?

Sent from my SM-N920I using Forum Fiend v1.3.3.

[rosan]

Because the KPI equivalent to msg3/msg1 which is LTE_1056d have some bugs and a new KPI replace it in RL70. Connected modr DRX will impact this KPI.

Sent from my SM-N920I using Forum Fiend v1.3.3.

[kentck86]

Because the KPI equivalent to msg3/msg1 which is LTE_1056d have some bugs and a new KPI replace it in RL70. Connected modr DRX will impact this KPI.

Sent from my SM-N920I using Forum Fiend v1.3.3.

Hi Rosan,

What is the new KPI said to replace this in RL70 and the KPI formula is?

thank you

[rosan]

LTE_5670a

Sent from my GT-I9507 using Forum Fiend v1.3.3.