5G NR Measurement Events Explained
Measurement events in 5G NR are configured conditions that determine when a UE should report radio measurements to the gNB. They are one of the most important practical building blocks behind mobility, handover timing, and radio optimization in the NG-RAN.
The big idea is simple: the gNB tells the UE what kind of radio change matters, the UE keeps watching the configured measurements, and a MeasurementReport is sent only when the event logic says the condition is met.
Quick facts
| What they are | Measurement events are UE reporting conditions configured by the gNB to decide when radio observations are important enough to report. |
|---|---|
| Where they live | They are part of RRC measurement configuration, especially ReportConfig inside MeasurementConfig. |
| Most common event | Event A3 is one of the most common connected-mode handover triggers. |
| Main tuning knobs | Thresholds, hysteresis, offsets, and time-to-trigger strongly affect report timing. |
| Main engineering use | They help the network detect serving-cell degradation, better neighbors, and inter-RAT fallback opportunities. |
| Important distinction | Event-based reporting is mainly a connected-mode concept. Idle-mode mobility is driven by reselection rules instead. |
Where measurement events fit
The flow is straightforward. The gNB configures the event rules through RRC, the UE watches the radio environment, and once the configured condition fires the UE sends a report that the gNB can use for handover or optimization decisions.
- gNB configures measurement events using RRC measurement configuration.
- UE monitors serving and neighbor radio conditions.
- UE evaluates thresholds, offsets, hysteresis, and time-to-trigger.
- UE sends MeasurementReport when the event condition is satisfied.
- gNB decides whether to keep monitoring, optimize, or trigger mobility action.
Measurement configuration in 5G
Measurement events do not stand alone. They are part of the wider RRC measurement configuration sent by the gNB to the UE. That configuration defines the measured targets, the event rules, and the mapping between them.
- MeasObject defines what the UE should measure.
- ReportConfig defines when the UE should report.
- MeasId links the measured target to the reporting rule.
- QuantityConfig affects how values are filtered and evaluated.
- MeasGapConfig helps when inter-frequency or inter-RAT observation is needed.
In live networks, many apparent “handover problems” are actually measurement event tuning problems. The event logic may be too aggressive, too conservative, or simply pointed at the wrong targets.
Key measurement events in 5G NR
Event A1: Serving becomes good
Event A1 is triggered when the serving cell becomes better than a configured threshold. It is often used to stop unnecessary reporting or reduce signaling once the serving radio condition is healthy again.
Event A2: Serving becomes bad
Event A2 is triggered when the serving cell becomes worse than a configured threshold. This is useful when the network wants earlier warning that mobility preparation or more aggressive neighbor observation may be needed.
Event A3: Neighbor becomes better
Event A3 is one of the most important connected-mode handover triggers. It fires when a neighbor cell becomes better than the serving cell by a configured offset.
Neighbor > Serving + Offset
Because A3 compares relative quality instead of just checking a fixed threshold, it is often the event that best matches “move when the neighbor is clearly better.”
Event A4: Neighbor becomes good
Event A4 is triggered when a neighbor cell exceeds a fixed threshold. It is useful when the network wants to monitor or prepare around candidate neighbors that cross a minimum quality line.
Event A5: Serving bad and neighbor good
Event A5 combines two conditions at once: the serving cell must fall below a threshold and a neighbor must rise above another threshold. This makes it a more conservative and often more stable trigger than A3 alone in some deployments.
Event B1: Inter-RAT becomes good
Event B1 is used when an inter-RAT target such as LTE becomes better than a threshold. It is especially relevant when the network wants visibility into fallback or redirection candidates outside NR.
Event B2: Serving bad and inter-RAT good
Event B2 combines bad serving-NR quality with good inter-RAT quality. It is a classic inter-RAT mobility trigger pattern when NR is degrading and a fallback target is ready.
Summary of events
| Event | Condition | Typical use |
|---|---|---|
| A1 | Serving good | Reduce reporting or stop additional mobility monitoring. |
| A2 | Serving bad | Warn that serving quality is degrading. |
| A3 | Neighbor better than serving by offset | One of the most common handover triggers. |
| A4 | Neighbor good | Neighbor monitoring and preparation. |
| A5 | Serving bad and neighbor good | More conservative handover triggering. |
| B1 | Inter-RAT target good | Inter-RAT visibility and fallback readiness. |
| B2 | NR bad and inter-RAT target good | Inter-RAT handover or fallback trigger. |
Measurement parameters
Event behavior depends as much on the parameters as on the event name itself. Two networks may both use A3 but behave very differently because the offsets, timers, and hysteresis are tuned differently.
- Threshold defines the level that must be crossed.
- Hysteresis adds margin so minor fluctuations do not create unstable reporting.
- Time-to-trigger ensures the condition persists before it is reported.
- Offset is used for relative comparisons, especially with A3.
Measurement quantities
The event logic is usually evaluated using standard radio-quality quantities:
- RSRP for received reference-signal power.
- RSRQ for received reference-signal quality.
- SINR for quality relative to interference and noise.
These numbers are not just statistics. They become mobility evidence once they are fed into the configured event rules.
Measurement reporting
When an event condition is satisfied, the UE sends a MeasurementReport back to the gNB. That report carries the measured results needed for the network to decide what to do next.
- Serving-cell measurements may be included.
- Neighbor-cell measurements may be included.
- The report context reflects the configured event logic.
This is the bridge between radio observation and mobility action.
Measurement events and handover
Measurement events are one of the main triggers for handover. A common pattern is the classic A3-driven case:
- UE sees a neighbor become better than the serving cell by the configured offset.
- Event A3 is satisfied.
- UE sends MeasurementReport.
- gNB evaluates target suitability and decides whether to initiate handover.
That is why engineers spend so much time reading measurement configuration and report timing when a handover looks late, early, or unstable.
Avoiding mobility problems
Event tuning is always a balance. You want enough sensitivity to move before radio failure, but not so much sensitivity that the UE oscillates between cells.
- Ping-pong behavior is often reduced with better hysteresis and time-to-trigger tuning.
- Late handover can happen when thresholds are too conservative or timers are too long.
- Early handover can happen when event triggers are too aggressive.
- Missing reports can happen when the wrong event, object, or target mapping is configured.
Measurement events and RRC
Event behavior is configured through RRC, most often inside MeasurementConfig delivered by RRCReconfiguration. This is why RRC traces are the first place to look when the UE seems to be measuring the wrong thing or reporting at the wrong time.
A good troubleshooting sequence is usually: confirm the configured object, confirm the report configuration, confirm the parameter values, then compare that setup with the actual MeasurementReport behavior.
Measurement events in idle mode
Event-based reporting is mainly a connected-mode mechanism. In idle mode, the UE usually follows cell reselection rules instead of sending event-based MeasurementReport messages back to the network.
That distinction matters because some mobility questions are really about reselection tuning, not connected-mode event configuration.
Measurement events and beam management
In NR, measurements are often more nuanced than a simple “best cell” view because the UE may be evaluating multiple beams within or across cells. That means measurement behavior can reflect both cell-level and beam-level radio conditions.
From an engineering perspective, this is one reason 5G mobility can look more dynamic than older LTE examples: the radio environment itself is more directional and more configurable.
Common troubleshooting areas
- No MeasurementReport is sent even though radio conditions appear to justify it.
- The wrong event is configured for the intended mobility strategy.
- Thresholds or offsets are too aggressive or too conservative.
- Hysteresis or time-to-trigger create unstable or delayed mobility.
- Inter-RAT fallback fails because B1 or B2 logic is not aligned with the target strategy.
FAQ
What are measurement events in 5G?
They are configured conditions that tell the UE when it should send a MeasurementReport to the gNB.
Which event is most important?
Event A3 is one of the most common handover triggers because it compares neighbor quality to the serving cell with an offset.
What is hysteresis?
It is a margin used to reduce unnecessary switching or noisy reporting near a decision boundary.
What is time-to-trigger?
It is the time an event condition must remain true before the UE reports it.
Do measurement events work in idle mode?
No, not in the same way. Idle mode is mainly driven by reselection logic rather than connected-mode event reporting.
Key takeaways
- Measurement events are the conditions that drive UE reporting in connected mode.
- A3 is one of the most common handover triggers, but A5, B1, and B2 are also important.
- Thresholds, hysteresis, offsets, and time-to-trigger are what make event behavior stable or unstable in practice.
- Measurement events sit inside the wider MeasurementConfig structure delivered through RRC.
- Understanding event logic is essential for debugging handover timing, ping-pong behavior, and inter-RAT fallback.
References
- 3GPP TS 38.331 - NR RRC protocol specification Primary RRC reference for measurement events, ReportConfig, thresholds, time-to-trigger, and MeasurementReport signaling.
- 3GPP TS 38.300 - NR and NG-RAN overall description; Stage-2 High-level NR architecture reference for mobility behavior, measurements, and NG-RAN context.