How to Model Indoor, UAV and FWA Use Cases in a RAN Digital Twin

RAN digital twin modelling becomes technically useful when the model can preserve engineering detail while supporting repeatable calculations. A practical approach connects four workflows: IFC-based indoor modelling, UAV flight path analysis, ecosystem integration and automated FWA eligibility calculations.

The focus was not a generic 3D map. It was the relationship between physical data, RAN and RAT models, propagation predictions, and automation. Atoll provides the interactive planning environment; Naos provides the cloud-native platform for larger-scale automated workflows.

How is IFC data brought into indoor RAN planning?

IFC, or Industry Foundation Classes, is a standardised and neutral interchange format associated with BIM workflows. In this process, an IFC file containing building geometry, floors and materials is imported into Atoll’s in-building environment.

The technical workflow includes:

• importing the building structure and floor information from the IFC file;
• matching materials from the IFC model to materials available in the building model;
• reviewing walls, pillars, windows and other structural elements in the 3D view; and
• correcting material mappings where an automatic match is not available.
   

This step is important because indoor propagation depends on more than the building outline. The model needs to represent the physical obstacles and material assumptions used in the calculation. If a material cannot be matched automatically, the engineer must select an appropriate mapping rather than treating the import as complete without review.

How are outdoor and indoor predictions combined?

Outdoor-to-indoor RF planning can be handled in one workflow. The outdoor propagation calculation is followed to the building façade, after which the indoor propagation model is used inside the building.

The Atoll workflow includes:

• placing indoor radio elements such as active remote units;
• grouping elements into sectors and associating them with a signal source;
• selecting the technology and frequency band for the sector;
• defining relevant calculation parameters, including the vertical calculation range; and
• calculating floor-specific path-loss matrices and coverage.
   

The results can be inspected floor by floor or in a 3D view. Engineers can also test alternative arrangements, such as adding indoor small cells or outdoor micro cells, and recalculate the coverage. The output is a prediction based on the selected data and parameters; it should not be described as a field measurement or as a guarantee of deployed indoor performance.

The workflow also supports data exchange. The building and radio system can be exported to IFC, including components, connections and equipment data. When the file is opened in another Atoll in-building project, the physical and radio elements are already defined, although the logical transmission layer must be recreated before recalculation.

How do you analyse a UAV flight path?

UAV analysis requires the receiver height to change along the route. A linear path analysis workflow can use vector data containing coordinates and altitude information.

The analysis can be structured as follows:

• import or draw a flight path with varying altitudes;
• calculate three-dimensional path loss between the transmitters and points along the path;
• rank the strongest serving candidates at each point;
• calculate radio metrics such as RSRP, SINR and throughput; and
• inspect the results in a grid, on a map or through a profile-style analysis view.
   

The workflow supports the ITU-R P.526-15 air-to-ground propagation model. Point analysis automatically adjusts the receiver height to the altitude of the selected point, which is necessary when reviewing terrain and signal conditions along a changing trajectory.

The results can be filtered, sorted and exported to CSV or Excel. A Google Earth export supports three-dimensional viewing of the route and its altitude changes. This is a visualisation and analysis workflow for a defined trajectory. It is not the same as automatic flight-path optimisation. For exploratory route analysis, one practical approach is to generate a grid of points at different altitudes and inspect the resulting metrics.

Can the digital twin be synchronised with OSS data?

Two integration paths are available. Atoll’s OSS interface can import performance-management data, including traffic counts and interference matrices, as well as configuration-management data. This interface works with Huawei, Ericsson, Nokia and ZTE systems.

For Naos digital twin platform, the integration route uses the Naos Data Access Service and REST APIs. This allows an operator to connect OSS systems, inventory databases and the planning engine through an automated flow.

The relevant engineering questions are:

• Which data objects are authoritative in each source system?
• How frequently should planning data be updated?
• Which configuration and performance parameters are required for the intended calculation?
• How are mismatches between inventory, OSS and planning records handled?

A digital twin can only remain aligned when these data-governance questions are addressed. APIs provide an integration mechanism, but they do not remove the need for source ownership, validation and update rules.

How is FWA eligibility automated?

An API can send a list of points with x, y and z information to Naos. Naos identifies the best server, groups points into batches and runs calculations across workers.

The resulting output can include:

• RSRP-based eligibility against a defined threshold;
• path-loss information from the propagation calculation;
• incidence angles between the transmitter and receiver; and
• azimuth and tilt information that can help an installer aim an outdoor antenna towards the selected server.
   

High-resolution 3D geodata can also be used to validate line of sight, while simulation can be used to consider FWA and mobile traffic on shared sectors. The exact thresholds, propagation models, data quality and operational rules must be defined by the operator. Naos automates the calculation workflow; it does not make the deployment decision independently of those engineering inputs.

What should engineers validate before relying on the model?

The first validation point is data fidelity: building geometry, materials, terrain, clutter, antenna information and network configuration must match the intended scenario. The second is model configuration, including the propagation approach, thresholds, receiver heights and traffic assumptions. The third is the distinction between predicted results, measurements and live-network data.

A robust RAN digital twin is therefore not a single file or a single map. It is a maintained relationship between geodata, network models, prediction engines and operational systems. Atoll supports the detailed interactive work; Naos supports automation and API-based integration. The engineering value comes from keeping those layers consistent and making the assumptions visible.