Why a Network Digital Twin Needs More Than a 3D Map

A network digital twin is useful only when it represents both the physical environment and the network operating within it. A 3D visualisation on its own may look convincing, but it does not answer the questions operators need to make deployment and commercial decisions: where will coverage reach inside a building, how will a UAV remain connected along a flight path, which households are eligible for FWA, and how can the model stay aligned with the live network?

A practical architecture for addressing these questions combines Atoll’s interactive planning environment for detailed RAN design and optimisation with Naos’s cloud-native automation platform for scaling calculations and connecting workflows through APIs.

What should a network digital twin represent?

A useful network digital twin needs more than a map. It needs a structured representation of the physical environment, the active RAN and RAT configuration, and the predictions or simulations generated from those inputs.

A useful framework has three connected pillars:

• Precision design: high-resolution geodata, 3D terrain and clutter, and detailed building models.
• Automated scale: cloud-native calculations and repeatable workflows that can process large areas.
• Business relevance: outputs that can support engineering, operations and commercial decisions.

This structure matters because the same underlying model can support different teams. Engineering can use it to test network designs. Operations can use updated data to understand network changes. Commercial teams can use calculated FWA eligibility information rather than relying only on manual desktop assessments.

Why does indoor-outdoor modelling matter to deployment decisions?

Indoor coverage cannot always be inferred reliably from an outdoor view. Building geometry, walls, openings and material types affect how the signal propagates into and through a structure. IFC data from a BIM workflow can be imported into Atoll so that the building is represented through its physical geometry and associated materials.

For an operator, the value is not simply a more detailed visual model. The indoor model can be used alongside the existing outdoor macro network to calculate outdoor-to-indoor propagation, visualise coverage by floor and assess alternative layouts.

This workflow supports decisions such as:

• whether the outdoor network provides sufficient indoor coverage at different floors;
• where indoor small cells or outdoor micro cells could be evaluated in a what-if scenario;
• whether a dedicated in-building system needs to be considered; and
• how the building and radio system can be shared with construction or subcontracting teams through an IFC export.

These are planning and simulation outputs, not guarantees of live performance. Field conditions, installation quality, equipment configuration and other deployment dependencies still matter. However, a higher-fidelity model can help teams focus site work and compare options before committing resources.

How can a digital twin support UAV connectivity planning?

UAV planning introduces a three-dimensional problem in which altitude changes the relationship between the aircraft and terrestrial transmitters. Atoll can use imported or drawn flight paths at varying altitudes to analyse connectivity along a trajectory.

The workflow can provide:

• air-to-ground predictions using the ITU-R P.526-15 propagation model;
• RSRP, SINR and throughput results along the path;
• best-server analysis and point-level inspection with receiver height adjusted to the flight altitude; and
• tabular outputs that can be filtered, sorted and exported for further analysis.

A jammer scenario can also be modelled by introducing an interfering transmitter and examining its impact along a flight path. This illustrates an important decision principle: aerial coverage planning is not only about signal presence. It also requires analysis of interference and serving-cell behaviour along the intended route.

The current workflow analyses a defined path. For exploratory analysis, a practical approach is to use a grid of points at different altitudes to investigate potential routes where the desired path is not yet known. That is different from claiming that the software automatically optimises a flight path.

What does automation change for FWA decisions?

FWA qualification can become difficult when every address requires a separate manual assessment. Naos can receive points through an API, identify the best server, group work into calculation batches and return results for an eligibility database.

The resulting output can include:

• a signal-based eligibility criterion using RSRP;
• propagation calculations and path-loss information;
• incidence-angle information that can help indicate the direction for an outdoor reception antenna; and
• a result table and map visualisation that can be returned to another system.

The same planning architecture can also be used with high-resolution 3D data for line-of-sight validation and to simulate multi-service traffic where FWA and mobile users share network resources. These capabilities should be assessed against the operator’s own data, thresholds and deployment process; an eligibility result is not the same as a completed installation or a guaranteed customer experience.

What should executives look for in a digital twin programme?

The executive question is not whether a digital twin can produce an attractive 3D view. It is whether the model can reduce uncertainty in specific decisions and whether it can be maintained as the network changes.

A practical evaluation should ask:

• Can the model represent the physical environments that matter to the business?
• Can engineers reuse detailed Atoll models in automated Naos workflows?
• Can OSS, inventory and planning data be connected through supported interfaces?
• Are outputs clearly distinguished as predictions, simulations, measurements or live data?
• Can engineering, operations and commercial teams use the same underlying information without creating separate silos?

Atoll and Naos address complementary parts of this problem. Atoll is used for interactive, high-precision RAN planning and optimisation. Naos is used to automate calculations at larger scale and expose workflows through APIs. Together, they provide a basis for connecting detailed engineering work with repeatable operational processes.

A network digital twin should therefore be treated as an engineering and data architecture decision, not only as a visualisation project. Its usefulness depends on the fidelity of the inputs, the quality of the network model and the way outputs are integrated into real decisions.