Before a team repeats a drive or proposes a network change, it often has several possible explanations and interventions to compare. CAKRA is introducing Virtual Drive Test (VDT) as a place to examine those possibilities in a declared, repeatable scenario. The feature is available to Enterprise organizations with VDT access enabled.
VDT estimates what a configured radio scenario could look like along a route. It is a planning workbench, not a replacement for a measurement vehicle, an operator inventory, or acceptance testing. That boundary is part of the product: inputs, warnings, and run provenance are kept visible beside the resulting predictions.
Start with a declared scenario
A VDT study begins with site and sector positions, radio settings, antenna parameters, receiver assumptions, and a route. Teams can use a virtual loop, draw a path, or bring a suitable GPS route into the workspace. A scenario can be saved, revised, and exported so another engineer can see which configuration produced a particular run rather than reconstructing it from a screenshot.
The workbench also makes environmental inputs explicit. Imported terrain, antenna patterns, and a study-specific building dataset can change the calculation when supplied and enabled. Buildings visible on a basemap are only map context until a separate dataset is imported for the study. Missing terrain or unresolved input references remain visible as limitations rather than being represented as surveyed facts.
Compare the route, not only a headline number
After a run, CAKRA exposes route-level estimates such as serving signal, candidate cell transitions, serviceable samples, and the timeline behind them. The map, trace, and results panels let an engineer inspect where the model changes its serving choice or shows a weak interval. Exports carry predicted samples and run context for review outside the browser.
Teams can change a declared input, run again, and compare scenarios rather than treating the first output as an answer. A changed scenario marks the previous result as stale until it is recalculated. This makes the relationship between an intervention and its modeled effect easier to discuss, while keeping the version of the inputs attached to each result.
Prediction needs an evidence check
VDT uses documented propagation and mobility assumptions. Its defaults are starting values, not a verified description of a particular operator network. A predicted handover is a model transition, not proof of a successful signaling exchange. A percentage of serviceable route samples is not an area-coverage guarantee, and a map building does not automatically become a physical obstacle in the RF engine.
Where measured drive-test data and verified site identity are available, the workbench supports a calibration and validation review with separate fit and holdout portions. Those checks can reveal a model mismatch; they do not by themselves prove field accuracy on an independent route. A decision to change a live network still belongs to the responsible engineering and operator process.
How teams can begin
An enabled Enterprise team can begin with a sample scenario to learn the controls, then replace every illustrative site and radio setting with inputs it can substantiate. The next steps are to define a study area, check source provenance, run a baseline, change one assumption at a time, and review the difference alongside any field evidence. CAKRA does not send configuration changes to a live network.
The release places scenario review in the same CAKRA workspace used for drive-test evidence. Its value is the ability to make an assumption visible and test its modeled consequence before spending time on a field action. The final answer still depends on reliable operator inputs and independent measurements.