Measurements & Events (A1–A5, B1/B2) in LTE 4G

Introduction

Connected-mode measurements are the RRC framework (TS 36.331) that feeds every handover decision in LTE. The eNB hands the UE a set of measurement objects, report configurations, and the links between them; the UE evaluates them continuously against the live radio and sends a MeasurementReport only when a configured condition fires. The physical quantities themselves — RSRP, RSRQ, RSSI — are defined in TS 36.214.

This machinery runs in RRC_CONNECTED, once the UE has a bearer and a C-RNTI, and it is the direct precursor to network-controlled mobility: intra-frequency and inter-frequency handover, inter-RAT fallback to 3G/2G, load-balancing, and redirection. Unlike idle-mode reselection — which the UE decides alone — here the UE only supplies evidence; the eNB owns the decision and issues the handover command.

Because the whole chain is a set of cooperating pieces — object (what) + report config (when) bound by a measId, stabilised by layer-3 filtering, delivered through measurement gaps — a mobility problem almost always localises to one piece: a wrong object frequency, an event threshold that never fires, a filter too heavy, or a gap never configured. Knowing which piece broke turns "handover isn't happening" into a specific parameter to check.

Why measurements are needed

Concretely, before any handover the eNB needs radio evidence it cannot gather itself: how strong is the serving cell right now, and is any neighbour clearly better? The naive approach — stream raw samples continuously — would drown the uplink and still deliver noisy data. So LTE flips it: configure the UE to watch for specific conditions and speak up only when one is met and stays met. That keeps the air interface quiet, and it makes the mobility decision repeatable, because every report already represents a condition the network chose to care about.

measConfig — anatomy of the configuration

The measConfig IE is the complete instruction sheet the eNB sends to configure UE measurements. It is not one flat blob; it is a small set of cooperating parts, each an add/modify/remove list so the eNB can incrementally reconfigure a UE without resending everything. When the UE receives a measConfig inside an RRCConnectionReconfiguration, it merges each list into its stored measurement configuration (its VarMeasConfig) and then evaluates the results continuously.

Four things travel together. The objects (measObjectToAddModList) name the frequency layers to watch. The report configs (reportConfigToAddModList) define the conditions and the reporting behaviour. The measurement identities (measIdToAddModList) pair one object with one report config. And two cross-cutting settings apply to the whole configuration: quantityConfig (the layer-3 filtering) and measGapConfig (the gaps that let a single-receiver UE go off-frequency). There are matching ...RemoveList variants for each list so the eNB can tear entries down.

measObject — what to measure

Every measurement starts with an object that names a piece of spectrum. For LTE that object is a MeasObjectEUTRA, and it answers "which carrier frequency should I watch, and how wide?" Each entry in measObjectToAddModList is tagged with a measObjectId. Its key fields are carrierFreq (the E-UTRA carrier as an EARFCN) and allowedMeasBandwidth (how many resource blocks the UE is allowed to average over — 6, 15, 25, 50, 75, or 100 RB). It also carries neighCellConfig, two-bit information about the MBSFN and TDD configuration of neighbour cells on that frequency so the UE knows how to interpret what it measures there.

Beyond those, a MeasObjectEUTRA can carry a neighbour cell list (cellsToAddModList) with per-cell cellIndividualOffset values, a blacklist (blackCellsToAddModList) of cells the UE must not report, and a frequency-wide offsetFreq. Measuring the serving carrier is intra-frequency; a second MeasObjectEUTRA at a different carrierFreq makes it inter-frequency. The clean mental model: one measObjectId equals one frequency layer to be watched.

Neighbours on another radio technology each need their own object type. A MeasObjectUTRA names a 3G UTRAN carrier (its carrierFreq is a UARFCN), a MeasObjectGERAN names a set of 2G GSM ARFCNs with a band indicator, and a MeasObjectCDMA2000 names a CDMA2000 (1xRTT / HRPD) carrier by band class and frequency. These inter-RAT objects are what make coverage-driven fallback to legacy networks possible, and they are always paired with a ReportConfigInterRAT carrying B1 or B2, never an A-series event.

reportConfig — when and how to report

An object tells the UE where to look. A report config tells it what condition makes a measurement worth sending, and what the report should contain. Each entry in reportConfigToAddModList is a ReportConfigEUTRA (intra-LTE) or a ReportConfigInterRAT (inter-RAT), identified by a reportConfigId. The first choice inside it is triggerType: event (report when a condition is met) or periodical (report on a timer regardless of any threshold, used mainly for network-controlled measurement logging and for reporting the strongest cells).

For an event-triggered config you specify an eventId — A1, A2, A3, A4, A5 for intra-LTE, or B1, B2 for inter-RAT — each carrying its own thresholds or offset. Around the event sit the two anti-ping-pong knobs and the leave behaviour:

• hysteresis — a margin added to the condition so the UE does not flip-flop around the boundary. It widens the gap between the entering and leaving thresholds.
• timeToTrigger (timeToTrigger) — the condition must stay true continuously for this long (e.g. 40, 100, 320, 640 ms) before the UE actually reports.
• reportOnLeave — send an extra report when the leaving condition becomes satisfied, so the eNB learns the event has ended.

Independent of the event, the config sets triggerQuantity (whether the event is evaluated on rsrp or rsrq), reportQuantity (what the report includes — sameAsTriggerQuantity or both), and the repetition behaviour: reportInterval (how often to repeat once triggered, from ms120 up to minutes) and reportAmount (how many reports to send — 1, 2, 4, …, 64, or infinity). maxReportCells caps how many neighbours a single report may list. The table below groups these.

The events: A1–A5 and B1–B2

The event is the heart of a report config. Each event has an entering condition and a mirror-image leaving condition, and hysteresis is applied so the two never coincide. The A-series compares E-UTRA cells; the B-series brings in an inter-RAT neighbour. Learn what each one is for, not just its inequality, because the network picks events by intent.

A3 is the workhorse for intra-frequency handover. Its entering condition compares the neighbour to the serving cell after applying offsets and hysteresis:

Where M_n is the neighbour measurement result, Of_n and Oc_n are the frequency-specific offsetFreq and cell-specific cellIndividualOffset for the neighbour, Hys is the hysteresis, M_s is the serving-cell measurement, Of_s/Oc_s are the serving frequency/cell 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 leaving condition flips the inequality and adds hysteresis on the other side, so a neighbour that dips back only marginally does not clear the event.

The B-series mirrors this for inter-RAT. B1 is the inter-RAT analogue of A4 (a legacy neighbour crosses an absolute threshold), and B2 is the analogue of A5 (serving is failing and a legacy neighbour is strong enough to catch the UE). Because inter-RAT measurement is expensive, B-series events are almost always gated behind an A2 that starts the measurement gaps in the first place.

measId — the glue

You now have objects (what) and report configs (when), but they live in separate lists and nothing happens until you connect them. That connection is the measId. 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." Only now does the UE have a complete, self-contained measurement identity it can start evaluating.

This many-to-many flexibility is the quiet power of the framework. One neighbour frequency (measObjectId) might feed an A1, an A2, an A3, and an A5 config simultaneously, each under its own measId. When the eNB wants to stop watching for one condition, it removes a single measId via measIdToRemoveList without disturbing the object or the report config, which other identities may still be using.

RSRP, RSRQ and layer-3 filtering

Everything above assumes the UE has a stable number to compare. It does not, natively — the physical layer produces noisy per-sample estimates that would trigger events on ordinary fading dips. Two things fix this: well-defined measurement quantities (RSRP and RSRQ) and a layer-3 filter that smooths them before any event logic ever sees them.

RSRP (Reference Signal Received Power) is the linear average, in watts, of the power contributions of the resource elements that carry cell-specific reference signals, within the measurement bandwidth — an absolute signal-strength measure. RSRQ (Reference Signal Received Quality) is defined as N × RSRP / RSSI, where N is the number of resource blocks over which RSSI is measured and RSSI is the total wideband received power (signal + interference + noise). RSRP tells you how strong your cell is; RSRQ tells you how clean it is relative to everything else on the band, which is why RSRQ falls under load even when RSRP holds steady.

Both are then smoothed by quantityConfig. The quantityConfig IE (a QuantityConfigEUTRA for the E-UTRA case, with per-RAT siblings) carries the layer-3 filterCoefficient applied to rsrp and rsrq before events are evaluated. The filter is a first-order IIR: each new physical-layer-reported value is blended with the running average.

Here k is filterCoefficient and M_n the latest layer-1 value. A larger k means heavier smoothing and slower response; a smaller k tracks the radio more closely; fc0 effectively disables filtering. The filtered value F_n is exactly what feeds M_n and M_s in the event conditions of the previous section — so filter coefficient and event thresholds must be tuned together. Set k too high and the UE reacts to a fast-moving neighbour too late; too low and it ping-pongs on fading. This filter is one measurement stage; the physical layer already applies its own internal averaging beneath it.

Gaps, the A3 timeline, and the report

There is one hardware wrinkle for LTE: to measure a carrier the UE is not camped on — any inter-frequency or inter-RAT layer — the UE must retune its single receiver away from the serving cell. It cannot receive and measure at the same time. The eNB therefore configures measGapConfig, a periodic pattern (gp0 at 40 ms period or gp1 at 80 ms period, each a 6 ms gap) during which no serving-cell scheduling happens so the UE can go and measure. This is exactly why A2 is used to start gaps when serving quality drops, and A1 to stop them once serving recovers — measuring off-frequency costs throughput, so you only pay for it when you might actually need to move.

Now put the trigger together as a timeline. The diagram below shows the classic A3 case: the neighbour curve rising until it crosses the serving curve plus the offset, the condition then held for timeToTrigger, with hysteresis as the band that stops noise from re-triggering.

When timeToTrigger expires with the condition still true, the UE builds a MeasurementReport carrying a measResults IE. Inside it: the measId that fired (so the eNB knows which pairing), the serving-cell result via measResultPCell, and measResultNeighCells listing each reported neighbour by physCellId with its rsrpResult and rsrqResult. The number of neighbours is capped by maxReportCells, and which quantities appear depends on reportQuantity. After the first triggered report the UE keeps reporting every reportInterval up to reportAmount times, so the eNB receives a short stream rather than a single snapshot — and then typically issues the handover command.

Reading a MeasurementReport in the logs

The report is where the whole framework becomes visible: the measId tells you which object/report-config pairing fired, and the encoded results are what the eNB acts on. rsrpResult/rsrqResult are reported as quantised indices (RSRP 0–97, RSRQ 0–34), not dBm/dB — you convert them back to read the RF.

Representative log — illustrative, values vary by vendor/build:

Summary

LTE measurements are the evidence pipeline for network-controlled mobility, and they debug best piece by piece. The measConfig inside an RRCConnectionReconfiguration merges three lists into the UE's VarMeasConfig: objects (what layer, by carrierFreq), report configs (which event and thresholds), and measIds (the glue binding one object to one report config). Two cross-cutting settings shape the whole thing: quantityConfig's layer-3 filterCoefficient stabilises RSRP/RSRQ before any event sees them, and measGapConfig carves out the gaps a single-receiver UE needs to measure off-frequency.

The events encode intent — A1/A2 manage gaps, A3 is the relative intra-frequency workhorse, A4/A5 handle coverage and load, B1/B2 fall back to legacy RATs. When the condition holds for timeToTrigger, the UE sends a MeasurementReport echoing the measId and the measResultPCell/measResultNeighCells the eNB acts on. When a handover does not happen, localise it: wrong object frequency, an event that can't enter, a filter too heavy, a missing gap, an unbound measId, or a report the eNB can't act on. Each points at one specific parameter.