Purpose of T3470: Timer T3470 is used in the Identification Procedure to ensure that the network receives a timely response from the User Equipment (UE) after sending an IDENTITY REQUEST message. The timer supervises the communication and manages retransmissions or terminations if the procedure cannot be completed.

Timer T3470 plays a critical role in:

• Ensuring timely identification of the UE.
• Allowing recovery from temporary communication failures by managing retransmissions.
• Preventing indefinite delays in network procedures by terminating stalled identification processes.
• Managing procedural collisions, such as prioritizing attach requests over identification when applicable.

T3470 is a network timer in the MME, and its value is 6 s. It is the simplest of the EMM common procedure timers, because only one answer stops it. The interesting parts are when the MME uses the procedure and how it collides with procedures that the UE starts.

• Key Scenarios Involving T3470
• Which identities can the network request, and when?
• How long can the MME wait for IDENTITY RESPONSE?
• Reference

Key Scenarios Involving T3470

The identification procedure is a single request and a single response. So T3470 has one start event, IDENTITY REQUEST sent, and one normal stop event, IDENTITY RESPONSE received. Let's look at the normal exchange first, and then at the failures and collisions that end it early.

Identification Procedure:

The UE must be ready to answer an IDENTITY REQUEST at any time in EMM-CONNECTED mode. The request names one identity type, and the response carries that identity. The procedure has no reject message. When the UE cannot provide the identity, it answers with "no identity" instead.

• Initiation: When the network sends an IDENTITY REQUEST message to the UE, it starts timer T3470. This message specifies the type of identity being requested (e.g., IMSI, IMEI).
• Completion: Upon receiving the IDENTITY RESPONSE from the UE, the network stops T3470. The received identity information is then used to proceed with further signaling or authentication.

The diagram below shows T3470 inside an authentication failure. The UE rejects the first challenge with MAC failure, and the network asks for the IMSI before it sends a new challenge. T3470 is the middle of the three brackets on the network side.

T3470 runs between the two authentication challenges. The IMSI in the response lets the network check the GUTI that it used for the first challenge.

• T3470 : the middle bracket at the right. It starts with the request that the drawing labels Indentity Request, and Identity Response with the IMSI stops it.
• T3460 : the upper and the lower bracket at the right. Each Authentication Request starts one, and the answer to it stops it. The T3460 page covers it.
• T3418 : the long arrow at the left. The UE runs it from Authentication Failure until the new Authentication Request. The whole T3470 exchange must fit inside it. The T3418 page covers it.

The last bullet has a practical consequence. T3418 is 20 s, and one T3470 period is 6 s. So the MME can retransmit IDENTITY REQUEST twice in this situation, and it still has time left for the new challenge. If it needs more retransmissions, T3418 expires in the UE first, and the UE normally treats the network as false.

Abnormal Cases on the Network Side:

24.301 clause 5.4.4.6 lists the abnormal cases for the network. The lower layer failure and the expiry of T3470 end the procedure. The collisions do not always end it, because the network often runs both procedures.

• Lower Layer Failures:
• If a lower layer failure is detected before the IDENTITY RESPONSE is received, the network stops T3470 and aborts the identification procedure as well as any ongoing EMM procedure.
• Timer T3470 Expiry:
• If T3470 expires before the IDENTITY RESPONSE is received:
• The network retransmits the IDENTITY REQUEST message and resets T3470.
• This process is repeated up to four times.
• On the fifth expiry:
• The network aborts the identification procedure.
• Any related ongoing EMM procedure is also terminated.
• Collision with an Attach Procedure:
• If the network receives an ATTACH REQUEST message while an identification procedure is ongoing, it checks whether there is a pending attach procedure:
• If no pending attach procedure exists (e.g., no ATTACH ACCEPT/REJECT message waiting to be sent), the network stops T3470 and proceeds with the new attach procedure.

The attach collision has a second case. An attach may be pending because the identification procedure itself was started for that attach. The network then compares the new ATTACH REQUEST with the earlier one. If any IE differs, the network proceeds with the new attach procedure. If nothing differs, the network ignores the new request.

Three more collisions appear in the same clause. A DETACH REQUEST with "switch off" makes the network abort the identification and run the detach. A DETACH REQUEST without "switch off" waits until the identification completes. A TRACKING AREA UPDATE REQUEST, or an EXTENDED SERVICE REQUEST for CS fallback or 1xCS fallback, runs in parallel with the identification.

• IDENTITY RESPONSE is the only normal stop : the procedure has no reject message, and the UE sends "no identity" if it has nothing to send.
• Four retransmissions, then abort : the fifth expiry ends the identification and any ongoing EMM procedure.
• T3470 can run inside T3418 : after a MAC failure, the identification must finish before the UE gives up on the network.
• Most collisions do not end the identification : only a switch off detach aborts it, and an attach takes priority as described above.

Which identities can the network request, and when?

An IDENTITY REQUEST asks for exactly one identity. So the MME must decide what it needs before it sends the message. Let's look at the identity types first, and then at the situations where 24.301 expects an identification procedure.

The request carries the Identity type 2 IE. 24.301 clause 9.9.3.17 takes it from 24.008 clause 10.5.5.9. Bits 3 to 1 select the identity, as the table below shows. All other values are interpreted as IMSI.

The IMSI request has a special security status. 24.301 clause 4.4.4.2 lists IDENTITY REQUEST for the IMSI among the few messages that the UE processes without integrity protection. The reason is that the MME may need the IMSI before any security context exists. A request for the IMEI or the IMEISV, by contrast, is processed only after the secure exchange of NAS messages has been established.

Now let's see when the MME sends the request. The first case is a GUTI that the MME cannot resolve. For example, a TAU arrives with a GUTI and an eKSI, but the MME cannot retrieve the EPS security context for them. The MME may then ask for the IMSI. The second case is an authentication failure. After the first AUTHENTICATION FAILURE with #20 or #26, the network may ask for the IMSI to check the GUTI to IMSI mapping. The third case is a RES that does not match after the UE used a GUTI. The network should then run an identification procedure before it decides on AUTHENTICATION REJECT.

• One request asks for one identity : IMSI, IMEI, IMEISV or TMSI, selected by bits 3 to 1.
• An IMSI request needs no integrity protection : the UE answers it even before security is active.
• A GUTI problem is the usual trigger : an unknown GUTI, a MAC failure or a wrong RES leads the MME to ask for the IMSI.

How long can the MME wait for IDENTITY RESPONSE?

T3470 uses the same values as T3460, and it follows the same rule of five expiries. So the total waiting time is easy to predict. What changes is the effect of the waiting time on the UE timers around it.

24.301 Table 10.2.2 gives T3470 a value of 6 s. For a UE in CE mode A or CE mode B that supports CE mode B, and for MEO and GEO satellite access, the value is 24 s. In NB-S1 mode the MME adds 240 s, so T3470 is 246 s. With the fifth expiry as the abort point, the MME waits 30 s in normal S1 mode, 120 s in WB-S1/CE mode and 1230 s in NB-S1 mode.

On the UE side, the identification procedure has no timer at all. The UE simply answers. If the lower layers report that the IDENTITY RESPONSE could not be sent, the UE aborts the identification procedure. If an attach or a TAU triggered it, the UE starts that procedure again. If a service request triggered it and the UE is now outside its TAI list, the UE starts a TAU. Otherwise the UE implementation decides how to run the service request again.

One more lower layer case belongs to the network. If an intra MME handover prevents delivery of the IDENTITY REQUEST, the MME retransmits it after the handover. This retransmission does not wait for T3470 to expire.

• T3470 is 6 s : 24 s in WB-S1/CE mode and 246 s in NB-S1 mode.
• Five expiries take 30 s : the MME gives up 30 s after the first IDENTITY REQUEST with default values.
• The UE has no identification timer : a transmission failure makes it restart the procedure that triggered the identification.

Reference

[1] 3GPP TS 24.301 v20.0.0 - clause 4.4.4.2, Integrity checking of NAS signalling messages in the UE, clause 5.4.2.5 and 5.4.2.7, clause 5.4.4, Identification procedure, clause 4.7 and 4.8, and Table 10.2.2

[2] 3GPP TS 24.008 v20.0.0 - clause 10.5.5.9, Identity type 2