D5.3: Final report on evaluation results and proof of concept demonstrations

D5.3: Final report on evaluation results and proof of concept demonstrations HEU 6G SNS JU Project Grant No. 101096466 D5.3: Final report on evaluation results and proof of concept demonstrations 2 Document properties Document number D5.3 Document title Final report on evaluation results and proof of concept demonstrations Work Package WP5 Editors Francesco Paolucci (CNIT), Michelangelo Guaitolini (CNIT) Authors Asim Zoukarni, Francisco Vogt, Anestis Dalgkitsis, Cyril Hsu, Jose Zerna Torres, Chrysa Papagianni (UVA), Juan José Vegas Olmos, Amelia Pakouline-Navarro (NV), Carlos J. Bernardos, Adam Zahir, Sandra Álvarez, Maria Molina (UC3M), Francesco Paolucci, Michelangelo Guaitolini, Rana Abu Bakar (CNIT), Attila Mihály, Gergely Pongrácz (ERI-HU), Michele Gucciardo (NEC), Anastassios Nanos, Christos Panagiotou, Konstantinos Papazafeiropoulos, Maria Rafaela Gkeka, Anastasia Mallikopoulou, Panagiotis Mavrikos, Maria Goutha, Charalampos Mainas (NUBIS), Chathuranga Weeraddana (UOU), Luis Velasco, Marc Ruiz, Jaume Comellas, Davide Careglio (UPC), Sándor Laki, Gergő Gombos, Károly Kecskeméti, Dávid Kis (ELTE), Andrea Sgambelluri, Faris Alhamed, Emilio Paolini, Massimo Satler, Domenico Uomo (SSSA), Mark Angoustures, Vincent Lefebvre (TSS), Marta Blanco Caamaño, Miguel A. Carnero Fernández (TID), Sultan Ertaş, Zekvan Yilmaz (EBY), Simon Pryor (ACC). Internal reviewers 1. Carlos J. Bernardos (UC3M) 2. Andrea Sgambelluri (SSSA) External reviewers 1. Gergely Pongrácz (ERI-HU) 2. Chrysa Papagianni (UVA) Dissemination level Public Status of the document Final version Version 3 File name DESIRE6G_D5_3_Final_report_evaluation_results_and_proof_of _concept_demonstrations Contractual delivery date 31/12/2025 Delivery date 23/12/2025 D5.3: Final report on evaluation results and proof of concept demonstrations 3 Document history Revision Date Issued by Description V0 October 1st 2025 F. Paolucci; M. Guaitolini Final ToC ready October 29th 2025 First round of contributions November 11th 2025 Second round of contributions V1 November 28th 2025 Internal review December 3rd 2025 Internal review revisions V2 December 10th 2025 External review December 17th 2025 External review revisions V3 December 22nd 2025 Final editing and quality check December 23rd 2025 Submission D5.3: Final report on evaluation results and proof of concept demonstrations 4 Abstract Deliverable D5.3 presents the final evaluation results and comprehensive Proof-of-Concept (PoC) demonstrations within the DESIRE6G project. This document reports on the finalized testbed deployments, the execution of the integrated demonstrators, and the collection and analysis of the final data sets. It provides a consolidated view of the DESIRE6G architecture as realized with the final release components and applications delivered by WP3 and WP4. In alignment with the official project description in the DoA, D5.3 reports: 1. The final integration and validation of the components and applications that will be demonstrated; 2. The performance results and the analysis of the experiments carried out in the integrated testbeds and in the two final demos, with detailed KPI assessment. Building upon the initial evaluations presented in Deliverable 5.2, D5.3 highlights the fully integrated PoC solutions across both global and local testbeds. It provides a detailed account of the deployment, execution workflows, and experimental validation of use cases and applications, with a focus on KPIs such as latency, reliability, scalability, and service assurance. The document reports the following main contributions: • Deployment and integration of DESIRE6G Final Release components across all designated global and local testbeds. • Results from PoC demonstrations, evaluating the achieved KPIs and providing insights into system performance and reliability. • Functional validation of integrated components and use cases, demonstrating the readiness of the DESIRE6G platform for advanced operational scenarios. • Analysis of KPI conformance, informing lessons learned and recommendations for future project phases. By presenting these results, D5.3 provides the foundation for future advanced demonstrations and sets the stage for project activities in Year 3, ensuring that the DESIRE6G platform achieves its envisioned performance and operational objectives. D5.3: Final report on evaluation results and proof of concept demonstrations 5 Keywords Use Case Analysis demonstrators, testing and validation, evaluation, integration, tests, PoCs demonstrations Disclaimer This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101096466. DESIRE6G is supported by the Smart Networks and Services Joint Undertaking. This report reflects only the author's view and the Commission is not responsible for any use that may be made of the information it contains. D5.3: Final report on evaluation results and proof of concept demonstrations 6 Table of Contents 1 Introduction .................................................................................................... 22 2 Final Testbeds ................................................................................................ 24 2.1 Global testbeds .................................................................................................. 24 2.1.1 5TONIC ........................................................................................................................................................................................................................................................... 24 2.1.2 ARNO ................................................................................................................................................................................................................................................................. 31 2.2 Local Testbeds ................................................................................................... 36 2.2.1 PoC#1 Testbed ...................................................................................................................................................................................................................................... 37 2.2.2 PoC#2 Testbed .....................................................................................................................................................................................................................................38 2.2.3 PoC#3 Testbed .....................................................................................................................................................................................................................................39 2.2.4 PoC#4 Testbed.................................................................................................................................................................................................................................... 40 2.2.5 PoC#5 Testbed ..................................................................................................................................................................................................................................... 41 2.2.6 PoC#6 Testbed..................................................................................................................................................................................................................................... 42 2.2.7 PoC#7 Testbed .....................................................................................................................................................................................................................................43 2.2.8 PoC#8 Testbed.................................................................................................................................................................................................................................... 44 2.2.9 PoC#9 Testbed.................................................................................................................................................................................................................................... 45 2.2.10 PoC#10 Testbed ................................................................................................................................................................................................................................ 46 3 Use Cases Integration and Functional Validation ................................................ 48 3.1 Use Cases Integration with DESIRE6G Final Release ............................................... 48 3.1.1 Final Release – Progress from Initial Release ......................................................................................................................................... 49 3.1.2 Integration Methodology and Coordination ............................................................................................................................................. 50 3.1.3 Specific Achievements in the Final Release .............................................................................................................................................. 52 3.1.4 Challenges Addressed in Final Release ........................................................................................................................................................... 53 3.1.5 Component Classification and Final Integration Status ........................................................................................................... 54 3.2 Functional Validation of Components .................................................................... 55 3.2.1 Validation Framework .............................................................................................................................................................................................................. 56 D5.3: Final report on evaluation results and proof of concept demonstrations 7 3.2.2 Cross-Component Integration Testing .............................................................................................................................................................. 57 4 Demo 1: AR with Perceived Zero Latency .......................................................... 60 4.1 Introduction, testbed and components .................................................................. 60 4.1.1 Demo deployment ..........................................................................................................................................................................................................................61 4.1.2 Components ............................................................................................................................................................................................................................................ 62 4.2 Goal of the Demonstrator and KPIs ....................................................................... 64 4.2.1 Objectives .................................................................................................................................................................................................................................................. 64 4.2.2 Target KPIs ............................................................................................................................................................................................................................................... 66 4.3 Demo1 Functional Validation ................................................................................ 67 4.4 Implementation of the application ......................................................................... 69 4.4.1 Distributed AR application workflow .................................................................................................................................................................. 69 4.4.2 Application Hardware and Software components ........................................................................................................................... 70 4.5 Demonstration startup and workflows ................................................................... 77 4.5.1 Startup and steady state ........................................................................................................................................................................................................ 78 4.5.2 Workflow 1: Service Deployment.............................................................................................................................................................................. 85 4.5.3 Workflow 2: Secure MAS Attestation and Runtime Verification .................................................................................... 92 4.5.4 Workflow 3: Combined In-band control-MAS Service Assurance ............................................................................... 95 4.5.5 Workflow 4: IML-driven Service Assurance ................................................................................................................................................ 99 4.5.6 Workflow 5: MAS-driven Service Reconfiguration ........................................................................................................................ 104 4.6 Test and results ................................................................................................ 109 5 Demo 2: Real-Time Digital Twin ..................................................................... 136 5.1 Introduction, testbed and components ................................................................ 136 5.1.1 Demo deployment ...................................................................................................................................................................................................................... 136 5.1.2 Components .........................................................................................................................................................................................................................................138 5.2 Goal of the Demonstrator and KPIs ..................................................................... 140 5.2.1 Objectives ............................................................................................................................................................................................................................................... 140 5.2.2 Target KPIs ............................................................................................................................................................................................................................................. 142 D5.3: Final report on evaluation results and proof of concept demonstrations 8 5.3 Demo2 Functional Validation .............................................................................. 143 5.4 Implementation of the application ....................................................................... 145 5.4.1 Distributed DT application workflow ............................................................................................................................................................... 146 5.4.2 Application tools and software ................................................................................................................................................................................. 148 5.5 Demonstration startup and workflows ................................................................. 149 5.5.1 Startup and steady state ......................................................................................................................................................................................................151 5.5.2 Workflow 1: Service Deployment............................................................................................................................................................................ 153 5.5.3 Workflow 2: IML-based Service Assurance ............................................................................................................................................... 157 5.5.4 Workflow 3: Multi-domain Blockchain Federation ........................................................................................................................ 158 5.6 Test and results ................................................................................................ 160 6 Proof of Concepts (PoCs) .............................................................................. 182 6.1 PoC 1 - Offloading of UPF Functions in BF-3 Smart NIC ........................................ 184 6.1.1 Goal and KPIs .................................................................................................................................................................................................................................... 184 6.1.2 Implementation.............................................................................................................................................................................................................................. 184 6.1.3 Test and results .............................................................................................................................................................................................................................. 186 6.2 PoC 2 - Intelligent Image Monitoring .................................................................. 187 6.2.1 Goal and KPIs ..................................................................................................................................................................................................................................... 187 6.2.2 Implementation.............................................................................................................................................................................................................................. 188 6.2.3 Test and results ................................................................................................................................................................................................................................191 6.3 PoC 3 - Software Performance Monitoring .......................................................... 195 6.3.1 Goal and KPIs .....................................................................................................................................................................................................................................195 6.3.2 Implementation...............................................................................................................................................................................................................................196 6.3.3 Test and results ...............................................................................................................................................................................................................................196 6.4 PoC 4 - SLA-to-Intent Translator........................................................................ 199 6.4.1 Goal and KPIs .....................................................................................................................................................................................................................................199 6.4.2 Implementation...............................................................................................................................................................................................................................199 6.4.3 Test and results .............................................................................................................................................................................................................................. 201 D5.3: Final report on evaluation results and proof of concept demonstrations 9 6.5 PoC 5 - CU-UP Offloading .................................................................................. 205 6.5.1 Goal and KPIs ................................................................................................................................................................................................................................... 206 6.5.2 Implementation............................................................................................................................................................................................................................. 206 6.5.3 Test and results ............................................................................................................................................................................................................................. 208 6.6 PoC 6 - Inter-slice Radio Resource Scheduling .................................................... 211 6.6.1 Goal and KPIs ...................................................................................................................................................................................................................................... 211 6.6.2 Implementation............................................................................................................................................................................................................................... 213 6.6.3 Test and results ............................................................................................................................................................................................................................... 215 6.7 PoC 7 – 5/6G in a backpack – UPF scaling ........................................................... 219 6.7.1 Goal and KPI ......................................................................................................................................................................................................................................... 219 6.7.2 Implementation.............................................................................................................................................................................................................................. 220 6.7.3 Test and results ...............................................................................................................................................................................................................................222 6.8 PoC 8 - Hardware-agnostic AI inference offloading for edge robotics ..................... 223 6.8.1 Goal and KPI ........................................................................................................................................................................................................................................ 223 6.8.2 Implementation.............................................................................................................................................................................................................................. 224 6.8.3 Test and results .............................................................................................................................................................................................................................. 225 6.9 PoC 9 MAS deployment, attestation and secure communication............................. 227 6.9.1 Goal and KPI .........................................................................................................................................................................................................................................227 6.9.2 Implementation...............................................................................................................................................................................................................................227 6.9.3 Test and results ..............................................................................................................................................................................................................................230 6.10 PoC 10 SMO scalability .................................................................................. 231 6.10.1 Goal and KPI ......................................................................................................................................................................................................................................... 231 6.10.2 Implementation.............................................................................................................................................................................................................................. 232 6.10.3 Test and results .............................................................................................................................................................................................................................. 234 7 KPIs Conformance Analysis and Lessons Learnt .............................................. 237 7.1 Use cases KPIs ................................................................................................. 237 7.1.1 Augmented Reality (Demo1) ........................................................................................................................................................................................ 237 D5.3: Final report on evaluation results and proof of concept demonstrations 16 List of Tables Table 1. 5TONIC testbed equipment with hardware and software specifications ................................................................... 29 Table 2 ARNO Equipment: Hardware and Software specifications ............................................................................................................... 35 Table 3 POC LIST and LOCAL TESTBEDS ........................................................................................................................................................................................... 37 Table 4. desire6g final integration status .......................................................................................................................................................................................... 54 Table 5 Demo 1: List of modules ..................................................................................................................................................................................................................... 62 Table 6 Demo 1 KPI........................................................................................................................................................................................................................................................... 66 Table 7 Demo 1 Integration Map .................................................................................................................................................................................................................... 68 Table 8 Demo 1 Workflows .................................................................................................................................................................................................................................... 77 Table 9 Accelleran RAN features ................................................................................................................................................................................................................... 80 Table 10 Accelleran RAN interfaces specifications .............................................................................................................................................................. 81 Table 11 Workflow 2 results.................................................................................................................................................................................................................................. 121 Table 12. Components and modules Integrated in Demo 2 .................................................................................................................................. 139 Table 13. KPIs evaluated in Demo 2 for the Digital Twin use case and DESIRE6G Objective O7 .................... 142 Table 14 Demo 2 Integration Map ............................................................................................................................................................................................................. 145 Table 15 POC summary ............................................................................................................................................................................................................................................. 182 Table 16: Components and modules integrated in poC 1......................................................................................................................................... 184 Table 17 6G UPF Results ......................................................................................................................................................................................................................................... 186 Table 18 6G UPF against existing architectures..................................................................................................................................................................... 187 Table 19 SELF CONTAINED MONITORING ACCURACY KPI TABLE ........................................................................................................... 197 Table 20: self-contained monitoring penalty kpi table ................................................................................................................................................ 198 Table 21 UPF scaling performance ............................................................................................................................................................................................................222 Table 22 UPF control plane performance ....................................................................................................................................................................................... 223 Table 23. Components and modules Integrated in PoC 8 ...................................................................................................................................... 224 Table 24 COMPONENTS AND MODULES INTEGRATED IN POC 9.............................................................................................................227 Table 25 MAS Deployment Workflow Metrics .........................................................................................................................................................................230 Table 26 SECaaS Overhead Measurements ................................................................................................................................................................................. 231 D5.3: Final report on evaluation results and proof of concept demonstrations 17 List of Acronyms 3GPP 3rd Generation Partnership Project AAL Acceleration Abstraction Layer AF Application Function AI Artificial Intelligence AI/ML Artificial Intelligence / Machine Learning AIaaS Artificial Intelligence as a Service AP Access Point AR/ VR/ XR Augmented Reality/ Virtual Reality/ Extended Reality ASIC Application Specific Integrated Circuit BWE Bandwidth Enforcer CFS Control Flow Shadowing CID Connection ID CODP Communication and Dissemination Plan CPU Central Processing Unit CU Centralized Unit CUDA Compute Unified Device Architecture DFP Data Flow Programming DLINT Deterministic Lightweighted In-Band Network Telemetry DLT Distributed Ledger Technology DNN Deep Neural Network DPU Data Processing Unit DT Digital Twin DU Distributed Unit E2E End-to-End FPGA Field Programmable Gate Array FPS Frames Per Second GPU Graphics Processing Unit GUI Graphic Users Interface HAP High-Altitude Platform HD High Definition HH Heavy hitter D5.3: Final report on evaluation results and proof of concept demonstrations 18 HLIR High-Level Intermediate Representation HQoS Hierarchical Quality of Service HW Hardware IML Infrastructure Management Layer INT In-band Network Telemetry IoT Internet of Things ITU-T International Telecommunication Union Telecommunication standardization sector K8S Kubernetes KPI Key Performance Indicator KVI Key Value Indicators L4S Low Latency, Low Loss, Scalable Throughput LEO LEO LO-DP Load Optimizer data plane MAS Multi Agent System MIMO Multiple-Input and Multiple-Output ML Machine Learning MLFO Machine Learning Function Orchestrator MR Mixed Reality NF Network Function control plane NF-DP Network Function data plane NFR Network Function Routing NGMN Next Generation Mobile Networks NIC Network Interface Card NN Neural Network NS Network Service OAM Operations, Administration and Maintenance O-RAN Open RAN OVS Open vSwitch P4 Programming Protocol-Independent Packet Processors PDP Programmable Data Plane PLINT Probabilistic Lightweighted In-Band Network Telemetry PM Performance Monitoring PoC Proof of Concept D5.3: Final report on evaluation results and proof of concept demonstrations 19 PPV Per Packet Value QoS Quality of Service RAN Radio Access Network RIC Real Time Intelligent Controller RNN Recurrent Neural Network ROS Robot Operating System RoT Root of Trust RTK Real-Time Kinematic positioning RTT Round-Trip Time SDG Sustainable Development Goals SDN Software-Defined Networking SDN-CP Software-Defined Networking Control Plane SECaaS Security as a Service SLA Service Level Agreement SLAM Simultaneous Localization and Mapping SMO Service and Management Orchestrator SNS IA Smart Networks and Services Infrastructure Association SNS JU Smart Networks and Services Joint Undertaking SO Service Orchestrator SRv6 Segment Routing IPv6 SW Software TRL Technology Readiness Levels UAV Unmanned Aerial Vehicle uCID Micro Connection ID UE User Equipment uFC Micro Flow Cache uRLLC Ultra-High Reliability & Low Latency Communications VES VNF Event streaming VNF Virtual Network Function WAN Wide Area Network D5.3: Final report on evaluation results and proof of concept demonstrations 20 Executive Summary Deliverable D5.3 – Final report on evaluation results and Proof-of-Concept (PoC) demonstrations presents the final outcome of the DESIRE6G project’s experimental activities, consolidating the evaluation results, testbed deployments, functional validations, and PoC demonstrations performed with the Final Release of the DESIRE6G architecture. This document reports the final integration activities started with Deliverable D5.2, providing a comprehensive report of the completed integration, the execution of full demonstrators, and the final assessment of KPIs across global and local testbeds. During Year 3, DESIRE6G partners have completed the deployment of the two global testbeds (5TONIC and ARNO) along with a set of local testbeds specifically designed for PoC, testing the use cases under realistic conditions. The final experimental results validate the feasibility, scalability, and performance of the DESIRE6G architectural components—ranging from service orchestration and federated control to pervasive telemetry, programmable data planes, and AI-driven service assurance. As presented in D5.2, two end-to-end demonstrators provide the backbone of the final evaluation: • Augmented Reality with Perceived Zero Latency, executed in the ARNO testbed, demonstrating ultra-low-latency streaming, intelligent traffic steering, programmable data-plane control, and multi-agent–based service assurance. • Real-Time Digital Twin for Robotics, executed in the 5TONIC testbed, showcasing deterministic networking, reliable wireless connectivity, multi-site orchestration, and GPU-accelerated simulation. In addition, ten PoC evaluations explore technological enablers of the DESIRE6G architecture, including AI-driven optimization, programmable data-plane functionalities, SmartNIC offloading, secure multiagent systems, workload migration, RAN/CU-UP acceleration, SMO scalability, and blockchain-enabled federated orchestration. Key contributions of this deliverable include: • Final Testbed Deployment: Complete description of global and local testbeds, integrating DESIRE6G Final Release components and enabling multi-domain experimentation. • Final PoC Demonstrations: Execution of ten PoCs validating specific innovations in programmable networking, AI, orchestration, security, and RAN/edge acceleration. D5.3: Final report on evaluation results and proof of concept demonstrations 21 • End-to-End Demonstrators: Comprehensive documentation of the final demonstrators, including workflows, KPIs, and system behaviour under realistic conditions. • Component Integration and Functional Validation: Full integration of architectural components across SMO, IML, programmable data plane, monitoring, and intelligent control layers. • KPI Evaluation: Final assessment of latency, reliability, scalability, and service assurance across testbeds, revealing strong performance alignment with project targets. • A synthesis of integration and deployment challenges encountered, along with solutions and recommendations for future 6G system design. Overall, this deliverable provides the final validation of the DESIRE6G architecture, demonstrating its operational readiness, robustness, and suitability as a building block for next generation 6G network systems. The outcomes reported in D5.3 form the foundation for follow-up activities within the wider SNS ecosystem and pave the way for future innovations in distributed, intelligent, and resilient 6G infrastructures. D5.3: Final report on evaluation results and proof of concept demonstrations 22 1 Introduction In the DESIRE6G project, Work Package 5 (WP5) is responsible for the integration, functional validation, and experimental evaluation of key technological components developed across the project. Leveraging distributed global and local testbeds, WP5 evaluates the feasibility, performance, and scalability of the DESIRE6G architecture under realistic operational conditions. Deliverable D5.3 – Final report on evaluation results and PoC demonstrations builds upon the initial evaluation results presented in Deliverable D5.2. While Deliverable D5.2 focused on assessing DESIRE6G Release 1 components and reporting initial PoC demonstrations, D5.3 provides a comprehensive account of the final testbed deployments, integrated PoC executions, and performance evaluation using the DESIRE6G final release. This deliverable consolidates experimental results, functional validation, and KPI assessments, offering a complete picture of the platform’s capabilities. Main objectives of this document are: • Document the final testbed setups, including both global (5TONIC and ARNO) and local PoC environments, and describing the integration of DESIRE6G final release components. • Report the final main demonstrators: this document will report final activities, workflows, hardware and software components related to the first two demonstrators. o AR with perceived zero latency demonstrator o Real-time digital twin demonstrator • Report the final PoC demonstrators, detailing workflows, hardware/software components, and integration processes for each PoC. Specifically, this document will report activities related to the following PoC: o PoC 1 – Offloading of UPF function in BF-3 Smart NIC o PoC2 - Intelligent Image Monitoring o PoC3 - Software Performance Monitoring o PoC4 - SLA-to-Intent Translator o PoC5 – Offloading of CU-UP function in in BF-2 Smart NIC and Tofino Switch o PoC6 - Inter-slice Radio resource scheduling o PoC7 – 5/6G in a backpack – UPF scaling o PoC8 - AI inference workload edge offloading o PoC9 - Secure MAS deployment and attestation D5.3: Final report on evaluation results and proof of concept demonstrations 23 o PoC10 - SMO scalability • Providing a thorough evaluation of KPIs, including latency, reliability, scalability, and service assurance, based on experimental results from all demonstrators and PoCs. • Highlighting lessons learned and insights for further optimization of the DESIRE6G architecture and its application. The deliverable is structure to provide a clear, systematic presentation of results: • Section 2 presents the final global and local testbeds, their configuration, and deployment status. • Section 3 details the integration of use cases with DESIRE6G final release components and functional validation activities. • Sections 4 and 5 describe the main demonstrators, including the AR with perceived zero latency and real-time digital twin applications, covering testbed setup, components, KPIs, and execution workflows. • Section 6 covers the ten PoCs, describing their goals, implementation, and evaluation results. • Section 7 provides a conformance analysis of KPIs across demonstrators and PoCs, and outlines the lessons learnt for future 6G deployments. • Section 8 summarizes the final conclusions. D5.3 represents the final stage of the DESIRE6G experimental and validation efforts, offering final insights into the performance, reliability, and scalability of the integrated platform, and establishing a strong foundation for the whole SNS ecosystem and subsequent project follow up activities. D5.3: Final report on evaluation results and proof of concept demonstrations 24 2 Final Testbeds This section reports the description of the testbeds utilized for the execution of DESIRE6G demonstrators and PoC evaluations. The final setup of each testbed is reported in order to describe in detail the actual experimental environment used for the DESIRE6G architecture evaluation. 2.1 Global testbeds The two main global testbeds are 5TONIC and ARNO, both used for the integration of the DESIRE6G architecture. A comprehensive description of the testbed has been provided in D5.1 [1] and D5.2 [2]. However, this final description includes the details referred to the integrated demo environment including the final AR and DT applications. 2.1.1 5TONIC The 5TONIC testbed 1 has been presented in D5.1 [1], with emphasis on its hardware and software infrastructure, and in D5.2, which detailed its use in the Y2 demonstration of a real-time Digital Twin (DT) system for a quadruped robot, including the integration of early releases of the SMO and IML modules. In this deliverable, we document the final configuration of the testbed and the complete set of hardware and software components employed for the execution of the final integrated demonstration. The testbed is hosted in the 5TONIC laboratory at the IMDEA Networks Institute in Leganés, Madrid (Spain), and is distributed across two rooms: the Main Lab (X3 Indoor Experimentation Room) and the Edge Data Center. 2.1.1.1 Main Lab (X3 Indoor Experimentation Room) The Main Lab (shown in Figure 1) is the physical space where the quadruped robot operates autonomously using the DT system developed for this demonstration. The room is equipped with a full commercial 5G Stand Alone (SA) network provided by Ericsson Spain, including the Radio Access 1 The 5TONIC testbed was officially renamed to NEXTONIC following its 10th anniversary. For consistency with previous DESIRE6G deliverables, we continue to refer to it as 5TONIC throughout this document. D5.3: Final report on evaluation results and proof of concept demonstrations 25 Network (RAN) and the 5G User Plan Function (UPF). This infrastructure provides ultra-low-latency wireless connectivity to the edge data center, which hosts the remaining 5G core functions, the DT application, the data-plane devices, and the DESIRE6G components. The RAN uses an indoor small-cell Radio Unit (Ericsson Dot 4479) mounted on the upper wall of the lab, which provides radio coverage to the robot and connects to the 5G base station (gNB) and the UPF toward the data center, as illustrated in Figure 2. FIGURE 1. 5TONIC MAIN LAB (X3 INDOOR EXPERIMENTATION ROOM) The room hosts the quadruped robot prototype used for the DT demo (shown in Figure 3). The robot is the Unitree Go1 Edu platform equipped with a Leotec N100 Mini-PC, a Logitech C920e Full HD camera, a SLAMTEC RPLIDAR A3 laser scanner, and a commercial 5G User Equipment (UE). The onboard Mini-PC extends the robot’s local computing capabilities by running the camera and LiDAR drivers, together with an application wrapper that exposes robot control and state information (e.g., odometry, joint states, and IMU data) over the Robot Operating System (ROS). The full information regarding the robot platform configuration can be found in D5.2 [2]. D5.3: Final report on evaluation results and proof of concept demonstrations 32 interface used to interconnect the devices. The Meta Quest 3 is used as final headset, attested to the switch that connects the edge cluster. FIGURE 6 ARNO: DRONE FACILITY ROOM FIGURE 7 ARNO: POSITIONING SYSTEM, 5G RADIO UNITS AND DATA PLANE DEVICES The room hosts the drone prototype used for the AR demo, assembled at the SSSA lab premises, shown in Figure 9. The drone is a quadcopter with dual on-board companion computer and a flight control. The flight control unit (FCU) is hosted within a Pixhawk 6X board. Two companion boards are interconnected by means of a Gigabit Ethernet interface: 1) an ARM-based Jetson ORIN NX with two micro cameras and 2) a x86 Intel NUC Core i7-1185G7. The Jetson board hosts the AR source app, including object detection capabilities, while the NUC is responsible for the DESIRE6G networking configuration (e.g., embedded P4 switch), including the Quectel User Equipment, attached to the NUC via USB-3 interface and equipped with four antennas suitable for the n78 frequency slot (3300-3800 MHz, TDD). D5.3: Final report on evaluation results and proof of concept demonstrations 33 FIGURE 8 ARNO: DATA PLANE DEVICES FIGURE 9 DRONE QUADCOPTER 2.1.2.2 Control Room and Main Lab Room The control room is adjacent to the Drone facility room. Through a glass wall, it is possible to view and check all the demo operations taking place in the drone room. PCs and monitors are available for launching the demo tests and workflows with full security. The main lab room is placed on the first floor of the CNIT/SSSA premises and includes all the lab facilities, including optical devices, packet-optical programmable devices, routers, server racks, etc. The room is connected to the drone and control rooms via internal cabling using a dedicated Gigabit D5.3: Final report on evaluation results and proof of concept demonstrations 34 Ethernet connectivity. In the lab room, pure control plane devices are deployed within dedicated servers. In particular, one R760 Dell server equipped with NVIDIA A16 GPU is used to host the SMO components and the IML instances and components. Additional servers are utilized to instantiate the secure MAS instances along with software attestation capabilities. The two rooms are shown in Figure 10. FIGURE 10 ARNO CONTROL AND MAIN LAB ROOMS 2.1.2.3 Equipment mapping and list The mapping between the equipment and the main DESIRE6G components integrated in the testbed is shown in Figure 11. Further explanation about the full demo setup is provided in Section 4.1.1. FIGURE 11 ARNO: EQUIPMENT-COMPONENTS MAPPING As shown before, the setup is distributed across two physical locations: the Drone Facility on the second floor and the Main Lab on the first floor. The upper section represents the Drone Facility, where the radio access, data plane, and edge computing infrastructure are co-located to support real-time drone D5.3: Final report on evaluation results and proof of concept demonstrations 35 operations. The programmable data plane is handled by the Tofino switch, the SDN servers and the Drone x86 board, enabling in-network telemetry, traffic steering, and packet manipulation in the whole segments (drone-RAN-SDN-edge). These programmable switch instances interface with the IML and SDN controller, running P4-enabled components and Kubernetes-based orchestration for service deployment. The edge cluster composed of several servers provides computational resources for AIbased analytics, data processing, and AR application hosting. These nodes run Kubernetes workloads and host AR services as well as the Quest 3 headset used for immersive visualization and remote control of drone operations. The servers of the Main Lab host the Service Management and Orchestration (SMO) framework and the Intelligent Management Layers (IML1 and IML2), responsible for data plane deployment and configuration. Nearby, two servers (MAS1 and MAS2) execute distributed AI multi-agents that perform predictive analytics and multi-agent coordination tasks. All these systems are integrated under a control plane that spans both the edge and core domains. The full list of the ARNO equipment used in the demonstrator, along with hardware and software specifications, is detailed in Table 2. TABLE 2 ARNO EQUIPMENT: HARDWARE AND SOFTWARE SPECIFICATIONS Equipment Hardware Software 2x Benetel RUs Benetel SC-705e, 5G Open RAN Remote Radio Unit, eCPRI and Ethernet interfaces API 6.4.0.14 RAN vDU server AS -1015A-MT, CPU AMD Ryzen9 7950X 16cores @3000MHz, RAM 128GB, Linux Ubuntu 22.04.05 LTS, kernel Linux 5.15.0-1032-realtime RAN RIC-CU-CN server Dell PowerEdge R760, CPU Intel(R) Xeon(R) Gold 6438Y+ 128 cores @2000MHz, RAM 251G, GPU NVIDIA A16 Linux Ubuntu 22.04.4 LTS, kernel Linux 6.5.0-41-generic 2x SDN network servers Dell PowerEdge R7515, CPU AMD EPYC 7262 8Core Processor 16 cores @3194MHz, RAM 16GB Linux Ubuntu 22.04.5 LTS, kernel 6.8.060-generic 4x ORIN boards NVIDIA Jetson AGX Orin 64GB, edge AI computing module con CPU Arm Cortex-A78AE 12-core, GPU Ampere 2048 CUDA + 64 Tensor Cores, 64 GB LPDDR5, interfaces Ethernet 10 GbE, PCIe Gen4, USB 3.2, e GPIO. Linux Ubuntu 22.04.5 LTS Tofino switch Hardware: APS Tofino BF2556X, Intel Tofino ASIC (6.5 Tb/s throughput, <400 ns latency), 56 × 10/25 GbE and 6 × 100 GbE ports, programmable packet parser/deparser, matchLinux Ubuntu 18.08.5 LTS, kernel Linux 4.15.0-197-generic x86_64 Barefoot SDE D5.3: Final report on evaluation results and proof of concept demonstrations 36 action pipeline with stateful ALUs, in-band telemetry and traffic metering support, managed via P4Runtime and Barefoot SDE. Control: Intel Xeon CPU D-1548, 2GHz Control server Dell PowerEdge R760, CPU Intel Xeon Gold 6438Y+ 64 core @2000MHz, RAM 256GB, GPU NVIDIA A16 Linux Ubuntu 22.04.5 LTS, kernel Linux 5.15.0-144-low latency MAS server Dell PowerEdge R760, CPU Intel(R) Xeon(R) Gold 6238R CPU @2.20GHz, RAM 256GB Linux Ubuntu 24.04.2 LTS, kernel Linux 6.8.0-87-generic Drone Jetson NX Arm® Cortex®-A78E v8.2 64-bit CPU; GPU Nvidia Amps 1024 core; NVDLA v2.0 and PVA 2.0; 8 GB LPDDR5 1289 bit; RAM 8GB, 102.4 GB/s, Power 10-20 W Linux Ubuntu 24.0.4.2 LTS; Nvidia JetPack 6.1 Drone x86 board Intel® companion x86, quad-core NUC Intel® Core i7-1185G7; Intel® Iris® Xe Graphics; Power 28 W; MAVSDK for Linux Drone Flight Control Unit Pixhawk X6 Autopilot Flight Control System. 32 bit Arm® Cortex®-M7 480 MHz, 2MB flash memory, 1MB RAM; ST32F103 IO Processor; 3x accel/gyro on-board sensors ICM-45686 (with BalancedGyro™), ICP20100 & BMP388 barometer, BMM150 magnetometer. PX4 Flight controller firmware, v1.15.4 Drone external on-board elements Single point LiDAR range finder, 4S LiPo 6300mAh battery. Vicon Tracker 4, dedicated to track rigid bodies and provide highly accurate 6DoF data with low latency. Meta Quest 3 Headset Meta Quest 3 Headset, XR standalone headset, SoC Qualcomm Snapdragon XR2 Gen 2, CPU Kryo Octa-core, GPU Adreno 740, 8 GB RAM, display dual LCD 2064×2208 px per-eye; interfaces Wi-Fi 6E, Bluetooth 5.3 and USB-C. Android-base OS; Qualcomm Snapdragon XR2 Gen 2; Refresh rate up to 120Hz 2.2 Local Testbeds Local testbeds are designed to execute, test and collect results of the DESIRE6G PoCs, extensively described in Section 6. Namely, the following PoCs have been evaluated and for each of them a local testbed is reported (see Table 3): D5.3: Final report on evaluation results and proof of concept demonstrations 37 TABLE 3 POC LIST AND LOCAL TESTBEDS PoC Title Host Description PoC#1 Offloading of UPF Functions in BF-3 Smart NIC CNIT, NV Evaluate UPF offloading using BF-3 SmartNICs; highperformance, low-latency packet processing. PoC#2 Intelligent Image Monitoring ELTE Test intelligent image monitoring and dynamic data plane reconfiguration in industrial scenarios. PoC#3 Software Performance Monitoring TSS, ERI-HU Assess software performance monitoring through timestamp-based metrics for workload execution. PoC#4 SLA-to-Intent Translator EBY Validate SLA-to-Intent translation using LLM-based chatbot and vector database for service identification. PoC#5 CU-UP Offloading UVA, ERI-HU Evaluate CU-UP offloading with SmartNICs and programmable switches in a 5G network environment. PoC#6 Inter-slice Radio Resource Scheduling UVA Test inter-slice radio resource scheduling on a realistic multi-UE, multi-slice 6G RAN/core platform. PoC#7 5/6G in a backpack – UPF scaling ERI-HU Evaluate ERU-HU D6G UPF functionalities (details in section 2.2.7). PoC#8 AI inference workload edge offloading UC3M, NEC, NUBIS Assess AI inference workload offloading at the edge with heterogeneous hardware resources. PoC#9 Secure MAS Deployment and Attestation UPC, TSS Deploy and validate secure MAS agents, attestation, and DLT-based orchestration in a virtualized environment. PoC#10 SMO scalability NUBIS Evaluate SMO microservice scalability and orchestration pipeline performance for large-scale service requests. 2.2.1 PoC#1 Testbed The ARNO testbed, hosted across the CNIT and SSSA laboratories, provides a high-performance, distributed infrastructure for evaluating User Plane Functions (UPFs) accelerated with NVIDIA BlueField3 (BF-3) DPUs. For what concerns PoC#1, the testbed is shown in Figure 12 and integrates programmable networking, edge computing, and RAN/CN elements to address 6G requirements for high throughput, low latency, and large-scale connectivity. Key components employed in PoC#1 include: • Edge and UPF Servers: The Dell PowerEdge servers are equipped with BF-3 DPUs host the UPF functions and offload tasks such as GTP encapsulation and QoS enforcement, leveraging DOCA Flow APIs for hardware acceleration. D5.3: Final report on evaluation results and proof of concept demonstrations 38 • Edge AI Cluster: NVIDIA Jetson Orin modules provide computational resources for AI-based analytics, assisting in network monitoring and service management. • Traffic Generators: the commercial VIAVI Traffic Generator is capable to send and receive L2 and L3 traffic up to 400Gbps; the software-based Cisco Trex traffic generator is able to send up to 100Gbps traffic with custom packet protocol stacking. FIGURE 12 POC 1 TESTBED This configuration enables PoC#1 to demonstrate a scalable and high-performance UPF architecture. By offloading critical UPF functions to hardware while maintaining full orchestration and monitoring, the ARNO testbed validates DESIRE6G’s capability to meet next-generation mobile network performance and reliability requirements. 2.2.2 PoC#2 Testbed In PoC#2, we use the ELTE site of the NPT-Budapest: Network Programmability Testbed. The testbed was built to support the evaluation and validation of data plane algorithms and methods. The testbed relies on servers, high-speed NICs, programmable NICs and programmable switches (Intel Tofino, and PcEngines APU boxes). Key components and their deployment in PoC#2: D5.3: Final report on evaluation results and proof of concept demonstrations 39 • Emulated video sources and robot status traffic: These traffic emulators run on an x86 server (AMD Ryzen Threadripper 1900X 8-Core, 128GB RAM) • Infrastructure and custom data plane NFs at the emulated industrial site: A PcEngines APU x86-based switch represents the gateway node of the industrial site. This is the only node belonging to the Desire6G domain. The node runs the pre-deployed infrastructure NFs (UE2SM, NFR) and any custom P4or eBPF/XDP-based NFs to be deployed. In the PoC, it runs the QoSControl NF. • Infrastructure data planes at the remote site: The gateway at the remote site is a Tofino ASICbased switch (UfiSpace S9180-32X), it only runs the infrastructure NFs at this site. • Industrial controller application: This application is the receiver of the video streams and the robot states. Based on video streams it determines the commands to be sent to the robot. This component runs on another x86 server (AMD Ryzen Threadripper 1900X 8-Core, 128GB RAM) in a container. • Local orchestration: Each site is controlled by a local IML LNFVO instance. At the industrial site, IML runs on the PcEngines APU switch, while at the remote site it is located on the remote server. This setup enables us to show the on-thy-fly data plane reconfiguration capabilities of Desire6G’s unified data plane layer and allows us to measure its effect on the traffic flows (loss, outage, throughput) and the application-level requirements. 2.2.3 PoC#3 Testbed The testbed is set up in TSS’s infrastructure. Two workbenches were implemented within TSS’s infrastructure to cover both fixed-lifetime and persistent software. Because it is more specific, we designed a dedicated workbench for the L2Fwd network function, driven by the TRex traffic generator, monitored with DPDK, and stressed using worker processes from stress-ng. The testbed is shown in Figure 13. Tests were conducted on the following host machine: • OS Version: Ubuntu 24.04.3 LTS • Architecture: x86_64 GNU/Linux • CPU: Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50 GHz • CPU min/max MHz: 1200 / 3900 • Important CPU Flags: constant_tsc D5.3: Final report on evaluation results and proof of concept demonstrations 40 • RAM: 32 GB DDR3 1600 MHz • VirtualBox Version: 7.0.26r168464 • stress-ng Version: 0.17.06 Virtual machines: • VM 1 (trex): Ubuntu_64, kernel 6.5.0-26-generic, 2 CPUs, 2048 MB RAM • VM 2 (l2fwd): Ubuntu_64, kernel 6.5.0-44-generic, 3 CPUs, 2048 MB RAM FIGURE 13 POC 3 TESTBED 2.2.4 PoC#4 Testbed The PoC was implemented on a VM-based single-node testbed to validate the proposed architecture and workflows as shown in the Figure 14. FIGURE 14 POC 4 TESTBED The testbed consists of the following services and functions: D5.3: Final report on evaluation results and proof of concept demonstrations 41 • UI Frontend: Provide frontend components for user input and interaction. • The UI Backend: Acts as an intermediary layer between the UI frontend components and the core backend services within the VM-based PoC testbed • Vector Database: Generates embeddings and performs similarity-based retrieval using a similarity index. • Similarity Check: Evaluates semantic similarity between user inputs and existing services or intents to identify the most relevant matches. • SLA/SLO Creator: Generates SLA and SLO context based on predefined structures and templates. • Intent Creator: Constructs intent context in alignment with the defined intent models and templates. • Agent: Operates as an interaction and reasoning layer between the UI Backend Service and the GPT-mini LLM. Testing was carried out on the following host system: • vCPU: 8 vCPU – Supports concurrent UI requests, embedding generation, and LLM inference calls, similarity check • RAM: 32 GB – Required for in-memory vector database, embeddings, and LLM context handling • Storage: 200 GB SSD – Model cache, embeddings, vectordb, and service/intent repository • Network: 1 Gbps (virtual) – Ensures low-latency calls to external models All components except the external LLM are hosted inside the VM. The vector database runs in-memory with periodic persistence to disk. UI-related components were implemented in Java, while others were developed in Python. 2.2.5 PoC#5 Testbed The complete PoC#5 is deployed and evaluated at the University of Pampa (UNIPAMPA) testbed in Brazil, in collaboration with the SMART NEtworks and ServiceS for 2030 (SMARTNESS) FAPESP Engineering Research Center [3]. The testbed was built to evaluate the potential benefits of offloading tasks from traditional servers to hardware accelerators such as SmartNICs and programmable switches. Figure 15 presents how the testbed is organized and below we detail the components characteristics. D5.3: Final report on evaluation results and proof of concept demonstrations 48 3 Use Cases Integration and Functional Validation The integration work presented in this section represents a natural progression from the foundational efforts we documented in Deliverable D5.2. [2] That earlier deliverable captured our initial experiences deploying and validating the DESIRE6G Release 1 components — essentially our first working prototype. Looking back at where we started and comparing it to where we are now with the Final Release, the difference is quite substantial. What began as a collection of promising but incomplete modules has evolved into a cohesive, production-ready platform. 3.1 Use Cases Integration with DESIRE6G Final Release Throughout the development cycle, there have been several key areas of improvement that collectively define the maturation journey of the DESIRE6G solution: • Component maturity: In Release 1, many components were still in their early stages — functional enough to demonstrate core concepts but lacking the robustness needed for real-world deployment. Over the past year, each module has undergone significant refinement. What were once preliminary implementations have transformed into deployable components supporting final demos and PoCs. • Connections between components: One of the more challenging aspects of building a distributed system like DESIRE6G is ensuring that all the pieces talk to each other effectively. In Release 1, we encountered numerous integration headaches — mismatched data formats, timing issues, and communication bottlenecks between WP3 (control and orchestration) and WP4 (infrastructure and monitoring) components. The Final Release reflects interface refinement, protocol harmonization, and architectural adjustments. Today, these components communicate more seamlessly, with cleaner APIs and more robust error handling than we had originally implemented. • Testing multi-site deployments: Initially, the integration work focused on single-site deployments — getting everything working within one testbed environment was challenging enough. However, real 6G networks will need to operate across distributed, federated infrastructures. Recognizing this reality, we now showcase multi-site deployments for the two D5.3: Final report on evaluation results and proof of concept demonstrations 49 main demos and selected POCs, reflecting the distributed nature of the future 6G network architectures. • Iterations on system stability: One of the most tangible improvements between Release 1 and the Final Release is overall system stability. During early integration testing, issues—race conditions in control plane operations, memory leaks in monitoring agents, configuration conflicts in programmable switches, and synchronization problems in federated orchestration were identified. The Final Release represents the resolution of these challenges through systematic debugging, architectural refinements, and continuous testing cycles. 3.1.1 Final Release – Progress from Initial Release The Final Release integration phase spanned roughly nine months, from late 2024 through mid-2025. During this period, the primary objective has been to achieve operational readiness for DESIRE6G's demonstrators. The focus has been in integration efforts on two distinct use cases; each deployed in its own testbed environment: • Demo1 showcases Augmented Reality with Perceived Zero Latency, deployed at the ARNO testbed in Pisa. This demonstrator pushes the boundaries of ultra-low latency communication, combining edge computing, intelligent traffic steering, and in-band network telemetry. More details are provided in Section 4. • Demo2 demonstrates real-time Digital Twin capabilities for robotics, hosted at the 5TONIC testbed in Madrid. This use case explores cloud-native orchestration, programmable traffic management, and multi-domain domain federation in dynamic scenarios. More details are provided in Section 5. As we documented in deliverable D5.2, Release 1 established the fundamental architectural framework for DESIRE6G. That initial integration validated our basic design assumptions—we proved that the Service Management and Orchestration layer could communicate with Infrastructure Management components, that programmable data planes could be controlled through standardized interfaces, and that pervasive monitoring could collect meaningful telemetry data. These foundational achievements, while modest, gave us confidence to proceed with more ambitious integration goals. The Final Release takes these foundations and builds substantially upon them. Rather than simply validating that components can work together, we now demonstrate that they work together well — D5.3: Final report on evaluation results and proof of concept demonstrations 50 handling complex workflows, recovering from failures, and delivering the performance needed for demanding 6G use cases. 3.1.2 Integration Methodology and Coordination The integration methodology adopted for the Final Release (June 2025) follows the architectural guidelines established in D2.2 [6] and the integration framework defined in D5.1 [7]. FIGURE 21. DESIRE6G ARCHITECTURE AND LAYERS - FINAL INTEGRATION STATUS The Integration methodology involves the following steps. Component-level integration Each module developed in WP3 (Service Management and Orchestration) and WP4 (Infrastructure Management and Pervasive Monitoring) underwent standalone functional testing before testbed deployment. This ensured that individual components met their specified interfaces and functional requirements prior to integration activities. Interface validation D5.3: Final report on evaluation results and proof of concept demonstrations 51 Following component-level testing, interface validation verified communication protocols, data models, and message exchanges between interconnected modules. The integration effort relied on standardized interfaces including: • REST APIs for control plane interactions (SMO ↔ IML, SO ↔ OE) • P4Runtime for programmable data plane configuration (IML ↔ switches, NF-CPs ↔ NF-DPs) • gRPC/Kafka for telemetry data collection (Telemetry Collectors ↔ Agents) • DLT smart contracts for federated orchestration (SO ↔ remote sites) Testbed Deployment and Configuration Validated components were deployed to the ARNO and 5TONIC global testbeds following the infrastructure configurations described in Section 2. Deployment procedures ensured: • Correct placement of control plane components (SMO, IML instances) • Proper configuration of programmable data plane elements (Tofino switches, NIKSS nodes) • Network connectivity verification between sites and across domains (RAN, SDN, edge) • Resource allocation for containerized workloads (Kubernetes, Docker environments) End-to-End Functional Validation After deployment, end-to-end validation verified complete workflows execution from service request through deployment, monitoring, and service assurance. This validation, detailed in subsections 3.2.1 and 3.2.2, confirmed operational readiness for demonstration activities. Coordination Across Partners The integration effort involved close coordination among 12 partner organizations, with clearly defined responsibilities: • NUBIS: SMO orchestration components (DL, SO, SC, Topology) • UPC: Multi-Agent System and MLFO D5.3: Final report on evaluation results and proof of concept demonstrations 52 • ELTE: IML components and infrastructure NFs (NFR, UE2SM, PPV-TM) • CNIT/SSSA: Pervasive service and infrastructure monitoring, INT-based telemetry • UC3M: DLT-based federation mechanisms • TID: DetNet-PREOF transport network • UVA: Optimization Engine • ACC: RAN telemetry and CU-UP functions • NEC: SOL server integration • TSS: Security-as-a-Service (SECaaS) Regular integration meetings, GitLab-based code repositories, and shared documentation ensured alignment across partners and facilitated issue resolution throughout the integration period. 3.1.3 Specific Achievements in the Final Release Final Release integration accomplishes several critical objectives: • Deployment of all planned modules from both WP3 and WP4 were completed. While Release 1 included only a subset of components at varying maturity levels, the Final Release brings together the complete architectural stack—from high-level service orchestration down to programmable data plane elements and pervasive monitoring infrastructure. • End-to-end workflows have been validated, spanning multiple architectural layers, demonstrating complete service lifecycles from initial request through deployment, monitoring, optimization, and eventual teardown. The Final Release integration proves that these multi-layer workflows function correctly across our distributed testbed infrastructure. • Cross-site federation using blockchain-based (DLT) mechanisms is in place (demo 2). This capability enables service orchestration across geographically separated testbeds, with autonomous sites coordinating deployment decisions through smart contracts rather than centralized control. This federated approach represents a significant architectural advancement over the single-site deployments of Release 1. D5.3: Final report on evaluation results and proof of concept demonstrations 53 • Functional validation of closed-loop service assurance and orchestration was reached. The Final Release includes working implementations of intelligent agents that monitor service performance, detect violations of service-level agreements, and trigger corrective actions automatically. These closed-loop capabilities move us beyond static deployment toward truly adaptive network management. 3.1.4 Challenges Addressed in Final Release The Final Release integration demonstrated: 1. Multi-layer orchestration: SMO-driven service deployment coordinating with IML for infrastructure provisioning and MAS for runtime optimization. 2. Programmable data plane control: P4-based switches (Tofino, BMv2, NIKSS) configured dynamically by IML to support NFR, UE2SM, and INT functions. 3. Cross-domain telemetry: End-to-end latency visibility from UE (drone/robot) through RAN and SDN domains to edge, enabling closed-loop service assurance. 4. Federated orchestration: DLT-based federation enabling service deployment across geographically distributed ARNO and 5TONIC sites. 5. AI-driven optimization: MAS agents performing real-time traffic steering decisions based on INT-collected telemetry data. Integration Challenges Addressed Several integration challenges were approached during the Final Release phase: • Interface Alignment: Differences in data model representations between WP3 and WP4 components required harmonization efforts. For example, service descriptors from the SO needed transformation to match IML's internal service graph format. This was resolved through adapter logic in the LNFVO component. • Timing and Synchronization: Coordination of control plane actions across multiple components (e.g., SDN controller programming Tofino switches while IML deploys K8s pods) required careful sequencing to avoid race conditions. Implementation of event-driven triggers and state management in the SO addressed this challenge. D5.3: Final report on evaluation results and proof of concept demonstrations 54 • Testbed Connectivity: Establishing stable, low-latency connectivity between federated testbeds (ARNO in Pisa, 5TONIC in Madrid) required GRE tunneling and VXLAN overlay configuration. Network latency (~30ms RTT) based on preliminary measurement, impacted MAS reaction times in preliminary tests, addressed by co-locating MAS agents with their monitored domains in the Final Release. Component Versioning: Managing dependencies between rapidly evolving components across partners necessitated strict version control and compatibility testing. GitLab-based CI/CD pipelines and containerization (Docker) facilitated versioning and deployment consistency. 3.1.5 Component Classification and Final Integration Status The Final Release encompasses 32 distinct modules spanning four architectural layers, as defined in the DESIRE6G architecture (D2.2). Table 4 presents the classification of integrated components by architectural layer and their integration status at the end of the project. TABLE 4. DESIRE6G FINAL INTEGRATION STATUS Layer Module Responsible partner Integration Status (%) Involved Testbeds Target Demo SMO Layer Data Lake (DL) NUBIS 100% ARNO, 5TONIC Demo1, Demo2 Service Orchestrator (SO) NUBIS 100% ARNO, 5TONIC Demo1, Demo2 Service Catalog (SC) NUBIS 100% ARNO, 5TONIC Demo1, Demo2 Topology NUBIS 100% ARNO, 5TONIC Demo1, Demo2 IBN (SLA-to-Intent) EBY 50% 5TONIC Demo2 DLT-federation UC3M 100% 5TONIC Demo2 Optimization Engine (OE) UVA 100% ARNO, 5TONIC Demo1, Demo2 SDN Controller UPM 100% 5TONIC Demo2 Intelligent Distributed Control MLFO UPC 100% ARNO Demo1 MAS Agents UPC 100% ARNO Demo1 SECaaS TSS 100% ARNO Demo1 IML Layer D5.3: Final report on evaluation results and proof of concept demonstrations 55 LNFVO ELTE 100% ARNO, 5TONIC Demo1, Demo2 Enhanced VIM (EVIM) NUBIS 100% 5TONIC Demo2 Unified PDP PPV-TM ELTE 100% 5TONIC Demo2 NF Routing (NFR) ELTE 100% ARNO, 5TONIC Demo1, Demo2 UE2Service Mapper (UE2SM) ELTE 100% ARNO, 5TONIC Demo1, Demo2 P4 Data Plane Aggregator ELTE, ERI-HU 100% ARNO Demo1 P4Runtime Proxy ELTE 100% ARNO Demo1 Pervasive Monitoring Telemetry Agent UPC 100% ARNO Demo1 Telemetry Collector CNIT, SSSA, NVIDIA 100% ARNO Demo1 In-band Telemetry (INT+INC) CNIT, SSSA 100% ARNO Demo1 RAN Telemetry Collector ACC 100% ARNO Demo1 Infrastructure Kafka Monitoring SSSA 100% ARNO, 5TONIC Demo2 Network Functions CU-UP UVA, ERI-HU 100% UVA/UNIPAMPA PoC5 UPF ERI-HU 100% NPT-Budapest PoC7 SOL Server NEC 100% 5TONIC Demo1 Demo2 DetNet-PREOF TID 100% 5TONIC Demo2 Modules marked at 100% integration are fully deployed in testbeds and have completed functional validation. The IBN module is integrated at 50% as only selected features (SLA to intent translation) have been employed in the final demonstrators. The entire IBN framework has been integrated in the Ericsson product portfolio. 3.2 Functional Validation of Components Functional validation of DESIRE6G Final Release components verified that integrated modules perform their intended functions correctly and meet interface specifications. This validation extends beyond the unit testing conducted during component development (WP3/WP4) by verifying behaviour in the integrated testbed environment with realistic workloads and interactions. D5.3: Final report on evaluation results and proof of concept demonstrations 56 3.2.1 Validation Framework The functional validation framework applied to both Demo1 and Demo2 encompasses four validation dimensions: 1. Interface compliance validation Each component interface (REST API, gRPC, P4Runtime, etc.) was tested to confirm: • Correct message format and protocol compliance. • Proper handling of request/response exchanges. • Error handling and timeout behaviour. • Authentication and authorization mechanisms (where applicable). 2. Functional behaviour validation Each component's core functionality was verified in the testbed environment: • Data plane components correctly process and forward packets according to configured policies. • Orchestration components successfully deploy and manage service lifecycle. • Monitoring components (Telemetry Collectors, Agents) accurately capture and report performance metrics. • Control components (MAS, SDN Controller) correctly compute and apply optimization decisions. 3. E2E workflow validation Complete workflows spanning multiple components – as defined in D2.2 – were executed and validated: • Service deployment workflow: User request → SO → OE → LNFVO → infrastructure provisioning → service activation. • Service assurance workflow: Performance degradation → Telemetry Agent → MAS → LNFVO → infrastructure reconfiguration. • Telemetry collection workflow: INT data → Telemetry Collector → aggregation → Telemetry Agent → MAS decision. Workflow validation confirmed correct sequencing, data propagation, and error recovery across component boundaries. 4. Integration resilience validation • System behaviour under failure and recovery scenarios was validated. D5.3: Final report on evaluation results and proof of concept demonstrations 57 • Component restart and reconnection. • Network connectivity interruption and restoration. • Resource exhaustion and graceful degradation. • Configuration error detection and correction. These validation dimensions were applied systematically to both Demo1 and Demo2 integrations, with specific test scenarios adapted to each demonstrator's architecture and use case requirements. 3.2.2 Cross-Component Integration Testing Beyond individual component validation, cross-component integration testing verified correct interaction patterns between modules from different architectural layers. Key integration points tested include: SMO ↔ Optimization Engine Integration The Optimization Engine (OE) enhances service deployment decisions: • SO sends an aggregated and end-to-end service request to OE. • OE fetches topology information from Topology Module. • OE computes optimal placement of service components across sites. • OE returns optimized service partitions to SO for deployment. Integration testing validated: • Correct topology representation and consumption by OE. • Optimization algorithms produce feasible placement solutions. • Optimized deployments achieve better KPIs than unoptimized baselines. • OE response latency achieves near-real-time requirements (<100ms). SMO ↔ IML Integration The Service Orchestrator (SO) interacts with the Local NFVO (IML) to deploy service components: • SO sends a service descriptor containing application functions and network function requirements. • LNFVO provisions infrastructure resources (compute pods with infrastructure NFs, site-internal network paths). D5.3: Final report on evaluation results and proof of concept demonstrations 64 4.2 Goal of the Demonstrator and KPIs In this section we report the main goals of the AR demonstrator and the KPI that have been evaluated. 4.2.1 Objectives Objective 1 – Validation of a multi-layer, cloud-native 6G architecture integrating AI, telemetry, and serverless function orchestration. The demonstrator aims at validating the DESIRE6G reference architecture presented in D2.2 [6] by showcasing the seamless integration of intent-based orchestration (SMO), distributed AI-based monitoring (MAS), and network function programmability (IML) across federated sites. The system leverages cloud-native and serverless principles to dynamically instantiate, scale, and migrate network and application functions on demand. This enables adaptive distribution of processing tasks across the RAN, transport, and edge domains while maintaining strict latency and reliability guarantees. Objective 2 – Demonstration of hierarchical service assurance mechanisms with multi-layer triggers The demo illustrates the multi-layer service assurance framework of DESIRE6G, highlighting the different reaction paces, visibility scopes, and granularities offered at each architectural layer, applied to the end-to-end one-way latency requirement. It targets three levels of service assurance through different multi-timescale control loops, as shown in Figure 23. FIGURE 23: CONTROL LOOPS IN DIFFERENT LAYERS / TIME SCALES (FROM D2.2) AND THE ONES DEMONSTRATED IN DEMO1 D5.3: Final report on evaluation results and proof of concept demonstrations 65 At the data plane, the In-Network Control (INC) function reacts within microseconds (real-time model at data plane traffic management) to congestion or link degradation, autonomously rerouting affected traffic to pre-set backup paths: using pre-determined routing policies enforced in network functions. At the infrastructure layer, IML modules enable millisecond-level response (near real-time model, local optimization) through workload scaling or migration in Kubernetes and serverless environments, with the help of Pervasive monitoring components (Kafka-based). At the service layers, MAS utilizes service monitoring information (i.e., INT, RAN xApp metrics) and coordinates cross-site optimizations at sub-second timescale (near real-time model, service optimization), ensuring sustained SLA compliance and global service stability. This demonstrates the hierarchical assurance concept of DESIRE6G, where fast local reactions and slower, broader optimizations operate in synergy for end-to-end resilience. Objective 3 – Deployment of secure, distributed multi-agent systems for autonomous monitoring and reconfiguration The demonstrator validates the use of securely attested Multi-Agent Systems (MAS) for autonomous decision-making and performance optimization. Each agent operates close to its monitored domain— RAN, SDN, or edge—processing real-time telemetry to detect anomalies and initiate localized reconfiguration. The D-MUTRA continuous runtime verification framework guarantees trustworthy coordination across agents and sites, while AI-based logic enables adaptive, self-healing behaviour guided by SMO policies. Objective 4 – Realization of a distributed, serverless AR surveillance application as an end-to-end validation scenario identified as a key use case in WP2 The demonstrator employs a distributed Augmented Reality (AR) application as a real-world validation of the DESIRE6G architecture, as identified by WP2 in D2.1. The application uses serverless computing principles to deploy lightweight AI-based functions (e.g., object detection, pose estimation, and 3D reconstruction) dynamically across the drone, edge cluster, and AR headset. Each component—AR1, AR2, and AR3—can be elastically instantiated or migrated according to network and compute conditions. The system exploits real-time telemetry and hierarchical service assurance triggers to preserve an end-toend latency below 10ms even under congestion, resource exhaustion, or RAN degradation. This D5.3: Final report on evaluation results and proof of concept demonstrations 66 demonstrates DESIRE6G’s capacity to sustain latency-critical, distributed serverless applications in a programmable 6G environment. 4.2.2 Target KPIs Table 6 shows the KPI evaluated in Demo 1. We report the use case KPI identified in D2.1 [7] related to the AR/VR use case, with optional target evaluation, and the DESIRE6G Objectives KPI, identified in the project’s proposal [8], related to O7 (demonstration), with mandatory target evaluation. TABLE 6 DEMO 1 KPI KPI type KPI target Measurements AR/VR use case KPI (D2.1) KPI1 -E2E latency: 5ms for the network, <20ms total (ideal), <50 ms total (tolerated) End-to-end service latency AR/VR use case KPI (D2.1) KPI2 - Bandwidth (per-flow): 50-100Mbps (uplink), 130Mbps-960Mbps (downlink) Service Throughput AR/VR use case KPI (D2.1) KPI3 - Reliability: 99% Reliability AR/VR use case KPI (D2.1) KPI4 - Scalability. Number of drones per service: 1/10. Number of users per service: 100 Scalability DESIRE6G Objectives KPIs (O7) KPI7.1: >1000 real/emulated devices, simultaneously requiring > 100 heterogeneous realistic services (including ultra-low latency-bounded services) • SMO scalability in the service orchestration of more than 100 AR services DESIRE6G Objectives KPIs (O7) KPI7.2: all services handled with no manual intervention, including creation and suppression, based on the defined MAS system, with knowledge transfer among MAS for perceived infinite capacity. • SMO computation times of each module • IML computation times • IML instantiation times • IML/SDN flow entry enforcement times • Reconfiguration automation (IML, MAS, PDP) DESIRE6G Objectives KPIs (O7) KPI7.3: <100ms AI-driven decision making (leveraging on appropriate HW acceleration) and re-optimization, guaranteeing the defined KQIs, including end-to-end latency from terminal to edge under varying traffic and service conditions. • Deployment: AI-driven deployment decision (OE) • In-band: reconfiguration at PDP • IML: forecast and reconfiguration • MAS: AI-driven decision DESIRE6G Objectives KPIs (O7) KPI7.4: Dynamic serverless function placement with function redundancy and replication, and topology reconfiguration for • Serverless app deployment placement D5.3: Final report on evaluation results and proof of concept demonstrations 67 application resilience with perceived zerolatency, in the sub-second scale. • IML-based serverless scaling/migration delay 4.3 Demo1 Functional Validation Demo 1 implements the Augmented Reality use case in the ARNO testbed and integrates all the main DESIRE6G architecture components. Specifically, as shown in Figure 24, it integrates software modules belonging to all the architectural layers (i.e., SMO, MAS, IML, infra NF, physical infra-layer). In Demo 1, the functional validation has been exploited by finalizing the integration of each involved component with a validation test against all its interacting components and the preliminary execution of all the planned workflows to check that all the steps are correctly handled by each component as planned and implemented. FIGURE 24 DEMO 1: INTEGRATION OF THE ARCHITECTURAL LAYERS AND MODULES Table 7 reports the integration map of demo 1, where each green cell represents the full bidirectional integration of two peer modules through an interface (I), each orange cell represents the master-slave module dependency in terms of parameter or function (F), each blue cell represents a deep integration through code or internal dependency (C). Up to 33 integration pairs between modules are enforced and tested in demo 1. • The SMO part has been first validated in its northbound modules, with tests involving the SO, the service catalogue, the data lake, and the optimization engine. The aim was to check that the input service graph of demo 1 is correctly handled and processed, producing correct network D5.3: Final report on evaluation results and proof of concept demonstrations 68 service descriptors for the IML. Further validation has been performed by submitting network service graphs to the two IML instances of the demo including the LNFVO, checking that they are correctly processed, and network functions deployment is executed properly with the desired order, place and configuration. • SECaaS and MAS agents have been deeply integrated and tested to check the consistency of the attestation procedure and runtime verification. • MAS integration with Telemetry collectors have been checked carefully, resorting to the existing integration carried out in Y2 demos (see D5.2). • Extensive validation efforts have been put in the integration of the programmable data plane. Deep integration of UE2SM, NFR, INT+INC network functions and tests have been conducted in the full testbed chain to verify that packets are processed correctly, header processing, encapsulation and decapsulation procedures are handled without errors or malformed fields. The P4DPA aggregator is used to compact all the NF onto a single P4 code. In addition, the protocol fields semantic check has been checked. For example, a deep analysis has been carried out to check that latency values are always consistent with the AR packets experienced delay. TABLE 7 DEMO 1 INTEGRATION MAP Module 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 1 DL 2 SO I 3 SC I I 4 Topology I I I 5 MLFO - - - - 6 MAS Agent - - - - I 7 SECaaS - - - - - I 8 LNFVO - I - - - - - 9 NFR - - - - - - - F 10 UE2SM - - - - - - - F C 11 OE - I I I - - - - - - 12 P4DPA - - - - - - - I F F - 13 P4RTProxy - - - - - - - I - - - - 14 Telemetry Agent - - - - I I - - - - - - - 15 Telemetry Collector - - - - - - - - - - - F - I 16 UE INT+INC - - - - - - - F C C - F - - I 17 RAN Telemetry Collector - - - - - I - - - - - - - I - - 18 CU-UP - - - - - I - - - - - - - - - - C 19 Kafka Pervasive Monitoring - - - - - - - I - - - - - - - - - - D5.3: Final report on evaluation results and proof of concept demonstrations 69 4.4 Implementation of the application The demonstrator integrates a distributed Augmented Reality (AR) application designed to show realtime collaboration between aerial and human-operated agents through a 6G-enabled network infrastructure. The use case, fully described in deliverable D2.1 [7] represents a remote surveillance and situational awareness scenario, in which a drone and an AR-equipped operator cooperate to inspect and monitor an inaccessible or obstructed area, leveraging multi-site computing resources and AI-assisted analytics. Using AR Headset, the operator may have an augmented AI-enriched view of the occluded area, with the possibility of detecting objects, persons with their pose (e.g., identifying if they are alive and how they are moving). 4.4.1 Distributed AR application workflow The application workflow is distributed across both Site 1 (RAN domain) and Site 2 (Edge domain), providing the required level of latency and computational efficiency to guarantee immersive experience and real-time involvement. The AR distributed service is depicted in Figure 25 Distributed AR application. The drone, connected via the 5G RAN, captures real-time video streams and transmits them to serverless function AR1, which performs object detection and initial pre-processing using AI models deployed at the drone payloads. The processed video and metadata are forwarded through the RAN and the SDN network to serverless function AR2, hosted in Site 2, where advanced pose estimation, segmentation, and data fusion are performed to refine the visual analysis. At the final stage, AR3, executed on a Quest 3 AR headset, receives the reconstructed scene and semantic overlays, providing the surveillance operator with immersive situational awareness. The operator can visualize detected objects, obstacles, and human movements within the environment in real time. Control feedback, such as drone navigation adjustments or camera focus commands, is sent back to Site 1, closing the interactive control loop between the drone and the operator. D5.3: Final report on evaluation results and proof of concept demonstrations 70 FIGURE 25 DISTRIBUTED AR APPLICATION This distributed processing chain—spanning AR1 (object detection), AR2 (pose estimation), and AR3 (3D reconstruction and feedback)—demonstrates the low-latency, high-reliability, and AI-driven capabilities of the DESIRE6G architecture. The experiment validates how programmable networking, real-time telemetry, and multi-agent orchestration can sustain XR applications requiring sub-20 ms end-to-end latency, even under dynamically changing network or compute conditions. 4.4.2 Application Hardware and Software components The following section details software and hardware components employed for the AR application: although it is a detailed description of any involved tool, this report goes besides the main objectives of Demo 1. 4.4.2.1 Application tools and software The application system performs real-time visual analysis by using YOLO and ResNet deep neural network models to detect objects within a video feed. Concurrently, it employs a PoseNet model to estimate the body pose of any detected humans. To achieve maximum performance on its NVIDIA Jetson edge computing hardware, all models are optimized using NVIDIA TensorRT, which accelerates inference. Finally, the resulting data, such as bounding boxes and pose keypoints, is efficiently broadcast over the network using the low-latency Zenoh message system. D5.3: Final report on evaluation results and proof of concept demonstrations 71 The system utilizes the GStreamer multimedia framework to manage and transmit the video feed efficiently. A flexible GStreamer pipeline is constructed to capture the raw video stream, often directly from a camera source. This raw data is then immediately processed by an encoder element to compress the video, reducing the bandwidth required for transmission. Then, the feed is packetized using RTP (Real-time Transport Protocol) and finally streamed over the network via a UDP sink, allowing other network-connected applications to receive and decode the live video feed with minimal latency. The user wears a Meta Quest VR device running a native Unreal Engine 5 application on the headset, configured for augmented reality using the Meta XR Plugin and OpenXR. This setup enables the headset's passthrough cameras, allowing the user to see their real-world environment; the application uses a custom C++ network receiver to get bounding boxes and keypoints, that are rendered as a 2D overlay that appears perfectly "locked" onto the real-world objects and people visible through the headset's passthrough cameras. 4.4.2.2 Data Flow and Latency Management The AR application relies on a multi-segment data flow that traverses the RAN, SDN transport network, and edge domains, supported by INT and AI-assisted control loops to ensure end-to-end latency compliance. Video frames and sensor data captured by the drone are processed at AR1, where telemetry tags are embedded using P4-programmable data plane functions. These metadata—carrying timestamps, queue occupancy, and hop latency—are propagated across the SDN network and collected at the edge for real-time MAS analysis. Further internal SDN latency metadata are processed in-network to minimize the latency of the SDN segment with in-network active control. Within Site 2, the Kafka Monitoring and Service Multi-Agent System (S-MAS) continuously analyse the cluster state and the telemetry feedback, respectively. When network congestion, resource contention, or delay spikes are detected, the different layer triggers adaptive actions such as traffic rerouting, function migration, or dynamic resource scaling across edge and RAN domains. This closed-loop control mechanism guarantees that the cumulative latency budget—comprising wireless transmission and transport delay time—remains within 6G service constraints. By coupling realtime INT monitoring with AI-driven orchestration decisions, the system maintains stable frame rates and low motion-to-photon delay, guaranteeing a seamless XR experience for surveillance operators. D5.3: Final report on evaluation results and proof of concept demonstrations 72 4.4.2.3 Drone platform design, implementation and integration This section details the design, development, integration, and validation of the Unmanned Aerial System (UAS) platform designed for the AR application. The main objective was to deploy a customized aerial platform equipped with computation capabilities, onboard sensing and autonomous flight capabilities. The 6G_UAS resulted in an autonomous quadcopter platform designed with a dual onboard computing architecture combining ARMand x86-based companion computers. The flight control stack is built upon PX4 v1.15 and integrated with the MAVSDK library. 4.4.2.4 UAS Design, Configuration, and Component Selection The development process started with a review of the state-of-the-art and an analysis of commercialoff-the-shelf (COTS) components available to meet the specific project requirements. • Configuration Analysis: A comparative analysis of different multi-rotor configurations was performed. The quad-rotor configuration was selected as the optimal solution, providing the best trade-off between payload capacity, size, and energy efficiency for the mission profile. • Airframe and Customization: A commercial carbon-fiber frame kit (Holybro X500) was procured as the baseline frame. This frame has been modified to meet the project-requirements, primarily to ensure the correct housing and integration of the specific hardware components. • Avionics and Computation Architecture: The use-case scenario set requirements for the computing architecture. The final design integrates: 1. A Flight Control Unit (FCU) for the flight stabilization and the real-time drone control. 2. An x86-based companion computer, dedicated to managing high-bandwidth and low latency 5G radio communications. 3. An NVIDIA Jetson Orin NX ARM-based companion computer, featuring accelerated GPU computation, dedicated to executing real-time, onboard inference tasks (e.g., computer vision, AI inference and sensor fusion). In particular, the Holybro Pixhawk Jetson Baseboard Bundle has been selected which embeds in a single board bot the FCU and the NVIDIA companion computer (see Figure 26). D5.3: Final report on evaluation results and proof of concept demonstrations 73 FIGURE 26 HOLYBRO JETSON BASEBOARD BUNDLE 4.4.2.5 Mechanical design, procurement and prototyping To ensure the physical integration of the components onto the customized X500 airframe, several custom mechanical parts were required. These components were designed in-house (CAD) and then built using FDM 3D printing with tough PLA material. This approach speeds up the development process allowing for rapid iteration among improved components versions. In Figure 27 a detail on the attachment for the vision module (a wide FoV stereo camera) payload is provided, along with the enclosure and attachment for the 5G communication module. FIGURE 27 DRONE DETAILS OF THE CUSTOM-BUILT MECHANICAL SUPPORTS The components were stacked vertically: the NVIDIA Orin NX and FCU are mounted on an upper plane, while the Intel NUC is setup at the bottom part and the drone power distribution layer has been organized in the middle of the two plates. The following components have been integrated on the 6G_UAS platform: • Flight Control Unit (FCU): Pixhawk 6X D5.3: Final report on evaluation results and proof of concept demonstrations 80 FIGURE 34 RAN DEPLOYMENT: INTERNAL NETWORKING DETAILS On the left, the Accelleran server hosts two virtual Distributed Units (DU1 and DU2), each interfacing with a dedicated Radio Unit (RU) via front-haul interfaces (f1 for RU1, f2 for RU2). Additional 10GbE interfaces (i.e., f0 and f3) connect the vDUs to the mid-haul transport network, which bridges the RAN domain with the centralized processing layer. The transport network hosts a P4 switch used to create latency violations for specific service assurance experiments (see Workflow 5). This setup allows concurrent operation of multiple DUs, representing separate 5G cells or sectors, while maintaining centralized coordination through the CU. On the right, the DESIRE6G2 server hosts two virtual machines: the RIC/CU (RAN Intelligent Controller and Centralized Unit) and the 5G Core Network (VM core). These are interconnected through a virtual bridge (br0) to the DESIRE6G control plane network and physically linked to the transport network via interface eno12409np1. A further interface, not shown in the figure, connects the server with the Tofino switch to connect the RAN with the SDN domain. This configuration provides an end-to-end functional chain from the radio interface to the 5G core, enabling testing and validation of O-RAN-compliant interfaces (F1, E1, and NG) and control loops. For the scope of the MAS workflow, the DU1 traffic (RAN control + user plane) is steered to interface f0, while DU2 traffic is steered to f3. The full RAN setup software versions, relevant configurations and interfaces specifications are reported in Table 9 and in Table 10. TABLE 9 ACCELLERAN RAN FEATURES Accelleran RAN features Value Split type Split 7.2 dRAX software version 13.1.2 D5.3: Final report on evaluation results and proof of concept demonstrations 81 CU version 7.0.6 DU 4.1.0 Radio Channel 50MHz TDD pattern DSUUU [5ms] Tx power 24 dBm TABLE 10 ACCELLERAN RAN INTERFACES SPECIFICATIONS Accelleran RAN interfaces Value/Standard FH MAC 3GPP TS 38.321 version 16.13.0 FH PHY, General description 3GPP TS 38.201 version 16.0.0 FH PHY, Physical channels and modulation 3GPP TS 38.211 version 16.10.0 FH PHY, Multiplexing and channel coding 3GPP TS 38.212 version 16.11.0 FH PHY, Physical layer procedures for control 3GPP TS 38.213 version 16.15.0 FH PHY, Physical layer procedures for data 3GPP TS 38.214 version 16.14.0 FH PHY, Physical layer measurements 3GPP TS 38.215 version 16.6.0 FH M-plane O-RAN.WG4.TS.MP.0-R004-v17.01, RFC8071 for Call_Home N2 NGAP 3GPP TS 38.413 v15.6.0 N2 Signalling transport – SCTP, IP 3GPP TS 38.412 v15.4.0 E1 - E1AP 3GPP TS 38.463 v15.6.0 E1 - Signalling transport – SCTP, IP 3GPP TS 38.462 v15.6.1 F1-C - F1AP 3GPP TS 38.473 v15.7.0 F1-C - Signalling transport – SCTP, IP 3GPP TS 38.472 v15.6.0 F1-C PDCP (for control plane only) 3GPP TS 38.323 v15.6.0 F1-C RRC 3GPP TS 38.331 v15.6.0 N3 Data Transport 3GPP TS 38.414 v15.2.0 N3 GTPv1-U 3GPP TS 29.281 v15.7.0 N3 PDU Session User Plane Protocol 3GPP TS 38.415 v15.2.0 E1 E1AP 3GPP TS 38.463 v15.6.0 E1 Signalling transport – SCTP, IP 3GPP TS 38.462 v15.6.1 F1-U – Data Transport 3GPP TS 38.473 v15.9.0 F1-U GTPv1-U 3GPP TS 29.281 v15.7.0 F1-U SDAP 3GPP TS 37.324 v15.1.0 F1-U PDCP 3GPP TS 38.323 v15.6.0 F1-U NR User Plane Protocol 3GPP TS 38.425 v15.6.0 E2 O-RAN.WG3.E2SM-KPM-R003-v05.0; O-RAN.WG3.E2SM-R003-v05.00; ORAN.WG3.E2SM-RC-R003-v06.00; O-RAN.WG3.E2AP-R003-v05.00; O-RAN.WG3.E2SM-CCC-R003-v04.00 D5.3: Final report on evaluation results and proof of concept demonstrations 82 FIGURE 35 ACCELLERAN DRAX DASHBOARD FIGURE 36 ACCELLERAN XAPP DASHBOARD Figure 35 shows the Accelleran dRAX dashboard configured for Demo 1. The dashboard shows the CUUP configuration and the double DU/RU configuration with startup/reset/stop commands, along with the current state of each component. Figure 36 shows the xApps deployed in the dRAX. The UPC DESIRE6G xAPP performing Handover request is visible and its status is “Running” (see Workflow 5). Site 1 DESIRE6G control plane and Tofino-based data plane At the management and control plane, the secure MAS and the IML operate within a virtualized environment. S-MAS is deployed in dedicated virtual machine, while IML is deployed in the Kubernetes environment. The S-MAS interfaces with both the RAN Intelligent Controller (RIC) — responsible for nearreal-time control of RAN behaviour — and the Service Management and Orchestration (SMO) layer, which coordinates cross-site connectivity with Site 2. D5.3: Final report on evaluation results and proof of concept demonstrations 83 The programmable P4 switch (Tofino instance 1) serves as edge point between Site 1 and Site 2, in the data plane space. It is connected to the RAN and the transport SDN network through multiple highspeed interfaces (100 Gbit/s and 40 Gbit/s), enabling per-packet monitoring and forwarding optimization. One instance of Tofino runs Network Function Routing (NFR) and telemetry insertion point (INT). Thus, a first one-way latency measurement on the application packets is available between the drone and the Tofino, acting as full RAN latency measurement point. 4.5.1.2 Site 2 In this section we describe the Site 2 mapping of each service chain component (application and network functions) within the testbed equipment and how it is realized. The mapping of the different subsections is shown in Figure 37 and Figure 38. And the technical details are explained in the next subsections. SDN network Site 1 is connected to Site 2 by means of a 40Gb/s link connecting the Tofino switch instance 1 to a SDN network, composed of different P4 software switches. The SDN network provides a programmable and telemetry-enabled transport layer for end-to-end 6G service orchestration. The infrastructure is composed of a set of P4-programmable switches (N1–N4) managed by an SDN controller (SDNc), monitored by MAS2 and handled by the IML2 layers. Each node in the fabric (P4 N1–N4) implements in-band network telemetry and control (INC) functions, allowing extra metadata insertion and real-time path-level latency monitoring. The INC modules report latency and queue occupancy to the last node of the domain (i.e., N3), which implements the Data Plane Active Collector (DPAC). In fact, this node aggregates and analyses latency data of the SDN domain to detect performance degradations or anomalies. These insights are then used by the DPAC to trigger adaptive configuration updates—for instance, rerouting traffic or rebalancing loads—to maintain the required end-to-end latency and reliability guarantees. It is worth to note that INC functionality is handled fully in-network, in the data plane space, without resorting to IML or MAS for service assurance. In Workflow 3, we show the double-layer assurance performed by DPAC (real time) in the microseconds time granularity and by the MAS (near-real time) in the tens of milliseconds time granularity. D5.3: Final report on evaluation results and proof of concept demonstrations 84 FIGURE 37 SITE 2 SDN DOMAIN IMPLEMENTING IN-BAND TELEMETRY AND CONTROL The network topology follows a partially meshed layout, where P4 N1, N2, and N3 form the primary data path, and P4 N4 provides an alternative route for redundancy or congestion mitigation. The SDNc, implemented in Python, maintains real-time communication and flow rule configurability with each P4 node over dedicated control channels, while MAS2, SMO and IML2 modules operate at a higher orchestration layer, ensuring closed-loop feedback between telemetry, deployment, and control. The border interfaces em0 and em1 connect the SDN segment respectively to Site 1 and to the edge cluster of Site 2, creating a continuous monitored data plane across the entire demonstrator infrastructure. Edge cluster Site 2 hosts the Edge Cluster, which provides the execution environment for latency-sensitive AR applications, telemetry aggregation, and service orchestration functions. At the infrastructure level, the cluster is interconnected through a P4-programmable Tofino switching fabric, consisting of two nodes: • P4_1 (10.30.7.45), operating as a collector branch for in-band telemetry (INT) data generated along the end-to-end path (from RAN to edge across the SDN domain). • Tofino1 instance 2 (10.30.7.53), enabling NFR and real-time INT. The collected INT data are reported to the collector and processed by the s-MAS to detect and localize latency deviations along the end-to-end path (see Workflow 5). D5.3: Final report on evaluation results and proof of concept demonstrations 85 FIGURE 38 SITE 2 CLUSTER NODE AND MANAGEMENT/CONTROL MODULES The edge compute layer is composed of one server (P4_2), acting as final DESIRE6G NFR with D6G header decapsulation and packet forwarding to the edge app, and two NVIDIA Orin nodes (orin3 and orin4) running AI-enabled AR Edge Application (E-app). All the nodes run within a Kubernetes cluster environment and are attested to a local L2 switch. These E-apps receive the augmented streaming from the drone and apply further AR processing (i.e., pose estimation and 3D reconstruction), supporting adaptive rendering and quality adjustment for the Quest 3 headset connected locally to the cluster. At the control and management plane, additional nodes host the Service Management and Orchestration (SMO) framework coordinates all distributed components, including the secure MAS (SMAS), IML, and orchestration submodules such as Service Orchestrator (SO), Data Lake (DL), Topology Manager, Optimization Engine (OE), and Machine Learning Function Orchestrator (MLFO). The SMO also maintains northbound interfaces to Site 1’s MAS and IML, ensuring cross-site synchronization. The pervasive Kafka module oversees monitoring the state of the cluster containers and predict any future resource exhaustion (see Workflow 4). 4.5.2 Workflow 1: Service Deployment The service deployment describes the initial procedure to orchestrate, compute and instantiate the application and the network functions along the sites to allow the full service operativity. This workflow D5.3: Final report on evaluation results and proof of concept demonstrations 86 is shown in Figure 39 and describes the initialization process from the tenant request to when the network and the app is in full operational mode. FIGURE 39 DEMO 1 WORKFLOW 1 Step 1 – Tenant request The tenant sends a request to the Service Orchestrator (SO) for the initialization of the network service (1). Step 2 – Get service description and topology The SO issues a request to get the service description from the service catalogue (SC) (2) and the topology from the topology descriptor (3). This information is then used to generate the service graph. Step 3 – Decomposition The service graph is sent to the Optimization Engine (OE), which is issued with a decomposition request, runs the optimization algorithms (4) and provides all the pre-site network service descriptors at the end of the decomposition and optimization process (5). Step 4 –Transport Connectivity and NF-graph deployment The service orchestrator feeds the SDN controller with the descriptors and issues a request for starting transport connectivity (6), gets notified at the end of the initialization (7) and send sub-graph and NF flow rules to all the IMLs included in the network (8, 10). The IMLs deploy the required functionality and reply to the SO (9, 11). Note that steps 8 and 10 can be started in parallel. D5.3: Final report on evaluation results and proof of concept demonstrations 87 Step 5 – Deployment ready With its components initialized and working in standard mode (12), the network is now ready to operate, providing a closed-loop communication channel between the drone and the AR headset, through the RAN, the three P4 switches and the Kubernetes Edge Cluster. 4.5.2.1 SMO modules functionality and service graphs Demo 1 is structured across three sites. For the sake of deployment phase, the AR service is designed as end-to-end service including the User Equipment and the Drone. Thus, from the point of view of the deployment, the service spans three sites: Site 0 (drone and User Equipment), Site 1 (RAN site) and Site 2 (Edge Cluster site). Initial Service Graph The initial service graph, shown in the corresponding YAML NSD service graph structure is illustrated below, defines the full logical structure of the service before deployment. lnsd: ns-instance-id: "11223344" ns: name: "ARVR Demo1 Scenario" id: "d1" vendor: "D6G" descriptor-version: "1.0" location-id: 40 default-service-id: "30" infra-nfs: [] network-functions: [] application-functions: - instance-id: "edge" id: "arvredge" name: "AR edge app" version: "1.0" domain: "external" static-nfids: [44,45] static-ips: ["10.30.7.213"] is-scalable: true instances: 2 - instance-id: "src" id: " predeployed" name: "AR source app" version: "1.0" domain: "external" is-ue: true - instance-id: "ran" id: " predeployed" name: "RAN" version: "1.0" domain: "internal" is-ue: true static-nfids: [42, 43] static-ips: ["192.168.1.4"] forwarding_graphs: - graph-name: "upstream" direction: "upstream" D5.3: Final report on evaluation results and proof of concept demonstrations 88 links: - id: "upstream-1" connection-points: - if-id-ref: "ran:0" - if-id-ref: "edge:0" - graph-name: "downstream" direction: "downstream" links: - id: "downstream-1" connection-points: - if-id-ref: "edge:0" - if-id-ref: "ran:0" e2e_delay_budget: "25ms" The descriptor begins with the identification and general metadata of the service, specifying the vendor information and the descriptor version to enable consistent version tracking. nsd: ns-instance-id: "11223344" ns: name: "ARVR Demo1 Scenario" id: "d1" vendor: "D6G" descriptor-version: "1.0" location-id: "40" default-service-id: "30" ... It then enumerates all types of functions required for the service, including infrastructure network functions, software network functions, and application functions. infra-nfs: [] network-functions: [] application-functions: - instance-id: "edge" id: "arvrege" name: "AR edge app" version: "1.0" domain: "external" static-nfids: [44,45] static-ips: ["10.30.7.213"] is-scalable: true instances: 2 - instance-id: "src" id: "predeployed" name: "AR source app" version: "1.0" domain: "external" is-ue: true - instance-id: "ran" id: "predeployed" name: "RAN" version: "1.0" domain: "internal" is-ue: true static-nfids: [42, 43] static-ips: ["192.168.1.4"] The final part of the YAML representation includes the forwarding graphs assigned to the service and defines the total SLA end-to-end delay budget. forwarding_graphs: - graph-name: "upstream" direction: "upstream" links: - id: "upstream-1" D5.3: Final report on evaluation results and proof of concept demonstrations 89 connection-points: - if-id-ref: "ran:0" - if-id-ref: "edge:0" - graph-name: "downstream" direction: "downstream" links: - id: "downstream-1" connection-points: - if-id-ref: "edge:0" - if-id-ref: "ran:0" e2e_delay_budget: "25ms" This representation defines how the logical components interact and defines the full scope of the service requirements. In Demo 1, the service descriptor is sent from the Service Orchestrator (SO) to the Optimization Engine (OE) with a decomposition request. Pre-Deployment Optimization The objective of the OE is to compute the way a service graph should be deployed (decomposed) across the DESIRE6G sites including decomposing the corresponding SLO constraints, for example latency. It uses the constraints, abstracted resource availability from the infrastructure, and the service request specification, as presented in Figure 39. When the OE receives the initial service graph in YAML format, it converts it into an internal graph representation using NetworkX [9]. This structure allows the OE to merge real-time site (aggregated resources) and topology information made available to the DESIRE6G SMO, shown in (Step 3 and 4) in Figure 39. As described in Deliverable D3.2, Section 3.2, the OE uses a local Large Language Model (LLM)-based mechanism to select the most suitable optimization algorithm for this specific case. Specifically, the Algorithm Pool submodule contains a list of curated optimization algorithms in Python and additional metadata, such as Abstract Syntax Tree (AST) analysis, complexity analysis and numerical results of previous performance analysis, available in text format. The Prompt Generator submodule concatenates internal agentic pre-prompts, algorithm code analysis and previously evaluated performance, and an optional user defined prompt to guide the selection. The LLM Selector submodule is responsible for the communication with the LLM and handles cleaning the output, retries and re-prompting in case of an invalid response. Posterior of the selection, the graph is forwarded to the selected algorithm from the Algorithm Pool for optimization. For Demo 1, the optimization scenario corresponds to service partitioning under latency constraints, and the OE decides between multiple simplified greedy service graph partitioning strategies to demonstrate the selection process, however in a real-life deployment the Algorithm Pool could be populated and D5.3: Final report on evaluation results and proof of concept demonstrations 96 FIGURE 41 DEMO 1 WORKFLOW 3 Step 1 – INT processed at DPAC and MAS Application traffic packets with latency metrics are analyzed at the sink node equipped with DPAC (INC labels reporting SDN hop latency metrics), while segment INT reports are exported to the Telemetry Collector (1) aggregating per-flow latency and congestion indicators. The Telemetry Collector processes INT generating performance anomaly reports forwarded to the MAS (2). INT reports are locally analyzed and communicated to the other agent in the MAS (3). Step 2 – DPAC extra-latency detection and intervention The SDN network is fed with extra traffic spikes, specifically targeting N1 and N2 with extra traffic generation affecting N1-N2 link. The induction of this extra traffic determines congestion at N1 and a latency increase. The latency increase is immediately detected by the INC-DPAC service, deployed at Node 3 (sink). DPAC provides immediate feedback to Node 1 using INC message, communicating the involved traffic label and the N1 backup port indication (see D4.3 section 7.2 [15]). Step 3 – MAS Notification and PDP reconfiguration Network and flows changings are communicated to the MAS agents in the same way as Step 1 through the Telemetry Collector (5, 6) to grant distributed awareness about the current configuration and traffic status in the network. In the case of sub-optimal flows placement due to the local INC reconfiguration, the MAS decides to trigger PDP reconfiguration communicating with the SDN Controller, in charge to configure the optimal flow and traffic distribution along the network. The reconfiguration may take place D5.3: Final report on evaluation results and proof of concept demonstrations 97 in a different network segment (as depicted for the sake of generality in Figure 41). In the specific test execution, the re-optimization takes place at the same SDN domain in Site 2. 4.5.4.1 INC modules functionality and operation The In-band Network Control (INC) is implemented in the programmable data plane using the P4 language and it works in the SDN transport domain leveraging the L2.5 label forwarding. It uses two distinct headers, one is for performing the routing and monitoring of queuing delays (named SDN INT) and the second is for performing the control and rerouting of the packets (called INC) within the domain. The first header is the routing and monitoring header and is defined in P4 in the following way shown in Figure 42. FIGURE 42 P4 DEFINITION OF THE IN-BAND INT HEADER The SDN INT header is added to the packet right after the ethernet header by the ingress node in the SDN domain and the header contains three fields as shown in Figure 42, the first field is the sdn_label which is a 16 bit field, this label is assigned by the controller and is globally unique, furthermore, it is recognized by all nodes in the path. The label itself represents a set of flows which can be one or more flows grouped by source and destination as well as priority, meaning that if two sets of flows share the same source and destination but differ by priority, they will get assigned two different labels. Subsequent nodes in the SDN that come after the ingress node will read the label field and perform the routing based on the label. While the egress node will remove the L2.5 header and forward the original packet outside the domain. When the SDN INT header gets inserted the ethernet-type field of the ethernet header will be changed to indicate the presence of the SDN INT header, therefore it is necessary to preserve the original ethernet-type field, this is done by storing the ethernet-type field of the original packet in the 16-bit original_ether_type field of the SDN INT packet, so when the packet exits the SDN domain the value of this field is copied back to the ethernet-type field of the original packet. The third and last field of the SDN INT header is the 48-bit sdn_latency, which starts at zero when the SDN INT header is first inserted and then gets updated (by adding queuing delay) by each node in the network path including the ingress node which inserted the SDN INT header, The SDN controller then header sdn_int_t { bit<16> sdn_label; bit<16> original_ether_type; bit<48> sdn_latency; } D5.3: Final report on evaluation results and proof of concept demonstrations 98 at each egress node of different network paths (identified by different labels) configures a latency threshold that get checked for each packet at the SDN Egress node which also acts as the Data Plane Active Collector (DPAC), when a violation of the set threshold is detected, an In-band Network Control message is generated immediately by the DPAC from the packet where the violation has happened and is forwarded to the ingress node, the definition of this INC header is shown in Figure 43 and is composed of three fields, first one is a 16-bit sdn_label which is the backward control label that serves for sending the control message to the ingress node. Then there is a 7 bit reserved field filled with zeros as it is not used and serves to give the header a length that is a multiple of an integer number of bytes, then finally there is the output_port field which has a length of 9 bits and basically it tells the ingress switch where to reroute the traffic of the monitored flow (the flow that is suffering from an increase in queuing delay). The ingress switch knows which flow to reroute based on the received INC sdn_label. FIGURE 43 P4 DEFINITION OF IN-BAND NETWORK CONTROL PACKET Test results of the SDN In-band Network Control show the possibility of performing the reroute on the order of the speed of packet forwarding by the switch. This framework of in-band network telemetry and control is achieved by using P4 tables and registers to assign the output port of the incoming packets. Where a table assigns labels to incoming packets to identify their destination and priority (latency threshold) and then by mapping the label to a register number it is possible to read and write the output port in the data plane itself without the direct controller interaction enabling real time packet forwarding and rerouting. After the rerouting in the data plane happens which serves as an immediate remedy to the congestion problem caused by traffic bursts, the SDN controller is informed about this new configuration by the egress node that triggered the In-band Network Control so the controller can update its network description and recalculate the routing in the SDN domain. 4.5.4.2 MAS modules functionality and operation The MAS consists of two distinct agents: the Multi-Flow Agent (deployed at Site 1) and the Telemetry Agent (deployed at Site 2). header sdn_inc_t { bit<16> sdn_label; bit<7> reserved; bit<9> output_port; } D5.3: Final report on evaluation results and proof of concept demonstrations 99 The Telemetry Agent is responsible for collecting, processing, and transmitting INT data to the MultiFlow Agent. The Telemetry Agent integrates with the P4 Telemetry Collector by exposing a REST API through which telemetry data is periodically injected. The data processing workflow typically involves summarizing the collected information and reducing the number of forwarded measurements when no significant variations are detected. Additionally, the telemetry data is forwarded to an InfluxDB instance for long-term storage, visualization, and further analysis. The Telemetry Agent exposes the following endpoint: - /collector: receive INT reports from the Telemetry Collector. The Multi-Flow agent is responsible for monitoring the different segments of the network to ensure the QoS requirements of the service. In this case, it receives the INT collected by the Telemetry Agent to feed a DRL algorithm that computes the optimal percentage of traffic that the ingress route should send to each path of the packet network. Upon the arrival of a rerouting notification, the Multi-Flow agent sends a petition to the SDN Controller to apply a new routing policy. The Multi-Flow agent exposes the following endpoint: - /QoS: receive processed INT reports from the Telemetry Agent. 4.5.5 Workflow 4: IML-driven Service Assurance This workflow describes how the DESIRE6G architecture counteracts a CPU overload in its main channel, deploying traffic and requests to different nodes, assuring service through IML-driven intervention, by means of the Infrastructure Monitoring provided by Kafka Monitoring and Forecast Engines. Thus, with the AR application pod running in the Kubernetes cluster at the Edge, a load increase is induced in the hardware currently involved in the traffic, determining an alert to the IML which triggers the application scaling request, exploiting the P4 switch to re-route the traffic through a different application pod in the cluster. It is worth to note that IML-based service assurance operates inside its controlled site (Site 2). The workflow is depicted in Figure 44 and described below. D5.3: Final report on evaluation results and proof of concept demonstrations 100 FIGURE 44 DEMO 1 WORKFLOW 4 Step 1 – CPU load increase While the network is working in standard mode, a CPU load is induced (1) to the ORIN currently involved in the traffic: the CPU load increase is collected by the Pervasive Kafka monitoring service. Step 2 – Forecasting, prediction and alarm Due to the CPU load, the Pervasive Kafka service processes monitoring data and predicts a violation in the app SLA (2), feeding an alarm notification to the IML. Step 3 – IML migration/scaling As the IML is alarmed, it issues a command to start the recovery. Recovery may consider either migration or resource scaling. In the case of app migration, the IML (LNFVO) communicates with the involved cluster nodes to first instantiate a replica pod in Node 2 (3a), following the make-before-break approach. Once notified about the successful operation (3b), the IML sends traffic steering command to the cluster internal P4 switch to deviate the traffic towards the new pod (4). In the figure, the IML talks with a SDN controller for sake of generality (5) and receives an outcome ack (6). In this specific workflow, the LNFVO sends forwarding flow rules directly to the P4 switch resorting to its deployed network service graph (i.e., 4 and 5 are D5.3: Final report on evaluation results and proof of concept demonstrations 101 collapsed in a single message). After steering, traffic is recovered and the IML can delete the old pod instance (7a, 7b). In the case of resource scaling, two instances of the pod are pre-instantiated in the cluster (primary and backup). After the alarm for CPU load is raised, the IML skips instantiation/deletion operations and directly performs traffic steering from the affected (primary) pod instance to the backup one (4, 5, 6). 4.5.5.1 Service Kafka Monitoring functionality and operation The Kafka-based service Monitoring component has been adopted in the demo to collect periodically and in real-time the relevant metrics (CPU and RAM occupation). In this case the Monitoring Manager component is exploited. The module offers a REST-based API to trigger the activation of a new monitoring job pertaining to a specific pod running in the cluster. More specifically, Figure 45 shows the details of the APIs exposed by the Monitoring Manager, respectively (top down), to get details of active jobs, to start a new monitoring job or to deactivate an active job. To start a new monitoring job few parameters are needed, including “service-name”, “namespace” and “pod-name”. FIGURE 45. MONITORING MANAGER API. The monitoring system has a period of 5s and provides data in a csv-like format, including timestamp, cpu (mcore), RAM and number of connected clients. Another relevant component, adopted for this purpose, is the forecasting manager, shown in Figure 46. Also in this case, a REST-based module has been developed to spawn forecasting jobs. In particular, the D5.3: Final report on evaluation results and proof of concept demonstrations 102 API allows to trigger the activation of a new forecasting job, to deactivate an existing one or to retrieve the details of existing jobs. To start a forecasting job, three parameters are needed: the “service-name”, the “namespace” and the “pod-name”. The module reads from a dedicated Kafka topic (with topic name “servicename”_”namespace”_”pod-name” data sent by the monitoring job and computes the CPU forecasted version. When the forecasted CPU exceeds a threshold, an alert is sent to the IML. FIGURE 46. FORECASTING MANAGER API Figure 47 shows the trend of forecasted CPU and real CPU during the system validation. In particular, the plot shows how the orange curve (the forecasting of the CPU) anticipates the trend of the real CPU. For the validation, the the load of the CPU has been realized in the pod with a ad-hoc designed process, causing the 10% CPU load increase. FIGURE 47. FORECASTING PLOT OF THE CPU (IN ORANGE) VS THE REAL CPU (IN BLU). D5.3: Final report on evaluation results and proof of concept demonstrations 103 Figure 48 reports the overall integration of the three relevant components for this procedure. The IMLLNFVO, after the service instantiation, triggers the activation of a new pervasive monitoring with forecasting capability. For this purpose, a new forecasting job is activated, sending a REST PUT to the forecasting engine, providing “service-name”, “namespace” and “pod-name”. The forecasting engine, acting as singe endpoint, triggers the instantiation of a specific monitoring job, sending a REST PUT to the monitoring Manager component (using the received input parameters). Under normal conditions, the forecasting CPU is computed by the forecasting job, by consuming input metrics read from the Kafka topic related to this job. Once a critical condition is detected, an alarm is sent, using a REST POST towards the IML-LNFVO triggering the scaling of the pod instances. FIGURE 48. IML-NFVO, FORECASTING ENGINE AND SERVICE MONITORING MANAGER INTERACTIONS. 4.5.5.2 IML LNFVO functionality and operation The local IML instance in Site 2 first starts a forecasting job that automatically starts the required monitoring task. During operation, IML gets a notification on SLA violation via a REST API, indicating that the worker node hosting the application pod has started overloading. As a reaction, IML replicates the pod on a less loaded node via generating the manifests by its internal Helm-based template system and do the deployment through the standard K8S APIs. This step also includes the creation of a virtual network link to the D6GGateway (aggregated NFR and UE2SM) instance handling the node where the AF is running. Then it reconfigures the table entries in the NFR instance running in the K8S cluster (the last hop before the application) via its REST API (SDN Ctrl in Figure 44). The NFR then forwards the traffic to the new pod. Finally, IML deletes the old pod via the standard K8S API. In case of stateless transport protocols (e.g., UDP streams) this process works seamlessly, and the migration does not cause notable performance drops (1-3 packets were dropped in our experiments). This workflow only uses Site 2. D5.3: Final report on evaluation results and proof of concept demonstrations 104 4.5.6 Workflow 5: MAS-driven Service Reconfiguration In this workflow, AR service assurance is evaluated against a latency anomaly event occurring at different sites and network segments, i.e., the SDN network and the RAN, assuming that these portions of the end-to-end data plane are not served by real-time in-band telemetry and control (INC), as in Workflow 3. INT metadata collected from the UE to the edge node are exploited to trigger the intervention of the MAS agents, the third layer of the D6G architecture, that supervisions the deployed AR service SLA along the different data plane segments. Latency anomaly events are created in the SDN domain using extra congestion traffic as in Workflow 3, while latency events are created in the RAN domain in more sophisticated way. Most latency anomaly events occurring inside the RAN are particularly difficult to detect, locate and notify to service assurance layers. In fact, if the anomaly occurs inside the DU, CU and CN containers (CPU overloading, resource exhaustion), the RIC has the capability to intervene along with the internal Kubernetes agents with migration or scaling operations, similarly to Workflow 4 related to the edge application. However, if the latency anomaly affects the internal RAN subnet, for example the mid-haul segment, the RIC may not be aware and failure localization is not trivial. FIGURE 49 DELAY TUNER AT THE RAN MID-HAUL Latency anomaly events at the RAN are created as follows. Figure 49 shows how the user-plane latency anomaly occurrences are created within the disaggregated RAN architecture. A P4-programmable switch is placed in the mid-haul path between the DUs and the CU. This switch hosts the User Plane Delay Tuner, a custom P4 network function that emulate controlled latency impairments and evaluate the responsiveness of the service assurance mechanisms. The Delay Tuner allows the injection of deterministic delays into user-plane traffic, simulating real-world congestion or processing bottlenecks. D5.3: Final report on evaluation results and proof of concept demonstrations 105 It is worth to note that the RAN control plane traffic is not affected by any additional delay, since flow rules are configured to trigger delay only to user plane flows, identified by different subnetting. Such delay is not intercepted by any of the RIC metrics, thus the RAN cannot intervene directly. Instead, UEINT metadata collected at the MAS allows to detect the cumulated delay at the RAN segment, at the SDN segment and e2e. This allows the MAS to identify the problem at the RAN network excluding container-based issues, suggesting the handover from DU1 to DU2 to circumvent the issue in the midhaul segment. FIGURE 50 DEMO 1 WORKFLOW 5 Figure 50 shows the workflow steps involving the relevant DESIRE6G components. This workflow demonstrates the reaction loop of the DESIRE6G architecture when a network degradation (e.g., link congestion or increased latency) occurs, involving both data-plane telemetry triggers and control-plane corrective actions coordinated through the MAS. The steps correspond to the numbered interactions in the figure. Step 1 – In-band Telemetry Degradation Detection The P4 programmable nodes communicates the latency metadata degradation event through UE InBand Network Telemetry (INT) and the Telemetry Collector module. INT metadata is immediately exported to the Telemetry Collector, which aggregates per-flow latency and congestion indicators. At the same time, RAN telemetry metrics are exported to the Site 1 MAS. Step 2 – Data Collection and Reporting D5.3: Final report on evaluation results and proof of concept demonstrations 112 averaging roughly 50 Mbit/s. The average jitter ≈ 0.13 ms, is extremely low — excellent for real-time or low-latency services. Downlink packet loss averages around 4–5 %, with spikes up to 25 % (notably at 17 s), due to RLC retransmission switch off using UM mode. After the spike, the link recovers quickly, showing good link adaptation and error correction efficiency. End-to-end results with iperf3, all D6G data plane active FIGURE 55 END-TO-END RTT IN THE DESIRE6G SITES – DATA PLANE DEPLOYED The graph in Figure 55 represents the latency behaviour of the end-to-end communication path measured between the drone and the edge node when all the DESIRE6G data plane is configured and active. It shows how Round-Trip Times (RTTs) are distributed within the 10–50 ms range — the region where most latency samples occur. The histogram (bars) captures the frequency of RTT occurrences. The main RTT occurrences lie between 15 ms and 25 ms. The narrow distribution and low jitter imply that both the wireless link, SDN and the edge compute chain are well-optimized (e.g., short MAC scheduling window, low buffer queuing). Occasional longer RTTs up to ~40 ms correspond to transient medium congestion, PHY retransmissions, mainly at the RAN side. Typical RTTs under 30 ms meet requirements for tactile Internet, remote piloting, or edge-assisted XR. The small right tail (35–45 ms) suggests rare but detectable delay spikes — worth monitoring when ultra-low latency (< 20 ms) consistency is a hard constraint. D5.3: Final report on evaluation results and proof of concept demonstrations 113 AR App performance Figure 56 shows the main performance of the AR app when launched. Two video versions have been considered: a) motion JPEG 1280x768 resolution and b) h264 1280x720. In version a) the throughput is 20Mb/s uplink, in version b) the throughput is variable between 5 and 12 Mbit/s. The video shows the performance of the motion JPEG version. In all the cases, the one-way latency of the end-to-end path, from the drone to the edge app, is 9-11 ms. The RAN latency accounts for 8-9 ms, including the wireless link. The SDN and cluster accounts for 1-2 ms. The Tofino latency is negligible (around 4us), thus the contribution is given by the BMv2 switches and the data plane path of the Kubernetes cluster. FIGURE 56 APP PERFORMANCE Drone Flying mission In this step the Drone controller enforces the flying mission. The drone start flying following the trajectory imposed by the MAVLink system and continuously monitored by the VIACON system. The AR app fully operates with bidirectional transmission of video, artifacts and commands. Figure 57 shows the parallel video recordings obtained during the flying mission. The top-left video is the output of the s-App running in the Jetson payload of the drone, implementing object detection. The artifacts show a person identification with the accuracy level. The bottom-left video is the output of the e-App running in the D5.3: Final report on evaluation results and proof of concept demonstrations 114 Kubernetes cluster. The video received by s-App is enriched with the pose artifacts of the person. The output of this function is sent to the Quest 3. The Quest 3 Unity engine performs the 3D reconstruction and localization of the detected object and draws the red skeleton of the person in the environment. This way, AR artifacts are added to the bypass camera video of the Quest. The result is the detection of a moving person behind the obstacle. Videos are transmitted and received with a >30 frames per seconds. The latency of the AR app stages is around 8 ms. The total end-to-end one-way latency, including the app, is around 26ms, a value that allows live interaction. The main latency bottlenecks are the AI processing at each AR app stage and the RAN latency. FIGURE 57 AR APP ARTIFACTS AT THE DRONE, AT THE EDGE AND AT THE QUEST3 HEADSET The drone flying mission detailed results and metrics are reported in the plots of Figure 58. Figures show the path inside the laboratory that the drone is tasked to follow. More in detail, Figure 58 a) shows the drone 3D trajectory, while Figure 58.b) shows velocity and position vectors components, which presented very few fluctuations during flight, indicating steadiness and control. Figure 58.c) also represents velocity vectors over laboratory’s X and Y coordinates and Figure 58.d) shows the battery status during tests, which also presented no issue or fluctuation. D5.3: Final report on evaluation results and proof of concept demonstrations 115 a) b) c) d) FIGURE 58: A) DRONE TRAJECTORY B) DRONE LOCALIZATION, C) DRONE VELOCITY VECTORS, D) DRONE BATTERY STATUS Test outcome comments The RAN test shows stable DL throughput around 95–100 Mbit/s, with brief dips linked to short scheduling or fading events. UL throughput varies between 35–65 Mbit/s, averaging ~50 Mbit/s, while jitter stays extremely low (~0.13 ms). DL packet loss is generally 4–5%, with occasional spikes up to 25% that recover quickly. End-to-end RTTs with the full DESIRE6G data plane fall mostly in the 15–25 ms range, with a tight distribution and rare peaks up to 40–45 ms caused by transient RAN-side congestion. Typical RTTs <30 ms meet XR/remote-control requirements. The network maintains 9–11 ms one-way latency regardless of encoding; Motion JPEG needs ~20 Mbit/s UL, while H.264 uses 5–12 Mbit/s. RAN contributes 8–9 ms of this delay, SDN+cluster 1–2 ms, with negligible Tofino latency. Drone telemetry (localization, trajectory, velocity, battery) confirms stable flight and consistent data delivery. The total e2e latency including the app stages is around 26ms. D5.3: Final report on evaluation results and proof of concept demonstrations 116 Test Name Type of Test D6G Test Inventory ID Responsible Partner(s) D1-W1 Workflow 1 Main Test (Service Deployment) 2 CNIT, SSSA; NUBIS, UVA, ELTE, ERI-HU Testbed Demo/PoC Involved components Test ARNO Demo 1 SO, OE, Service Catalog, IML LNFVO, NFR, UE2SM, UE INT+INC Final Description of the test Main function Validate the full service deployment of the AR app in the ARNO testbed spanning three sites. Measure the overall deployment time and the time contribution of each component and module. Test requirements The SMO and all components need to be deployed and fully working. Drone, RAN, SDN, Tofino switch and cluster need to be connected and configured (interfaces) to support e2e flowing. External tools No external tools are used. Measurement - SMO processing time - OE and SC processing time - IML/LNFVO processing time at each site - Deployment time contributions due to SMO, IML and K8S - Deployment time of FaaS e-App Related Project KPIs KPI 7.2, KPI7.3, KPI 7.4 Test execution D5.3: Final report on evaluation results and proof of concept demonstrations 117 Initial setup/assumptions - Steps 0. Deploy and activate all the SMO and IML subsystems in the sites to run in steady state. 1. Check that the AR traffic is not flowing and services are not instantiated. 3. Start the workflow by sending the service deployment request from the tenant with the required service graph and the E2E latency requirement 4. Check the SC and the OE reply with the available service images and the service decomposition NSDs for each site 5. Check the SO sends the NSDs 6. Check the IML LNFVOs receive the NSD and parse the request 7. Check the IML LNFVO instantiate application pods and NFs 8. Check the IML LNFVO configure the NFs CP 9. Check the IML LNFVO returns the deployment outcome at each site 10. Check the SO receives the ack message from all the IMLs 11. Check the e2e traffic is flowing 12. Measure all the time contributions at SMO and IML. Test results The experimental results provide a breakdown of the execution time contributions across SMO and NonSMO components. The measurements shown in Figure 59, taken at the SMO level, are divided into the service request and composition steps at the SMO (red bars) and the SO calls to the IML in the different sites. The figure shows that all SMO-related operations, including SO, SC, and OE, consistently operate within the millisecond range. Specifically, SMO processing never exceeds a few tens of milliseconds, confirming that control and management functions introduce negligible latency in the end-to-end workflow. In particular, as shown in Figure 60, the service catalogue retrieval takes around 5ms. The decomposition request and reply, including communication, between the SO and the OE takes 27ms. The net OE processing outcome is around 13ms. The OE outcome is processed by the SO to compose the NSD YAML files (13 ms) and to retrieve the IML endpoints (9ms). The total contribution of the SMO is around 54ms. The figure shows the time seen by the SMO when calling the IML instances and receiving the reply. These contributions are not inclusive of the time spent by K8S to enforce the deployment of software pods. The figure shows the time spent in Site 1 that includes the enforcement of the Tofino instance and the flow rules (around 122ms). Thus, from the SMO point of view, the entire control plane operation (without K8S) operation is concluded after around 175ms. D5.3: Final report on evaluation results and proof of concept demonstrations 118 FIGURE 59 DEPLOYMENT: SMO AND NON-SMO PROCESSING TIMES FIGURE 60 DEPLOYMENT: SERVICE DECOMPOSITION TIME CONTRIBUTIONS FIGURE 61 DEPLOYMENT: IML TIME CONTRIBUTIONS INCLUDING K8S IN SITE 2 From the IML perspective, Figure 61 shows the time contributions measured by the IML LNFVO API in Site 2, the most complex one. When receiving the NSD, the IML performs its computation in less than 500us, then it prepares the pod instance configurations in 25ms., invoking the K8s API calls. Actual pod instantiations are run in parallel and take some seconds for 4 pods (e-App1 in orin3, e-App2 in orin4, NFR and edge monitoring engine used to run Workflow 4). At the end of deployment, control plane rules are D5.3: Final report on evaluation results and proof of concept demonstrations 119 computed and sent to NFR and monitoring engine in less than 1.5s. The total IML deployment time takes around 16 seconds. Test outcome comments The obtained results confirm that the SMO/IML architecture meets the targeted automation, decisionmaking, and resilience KPIs. Service creation and deployment triggering were executed fully autonomously, with no manual intervention required. This directly validates KPI7.2. The measured execution times of SMO components (SO, SC, and OE) consistently remain in the millisecond range, with OE-based AI-driven optimization and re-optimization phases well below the 100 ms threshold. This confirms compliance with KPI7.3. Notably, the end-to-end SMO control-plane latency remains negligible compared to execution-layer delays, ensuring timely reactions under varying traffic and service conditions. Regarding KPI7.4, results show that FaaS placement and redundancy are computed within sub-second timescales, if K8S-based deployment phase is not considered. The IML LNVFO exhibits low computation and calling times, in the order of tens of milliseconds. Control plane commands depend on the considered NFV backend. For Tofino, around 100 ms are required, while for software-based NFV more time is needed (around 1 s). The overall deployment time is dominated by the K8S API calls and actual pod deployment phase, requiring some seconds depending on the pod image type. Test Name Type of Test D6G Test Inventory ID Responsible Partner(s) D1-W2 Workflow 2 Main Test (MAS agent Runtime Verification) 3 CNIT, SSSA, UPC, TSS Testbed Demo/PoC Involved components Test ARNO Demo 1 MAS Agents, DMUTRA Sidecar & DLT Verifier, SECaaS/Blockchain Connector Continuous attestation of MAS agents during runtime Description of the test D5.3: Final report on evaluation results and proof of concept demonstrations 120 Main function Validate the mutual remote attestation of distributed MAS agents ensuring runtime code integrity and trust establishment through D-MUTRA blockchain-based signatures. Test requirements Agents wrapped via SECaaS; DLT access enabled; verifier nodes reachable. External tools - Measurement - Duration of attestation (from request to verification result) - Duration overhead of the agent over attestation process. Related Project KPIs - Performance overhead - Attestation cycle duration Test execution Initial setup/assumptions All MAS containers deployed with sidecar; reference signatures anchored on SECaaS database; verifier registered in DLT nodes. Setup • Prover Agents: Two agents, multiflow and telemetry . Each extracts the .text section of its binary, computes a SHA-256 hash, and submits this measurement to the blockchain as attestation evidence. • SECaaS Verifier • Sidecars and Metrics Collection: Each agent is paired with an attestaion sidecar. • Sidecars record all timing probes locally and push them to Redis, while a per-instance exporter periodically ships aggregated metrics to a centralized Prometheus instance via Pushgateway. • Blockchain Configuration: The experiment uses a 10-node Besu Proof-of-Authority (PoA) network to guarantee low-latency, deterministic block finality. D5.3: Final report on evaluation results and proof of concept demonstrations 121 Steps 1. Initialize the Blockchain Network Deploy the Besu PoA network and instantiate the attestation smart contract that manages evidence submission and verifier election. 2. Register Agents and Generate References Each agent is registered through the SECaaS wrapper, which computes its reference signature and stores it in the off-chain database. 3. Launch Agents and Sidecars Prover agents and their associated sidecars are started. Attestation cycles are executed automatically and continuously in background. 4. Collect Metrics Over 100 Attestation Cycles Timing probes and resource usage metrics are exported to Prometheus. After completing 100 cycles, metrics are extracted as CSV files using export_prometheus_to_csv.py. 5. Analyse Per-Instance Behaviour The exported data is analysed to compare performance. Test results The following table (Table 11) details the obtained measurement values. TABLE 11 WORKFLOW 2 RESULTS Category Metric Value Explanation Attestation Cycle End-to-End Attestation Time 4.0613 s Total time from measurement to final verdict; Measurement Time 0.001110 s Very fast hashing of the code section performed locally. DLT Commit Time 0.0078 s Time for the blockchain to accept and anchor the measurement. Verification Time 0.0025 s Time for the verifier to recompute and validate the measurement. System Overhead Agent CPU Usage 0.01 % Negligible CPU cost for the protected agent. D5.3: Final report on evaluation results and proof of concept demonstrations 128 - IML-driven Enforcement time Related Project KPIs KPI 7.2, KPI7.3, KPI 7.4 Test execution Initial setup/assumptions The service has been deployed and configured. Infrastructure monitoring has been activated by IML. Steps 0. Activate all the subsystems to run in steady state (deployed service, deployed monitoring, deployed network functions). 1. Check that the traffic is flowing from s-App to e-App. 2. Activate the extra CPU processing in the e-App pod at orin3 board. 3. Check pod CPU metrics are collected by Kafka monitoring 4. Check periodic CPU occupancy prediction is computed by the Forecast Engine – measure the forecast inference time. 5. Check the Alarm sent to the IML when predicted CPU load is greater than a defined threshold. 6. Check the IML computed and enforces the scaling. 7. Measure the scaling processing and enforcement time. 8. Check traffic is flowing to the new E-app pod. Test results FIGURE 68 WORKFLOW 4 EXPERIMENT SCREENSHOT Figure 68 shows the execution of the experiment through terminals. On the left side, the terminal displays the application traffic at the pod level, while on the right side the terminals correspond to the monitoring and intelligence engines, including metric collection, forecasting, and control actions. D5.3: Final report on evaluation results and proof of concept demonstrations 129 The monitoring engines continuously receive metric samples from the working pod, including CPU utilization, RAM usage, and number of active clients. These samples are collected at a 1-second granularity. Every 6 seconds, the collected metrics are aggregated and fed to the Forecast Engine, which generates a new prediction sample representing the anticipated system behaviour under the current load conditions. The monitoring platform evaluates both raw metrics and forecasted values. When the predicted behavior indicates a potential service degradation, an alarm message is generated and propagated to the IML. This alarm represents a semantic trigger, as it is not based solely on instantaneous threshold violations, but on predicted trends that may compromise service performance. Upon alarm reception, the IML computes a scaling decision and enforces it through the control plane. In the experiment, the scaling action consists of installing a flow rule at the Network Function Router (NFR), steering the application traffic towards an alternative pod deployed on the Jetson Orin4 board, which is not affected by the high CPU load observed on the original instance. The successful enforcement of this action is confirmed by the Scaling API response, reported as “Current instance changed to 1”. The end-to-end scaling time, measured as the interval between sending the Alarm POST message and receiving the final Scaling API response (“Current instance changed to 1”), is 215 ms. This duration includes: 1) Alarm reception and interpretation by the IML, 2) Computation of the scaling decision, 3) Enforcement of the control action via flow rule installation. The inference latency of the Forecast Engine was analyzed in detail (see distribution in Figure 69), by isolating the execution times corresponding exclusively to inference operations at the GPU, excluding data ingestion and scaling procedures. The results show a highly stable and deterministic behavior, characterized by median inference latency of 44 ms and standard deviation below 1.5 ms. This narrow distribution demonstrates that the Forecast Engine can operate reliably in real-time Service Assurance loops, without introducing significant computational overhead or timing jitter. Such stability is important in edge environments, where control decisions must be taken within tight latency constraints. D5.3: Final report on evaluation results and proof of concept demonstrations 130 FIGURE 69 FORECAST ENGINE INFERENCE TIME DISTRIBUTION Test outcome comments The monitoring platform reliably collected FaaS service metrics (CPU, RAM, and number of clients) at a 1-second granularity and correctly delivered them to the Forecast Engine. Prediction samples were generated at the expected 6-second interval, confirming the proper synchronization between metric ingestion and forecasting components. The Forecast Engine demonstrated stable and deterministic inference performance (median value of 44 ms) and a standard deviation below 1.5 ms. This confirms that the forecasting process introduces negligible overhead and is suitable for real-time and continuous Service Assurance operations at the edge. When predicted conditions indicated an imminent overload, the monitoring system correctly generated an alarm and forwarded it to the IML. The IML successfully computed and enforced a scaling decision, steering traffic to an alternative FaaS instance not affected by the high CPU load. The complete scaling reaction time, measured from alarm emission to confirmation of scaling enforcement, was 215 ms, demonstrating fast and effective closed-loop control. The observed reaction time confirms that the closed-loop control chain—from monitoring to prediction, decision, and enforcement—operates within sub-second timescales, making it suitable for proactive and predictive service assurance scenarios. D5.3: Final report on evaluation results and proof of concept demonstrations 131 Test Name Type of Test D6G Test Inventory ID Responsible Partner(s) D1-W5 Workflow 5 Main Test (MASdriven Service Assurance) 6 CNIT, SSSA, NVIDIA; UPC, ACC Testbed Demo/PoC Involved components Test ARNO Demo 1 INT-UE+INC, Telemetry Collector, Final Description of the test Main function Evaluate the capability of the pervasive telemetry + the MAS Agents to react promptly to different latency anomalies induced in the network. In this test the anomalies are congestion events occurring at one of the P4 switches (with no INC functionality) and at the RAN using the P4 Delay Tuner. Measure the times of the components and the full loop reaction time Test requirements AR app is flowing with INT functionalities. INT Reports are generated only for the considered flow from the sink node to the Telemetry Collector and aggregated to the Telemetry Agent. External tools Spirent Traffic Generator generating traffic congestion at the SDN domain (as in W3), InfluxdB and Grafana at the Collector to visualize time series. Measurement - MAS packet network anomaly detection time - MAS reaction time on network anomaly detection - MAS RAN anomaly detection time - MAS reaction time on RAN anomaly detection Related Project KPIs KPI 7.2, KPI 7.3 Test execution Initial setup/assumptions AR service has been already deployed; traffic flows through the end-to-end path; traffic flows through the radio segment; the MAS is deployed, the xApp is running, the Telemetry Collector is already configured to process AR traffic flows. D5.3: Final report on evaluation results and proof of concept demonstrations 132 Steps 0. Activate all the subsystems to run in steady state. 1. Check that the traffic is flowing from source to destination and steady state parameters at collector and MAS 2. For SDN failure: Activate Spirent traffic (with significant issues on congestion/latency). For RAN failure: Activate the Delay Tuner 3. Check and measure the congestion impact in terms of latency and queue length at the involved nodes 4. Check the MAS reaction (it should react with a suggested change) 5. Measure the time to inform the MAS about the anomaly 6. Measure the time needed by the MAS to perform the re-optimization suggestion 7. Measure the re-optimization enforcement time 8. Check that e2e latency is recovered 9. Evaluate the overall recovery time (collector+MAS+enforcement) Test results MAS agent processing - The MAS packet network anomaly detection time is < 10 ms - The MAS reaction time including the delay added for the MAS communication on packet network anomaly detection is ≈ 25 ms FIGURE 70 MAS AGENT PACKET NETWORK ANOMALY PROCEDURE - The MAS RAN anomaly detection time is < 10 ms - The MAS reaction time including the delay added for the MAS communication on RAN anomaly detection is ≈ 25 ms FIGURE 71 MAS AGENT RAN ANOMALY PROCEDURE INT collector and SDN results D5.3: Final report on evaluation results and proof of concept demonstrations 133 - D6G INT Collection and aggregation of 4 packets: FIGURE 72 WIRESHARK CAPTURE OF COLLECTOR INTERFACES FIGURE 73 A GROUP OF 4 INT PACKETS AND P4 COLLECTOR SUMMARY - Time taken to send collector report ~220us - INT server time to process and send aggregated and summarized reports to MAS ~ 10ms - Time for reconfiguration of P4 switch is < 1ms Overall loop Figure 74 summarizes the timings at each configuration step for reconfiguring P4 switches to go on the backup path. D5.3: Final report on evaluation results and proof of concept demonstrations 134 FIGURE 74 CLOSED LOOP INDIVIDUAL TIMES IN MS FOR P4 RECONFIG Figure 75 shows the Grafana time series of the latency values of AR App packets in the RAN segment during the tests. In steady state the latency is around 10ms with some spikes due to the RAN. When the Delay Tuner is configured, latency increases up to around 90ms. When the complete loop is executed and the Handover is forced, latency is restored to the nominal value. The shown recovery time (around 8s) is mainly due to the time needed by the RIC to force the Handover from DU1 to DU2. The time needed by the DESIRE6G data plane and the MAS to perform the Handover request is below 100ms. Thus, the remaining time is due to the xAPP command and by the RIC internal commands to enforce Handover, requiring synchronization with the UE. FIGURE 75 INT VALUES AT THE TELEMETRY COLLECTOR (RAN SEGMENT) Test outcome comments The results obtained confirm that the MAS agents achieve very low anomaly detection times (<10 ms) for both packet-network and RAN-level anomalies, demonstrating their suitability for near real-time D5.3: Final report on evaluation results and proof of concept demonstrations 135 feedback loops in 6G-aligned architectures. The end-to-end MAS reaction time (~25 ms), including communication overhead, remains well below the 100 ms envelope typically required for near-real-time control, validating the efficiency of the MAS-to-data-plane signaling path. The INT measurements further support this by highlighting precise, segment-level latency traces that can be exploited for adaptive control. The overall loop analysis shows that while the MAS + data-plane handover trigger completes within ~100 ms (i.e., below 50ms), the dominant contributor to total recovery time (~8 s) lies in the RIC/xAPP execution and UE synchronization. This separation clearly highlights the difference between system-internal overheads and control-plane orchestration delays. Grafana time-series results demonstrate that the AR application maintains a stable 10 ms RAN latency, increasing only when the Delay Tuner is intentionally activated, and returning to nominal values after the forced handover. These findings collectively show that the DESIRE6G data plane and MAS operate within stringent real-time constraints, and that remaining optimization opportunities lie primarily in RIC/xAPP orchestration latency. D5.3: Final report on evaluation results and proof of concept demonstrations 136 5 Demo 2: Real-Time Digital Twin 5.1 Introduction, testbed and components This demonstrator showcases the integrated 6G-ready DESIRE6G architecture, designed to enable automated and secure orchestration, and efficient traffic management for low-latency applications such as Digital Twins (DTs) for robotics and autonomous systems. The demo validates a cloud-native, multidomain framework that integrates programmable and deterministic data planes, IML-driven service assurance, and an intent-based orchestration layer supported by zero-trust, dynamic federation mechanisms. Together, these capabilities enable closed-loop control and decision-making across the edge–cloud continuum, while supporting interoperability with other 6G frameworks operated by independent administrative domains. The architecture implements a distributed control model spanning three independently operated domains, each with heterogeneous infrastructure. This model enables the dynamic deployment, reconfiguration, and federation of network and application services in response to changing operational conditions, ensuring continuous optimization and compliance with strict latency requirements. The demonstrator is deployed on the 5TONIC testbed in Madrid, Spain, and integrates a DT application distributed across heterogeneous equipment, including a quadruped robot, edge nodes, programmable and TSN switches, and intelligent orchestrators spanning multiple infrastructure domains. The showcased use case represents a robotics DT system, where a robots perform autonomous, real-time operations in industrial environments. The system architecture distributes robot functions across the device, edge, and cloud layers to effectively manage balance computational load, latency, and bandwidth demands. Through programmable traffic management and cross-domain federation at the orchestration layer, the system maintains strict end-to-end latency guarantees, even under network or resource degradation. The results demonstrate the seamless integration of cloud-native orchestration and programmable data-plane control, embodying the DESIRE6G vision of resilient, autonomous, and performance-aware 6G infrastructures. 5.1.1 Demo deployment The demonstrator has been fully implemented and deployed within the 5TONIC integrated testbed (shown in Figure 76Figure 76). The testbed includes three interconnected administrative domains, each D5.3: Final report on evaluation results and proof of concept demonstrations 137 with different hardware and software resources, representing a multi-domain, multi-technology 6Genabled edge infrastructure. The setup validates the DESIRE6G architectural framework by combining programmable data planes, deterministic networking, and multi-domain federation to achieve end-toend service assurance for latency-critical DT robotic applications. FIGURE 76. 5TONIC TESTBED SETUP FOR DEMO 2 Domain 1 hosts the Unitree Go1 mobile robot equipped with a Mini-PC, camera, LiDAR, and 5G UE. The UE connects the robot to the indoor radio unit, which interfaces with the RAN and the 5G Core Network located in the 5TONIC edge data center. A programmable Tofino switch interconnects the 5G infrastructure with Edge Node 1 and a traffic generator that injects industrial traffic to emulate congestion scenarios. An SMO, with all its subcomponents, manages the deployment and lifecycle of the DT system in coordination with the IML. The robot’s Mini-PC and Edge Node 1 form a Kubernetes cluster hosting the DT application and key DESIRE6G components, including the pervasive Kafka infrastructure-monitoring module (to collect and analyze application and infrastructure metrics), a MAS agent (to detect resource congestion and notify the SMO for reaction), and the IML (to manage the local virtualized infrastructure on Kubernetes and control the programmable switch). The Tofino switch implements the infra network functions (NFs) that form the forwarding graph between the robot and edge applications, as well as the Per-Packet-Value Traffic Manager (PPV-TM) module to ensure the quality of the mission-critical robotic data flows during network congestion. Domain 2 provides a deterministic transport network managed by a centralized SDN controller, linking Domain 1 with Domain 3. The network ensures reliable, low-latency connectivity through programmable Tofino switches implementing DetNet Packet Replication, Elimination and Ordering Functions (PREOF). D5.3: Final report on evaluation results and proof of concept demonstrations 144 Table 14 summarizes the bidirectional integration relationships established in Demo 2: green cells indicate full peer-to-peer integration via a defined interface (I), orange cells represent master–slave dependencies involving parameter exchange or function invocation (F), and blue cells denote tight integration through shared code or internal dependencies (C). In total, 24 inter-module integration relationships have been implemented and validated in this demonstrator. • The SMO components were initially validated at the northbound interface, building on baseline integration from the Y2 demonstration (see D5.2). Validation focused on the SO, SLA-to-IntentTranslation, SC, DL, OE, and MLFO, confirming that intent-level service graphs are correctly processed into deployable network service descriptors by the IML. • Further tests verified the correct handling of intent-based service requests by the SLA-to-IntentTranslation, site-decomposition decisions by the OE using live topology information, and the automatic generation of MAS pipeline descriptors at the MLFO based on service monitoring requirements. Validated service graphs were then submitted to the IML (LNFVO), confirming correct deployment of network functions, application components, and MAS agents, including placement, ordering, and configuration. • The MAS integration with the Kafka-based monitoring infrastructure was validated by verifying the availability and consistency of application-level and infrastructure metrics collected from the Kubernetes cluster. It is important to note that the MAS used in this demonstration differs from the one employed in Demo 1. In this case, a simplified MAS implementation developed by UVA is adopted, consisting of a single monitoring agent. Its role is to detect resource congestion and SLA violations affecting DT application functions and to notify the SMO layer for corrective actions. Tests confirmed that the monitored metrics were correctly ingested and made available to the MAS, enabling timely anomaly detection and escalation. • The interaction between IML and PPV-TM, building on Y2 integration, was tested under congestion scenarios. Results confirmed that the IML dynamically reconfigures PPV-TM policies in response to SLA violations, validating the service-assurance loop. Further validation of the programmable data plane included extensive testing of UE2SM and NFR functions, ensuring proper packet (de)encapsulation, D6G header handling, and forwarding behaviour across the testbed. • Significant validation effort was also dedicated to the DLT-based Federation module within the SMO. Tests verified correct interactions between the SO and the federation module via the D5.3: Final report on evaluation results and proof of concept demonstrations 145 east/westbound interface, including the creation and submission of blockchain transactions and the correct handling of smart-contract event notifications during inter-domain federation procedures. • Finally, the SDN controller was validated through integration tests with both the programmable Tofino switches (via the BFRT API) and the SMO (via REST-based northbound interfaces). These tests confirmed correct control of the transport network, including PREOF/DetNet P4 table loading and dynamic switch configuration driven by SMO instructions. TABLE 14 DEMO 2 INTEGRATION MAP Module 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 DL 2 SO I 3 SC I I 4 Topology I I I 5 SLA-to-Intent-Translation - I I - 6 OE - I I I I 7 DLT-Federation - I - - - - I 8 MLFO - I - - - - - 9 MAS - - - - - - - I 10 LNFVO - I - - - - - - - 11 PPV-TM - - - - - - - - - I 12 NFR - - - - - - - - - F - 13 UE2SM - - - - - - - - - F - C 14 SDN controller - I - - - - - - - - - - - 15 DetNet-PREOF - - - - - - - - - - - - - I 16 Infrastructure Kafka Monitoring - - - - - - - - I - - - - - - 5.4 Implementation of the application The demonstrator integrates a distributed DT application designed to showcase real-time collaboration between a robot and a human operator over a 6G-enabled network infrastructure. The use case, fully detailed in Deliverable D2.1 [7], represents an industrial warehouse scenario in which a remote operator uses the DT application to assign autonomous tasks (e.g., object delivery or inspection) to a mobile robot. During operation, the robot continuously sends joint states, LiDAR data, odometry, and camera feeds upstream to the edge computing platform, where applications process this information and generate safe control commands downstream that guide the robot throughout its mission. As the robot moves, D5.3: Final report on evaluation results and proof of concept demonstrations 146 its behaviour is mirrored in the virtual environment in real time, enabling continuous monitoring and allowing the human operator to intervene when necessary. 5.4.1 Distributed DT application workflow The distributed DT application workflow spans the robot, the 5TONIC-provided 5G SA network (including both RAN and Core), the programmable data plane, and the edge computing infrastructure, together providing the low latency, high bandwidth, and computational capacity required for real-time autonomous operation. As illustrated in Figure 79, the workflow is conceptualized within an industrial warehouse scenario, where the mobile robot has previously mapped its environment using Simultaneous Localization and Mapping (SLAM) algorithms and can autonomously perform intralogistics tasks such as transporting payloads between designated locations. First, the remote operator uses the DT application to assign an autonomous mission to the robot (Figure 79-A). Next, upon receiving the goal, the Auto Navigation Stack running on the edge computes a global path to the target position and continuously generates safe motion commands for the robot, taking into account obstacles and dynamic environmental changes (Figure 79-B). Finally, the robot executes these control commands locally and continuously streams sensor data (e.g., joint states, LiDAR scans, odometry, and camera feeds) to the edge node hosting the DT application, which processes this data in real time to synchronize the virtual model with its physical counterpart (Figure 79-C). As a result, the operator can see the robot’s movements mirrored live in the virtual space, visualize its trajectory on the dynamic map, and monitor the video feed simultaneously, achieving a real-time and safe closed-loop collaboration between human and robot. D5.3: Final report on evaluation results and proof of concept demonstrations 147 FIGURE 79. DISTRIBUTED DT APPLICATION WORKFLOW: (A) MISSION ASSIGNMENT BY THE REMOTE OPERATOR; (B) EDGE-BASED ROBOT AUTONOMOUS NAVIGATION AND CONTROL; (C) DT SYNCHRONIZATION D5.3: Final report on evaluation results and proof of concept demonstrations 148 5.4.2 Application tools and software The robot software is implemented using the Robot Operating System (ROS) framework, specifically the ROS 1 Noetic [18] distribution, while the DT application is developed using the NVIDIA Isaac Sim [19] robot simulator. All components of the distributed application are fully containerized and deployed as Pods and Services across a two-node Kubernetes cluster within Domain 1 (shown in Figure 80). The cluster is built using the K3s [20] lightweight Kubernetes distribution (version 1.28.8 + k3s1). Edge Node 1 operates as the K3s server (control-plane node), while the robot’s mini-PC acts as the K3s agent (worker node). Pod-to-pod communication is implemented through Virtual eXtensible Local Area Network (VXLAN) encapsulation protocol, manually configured via the Linux iproute2 [21] package. Each Pod is attached to the overlay network using the Multus [22] Container Network Interface (CNI) plugin, allowing seamless communication between the robot and edge applications. The distributed DT application consists of several key software modules: • Go1 ROS Wrapper (robot): Provides a high-level ROS interface for controlling the Unitree Go1 robot and publishing its state (odometry, joint states, and IMU data) over ROS topics. The interaction uses the Unitree Go1 SDK [23] in high-level control mode, enabling velocity, orientation, and gait commands for full-body motion control. • LiDAR (robot): Implements ROS drivers for the SLAMTEC RPLIDAR A3 laser scanner, offering a range of up to 25 m, a scanning frequency of 20 Hz, and millimeter-level precision. This component provides real-time mapping and obstacle detection, supporting navigation and SLAM in dynamic environments. • Camera (robot): Runs a video-streaming sender application that captures frames from the Logitech C920e UVC webcam. The video is encoded in MJPEG format and streamed in real time over UDP (User Datagram Protocol) to the Video Receiver component at a resolution of 720p and 30 FPS. • Video Receiver (edge): Receives the MJPEG stream, decodes it, and re-encodes it into H.264 at the target bitrate and resolution. The processed video is transmitted via SRT (Secure Reliable Transport) to a MediaMTX [24] media server, which redistributes the feed to web clients using the WebRTC protocol, allowing live visualization through a browser interface. Both the sender D5.3: Final report on evaluation results and proof of concept demonstrations 149 and receiver applications are written in Python and use GStreamer [25] multimedia framework, accessed via the PyGObject API, for video capture, encoding, and streaming. • ROS Master (edge): Provides naming and registration services for all ROS nodes in the DT system, enabling seamless inter-module communication through ROS topics and service registry. • Digital Twin (edge): Implements a high-fidelity virtual replica of the physical Unitree Go1 robot using NVIDIA Isaac Sim 2023.1.0, accelerated through the NVIDIA Container Toolkit [26] for GPUbased physics simulation. The ROS Bridge extension enables Isaac Sim to subscribe to real-time sensor data (e.g., joint states) and accurately reproduce the robot’s movements within the simulated environment. • Auto Navigation Stack (edge): Integrates the ROS navigation stack to enable autonomous motion planning and control of the robot. It performs SLAM using the Google Cartographer [27] algorithm to build and continuously update a two-dimensional occupancy map of the environment in real time. Based on this map, the stack computes a global path toward the target goal defined by the remote operator, while a local planner dynamically generates real-time velocity commands to avoid obstacles and ensure smooth, safe navigation. FIGURE 80. KUBERNETES CLUSTER ARCHITECTURE FOR THE DISTRIBUTED DT APPLICATION 5.5 Demonstration startup and workflows The demonstration comprises a startup phase followed by the execution of three workflows, each designed to validate specific capabilities of the DESIRE6G architecture under different operational D5.3: Final report on evaluation results and proof of concept demonstrations 150 conditions. An overview of the startup phase and workflows, and their mapping to the DESIRE6G architectural layers, is shown in Figure 81. The startup and steady-state phase (W0) establish the baseline operational conditions of the demonstrator. In this phase, the DT application is assumed to be already instantiated and running in the testbed, with all DESIRE6G network functions deployed and operational, in order to characterize steadystate system behaviour. This phase provides baseline measurements of robot traffic throughput and end-to-end communication performance. The first workflow focuses on service deployment (W1) and involves the full architectural stack, from the SMO layer down to the programmable data plane. It validates the coordinated interaction of orchestration, control, and infrastructure components required to instantiate the DT service. The second workflow (W2) addresses the service-assurance loop under service degradation conditions, in particular network congestion at the programmable data plane. This workflow involves the IML, which detects the degradation and autonomously restores service performance by reprogramming the PPVTM deployed on the Tofino switch. Appropriate QoS policies are enforced to prioritize mission-critical robot traffic over emulated background services and users. Finally, the third workflow (W3) validates the DLT-based multi-domain federation capabilities of DESIRE6G in a dynamic scenario triggered by application-level resource congestion. In this workflow, federation enables the on-demand migration of the affected serverless application function to an external administrative domain without prior bilateral agreements, thereby extending local infrastructure capabilities and ensuring service continuity. This workflow involves all architectural layers, with particular focus on the orchestration layer, which leverages blockchain technology to support secure and distributed control-plane interactions across domains during the federation process. D5.3: Final report on evaluation results and proof of concept demonstrations 151 FIGURE 81. DEMO 2 WORKFLOWS MAPPED IN THE DESIRE6G ARCHITECTURE 5.5.1 Startup and steady state This section describes the mapping of each service-chain component, including both application and network functions, within the 5TONIC testbed infrastructure. The focus is on Domain 1, which acts as the primary DESIRE6G site hosting the DT system, and on the end-to-end data path spanning the robot, the 5G RAN, the programmable data plane, and the edge node, which carries most of the workflow executed during the experimental validation. The mapping is shown in Figure 82. The DT network service deployed in this domain includes the distributed DT application (described in the previous section) and a firewall NF running on the edge node (as a containerized NF), both executed as containerized services within the Kubernetes cluster. During normal operation, the robot continuously transmits sensor data (LiDAR, camera, odometry, and state information) upstream to the edge node to update its virtual model, while receiving control commands downstream from the edge for navigation and actuation. The complete service chain, implemented using DESIRE6G data-plane components, operates as follows: Uplink direction: D5.3: Final report on evaluation results and proof of concept demonstrations 152 1. The robot sends sensor data streams through the 5TONIC-provided 5G network toward the Tofino switch acting as a DESIRE6G Gateway that implements the UE2ServiceMapper (UE2SM), Network Function Routing (NFR) functions (including transport adapter functions) and the PPVTM traffic management solution. We also created and artificial bottleneck between two ports of the switch. All the traffic (robot traffic and the background traffic generated by a traffic generator) is directed through this link to demonstrate the PPV-TM traffic management approach. For RAN traversal, the robot traffic is encapsulated in a VXLAN tunnel. The tunnel is terminated by Tofino switch and the decapsulated packets are handed over to the UE2SM. 2. The UE2SM attaches the D6G header to encapsulate flow metadata for service and UE identification and steering. The encapsulated packets are then forwarded by the Tofino switch’s NFR module to the NFR running on the local Kubernetes node that then forwards the packets to the firewall NF deployed on the same Kubernetes system (the edge node). 3. On the edge node, the firewall NF inspects the traffic before handing it over to the DT applications. The processed packets are then sent back to the NFR running on the Kubernetes node. 4. The NFR performs D6G header decapsulation and carries out the final packet forwarding to the destination DT application modules running on the Kubernetes cluster (edge node). The application pod cannot handle DESIRE6G headers and this it is external to the DESIRE6G domain and thus the removal of the special header is needed. Downlink direction: 1. The DT application modules running as AF pods on the Kubernetes cluster generates IP packets and thus, they are external to the DESIRE6G domain. The outgoing traffic of these pods are first handled by the UE2SM instance running on the edge server, extending packets with DESIRE6G headers. 2. The NFR also running on the same node then forwards the packets to the Firewall NF. 3. Then NFR gets back the packet, determines the next NF to be visited and forwards the packet to the Tofino switch. 4. The Tofino switch recognizes the DESIRE6G header and applies NFR to execute the forwarding logic. As a result, the DESIRE6G header is removed, the packet is encapsulated into a VXLAN tunnel and sent to the robot through the RAN. Note that the artificial bottleneck link is not crossed in the downlink direction. D5.3: Final report on evaluation results and proof of concept demonstrations 153 FIGURE 82. DEMO 2: MAPPING OF DATA PLANE COMPONENTS 5.5.2 Workflow 1: Service Deployment The workflow (illustrated in Figure 83) starts when the tenant submits a service-deployment request to the SMO, specifying high-level requirements (Step 1). The Intent-Based Networking (IBN) component translates this request into a service graph (Step 2), stores the resulting graph in the service catalog (Step 3), and forwards the intent to the Service Orchestrator (SO) (Step 4). Upon receiving the request, the SO retrieves the service graph and queries the Optimization Engine (OE) with a decomposition request, to determine how the service graph should be deployed across the DESIRE6G sites (Step 5). The OE collects aggregated infrastructure resource availability information from the Topology module and uses the service graph specifications and SLO constraints to determine which partitioning strategy has the highest probability to achieve the specified SLO constraints and executes the service-partitioning logic (Steps 6 and 7), as described in Deliverable D3.2, Section 3.2. In this scenario, there is only a single DESIRE6G site available. As expected, the OE annotates the graph with the corresponding site identifier and returns the updated graph to the SO (Step 8), as there is no need for service graph partitioning in this instance, showcasing an edge case scenario. The code below shows the final NSD YAML service graph deployed by the IML. The structure of the YAML service graph is analysed in Section 4.4.2.1. D5.3: Final report on evaluation results and proof of concept demonstrations 256 [57] DESIRE6G, “Video D6G Demo 1: AR with Perceived Zero Latency | EuCNC 2024,” June 2024. [Online]. Available: https://www.youtube.com/watch?v=HIjJMZ22-m8&t=4s. [58] DESIRE6G, “Video D6G Demo 3: Deployment of Secure MAS Pipelines for Near-Real-Time Control of 6G NSes,” 2024. [Online]. Available: https://youtu.be/ubIW1gi2e8c?si=mTXzwoy77cE5OqdD. [59] DESIRE6G, “Video D6G Demo 4: Distributed MAS fed with Telemetry Data for Near-Real-Time Service Operation,” 2024. [Online]. Available: https://youtu.be/OLA_e55urcM?si=83Ty6rE6sTd_5YO. [60] DESIRE6G, “Video D6G Demo 2: Real-time Digital Twins,” June 2024. [Online]. Available: https://www.youtube.com/watch?v=m8eEal_AegE. [61] DESIRE6G, “Presentation video Demo 3: Deployment of Secure MAS Pipelines for Near-RT Control | OFC 2024,” March 2024. [Online]. Available: https://youtu.be/d7CuSKNg470?si=kMboPP3U8Ny8Ql2X.