T304

Timer T304 is a critical supervisory timer in the handover process of an LTE network. It is used to monitor the time the UE takes to complete a handover, including synchronization with the target cell and establishing a connection. The timer ensures timely execution of the handover process and helps the UE determine if a handover has failed.

Importance of Timer T304 are

Ensuring Timely Handover: T304 prevents indefinite waiting during handovers and ensures the UE can quickly detect handover failures.
Facilitating Seamless Mobility: By supervising the transition, T304 ensures that the UE maintains service continuity during cell or RAT transitions.
Optimizing Network Resources: By monitoring and detecting failed handovers, T304 helps optimize network resource usage by avoiding unnecessary retries or prolonged attempts.
Supporting Inter-RAT Mobility: T304 plays a crucial role in ensuring successful handovers between different radio access technologies (e.g., LTE to NR, LTE to GERAN).

The sequence below shows the basic intra-LTE case. The network sends RRC Connection Reconfiguration for handover, and that message carries the T304 value. T304 runs from the reception of this message until MAC completes the random access procedure in the target cell. The note under the drawing points to 36.331 clause 5.3.5.4, where this rule is written.

T304 running from RRC Connection Reconfiguration for handover until completion of the PRACH process at MAC

T304 during an intra-LTE handover. The UE starts it on the handover command and stops it when the random access in the target cell succeeds.

Followings are the topics to be covered in this page.

Key Scenarios Involving T304

During a handover the UE has left the source cell but is not yet known in the target cell. T304 limits how long the UE may stay in that gap. Let's go through what starts the timer, what stops it, what happens at expiry, and how it interacts with the other timers of the UE.

Starting Timer T304:

T304 always starts on a command from the network, never on a UE decision. Two different messages can carry that command. The first is the intra-LTE handover command, and the second is the cell change order to GERAN.

During Handover:

When the UE receives an RRCConnectionReconfiguration message that includes mobilityControlInfo, the UE starts Timer T304. This message signals the start of the handover process, and T304 begins supervising the transition to the target cell.
The value of T304 is provided by the network in the mobilityControlInfo element.

In Cell Change Order (MobilityFromEUTRACommand):

If the network initiates a cell change order via the MobilityFromEUTRACommand message, T304 is started with the value specified in the message to oversee the transition.

For an intra-LTE handover, the target eNB, not the source eNB, chooses the t304 value. The target eNB builds the RRCConnectionReconfiguration with mobilityControlInfo during handover preparation, and the source eNB only forwards it to the UE. For a conditional handover, the UE starts T304 when it executes the stored RRCConnectionReconfiguration, not when it receives it.

Stopping Timer T304:

T304 stops only when the UE has proven that it can talk to the target cell. Downlink synchronisation alone is not enough. 36.331 clause 5.3.5.4 names two events, and either one of them stops the timer.

Timer T304 is stopped upon successful completion of the handover, such as:

The UE successfully synchronizes with the target cell, and then one of the two events below occurs.
Random access procedure is successfully completed in the target cell.
A valid PDCCH transmission addressed to the C-RNTI is received in the target cell, when rach-Skip is configured for a RACH-less handover.

For a cell change order the stop criterion comes from the target RAT. The UE stops T304 when the connection to the GERAN cell succeeds, as the GERAN specifications define it. In a DAPS handover, stopping T304 also stops T310 for the source PCell and triggers the UL data switching.

T304 Expiry - Handover Failure:

An expired T304 means the UE could not reach the target cell in time. The source cell may still be usable, but the UE has already applied the target configuration. So the UE has to undo that configuration before it can recover the connection.

If T304 expires before the handover is successfully completed:

The handover is considered a failure.
The UE reverts to the source cell’s configuration.
The UE may initiate a connection re-establishment procedure (as per clause 5.3.7).
For inter-RAT handovers, the UE reverts to the source RAT's configuration.

Actions Upon T304 Expiry:

The recovery actions depend on the type of mobility. The list below separates intra-RAT handover from inter-RAT mobility, and the paragraph after it gives the details that 36.331 clause 5.3.5.6 adds.

For intra-RAT handovers (E-UTRA to E-UTRA):

The UE performs the actions outlined in clause 5.3.5.6, which include:

Reverting to the source cell configuration.
Triggering the connection re-establishment procedure.

For inter-RAT handovers:

The UE may attempt to establish a connection with the source RAT or report the failure to upper layers.

Let's look closer at the revert. Without a conditional handover configuration, the UE reverts to the source PCell configuration except physicalConfigDedicated, mac-MainConfig and sps-Config. The UE then starts RRC connection re-establishment with reestablishmentCause set to handoverFailure. A DAPS handover is the exception. If the source link is still working, the UE releases the target side, resumes the SRBs in the source PCell and reports a DAPS HO failure with the failure information procedure.

Additional Points to be noted

T304 does not work alone. It changes the behaviour of the radio link monitoring timers while it runs, and it has a special role in conditional and DAPS handover. The notes below collect those interactions.

Triggering Handover Procedures:

Timer T304 is started whenever the UE is directed to perform a handover to a target cell or RAT.
During this time, the UE must synchronize to the downlink of the target cell and complete the random access procedure.

Conditional Reconfiguration:

If the handover occurs as part of a conditional reconfiguration execution while another timer like T311 was running, T304 ensures seamless transition by supervising the process.

Interaction with Other Timers:

T310: If T304 is running and the source cell detects radio link issues (e.g., N310 out-of-sync indications), T310 may be started to monitor the source cell’s stability. This applies only when a DAPS bearer is configured. Without DAPS, 36.331 clause 5.3.11.1 does not start T310 while T304 is running.
T316: T316 supervises the MCG failure information procedure, not DAPS handover. A handover command with mobilityControlInfo stops T316, so a handover that answers an MCG failure report ends T316 and starts T304.

Handover Failure Handling:

If T304 expires or the UE cannot comply with the configurations provided in the handover message, it triggers fallback actions like reverting to the source cell or initiating connection re-establishment.

What values can T304 take?

Unlike T300 or T310, T304 is not broadcast in system information. The network sets it per handover, inside the command itself. This lets the network choose a value that fits the target cell, for example a longer one when the target is a CE cell or a GERAN cell.

For an intra-LTE handover the value is the t304 field of MobilityControlInfo, in the listing below.

Following is based on 36.331 v19.3.0 (Release 19)

MobilityControlInfo ::=     SEQUENCE {
    targetPhysCellId                    PhysCellId,
    carrierFreq                         CarrierFreqEUTRA                    OPTIONAL,   -- Cond HO-toEUTRA2
    carrierBandwidth                    CarrierBandwidthEUTRA               OPTIONAL,   -- Cond HO-toEUTRA
    additionalSpectrumEmission          AdditionalSpectrumEmission          OPTIONAL,   -- Cond HO-toEUTRA
    t304                                ENUMERATED {
                                            ms50, ms100, ms150, ms200, ms500, ms1000,
                                            ms2000, ms10000-v1310},
    newUE-Identity                      C-RNTI,
    radioResourceConfigCommon           RadioResourceConfigCommon,
    rach-ConfigDedicated                RACH-ConfigDedicated                OPTIONAL,   -- Need OP
    ...,
    [[  carrierFreq-v9e0                CarrierFreqEUTRA-v9e0               OPTIONAL    -- Need ON
    ]],
    [[  drb-ContinueROHC-r11            ENUMERATED {true}                   OPTIONAL    -- Cond HO
    ]],
    [[  mobilityControlInfoV2X-r14  MobilityControlInfoV2X-r14              OPTIONAL,   -- Need ON
        handoverWithoutWT-Change-r14    ENUMERATED {keepLWA-Config, sendEndMarker}  OPTIONAL,   -- Cond HO
        makeBeforeBreak-r14             ENUMERATED {true}                   OPTIONAL,   -- Need OR
        rach-Skip-r14                   RACH-Skip-r14                       OPTIONAL,   -- Need OR
        sameSFN-Indication-r14          ENUMERATED {true}                   OPTIONAL    -- Cond HO-SFNsynced
    ]],
    [[
        mib-RepetitionStatus-r14        BOOLEAN                             OPTIONAL,   -- Need OR
        schedulingInfoSIB1-BR-r14       INTEGER (0..31)                     OPTIONAL    -- Cond HO-SFNsynced
    ]],
    [[  daps-Config-r16                 DAPS-Config-r16                     OPTIONAL    -- Cond NotFullConfigHO
    ]],
    [[  gnss-PositionFixDurationReporting-r18   ENUMERATED {true}       OPTIONAL    -- Need OR
    ]]
}

The range runs from ms50 to ms2000. A normal handover needs time for downlink synchronisation, for a possible wait for the next PRACH occasion, and for the random access itself. The last value, ms10000-v1310, was added in Release 13. E-UTRAN includes it only when the UE supports CE, because repetitions make the random access much longer.

For a cell change order the value is in CellChangeOrder, carried by MobilityFromEUTRACommand.

Following is based on 36.331 v19.3.0 (Release 19)

CellChangeOrder ::=             SEQUENCE {
    t304                                ENUMERATED {
                                            ms100, ms200, ms500, ms1000,
                                            ms2000, ms4000, ms8000, ms10000-v1310},
    targetRAT-Type                      CHOICE {
            geran                           SEQUENCE {
                physCellId                      PhysCellIdGERAN,
                carrierFreq                     CarrierFreqGERAN,
                networkControlOrder             BIT STRING (SIZE (2))       OPTIONAL,   -- Need OP
                systemInformation               SI-OrPSI-GERAN              OPTIONAL    -- Need OP
            },
            ...
    }
}

This range starts higher, at ms100, and goes up to ms8000, plus ms10000-v1310 for CE. The UE must first acquire the GERAN cell and its system information, unless the network provides it in the command. That takes longer than an LTE random access.

T304 comes with the command : MobilityControlInfo or CellChangeOrder carries it, not SIB2.
Intra-LTE handover uses ms50 to ms2000 : ms10000-v1310 is added only for a UE that supports CE.
Cell change order allows up to ms8000 : GERAN access needs more time than an LTE random access.

What does the UE record when T304 expires?

A handover failure is a network problem as much as a UE problem. The handover parameters may be wrong, or the target cell may be too weak. The eNB, however, only sees a re-establishment request that arrives later. So the UE keeps a record of the failure, and the network can collect it after the UE is connected again.

Except when the UE executed a conditional handover during cell selection while T311 was running, 36.331 clause 5.3.5.6 makes the UE store handover failure information in VarRLF-Report. The record contains these items.

measResultLastServCell, the RSRP and RSRQ of the source PCell at the moment of failure
measResultNeighCells, the best measured neighbour cells on the configured EUTRA, UTRA, GERAN, CDMA2000 and NR frequencies
failedPCellId, the target PCell of the failed handover
previousPCellId, the PCell where the UE received the handover command
timeConnFailure, the time from the handover command to the failure
connectionFailureType set to 'hof', and the C-RNTI used in the source PCell

The report tells the network more than the failure alone. The timeConnFailure field shows how long the UE spent on the handover before it failed. The neighbour results show whether another cell would have been a better target. The network retrieves the record with rlf-ReportReq in UEInformationRequest, and the UE may discard it 48 hours after the failure.

T304 expiry is logged as 'hof' : the RLF report separates handover failure from radio link failure.
The report names both cells : previousPCellId for the source and failedPCellId for the target.
The network pulls the report later : with rlf-ReportReq, within 48 hours of the failure.

Reference

[1] 3GPP TS 36.331 v19.3.0 - clause 5.3.5.4, Reception of an RRCConnectionReconfiguration including the mobilityControlInfo, clause 5.3.5.6, T304 expiry, clause 5.4.3, Mobility from E-UTRA, clause 6.3.4, Mobility control information elements, and clause 7.3, Timers