I think that’s more hypothetical.
If Continuous RACH fails and it will try other EARFCN of that cell I believe.
When there is no msg2 response, UE can send 5 RACH attampts each seperated by a specific NAS timer. Each RACH attempt contains a cluster of MSG1 requests allowable by RACH parameters.
After the failure counter reaches 5, NAS layer will start T3402 and block that PLMN.
From the network if back off indicator timer configure then UE will re for Rach else UE will check for second priority cell from initial search table.
So, subsequent attempts on a cell with same PLMN while T3402 is running at UE are not possible.
This timer is for LTE.
I am sure there is a similar NAS timer for this usecase for SA.
If second cell not available then it will block PLMN.
When does T3402 start?
At msg1 or msg3?
I think at msg3.
If it is, then t3402 may not come in to picture because we are failing at msg2?
If it is NAS timer, it may start even before msg1?
I referred above topic. Someone it is given in attach accept. If UE not even attached to nw it has not received attach accept then howbit will get t3402?
Any literature explaining this?
If it is the case then some urgent action required for me. Please confirm.
I think this 5Stuff is only for attach reject or for registering procedures not for regular traffic.
And is for 5 attach request nas messages not for 5 rach.
Ordinary rach.
Yes, I agree.
So T3402 is a NAS timer and is not related to MAC procedures of rach.
My opinion is that if RF conditions do not change ( so a better cell to come up) then UE will not try RACH many times untill it reaches periodic TAU update time.
At that point it will try to send RACH indefinite till it will empty the battery.
Unfortunately, I have to disagree with this. When RACH attempt fails (after exhausting all MSG1 attempts in one RACH attempt), lower layers declare RRC connection failure to NAS. After receiving 5 such failure indications, NAS has to block that PLMN and start T3402. The behavior is driven by the NAS spec itself.
Of course, there are other use cases that lead to the start of this T3402 but this is also one of those procedures
T3402 is related to NAS procedures, it has nothing to do with rach on MAC layer for traffic.
His question was about ordinary RACH not about RACH for attach request.
Again, with @Jaeku_Ryu help (ShareTechNote):
https://www.sharetechnote.com/html/Handbook_LTE_Timer_EPS_UE.html
T3402 start at attach failure not at RACH failure
Yes no link with RACH procedure.
In my view after continuous rach fail on same cell ue can barr that cell as well.
I think @sadanandk2 asked the question for initial access (correct me if I am wrong).
In initial access, NAS layer at UE triggers attach request.
This will trigger the RACH request at MAC.
Each RACH failure is counted as attach attempt failure at NAS level.
When this failure count reaches to 5, NAS will start T3402.
This is not just my understanding, but some operators have the conformance TCs to test this behavior.
Yes @pradeep, initial attach is also part of my query.
This answer is pretty convincing for initial attach.
For normal rach (eg. Idle to connected mode) query still remains.
According to the specs: T3402 is started when 5 attach request were sent by UE.
Sent means Ue managed to send attach request at NAS layer, not the RACH procedure.
@ran_core_consultant maybe you can better explain what is T3402 and the fact that it has nothing to do with RACH procedure.
Sent actually means “Sent by the NAS layer to the lower layers”. Doesn’t have to be OTA.
Actually it says attach failure.
That means attach request was sent and answer received.
Attach reject or failure.
T3402 actually stops when attach request (rrcsetup complete, msg5) is sent by UE.