Timer T3411 is used during the Attach Procedure and Tracking Area Update (TAU) Procedure to manage retries when the UE encounters issues such as network failures, rejected messages, or failed attempts. T3411 ensures that the UE does not retry excessively and provides a structured mechanism for initiating reattempts after a predefined waiting period.

Similarly, Timer T3402 is used when the retry limit for T3411 has been reached (typically after 5 failed attempts). T3402 introduces a longer backoff period before the UE can retry the Attach or TAU procedure. This timer is particularly important for mitigating signaling congestion on the network by spreading out retry attempts over time. The duration of T3402 is determined by the network and is communicated to the UE via the Attach Accept, TAU Accept or Attach Reject messages.

Together, T3411 and T3402 ensure a balanced and efficient retry mechanism:

• T3411 manages immediate, short-delay retries to quickly recover from transient issues.
• T3402 enforces a longer waiting period after multiple failures to avoid excessive signaling and allow the network to stabilize.

These timers work in tandem to optimize retry behavior, protect network resources, and enhance the overall user experience.

Timer T3411 is crucial for:

• Managing retries in a controlled manner to avoid overloading the network with frequent attempts.
• Introducing a delay before retries to allow the network to recover from transient issues.
• Structuring the UE’s behavior to comply with operator policies and regulatory requirements for retry mechanisms.

Timer T3402 is crucial for:

• Introducing a longer backoff period after multiple failed retries to prevent network congestion.
• Spacing out retry attempts to optimize resource usage and reduce signaling load.
• Allowing the network sufficient time to recover from overloads or issues.
• Aligning retry behavior with network operator policies and configurations.
• Enhancing the likelihood of successful retries by ensuring appropriate waiting times.

T3411 and T3402 can be illustrated as below (Refer to UE EPS Timer page for formal description in 3GPP). Based on the specification, the default value of T3411 is 10 seconds and N (number of reties) is 5, but as far as I tested various devices, these values seems to vary depending on device implementation. However, T3402 seems to be quite consistant (12 min by default). When you are testing this with test equipment, it would be important not to send RRC Connection Release before T3411 expires. If Network (Test requipment) send RRC Connection Release before T3411 expires, the counter value (N) may get to be initialized back to 0 and you may not get the expected result.

The diagram below shows an attach that never succeeds. The UE sends Attach Request, gets no useful answer, and waits for T3411 before it sends the next one. After N attempts it waits for T3402 instead, and then it sends Attach Request again.

T3411 spaces the attempts inside one cycle, and T3402 spaces one cycle from the next. Both timers run in the UE, although the drawing puts the T3411 bracket on the network side.

NOTE : Check out this tutorial in Amarisoft Tech-Academy on how to test T3402.

• UE and NW : the two vertical lines. Every arrow in the drawing is an Attach Request from the UE to the network.
• T3411 : the short bracket at the right. It starts when the attempt fails and ends at the line marked Expires. The drawing leaves out T3410, which normally runs first and whose expiry is one of the failures.
• Repeat N times : the red loop at the left. With the 24.301 counter, N is 5 attempts in total, and four T3411 periods separate them.
• T3402 : the long arrow at the left. It starts after the last failed attempt of the cycle, and its expiry triggers the next Attach Request and a fresh counter.

The sections below go from the basic scenarios to the attempt counter, the signalled T3402 value and the newer rules.

• Key Scenarios Involving T3411
• Key Scenarios Involving T3402
• How does the attempt counter choose between T3411 and T3402?
• How does the network set the T3402 value?
• Which newer rules change the retry timing?
• Reference

Key Scenarios Involving T3411

T3411 is the short retry timer, and it always follows a failure. Let's look at the procedures that start it, the events that stop it, and the limit after which the UE uses T3402 instead. Keep one fact in mind while reading. T3411 is 10 s in 24.301 Table 10.2.1, and the network does not send a value for it in any NAS message.

Attach Procedure:

During attach, the UE starts T3411 only after the attach attempt has failed. The failure can be a lower layer failure, a T3410 expiry, or an ATTACH REJECT with a cause that 24.301 clause 5.5.1.2.5 does not handle by itself. While T3411 runs, the UE is in EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH.

• Start of T3411:
• The UE starts T3411 when:
• The Attach Procedure fails due to network failure.
• The Attach Request is rejected for reasons not considered critical (e.g., EMM cause values indicating retry is allowed).
• The attach attempt counter is less than 5 (indicating retries are still permissible).
• Once T3411 expires, the UE retries the attach procedure.
• Stopping T3411:
• T3411 is stopped if:
• The attach procedure is retried due to expiration.
• The network successfully completes the attach procedure.
• The attach procedure is replaced by another higher-priority procedure (e.g., for emergency services).

In 24.301 terms, the UE stops T3411 whenever it sends a new ATTACH REQUEST. So a retry on expiry and an early attach for emergency bearer services both stop the timer in the same way.

Tracking Area Update - TAU Procedure:

The TAU case mirrors the attach case, but T3430 plays the role of T3410. There is one difference in state. If the current TAI is still in the TAI list and the update status is EU1 UPDATED, the UE waits in EMM-REGISTERED.NORMAL-SERVICE while T3411 runs.

• Start of T3411:
• The UE starts T3411 when:
• A TAU Request fails due to network failure.
• The TAU attempt counter is less than 5.
• The normal or combined TAU procedure needs to be retried after a delay.
• Expiration of T3411:
• When T3411 expires, the UE triggers a retry of the TAU procedure.

Otherwise, the UE sets the update status to EU2 NOT UPDATED and waits in EMM-REGISTERED.ATTEMPTING-TO-UPDATE. Either way, the expiry of T3411 triggers the next TRACKING AREA UPDATE REQUEST.

Abnormal Cases:

Most T3411 starts come from the abnormal-case clauses of 24.301, not from the reject clauses. A reject cause that the specification does not treat one by one falls into these abnormal cases. So the UE handles it as a generic failure and counts it.

• Attach Reject:
• For non-critical EMM cause values, the UE starts T3411 to delay the next attach attempt.
• If the attach attempt counter reaches 5, the UE switches to using T3402 for longer backoff before retrying.
• Lower Layer Failure:
• If the UE detects lower layer failures during attach or TAU procedures, T3411 is started to delay retries.

Retries and Limits:

The limit is not a separate timer. It comes from the attach attempt counter and the tracking area updating attempt counter, which the UE increments on each failure. The section on the attempt counter below shows the count step by step.

• The UE is allowed up to 5 attempts (managed by the attempt counter).
• After 5 failed attempts, T3411 is no longer used, and the UE switches to a longer backoff timer (e.g., T3402) for retries.

Combined Procedures:

A combined procedure can succeed for EPS services and still fail for the other part. In that case the UE is registered for EPS, but it keeps retrying the non-EPS part or the SMS part with the same two timers.

• For combined attach or TAU procedures involving EPS services and SMS:
• If EPS attach is successful but SMS is not accepted, the UE starts T3411 to retry the combined procedure after expiration.

Note which counter the UE uses here. After a combined attach accepted for EPS services only with cause #16 or #17, the UE increments the tracking area updating attempt counter, not the attach attempt counter. The expiry of T3411 then triggers a combined TAU with IMSI attach, not a new attach.

• T3411 always follows a failed attempt : a lower layer failure, a T3410 or T3430 expiry, or a reject cause that the UE treats as abnormal.
• T3411 has a fixed value : it is 10 s, and no NAS message carries a value for it.
• A new request always stops T3411 : the UE stops the timer when it sends ATTACH REQUEST or TRACKING AREA UPDATE REQUEST.
• A combined procedure counts with the TAU counter : the retry after an EPS only result is a combined TAU.

Key Scenarios Involving T3402

T3402 is the long timer. The UE reaches it after five failed attempts, or when a cause value tells the UE to stop counting. Its default is 12 min, but the network can send a different value. So the same UE can wait for different times in different PLMNs.

Starting T3402:

T3402 starts in two ways. The first is the attempt counter reaching 5 after repeated failures. The second is a cause value that makes the UE set the counter to 5 at once. Examples are #19 with some ESM causes and the protocol error causes #95, #96, #97, #99 and #111.

• Attach or TAU Rejection:
• When the UE receives an ATTACH REJECT or TRACKING AREA UPDATE REJECT message with specific causes (e.g., #19 ESM failure or a protocol error cause), T3402 is started based on the value provided by the network.
• Tracking Area Update Attempt Limit Reached:
• If the TAU attempt counter reaches 5 (maximum retries), the UE starts T3402 before initiating another attempt.
• Attach Attempt Limit Reached:
• Similarly, if the attach attempt counter reaches 5, T3402 is triggered to delay further attach requests.

Expiry of T3402:

On expiry, the UE gets a fresh set of five attempts. 24.301 lists T3402 expiry among the counter reset events, in clause 5.5.1.1 for attach and in clause 5.5.3.1 for TAU.

• On expiration, the UE:
• Retries the Attach Procedure or TAU Procedure depending on the scenario.
• Resets the attach or TAU attempt counter, enabling a fresh series of retries.

Network-Indicated Value for T3402:

The value of T3402 is the only part of this retry scheme that the network sends in NAS messages. The section on the T3402 value below lists the messages, the rules for storing the value, and the coding.

• The network can set a custom duration for T3402 in ATTACH ACCEPT, TRACKING AREA UPDATE ACCEPT or ATTACH REJECT messages. If no value is provided, the UE uses a default value.

Behavior During T3402:

While T3402 runs, the UE is normally in an ATTEMPTING-TO-ATTACH or ATTEMPTING-TO-UPDATE substate. It can also choose PLMN-SEARCH to select another PLMN. These substates block normal registration, but they leave a few exceptions open.

• The UE avoids initiating attach or TAU procedures while T3402 is running, except for:
• Emergency bearer services.
• Upper-layer requests for critical data transmission, such as for exceptional events or RLOS.
• The UE may attempt other recovery actions, such as selecting a new PLMN if allowed.

Two more exceptions are worth knowing. A UE configured to use AC11 - 15 may attach even while T3402 runs. And a UE that selects a new PLMN resets the attempt counter and starts a new attach there.

Abnormal Cases:

The two cases below are the ones where a cause value or a lower layer indication decides the timer. Read them with the reject clauses in mind. An ATTACH REJECT or TRACKING AREA UPDATE REJECT with #22 and a valid T3346 value does not use T3402 at all.

• Congestion (EMM Cause #22):
• If the UE receives a combined ATTACH ACCEPT or TRACKING AREA UPDATE ACCEPT for EPS services only with cause #22, T3402 is started immediately to enforce a delay before retrying. A reject message indicating congestion starts T3346 instead.
• Extended Wait Time Ignored:
• In cases where "Extended wait time" is ignored by the UE, and retries are allowed, T3411, or T3402 once the attempt counter reaches 5, ensures proper backoff.

• T3402 starts at the count of 5 : either after five failures, or after a cause that sets the counter to 5 directly.
• The default is 12 min : the network can replace it in ATTACH ACCEPT, TRACKING AREA UPDATE ACCEPT or ATTACH REJECT.
• T3402 expiry resets the counter : the UE then has five more attempts before the next T3402.
• A reject with #22 uses T3346 : T3402 follows #22 only in an accept for EPS services only.

How does the attempt counter choose between T3411 and T3402?

The UE never chooses between T3411 and T3402 from the failure alone. It chooses from a counter. Let's follow that counter through one attach that keeps failing, because the count explains the loop labelled Repeat N times in the T3411 and T3402 diagram.

24.301 keeps an attach attempt counter for attach and a tracking area updating attempt counter for TAU. Each failure from the abnormal cases increments the counter, unless it is already 5. The UE then compares the new count with 5. Below 5, it starts T3411. At 5, it starts T3402. The table below follows one attach cycle in which the network never answers.

So the UE sends five ATTACH REQUEST messages before the long wait, and four T3411 periods separate them. With the default values, one cycle takes 5 x 15 s of T3410 plus 4 x 10 s of T3411. That is 115 s, or about 2 min, followed by 12 min of T3402.

At the count of 5 the UE also cleans up. For attach, it deletes any GUTI, TAI list, last visited registered TAI, list of equivalent PLMNs and KSI, and it sets the update status to EU2 NOT UPDATED. It then waits in ATTEMPTING-TO-ATTACH, or it moves to PLMN-SEARCH to select another PLMN. A UE that also supports GERAN, UTRAN or NG-RAN tries one of those radio access technologies.

One more corner case sits at the count of 5. If the network has set T3402 to zero, the UE does not start the timer. Instead, it performs the T3402 expiry actions at once.

The counter does not only grow. The UE resets the attach attempt counter at power on, when a USIM is inserted, when an attach completes, and when a new PLMN is selected. Rejects with #11, #12, #13, #14, #15, #25 or #35 also reset it. In ATTEMPTING-TO-ATTACH, entering a new tracking area, T3402 expiry and a T3346 start reset it as well.

This reset list matters when you test with test equipment. It does not contain an RRC Connection Release. So a counter reset after an early release, as the test note in the introduction describes, is UE implementation behaviour, not a 24.301 rule. There is one related rule for TAU. After a failed periodic TAU with no other trigger, 24.301 allows the UE to stop T3411 when it enters EMM-CONNECTED mode.

• Five attempts make one cycle : the first attempt and four retries, separated by four T3411 periods.
• The counter decides the timer : below 5 the UE starts T3411, and at 5 it starts T3402.
• A zero T3402 skips the wait : the UE performs the expiry actions immediately.
• RRC Connection Release is not a reset event : a reset after an early release comes from the UE implementation.

How does the network set the T3402 value?

T3411 has one fixed value, but T3402 has a default and a signalled value. This difference matters in the field. One network can make a UE wait 12 min, and another network can make the same UE wait much longer or much shorter.

The network can include the T3402 value IE in three messages. The TRACKING AREA UPDATE REJECT message is not one of them. The table below shows the IE in each message and the rule for how long the UE keeps the value.

Now let's see when the UE ignores the network and uses the 12 min default. There are four cases. The first is an ACCEPT without a value, unless it answers a periodic TAU. The second is a value of "deactivated". The third is a UE with no stored value. The fourth is five failures in a new PLMN that is not an equivalent PLMN. For attach, the fourth case applies only when no ATTACH REJECT came from the new PLMN.

Note the second case carefully. "Deactivated" does not switch T3402 off. It only tells the UE to use the default value. A network that wants no long wait sends zero instead.

Both IE types carry the same one-octet timer value. Bits 8 to 6 give the unit, and bits 5 to 1 give the binary timer value.

Let's decode one value. The 12 min default, sent explicitly, is unit 001 and value 01100, so the octet is 0x2C. The largest value is 31 decihours, which is 186 min. So a network can make the UE wait just over 3 hours between cycles.

• Three messages carry T3402 : ATTACH ACCEPT and TRACKING AREA UPDATE ACCEPT with IEI 17, and ATTACH REJECT with IEI 16.
• A value in a reject needs integrity protection : without it, the UE uses the default value.
• Deactivated means the default : only a zero value removes the wait.
• The range reaches 186 min : the decihour unit with the value 31 gives the longest T3402.

Which newer rules change the retry timing?

The scheme of five attempts, T3411 and T3402 has been in 24.301 since the first EPS release. Later releases added device configuration that changes the timing for some failures. Let's look at the fixed values first, and then at one Rel-17 and one Rel-19 addition.

In 24.301 Table 10.2.1, T3411 is 10 s and T3402 has a 12 min default. Unlike T3410 or T3430, neither row refers to the NB-S1 or WB-S1/CE notes. So an NB-IoT UE adds 240 s to T3410, but it keeps T3411 at 10 s. The long wait for coverage-limited devices comes from T3410 and T3430, not from the retry timers.

The Rel-17 addition is CustomLLFailureRetry, added in 24.301 v17.7.0. It covers case aa of the abnormal cases, which is a lower layer failure to establish the RRC connection in the home country or in an EHPLMN. The UE must support this leaf of the NAS configuration MO, and the leaf must be present. The rule does not apply to an attach for emergency bearer services.

With the leaf present, the UE keeps a separate, implementation specific attempt counter. Below MaxMinRetry, the UE starts T3411 with the duration MinRetryTimer. At MaxMinRetry, it starts T3402 with the duration MaxRetryTimer and sets the attach or tracking area updating attempt counter to 5. The UE resets this separate counter when it enters EMM-CONNECTED mode, among other events.

The Rel-19 addition is faster service recovery, added in 24.301 v19.3.0 for a UE configured with the FasterRecovery leaf. It applies only when a lower layer failure, case aa or case b, put the UE into ATTEMPTING-TO-ATTACH or ATTEMPTING-TO-UPDATE. While T3411 runs, a ShortTimerEvent lets the UE start the procedure early, up to MaxNumShortTimerStop times. While T3402 runs, a LongTimerEvent lets the UE re-enable E-UTRA and try again, up to MaxNumLongTimerReg times.

The UE resets both of these counters when T3402 starts or when the attempt counter is reset. When both counters reach their maximum, the UE behaves as if it were not configured for faster service recovery. The two events are defined in the NAS configuration MO of 24.368, which this page does not cover.

• NB-IoT does not stretch T3411 or T3402 : only the procedure timers such as T3410 and T3430 get the extra 240 s.
• CustomLLFailureRetry replaces the durations : MinRetryTimer and MaxRetryTimer apply to RRC setup failures in the home country.
• Faster service recovery shortens the waits : configured events let the UE try again before T3411 or T3402 expires.
• Both additions need device configuration : a UE without the NAS configuration MO leaves follows the basic five attempt scheme.

Reference

[1] 3GPP TS 24.301 v20.0.0 - clause 5.3.6, Handling of timer T3402, clause 5.5.1.1 and 5.5.3.1, attempt counters, clause 5.5.1.2.6 and 5.5.3.2.6, Abnormal cases in the UE, clause 5.2.2.3.3, ATTEMPTING-TO-ATTACH, clause 8.2.1, 8.2.3 and 8.2.26, and Table 10.2.1

[2] 3GPP TS 24.008 v20.0.0 - clause 10.5.7.3, GPRS Timer, and clause 10.5.7.4, GPRS Timer 2