IT/ALB

Radio Access Network

Starting with the RAN, in the ATCLL infrastructure, the access network is implemented with two technologies (not including the extension): the open-source project srsRAN and the commercial solution CableFree. Both gNodeBs (gNBs) solutions provide a way to expose metrics that can be used to infer the performance of the RAN infrastructure, of the UE, and of the applications. The Metric Servers provide pre-processed data to a common Metric Processor, this component’s job is to receive the data and match RAN and core IDs with the identified users from the Core Network Processor. This way, each chunk of data always corresponds to a registered user in the 5G network.

The srsRAN solution exposes metrics in a push-proactive approach, which works by periodically publishing performance data with Hypertext Transfer Protocol (HTTP) requests to a designated address specified in the configuration files. The CableFree solution, on the other hand, works with pull-proactive logic. It exposes a Websocket remote API server that can be scraped by external Websocket clients that wish to get the gNB performance metrics. This way, the solution for data acquisition in the RAN domain consists on developing two metric servers that will interact with each technology to fetch the performance metrics, process them, and then forward them in the appropriate format and to a location where they can be accessible for other third-party entities to use in orchestration decision to improve the performance of the platform. The srsRAN metrics server represents an HTTP server where the antennas can publish their metrics. The CableFree metrics server represents a WebSocket client that periodically scrapes the gNB’s remote API. Both servers process the data in a common format and then forward it to the ATCLL data platform, where the data can persist and be made available for real-time and historical access.

Core Network

The 5G Core (5GC) in the ATCLL infrastructure is implemented, as previously referred, with the open-source solution Open5GS that can be integrated with the Prometheus monitoring tool. A couple of the Open5GS core network functions offer the possibility to configure an HTTP and Prometheus server that can be scrapped by other entities to gather metrics regarding their performance. The data, stored in a time-series database, can then be accessed for analytics, complex processing, or visualised with other software applications.

From RAN to 5GC, different identifiers (such as IMSI, AMF UE NGAP ID, RAN UE NGAP ID, and rnti) are used at each interface, which prevents direct attribution of RAN-level measurements (such as throughput, channel quality indicators, signal-to-noise ratio, and others) to a physical subscriber. To solve this, we designate the IMSI (present both in the physical SIM and in core network logs) as the single, persistent user identity. A custom log parser was developed for Open5GS’s Access and Mobility Management Function (AMF) that continuously processes container logs to extract real-time mappings between the IMSI and all transient identifiers used in the RAN and core. These mappings enable the metric processor to enrich every RAN measurement (vendor agnostic) with the corresponding IMSI and, consequently, the actual UE.

The same parser also detects key control-plane events (UE registration/deregistration, handovers) and maintains current state. An additional parser for the Session Management Function (SMF) extracts session-layer information, including Data Network Name (DNN), and allocated IPv4 addresses.

Digital Twin

The operational NDT is realized through a large-scale, containerized emulation environment that faithfully replicates both the 5G/B5G network and realistic urban mobility within a controlled, repeatable, and fully observable testbed. To achieve this, the entire radio access and core network are deployed on a Kubernetes cluster using UERANSIM for UEs and GNBs, Open5GS for the 5G core, and SUMO for high-fidelity vehicular traffic simulation. All components (GNB pods, UE pods, core network functions, and simulated vehicles) run as containerized microservices, enabling the instantaneous scaling of hundreds of UEs and tens of GNBs within a single cluster.

Resource consumption, network utilization, and application-layer performance of every pod are continuously collected by the Kubernetes built-in metrics pipeline (via Metrics Server and cAdvisor) and exported to Prometheus. The collection sub-flow described in Figure illustrates how the data is outputted to the data platform. This data includes detailed simulation-state KPIs (number of active GNBs and vehicles, simulation timestamps, antenna GPS coordinates, per-vehicle trajectories, etc.) at each SUMO time step. Vehicle positions and dynamics are also broadcast in real time as standardized ETSI CAM messages over a local MQTT broker, thereby feeding the live virtual representation of the NDT.

Network Probe Android Application

To complement passive monitoring of the physical network with controlled, repeatable, and UE-centric measurements, an additional measurement layer is provided by a custom Android application. This probe acts as a flexible traffic generator and diagnostic tool directly from real user equipment, enabling the on-demand injection of diverse traffic patterns (bulk transfer, low-latency, periodic IoT-like, etc.) and the collection of detailed radio environment parameters (such as RSRP, RSRQ, signal-to-noise ratio, and signal strength) from the UE perspective.

The network probe module is designed to monitor the radio environment. Cellular metrics are collected through the Android TelephonyManager API to continuously extract cell identifiers and low-level signal indicators, capturing critical RF (Radio Frequency) parameters such as RSRP (Reference Signal Received Power), RSRQ (Quality), and SINR (Signal-to-Interference-plus-Noise Ratio), along with the ARFCN (Absolute Radio Frequency Channel Number).

The MQTT Service module is responsible for reliably transmitting the collected data to external systems by managing the connection to a designated MQTT broker. Collected data and test results are formatted into JSON payloads and published to predefined topics on the data collection system broker. Finally, the MQTT service enables remote orchestration of the application from the data collection system, allowing coordinated execution of SpeedTest or iPerf3 tests.

Edge Platform

The edge platform implemented by a cluster of the lightweight Kubernetes distribution optimized for edge computing, k3s, supports the Prometheus monitoring tool, which enables real-time metrics collection, automatic service, pods, and node discovery. With this framework complete, a whole set of metrics that reflected the cluster and application status became available. These metrics mainly consist of gauges and counters. In addition to all the metrics provided by default through the Prometheus Helm chart, the Kubernetes extensions developed in the IT testbed allow application developers to define custom metrics that their containerized applications can expose to assess performance. These custom metrics are also available through the Prometheus API and provide valuable, customizable insights into the state of both the cluster and the applications.