Hello All.
We have set in some cases preamble as -116.
We have contention base cases for initial access and handovers.
Is it too high for msg1 to send request?
Hello All.
We have set in some cases preamble as -116.
We have contention base cases for initial access and handovers.
Is it too high for msg1 to send request?
-104 could be used.
-116 is too low.
I think preamblereceived target power can be anything between -110 dBm and -104 dBm
It is useless to have RACH success at -116 dBm if RRC will fail later.
What is the drawback?
And we have 16 preamble only and ct resolution timer as sf16.
-116 may increase the cell range in some locations.
-104 may shrink it but will offer good service with good KPIs.
They say it will improve RACH, but how?
Coverage will shrink you mean?
But in DT I am seeing msg 2 failures
Mainly where RSRP is -110, -115 and sometimes it is not able to trigger a3.
Only MR goes.
I have both initial access and handovers as contention based.
Why it is not able to trigger a3 then?
In some cases mainly epsfallback.
Can you share all your RACH parameters here?
And cbra should only be used in handover.
If you dont have any preambles so assign some for cfra first.
Our product does not support cfra.
In 5G SA.
This is the main drawback.
Ok, got it.
ct resolution is sf16 and we have 16 preambles.
Can we increase ct resolution timer?
It is not about ct resolution timer
Don’t you get msg2?
So raresponsewindow parameter should be checked first.
Find it from SIB1.
Window size is s110.
But fails happening after RRC request.
I have two cases one is rapid mismatch and another is ct expiry.
Sometimes my serving is -95 and neighbor is -75 , measurement goes no a3 trigger.
Sometimes rrc request is also seen in some times.
RACH ct expiry seen in both initial access and handovers.
Pramble target recoeved power by itself may not be very critical paramter for msg1 suceess as UE will perform power ramp if msg2 is not recieved
The important is message 3 so the sum of Pramble target power + msg 3 offset is what you should consider
Ok got it.
I would follow those steps:
Check msg1frequencystart and prachconfindex (if there is any conflict in the cells of the overlapping area)
Make sure neighbour is defined
Make sure rootsequenceindex is not the same in the overlapping area.
RSI mismatch is seen, ANR is there.
RSI sequence mismatch seen.
As wrong PRACH RSI configuration in event root cause.
After that mcg wrong to ho cell.
I told you -116 is too low for initial RAC attempt.
Yes, I agree -116 is very low.
Even I believe last value should be -108, and we are doing this in city.
@parkarnadeem86
Which frequency band?
Rapid mismatch could happen due to doppler shift if UE is moving fast