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

[pradeep]

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.

[Ashish_Satasiya]

If second cell not available then it will block PLMN.

[sadanandk2]

@pradeep

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.

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?

For LTE, when t3402 timer come into picture?

Hi Experts. For LTE, when t3402 timer come into picture?

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?

@Ashish_Satasiya

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.

Any literature explaining this?
If it is the case then some urgent action required for me. Please confirm.

[RFSpecialist]

@pradeep

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.

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.

[sadanandk2]

Yes, I agree.

[RFSpecialist]

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.

[PULI_RAJU]

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

5G NR RRC Timers, Counters and Constants - RRC Signalling

[pradeep]

@RFSpecialist

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.

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

[RFSpecialist]

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

[ankgitm]

Yes no link with RACH procedure.
In my view after continuous rach fail on same cell ue can barr that cell as well.

[pradeep]

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.

[sadanandk2]

Yes @pradeep, initial attach is also part of my query.

@pradeep

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

This answer is pretty convincing for initial attach.
For normal rach (eg. Idle to connected mode) query still remains.

[RFSpecialist]

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.

[pradeep]

@RFSpecialist

Sent means Ue managed to send attach request at NAS layer, not the RACH procedure.

Sent actually means “Sent by the NAS layer to the lower layers”. Doesn’t have to be OTA.

[Jaeku_Ryu]

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

[RFSpecialist]

Actually it says attach failure.
That means attach request was sent and answer received.
Attach reject or failure.

[sadanandk2]

@RFSpecialist

According to the specs: T3402 is started when 5 attach request were sent by UE.

T3402 actually stops when attach request (rrcsetup complete, msg5) is sent by UE.

[RFSpecialist]

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.

[sadanandk2]

@pradeep

Sent actually means “Sent by the NAS layer to the lower layers”. Doesn’t have to be OTA.

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

[ankgitm]

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