If there is no RAR response from eNB/gNB will UE keep sending msg1 till preambleTransMax?

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.

Here you can also find related timers in 5G NR: (thanks @Tech_Playon)

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.

I hope this would give some more intuition : 4G | ShareTechnote

1 Like

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.

T3402 starts when: At attach failure and the attempt counter is equal to 5.
At tracking area updating failure.
And the attempt counter is equal to 5.

One thing: How UE get this timer value if it has not yet attached?

I think it’s part of attach accept message this timer.
Conversation now mix NAS with MAC failure.