Description
Time To Trigger (TTT) is a critical hysteresis parameter in the Layer 3 mobility management procedures of User Equipment (UE) in LTE (E-UTRAN) and NR (NG-RAN). It is a configurable timer, broadcast by the network in system information (e.g., SIB3, SIB4, SIB5 in LTE) or provided via dedicated RRC signaling. TTT works in conjunction with event-triggered measurement reporting. For example, for an A3 event (neighbor cell becomes offset better than serving cell), the UE continuously evaluates the condition. Only when this condition is satisfied *uninterruptedly* for the entire duration of the TTT timer does the UE send a measurement report to the network, triggering a potential handover command.
The architecture involves the UE's RRC protocol entity, which manages the measurement configuration received from the gNB or eNB. This configuration includes the measurement event identity, offsets, hysteresis, and the TTT value. The UE's physical layer performs the Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) measurements. These raw measurements are filtered (Layer 3 filtering) and then evaluated by the RRC entity against the event entry condition. A persistent satisfaction of the condition starts the TTT timer. If the condition fails at any point before the timer expires, the timer is reset. This mechanism adds a layer of filtering to short-term signal variations caused by fast fading, user movement, or environmental interference.
How it works in practice: A UE moves towards a neighbor cell. The neighbor's RSRP slowly rises above the serving cell's RSRP (plus any configured offset). The A3 event condition becomes true. The UE starts the TTT timer (e.g., set to 320 ms). If for those 320 ms the neighbor cell remains better, a measurement report is sent. If, during that time, the serving cell's signal briefly improves again, the condition becomes false, the timer resets, and no report is sent. This prevents unnecessary handovers during transient conditions. TTT's role is to introduce a deliberate delay in the mobility decision process, trading off a slight delay in optimal connectivity for vastly improved network stability, reduced signaling load, and higher overall user experience by avoiding call drops from rushed or oscillating handovers.
Purpose & Motivation
TTT was introduced to solve the critical problem of handover ping-pong and unstable mobility in cellular networks. In early mobility algorithms that reacted instantly to measurement thresholds, rapid fluctuations in radio signal strength—due to fast fading, user turning a corner, or temporary obstructions—could cause a UE to be handed back and forth repeatedly between two cells within seconds. This 'ping-pong' effect generates excessive signaling load on the network, consumes UE battery, increases the risk of handover failure and call drops, and degrades user perceived performance.
The purpose of TTT is to add time-domain hysteresis. By requiring a potential target cell to be consistently better for a defined period, the network filters out short-term, non-significant signal variations and only reacts to sustained trends indicating genuine user movement. This ensures handovers are triggered only for stable, longer-term changes in the radio environment. It was motivated by the need for automated, robust mobility management in LTE's flat-IP architecture and became even more crucial in 5G NR with its use of higher frequencies (more prone to blockage and variation) and dense deployments. TTT allows network operators to fine-tune the aggressiveness of handovers; a short TTT makes the system responsive for high-speed users, while a longer TTT promotes stability in slow-moving or stationary users with fluctuating signals.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (20 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-12, normative work from Rel-15.
In Release 15, the TTT function itself was not newly introduced; however, several corrections were made to related triggering mechanisms. These corrections addressed specific procedures including sidelink measurement periodical triggering, BSR triggered SR, and SR triggering to accommodate the configured grant. The release also included corrections for triggering conditions based on the number of cells and for aperiodic CSI trigger configurations.
- Correction for sidelink measurement periodical triggering condition TS 36.331CR3544
- Correction on measurement triggering based on number of cells TS 36.331CR3657
- Correction on triggering idle mode measurement TS 36.331CR3658
- Correction to SR triggering to accommodate the configured grant TS 38.321CR0115
- RRC triggered BWP switching while RACH is ongoing TS 38.321CR0409
- Correction on BSR triggered SR TS 38.321CR0459
+ 5 more changes
In Release 16, the TTT function was refined within conditional reconfiguration execution to ensure it correctly triggered for only a single cell, preventing unintended actions for multiple cells. Additionally, corrections were made to the Beam Failure Recovery (BFR) process to properly trigger the generation and building of the BFR MAC CE. Further refinements addressed the unexpected triggering of the Sidelink Buffer Status Report (SL-BSR) specifically for the Sidelink Channel State Information (SL-CSI) MAC CE.
In Release 17, specific corrections were made to the triggering conditions for SDT (Small Data Transmission) and to the reporting of NR serving frequency results for event-triggered measurements. These updates refined the execution criteria that trigger a UE to perform specific procedures like conditional handover or measurement reporting, ensuring more accurate and reliable network behavior.
In Release 18, specific clarifications and corrections were made to procedures involving triggering mechanisms, including the early RACH procedure triggered by a PDCCH order. Furthermore, adjustments were specified for the triggering of Scheduling Requests (SR) by correcting the calculation of available UL-SCH resources that initiate the process.
In Release 19, the specification refined the conditions under which the Time To Trigger (TTT) function initiates specific procedures, including for conditional reconfigurations like conditional handover and conditional PSCell addition. The updates clarified that the execution criteria, which include TTT, trigger the UE to perform these actions upon meeting the defined entry conditions. Furthermore, the release provided additional procedural details for scenarios where TTT-based triggering interacts with other mechanisms, such as system information acquisition or RRC state transitions.
- Correction on DSR triggering TS 38.321CR2140
Explore further
Broader topics and technologies where TTT plays a role.
Defining Specifications
3GPP specifications that define or reference TTT, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TS 38.321 vj00 | NR MAC Protocol Specification | Rel-19 |