Passive Capture Meets Scripted Testing: When One Tool Does Both

It is 2:15 a.m. An RF engineer sits in the B2 parking level of a shopping mall, smartphone mounted on the dashboard, drive test tool recording. The measurement script runs a VoLTE call cycle every 90 seconds and an HTTP throughput test between each call. Results come in: calls established, throughput acceptable, MOS within target. Green across the board. Mission accomplished, or so it seems.

Yet between two scripted cycles, an incoming VoLTE call triggered by a colleague calling back fails silently. The terminal attempts an RRC Connection Request, receives a Reject, falls back to CSFB, then loses service for 4.2 seconds. The script captures none of this. As far as the tool is concerned, that interval does not exist. The report will show 100% call success.

This scenario is not hypothetical. It illustrates a structural blind spot that has existed since the birth of drive testing: traditional tools only measure what their scripts command. Everything else, meaning the actual experience of the terminal, slips through the cracks.

The gap between scripted measurement and field reality

Scripted drive testing has been a cornerstone of network optimization for over twenty years. A predefined scenario triggers calls, data sessions, and SMS messages in a controlled sequence. The engineer obtains reproducible results, comparable across runs, suitable for operator benchmarking.

But reproducibility comes at a cost: it only captures what it provokes. Industry reports consistently confirm this. Studies by organizations such as Opensignal and the GSMA reveal a persistent gap between drive test KPIs and the quality of experience (QoE) perceived by subscribers. The explanation is structural: scripted drive testing sees only its own stimuli. It ignores spontaneous terminal events, protocol layer transitions, and network procedure failures that fall outside the script.

In concrete terms, here is what a traditional test script systematically misses:

• Radio Link Failures (RLF) occurring between measurement cycles
• RRC state changes (Connected to Idle, Inactive) triggered by the network
• Failed handover attempts not correlated with an active test
• Data sessions initiated by device applications (push notifications, background syncs)
• Call management events (CM) triggered by the network, not by the script
• NAS procedures (attach, detach, TAU) that reveal actual core network behavior

This gap between controlled measurement and subscriber reality is not a configuration flaw. It is an architectural limitation of traditional measurement chains, which rely on a stimulus-response model: the script sends a command, the tool measures the result. Nothing more.

Anatomy of chipset-level passive capture

Passive capture adopts a fundamentally different philosophy. Instead of commanding actions and measuring their outcomes, it continuously listens to everything happening on the terminal, at the lowest possible level: the Qualcomm chipset diagnostic interface (DIAG).

The DIAG interface is a native binary channel that carries internal messages between the cellular modem and the application processor. Every protocol procedure, every state transition, every network event generates a DIAG message before it even reaches the Android layer. This is the closest observation point to the radio network that can be reached on a commercial terminal.

Real-time decoding means every event is interpreted at the moment of reception, not retroactively in post-processing software. An NR_RADIO_LINK_FAILURE is identified at the exact millisecond the modem reports it. An LTE_RRC_STATE_CHANGE is timestamped with DIAG bus precision, well below one second.

This granularity is not an academic luxury. It enables correlation of events that appear unrelated in a post-processing log but are actually linked by intervals of a few tens of milliseconds. For example, a CM_DS_CALL_EVENT_ORIG (call attempt) followed 80 ms later by an LTE_ESM_OUTGOING_MSG (EPS bearer activation) followed 200 ms later by an RRC failure: this sequence reveals a VoLTE bearer dimensioning problem that neither a call script (which will simply see “call failed”) nor a coverage analyzer (which will see correct RF levels) can diagnose alone.

Six protocol layers are decoded simultaneously. Each is filtered by a color code in the interface: RRC in green, RACH in orange, PHY in purple, NAS in cyan, HO in pink, CM in teal. The engineer can isolate a specific layer or view the entire event stream in real time.

Scripted + passive: the convergence that changes the game

Scripted testing and passive capture are not opposites. They answer different questions.

Scripted testing answers: “How does the network perform under controlled conditions?” It is the tool for benchmarking, operator comparison, and post-optimization verification. It produces standardized, reproducible KPIs that are contractually actionable.

Passive capture answers: “What does the terminal actually experience at every moment?” It is the tool for diagnostics, anomaly detection, and understanding network behavior as it manifests on the device.

Combining both on the same terminal, in the same measurement session, fundamentally transforms what a drive test can produce. The engineer launches standard benchmark scripts (VoLTE call campaigns, FTP/HTTP throughput tests, continuous ping, SMS cycles) while simultaneously capturing everything the terminal does outside those scripts, automatically.

The result is a dataset containing both the contractual benchmark KPIs and the complete protocol context of the terminal. When a scripted call fails, the passive capture shows the exact sequence of RRC, NAS, and CM messages that preceded the failure. When throughput drops during an HTTP test, passive events reveal whether a handover occurred, whether a band change (CM_BAND_PREF) was triggered, or whether the terminal suffered an RLF followed by re-establishment.

This level of correlation was previously reserved for heavy measurement chains with dedicated protocol analyzers, external controllers, and post-processing software. Executing it in real time on a commercial Android smartphone, with no additional hardware, changes the economics of drive testing.

For voice quality, MOS scoring is calculated using Google’s ViSQOL algorithm, a perceptual model based on machine learning that evaluates quality without a reference signal. Unlike traditional POLQA approaches that require a known source file, ViSQOL operates in no-reference mode, enabling scoring of both scripted calls and passively captured opportunistic calls alike.

What the Events screen reveals in real-world conditions

The Events screen is the visual embodiment of this convergence. In real-world drive test conditions, it displays a chronological log of every detected event, scripted and passive alike, with millisecond timestamps and protocol layer filtering.

The screenshot below shows a live session: a VoLTE call placed by the user (not by a script), with network events captured automatically, live RF KPIs at the top, and color-coded protocol layer filters.

During a typical field session, the following types of events stream through the log:

NR_RADIO_LINK_FAILURE: the 5G NR modem has detected a loss of synchronization with the serving cell. This event, captured passively, is invisible to a script that is not testing 5G coverage at that precise moment. It is timestamped and correlated with the cell’s PCI, RSRP (-115 dBm), RSRQ (-13.6 dB), and SNR (-1.2 dB) measured at the moment of failure.

LTE_RRC_STATE_CHANGE: the terminal transitions from RRC_CONNECTED to RRC_IDLE or vice versa. These transitions, commanded by the network via inactivity timers or explicit releases, are fundamental to understanding subscriber-perceived latency. A terminal oscillating rapidly between Connected and Idle (the “ping-pong” effect) generates additional latency at every connection resumption.

CM_DS_CALL_EVENT_ORIG: a call attempt is initiated. The CM (Call Manager) event captures the origin of the call, whether triggered by the script or by the terminal user. In dual SIM mode, each SIM generates its own CM events, identified separately.

LTE_ESM_OUTGOING_MSG: an outgoing message from the ESM (EPS Session Management) layer is emitted. These messages control the activation, modification, and deactivation of EPS bearers. Their passive capture reveals network resource allocations that precede each data session or VoLTE call.

CM_BAND_PREF: a band preference change is detected. This type of CM event indicates that the terminal or network has modified its band selection strategy, often in response to degraded RF conditions or an operator policy.

CM_SSAC_TIME: an event related to Service Specific Access Control, the 3GPP mechanism that regulates access to voice and video services during congestion. Its passive capture reveals network access restrictions that directly impact subscriber experience but are completely invisible to a traditional test script.

At the top of the screen, live RF KPIs provide permanent radio context: RSRP, RSRQ, SNR, RSSI. A badge indicates the active technology (4G or 5G) with the serving cell’s PCI (Physical Cell Identity). Full cell identity is available: ECI (E-UTRAN Cell Identifier), TAC (Tracking Area Code), eNB ID. In dual SIM mode, each SIM displays its own indicators.

During a typical 30-minute session in an urban area, it is common to capture more than 40 distinct events, all timestamped, filterable, and searchable. The built-in search engine allows instant retrieval of any specific event type across the entire session history.

Beyond measurement: understanding what the network actually does

The combination of scripted testing and passive capture on a single commercial Android smartphone, with no rack, no external controller, and no per-feature licensing, represents a fundamental shift in drive test methodology. It is no longer a choice between controlled measurement and real-world observation. It is both, simultaneously, on the same device, in the same results file.

For network optimization teams, the question is no longer “do our scripts show compliant KPIs?” but “what is actually happening on the terminal between our measurements?” The answer to that second question is often where the real problems reside: silent Radio Link Failures, erratic RRC transitions, VoLTE bearer failures that nobody sees because nobody is looking.

Traditional measurement chains were designed in an era when drive testing primarily served to validate coverage and throughput. Modern 4G/5G networks, with their protocol complexity, advanced mobility procedures, and real-time services (VoLTE, VoNR), demand a level of visibility that the scripted model alone can no longer provide.

The question for every field team is straightforward: what percentage of network reality are your current tools actually capturing?