Measurements & Events (measConfig → measReport) in 5G NR

Introduction

Measurements and mobility are the connected-mode counterpart of cell reselection. Where an idle UE moves itself, a UE in RRC_CONNECTED is told where to go: it gathers radio-quality evidence about the serving cell and its neighbours, sends that evidence upward when a configured condition is met, and the gNB decides whether — and to which cell — to hand it over. The entire configuration is pushed down in a single RRC IE, measConfig, and the entire result comes back in a single RRC message, MeasurementReport.

This procedure runs continuously throughout a connection and underpins almost every mobility feature: intra- and inter-frequency handover, inter-RAT fallback to LTE, carrier-aggregation SCell management, and the newer conditional handover (CHO) and NTN triggers. Get it wrong and you see the classic connected-mode failures — late handovers and dropped calls at cell edge, ping-pong between two cells, or handovers to a cell that is strong but congested. Get the filtering, hysteresis and timers right and mobility is invisible to the user.

Because the flow is a chain — configure objects, bind them to report configs, filter the samples, evaluate the event, transmit the report — a mobility problem almost always localises to one link. Knowing whether the UE was never configured to measure a layer, could not measure it (no gap), filtered too heavily, never satisfied the event, or sent a report the gNB ignored, turns a vague "handover failure" into a specific, testable hypothesis. The stage-by-stage debugging boxes below follow that chain.

Why measurements & mobility exist

Concretely, a handover decision needs evidence, but streaming every raw radio sample uplink would be wasteful and noisy. So the network configures the UE to report only when something meaningful happens: a neighbour becomes clearly better than the serving cell, the serving cell drops below a floor, an inter-RAT layer becomes viable. The UE smooths the inherently jittery radio, checks the configured condition, and only if the condition holds long enough does it spend uplink resources on a MeasurementReport. This keeps signalling low, suppresses ping-pong, and still gives the gNB timely, trustworthy evidence to act on.

The measurement framework

Think of the framework as three lists and one glue field. The gNB hands the UE a list of things to watch (measurement objects), a list of conditions that make a measurement worth sending (report configurations), and a list of pairings that bind one object to one report config (measurement identities). Once those are in place the UE runs a small state machine per pairing: sample the radio, smooth the samples, check the condition, and if it holds long enough, send a report.

measConfig — the container

One IE holds the whole configuration. Everything the UE knows about what to measure and when to report arrives inside measConfig, and it is almost always sent as a delta — add these, modify those, remove the rest.

Each list comes in a matched pair: a ...ToAddModList that adds new entries or overwrites existing ones by id, and a ...ToRemoveList that deletes them by id. That delta structure is why mobility reconfiguration is cheap: to swap a neighbour layer the gNB removes one measObjectId and adds another, without resending the rest. The measConfig itself is carried in an RRCReconfiguration and acknowledged by RRCReconfigurationComplete. The components below make up a complete measConfig.

A subtle but important field is s-MeasureConfig: it lets the UE skip neighbour measurement entirely while the serving cell is comfortably strong, waking the neighbour search only once serving quality drops below the configured threshold. It is a pure battery optimisation — there is no point burning cycles hunting neighbours when the current cell is excellent.

measObjectNR — what to measure

Every measurement starts with an object that names a piece of spectrum and the reference signal to measure on it. In NR that object is a MeasObjectNR, and it answers "which frequency, and using which reference signal?"

Inside measObjectToAddModList each entry is a MeasObjectNR tagged with a measObjectId. Its anchor field is ssbFrequency — the SSB centre frequency (the Global Synchronization Channel Number, or GSCN raster point) where the UE searches for cells — paired with ssbSubcarrierSpacing. A single object describes one frequency layer: reuse the serving carrier's frequency for intra-frequency measurement, or set a different ssbFrequency for an inter-frequency layer. That is the entire distinction between intra- and inter-frequency measurement — same object frequency versus different object frequency.

Two more parts shape how the object is measured:

• SMTC — the smtc1 (and optional smtc2) SSB Measurement Timing Configuration. It is a window (periodicity plus offset plus duration) that tells the UE when the target cell's SSB burst occurs, so the UE only opens its receiver during that window instead of listening continuously. SMTC periodicity ranges from 5 ms to 160 ms and is the single biggest lever on inter-frequency measurement effort.
• refFreqCSI-RS — the reference point for CSI-RS based measurement, used when the object also carries a csi-rs-ResourceConfigMobility. This lets the UE measure on CSI-RS resources rather than (or in addition to) SSB, giving finer beam resolution.

The object can also carry a cell list — cellsToAddModList for cell-specific offsets (Ocn), plus blackCellsToAddModList (never report) and whiteCellsToAddModList (only report these). For the mobility mental model, keep it short: one measObjectId equals one frequency layer to be watched, with an SMTC that says when to look.

reportConfig, measId and gaps — when to report

An object tells the UE where to look. A report config tells it what makes a measurement worth sending, and how often to keep sending once it starts. The measId then binds the two into a live measurement.

Each entry in reportConfigToAddModList is a ReportConfigNR identified by a reportConfigId. Its reportType is one of two things:

• periodical — report on a timer regardless of any condition. Used for logging, SON, and continuous serving-cell tracking.
• eventTriggered — report only when an event condition (A1–A6, B1/B2) fires. This is the mobility workhorse.

An event-triggered config carries a triggerQuantity — rsrp, rsrq, or sinr — which selects the quantity the condition is evaluated on, together with three timing/margin controls that appear on every event:

• hysteresis — a margin (in 0.5 dB steps) added to the entering condition and subtracted from the leaving condition, so the UE does not flip-flop around the boundary.
• timeToTrigger — the condition must stay true continuously for this long (0 ms up to 5120 ms) before the UE actually reports.
• reportOnLeave — send an extra report when the leaving condition later becomes satisfied.

Independent of the event, the config sets the reporting cadence: reportInterval and reportAmount (how often and how many times to repeat once triggered), reportQuantityCell / reportQuantityRsIndexes (which of RSRP/RSRQ/SINR to include, at cell and beam level), maxReportCells (how many neighbours to list), and rsType (whether reported quantities derive from ssb or csi-rs).

Now the glue. Each entry in measIdToAddModList is a MeasIdToAddMod carrying exactly three things: a measId, a measObjectId, and a reportConfigId. It says "watch this object with this report config, and call the pairing this measId." The same object can be reused under several measIds (A3 and A5 on the same neighbour layer); the same report config can be reused across frequency layers. The measId is also what the UE echoes back in measResults, so the gNB always knows which pairing fired.

The events: A1–A6 and B1/B2

Events are the language mobility speaks. Each one is a small inequality comparing a measured quantity against a threshold or against the serving cell, wrapped in hysteresis and timeToTrigger. Get the six intra/inter-frequency A-events and the two inter-RAT B-events straight and you can read almost any operator's mobility policy.

A3 is the workhorse for intra-frequency handover, and it is the one worth writing out. Its entering condition (called the A3 enter or condition 1) compares the neighbour to the serving cell after applying all offsets and hysteresis:

Where M_n is the neighbour's L3-filtered measurement, Of_n/Oc_n are the frequency-specific and cell-specific offsets for the neighbour, Hys is the hysteresis, M_p is the serving (primary) cell measurement, Of_p/Oc_p are the serving-side offsets, and Off is the event's a3-Offset. In plain terms: the neighbour must beat the serving cell by more than the offset plus hysteresis, and stay that way for timeToTrigger. The corresponding leaving condition simply flips the inequality and reverses the sign of hysteresis (add Hys instead of subtract), which is exactly what gives A3 its ping-pong-resistant deadband.

Every event has this enter/leave pair. For a threshold event like A2 the enter condition is Mp + Hys < Thresh and the leave condition is Mp − Hys > Thresh — the same hysteresis band, applied to a fixed threshold instead of to the serving cell. The dual-threshold events (A5, B2) require both sub-conditions to hold simultaneously for the whole timeToTrigger.

The figure below shows the A3 entering condition unfolding over time — the neighbour rising past the effective threshold, the hysteresis and offset that build that threshold, and the timeToTrigger window that must elapse before the report is sent.

Every event's enter and leave conditions

A3 is written out above; here is the same enter/leave treatment for all of them (TS 38.331). Two rules make the whole table readable: every enter condition subtracts Hys from the "rising" side (so the trigger must be clearly met), and every leave condition flips the inequality and adds Hys — that opposite-sign hysteresis is the deadband that stops ping-pong. Every condition must also hold for the whole timeToTrigger before it fires.

Notice the pattern families: threshold events (A1, A2, A4, B1) compare one measurement to a fixed Thresh; relative events (A3, A6) compare a neighbour to the serving/SCell plus an offset; and dual-threshold events (A5, B2) require a serving-degradation and a neighbour-quality condition to hold at once — that is why they are the "only hand over when the serving cell is genuinely failing" events. A6 uses only cell-specific offsets because the neighbour and the SCell are on the same frequency.

How these map to Conditional Handover (CHO) and NTN

L1 versus L3 filtering, and the quantities

Raw radio is noisy. If the UE evaluated events on instantaneous samples it would trigger on every fading dip. Two stages of filtering — one in the physical layer, one in RRC — turn jittery samples into stable trigger inputs.

L1 filtering happens inside the physical layer, invisible to RRC: the UE averages many reference-signal samples over an implementation-defined window (roughly 200 ms of measurement period) to produce one physical-layer measurement per beam/cell. L3 filtering then sits on top, in RRC, and is fully standardised by quantityConfig. It is a first-order IIR (infinite impulse response) filter applied to each new L1 measurement:

Here M_n is the latest L1 measurement, F_n the updated filtered value, and k the filterCoefficient from quantityConfig (configured separately per quantity). A larger k gives a smaller a, meaning heavier smoothing and slower response; a smaller k tracks the radio more closely and reacts faster. Setting k = 0 makes a = 1 and disables L3 filtering entirely (F_n = M_n). The filtered F_n is precisely what feeds M_n and M_p in the event inequalities above, so quantityConfig and the event thresholds must be tuned together — heavy filtering plus a long timeToTrigger is doubly sluggish.

Three quantities can be measured, filtered, and reported. Which one the event evaluates on is set by triggerQuantity; the others may still be carried in the report for the gNB's benefit.

A common pattern: trigger on rsrp (coverage is what actually drops calls) but include rsrq and sinr in reportQuantityCell so the target-cell selection can favour a less loaded or cleaner neighbour among several that all clear the RSRP bar.

Beam-level versus cell-level and consolidation

In NR a cell is not one beam — it is a set of SSB beams sweeping the sector. So there are really two measurement layers: per-beam values, and a single per-cell value derived from them. Events fire on the cell-level value; the report can also carry the strongest beams.

The UE first measures each SSB beam of a cell separately (indexed by SSB index). It then consolidates those beam measurements into one cell-level quantity using two fields carried in the measurement object / report config:

• nrofSS-BlocksToAverage — the maximum number of the strongest beams to linear-average into the cell value.
• absThreshSS-BlocksConsolidation — an absolute threshold; only beams above it are eligible for the average.

The rule is: take the beams above absThreshSS-BlocksConsolidation, keep at most the nrofSS-BlocksToAverage strongest of them, and linear-average those to get the cell-level result. If no beam clears the threshold, the cell value is simply the single strongest beam. This is why a cell with one excellent beam and several weak ones is represented fairly — the weak beams do not drag its cell-level RSRP down, because they never qualified for the average.

When the event finally fires, the resulting MeasurementReport carries a measResults IE containing: the measId that fired, a measResultServingMOList for the serving cell(s), and measResultNeighCells listing each reported neighbour by physCellId with its consolidated measResult and, if configured, its best beam indexes. The neighbour count is capped by maxReportCells, and after the first report the UE keeps sending every reportInterval up to reportAmount times — so the gNB receives a short stream to act on, not a single snapshot.

Reading a MeasurementReport in the logs

The whole framework converges on one uplink RRC message. A trace shows the event firing after its dwell, then the MeasurementReport itself — the measId that fired, the serving-cell result, and the neighbour list with consolidated per-cell values and best beams. Read it against your measConfig and the event inequality, and the mismatch is your root cause.

Representative UE log (event A3 handover) — illustrative, values vary by vendor/build:

LTE ↔ NR

Summary

Measurements and mobility are one chain, and root-causing a handover problem means finding the broken link: measConfig → measObject → measId binding → L3 filtering → event evaluation → MeasurementReport → gNB decision. If the UE never reports, check that the object exists after the delta, that a measId binds it, that a gap covers an inter-frequency/inter-RAT target, and that the SMTC aligns with the neighbour's SSB. If it reports too late or too early, look at hysteresis, timeToTrigger, the event offsets, and the L3 filterCoefficient — heavy filtering and a long TTT compound into sluggishness. If it reports the wrong target, check per-cell/per-frequency offsets and blacklists.

The mental model to keep: an object says what and when to look (frequency + SMTC), a report config says what makes it worth sending (event + hysteresis + TTT + cadence), the measId welds them and is echoed in the report, and every event is an enter/leave pair whose opposite-sign hysteresis is the ping-pong deadband. Above it all, the UE only ever proposes — the gNB disposes, by answering a MeasurementReport with an RRCReconfiguration carrying reconfigurationWithSync.

Q&A