Timer T3418 is used in the Authentication Procedure to manage the timing and response to authentication failures, specifically in cases where the UE sends an AUTHENTICATION FAILURE message to the network. It ensures the UE does not remain indefinitely waiting for further actions or responses and helps guide recovery or retry mechanisms.

Timer T3418 ensures:

• Controlled handling of authentication failures to prevent unnecessary retries or prolonged waiting.
• Clear procedures for retrying or aborting authentication challenges.
• Differentiated behavior for emergency services to ensure continuous access to critical connectivity.
• Improved reliability and security by identifying untrustworthy networks or failed authentication attempts in a timely manner.

T3418 is a UE timer, and its value is 20 s. The UE uses it to give the network one more chance after a failed challenge. If the network cannot produce a valid challenge in time, the UE treats it as a false network.

• Key Scenarios Involving T3418
• How does T3418 differ from T3420?
• What happens to the other UE timers while T3418 runs?
• Reference

Key Scenarios Involving T3418

EPS AKA is mutual. The network checks the UE with RES, and the UE checks the network with the MAC and the SQN inside AUTN. T3418 belongs to the second check. Let's follow it from the failed challenge to either a valid new challenge or a decision that the network is false.

Start of T3418:

Only two AUTHENTICATION FAILURE causes start T3418. A third cause, #21 "synch failure", starts T3420 instead, because the network must resynchronise the SQN rather than check the identity.

• The UE starts T3418 upon sending an AUTHENTICATION FAILURE message to the network. This failure could be due to issues such as:
• EMM Cause #20: MAC failure.
• EMM Cause #26: Non-EPS authentication unacceptable.
• AUTHENTICATION FAILURE messages indicate that the UE cannot process the received authentication challenge.

The diagram below shows the MAC failure case with the answer that 24.301 expects from the network. The network first checks the identity of the UE with an identification procedure, and then it sends a new challenge. Two network timers, T3460 and T3470, and one UE timer, T3418, appear in the same exchange.

The identification procedure runs inside the T3418 window. A new AUTHENTICATION REQUEST ends T3418, and the second challenge succeeds.

• Authentication Request and T3460 : the network starts T3460 with the first challenge. The AUTHENTICATION FAILURE with cause MAC Failure stops it, because a failure is also an answer.
• T3418 : the long arrow at the left. The UE starts it when it sends AUTHENTICATION FAILURE, and the second Authentication Request ends it.
• Identity Request and T3470 : the drawing spells the message Indentity Request. The network asks for the IMSI to check that the GUTI it used matches the right subscriber. T3470 runs until Identity Response with the IMSI arrives.
• Second Authentication Request : the network sends a new challenge after it has corrected the GUTI to IMSI mapping. T3460 starts again, and Authentication Response stops it.

The identification step is optional for the network. If the IMSI matches the GUTI, the network knows that the authentication really failed. In that case it sends AUTHENTICATION REJECT instead of a new challenge.

Actions While T3418 is Running:

While T3418 runs, the UE waits for the network. It answers an IDENTITY REQUEST normally. What it does with the next AUTHENTICATION REQUEST depends on whether that challenge passes the MAC and SQN checks.

• If the UE receives a new AUTHENTICATION REQUEST message while T3418 is running:
• The UE stops T3418 and processes the new authentication challenge.
• If the AUTHENTICATION REQUEST is invalid (e.g., MAC or SQN cannot be resolved), the UE starts the process again, either retrying authentication or proceeding based on the specific failure scenario.

Expiry of T3418:

An expiry means that no valid challenge arrived within 20 s. The UE then stops waiting and follows item f of 24.301 clause 5.4.2.7, "Network failing the authentication check". This path applies only when no emergency or RLOS PDN connection exists.

• If T3418 expires without receiving a valid response or a new AUTHENTICATION REQUEST:
• The UE considers the network to have failed the authentication check.
• The UE requests the release of the RRC connection and treats the active cell as barred.

Handling Consecutive Authentication Failures:

A false network could keep sending bad challenges, and each one would restart T3418. So 24.301 also limits the number of failed challenges. Challenges count as consecutive only when the second and the third arrive while the T3418 or T3420 of the previous failure is still running.

• If the UE experiences three consecutive authentication failures (e.g., due to MAC failure, synch failure, or unacceptable authentication challenges) while T3418 is running:
• The UE treats the network as untrustworthy.
• It proceeds to release the connection and treats the cell as barred.

Special Cases for Emergency Bearer Services:

24.301 treats an emergency call differently. The rules above change when the UE has, or is setting up, a PDN connection for emergency bearer services. The same change applies to a PDN connection for RLOS.

• If the UE has an active PDN connection for emergency services or is establishing one:
• The UE does not treat the network as having failed even if T3418 expires.
• The UE continues using the current security context.
• Non-emergency EPS bearer contexts are deactivated, and the UE remains attached for emergency services only.

The MME may answer the AUTHENTICATION FAILURE with a SECURITY MODE COMMAND that selects EIA0 and EEA0, the null algorithms. It may also abort the authentication and continue with the current security context. In both cases the UE ends up attached for emergency bearer services only.

Recovery Scenarios:

Two network messages end T3418 in a good way. A valid new challenge ends it in every case. A SECURITY MODE COMMAND ends it as well. 24.301 Table 10.2.1 lists it as a normal stop, and clause 5.4.2.7 describes it for a UE with an emergency or RLOS PDN connection.

• Upon receipt of a valid AUTHENTICATION REQUEST message before T3418 expires:
• The UE stops T3418 and resumes the authentication procedure.
• If the network initiates a SECURITY MODE COMMAND before T3418 expires:
• The UE stops T3418 and transitions to the security mode control procedure.

• Two causes start T3418 : #20 "MAC failure" and #26 "non-EPS authentication unacceptable".
• The network may check the identity first : an IDENTITY REQUEST for the IMSI can run while T3418 runs.
• An expiry means a false network : the UE releases the RRC connection locally and treats the cell as barred.
• Emergency and RLOS connections change the result : the UE keeps the current security context and stays attached for emergency bearer services only.

How does T3418 differ from T3420?

T3418 has a twin, T3420, and the two are easy to mix up in a log. Both run in the UE after an AUTHENTICATION FAILURE, and both lead to the same false network decision on expiry. The difference is in what the network is expected to do while the timer runs.

With #20 or #26, the UE did not trust the challenge itself. The MAC was wrong, or the separation bit in the AMF field of AUTN was 0. So the network may first check the identity of the UE, as in the diagram above, and then send a new challenge. With #21, the challenge was genuine but the SQN was out of range. So the UE sends AUTS, and the MME uses it to resynchronise with the HSS. The MME deletes the unused authentication vectors for that IMSI, gets new ones, and then sends a new challenge.

The table below compares the two timers. The values come from 24.301 Table 10.2.1, and the NB-S1 value is the normal value plus 240 s.

The two timers also share one count. The three consecutive failures can be any mix of #20, #21 and #26. For example, a MAC failure followed by two synch failures also makes the UE treat the network as false.

The network also has its own limit for #21. 24.301 allows the network to send AUTHENTICATION REJECT after two consecutive synch failures.

• T3418 is for a challenge the UE does not trust : a wrong MAC or a wrong separation bit.
• T3420 is for a genuine but stale challenge : the SQN is out of range, and AUTS lets the network resynchronise.
• T3418 is 5 s longer than T3420 : 20 s against 15 s in the normal case.
• Both timers feed one count : three consecutive failures of any of the three causes end the exchange.

What happens to the other UE timers while T3418 runs?

An authentication usually runs inside another procedure, such as an attach or a TAU. That procedure has its own supervision timer. If that timer kept running during a failed challenge, it could expire while the UE is still waiting for the network. So 24.301 pauses those timers.

When the UE sends AUTHENTICATION FAILURE with #20, #21 or #26, it stops any retransmission timer that is running. 24.301 names T3410, T3417, T3421 and T3430 as examples. The UE also deletes any stored RAND and RES and stops T3416. Then the UE starts the retransmission timers again in two cases. The first is a valid new challenge. The second is the decision that the network failed the check. In both cases the UE restarts only the timers that it stopped for this failure, and only if their procedures are still open.

T3418 itself stops for three more reasons. First, the UE stops T3418 when it enters EMM-IDLE mode, for example after a lower layer failure or a release of the NAS signalling connection. Second, the UE stops it when the lower layers report a transmission failure of the AUTHENTICATION FAILURE message. If an attach or a TAU triggered the authentication, the UE then starts that procedure again. Third, an AUTHENTICATION REJECT stops T3418 together with T3410, T3416, T3417, T3421, T3430 and T3420.

That last case has a security detail. An AUTHENTICATION REJECT is often sent without integrity protection. The UE accepts such a reject only while T3416, T3418 or T3420 is running. If none of them runs, the UE discards the reject. If one of them runs, the UE does not trust the reject fully. Unless it uses T3245, it starts T3247 with a random value between 30 min and 60 min, and it follows the rules of clause 5.3.7b for non-integrity protected rejects.

• A failed challenge pauses the procedure timers : T3410, T3417, T3421 and T3430 stop, and they start again after the outcome is known.
• EMM-IDLE ends T3418 : a lower layer failure or a released connection stops the timer.
• T3418 lets the UE process an unprotected reject : an unprotected AUTHENTICATION REJECT is only processed while T3416, T3418 or T3420 runs.
• T3247 follows an unprotected reject : the UE starts it with a random value from 30 min to 60 min.

Reference

[1] 3GPP TS 24.301 v20.0.0 - clause 5.4.2, EPS authentication and key agreement procedure, in particular clause 5.4.2.5, 5.4.2.6 and 5.4.2.7, clause 4.7 and 4.8, and Table 10.2.1