D4.4 Final Report on Trustworthy and Efficient Digital Components

© COREnext 2023-2025 D4.4 Final Report on Trustworthy and Efficient Digital Components D4.4 – Final Report on Trustworthy and Efficient Digital Components 2 | 46 Revision v1.0 Work package WP4 Task T4.1, T4.2, T4.3, T4.4 Dissemination level PU — Public, fully open. e.g., website Deliverable type R — Document, report (excluding periodic and final reports) Due date 30-09-2025 Submission date 30-09-2025 Deliverable lead IHP - Leibniz Institute for High Performance Microelectronics (IHP) Version v1.0 Authors Markus Ulbricht (IHP), Hendrik Borchert (IHP), Nils Asmussen (BI), Romain Beurdouche (EUR), Julien Lallet (NNF), Renaud Santoro (NNF), Viktor Razilov (TUD), Vasiliki Lambrousi (WINGS), Andreas Georgakopoulos (WINGS), Marco Bertuletti (ETHZ) Contributors Task partners (see below) Reviewers Dick van den Broeke (NXP), Romain Beurdouche (EUR) Abstract This deliverable concludes the COREnext work on trustworthy and efficient digital components for Beyond-5G and 6G networks. Building on the concepts and components introduced in D4.1, heterogeneous acceleration developments as presented in D4.2, and trustworthiness mechanisms for computation and orchestration discussed in D4.3, it now reports the final status of all components. For each building block we present the prototype maturity, achieved KPIs, and interactions across partners, together with their integration paths towards the upcoming demonstrators in WP6. The deliverable also outlines the research outlook and road to product, linking the technical results to the project’s exploitation plan. It thereby provides the complete picture of how COREnext digital components advance efficient processing and trustworthy execution for 6G. Keywords 6G, RAN processing chain, RISC-V accelerators, heterogeneous computing, forward error correction (FEC), MAC scheduling, orchestration, isolation, virtualization, microkernel (M³), FPGA multi-tenancy, DSP virtualization, IoT trust management, radio link authentication, efficiency, trustworthiness D4.4 – Final Report on Trustworthy and Efficient Digital Components 3 | 46 Document Revision History Version Date Description of change Contributor(s) v0.1 24-06-2025 initial file setup Markus Ulbricht (IHP) v0.2 09-09-2025 initial contributions and first review All v0.3 29-09-2025 Second review applied and addressed All Contributing Partners Abbreviation Company name BI BARKHAUSEN INSTITUT EAB ERICSSON CYB CYBERUS TECHNOLOGY EUR EURECOM WINGS WINGS ICT SOLUTIONS ETHZ EIDGENOESSISCHE TECHNISCHE HOCHSCHULE ZUERICH IHP IHP MICROELECTRONICS NNF NOKIA NETWORKS FRANCE IIIV NNF/IIIV LABS IFAT INFINEON TECHNOLOGIES KAL KALRAY EF ERICSSON FRANCE TUD TECHNISCHE UNIVERSITAET DRESDEN Disclaimer The information, documentation and figures available in this deliverable are provided by the COREnext project’s consortium under EC grant agreement 101092598 and do not necessarily reflect the views of the European Commission. The European Commission is not liable for any use that may be made of the information contained herein. Copyright Notice ©COREnext 2023-2025 D4.4 – Final Report on Trustworthy and Efficient Digital Components 4 | 46 Executive Summary This deliverable D4.4 presents the final results of COREnext Work Package 4 on trustworthy and efficient digital components for Beyond-5G and 6G networks. It concludes the work of D4.1 (concepts), D4.2 (heterogeneous acceleration), and D4.3 (trustworthy computation and orchestration), and serves as the final technical report before the integration into WP6 and WP7. The components covered are: Heterogeneous Acceleration for Efficient Processing: • Programmable Many-Core RISC-V Accelerator for PHY Processing: TeraPool • Programmable Vector Processing Accelerator • FEC Accelerator • MAC Scheduling Accelerator Trustworthy Computation and Orchestration: • FPGA Multi-Tenancy • Digital Signal Processor Virtualization • M³ Microkernel-Based System • IoT Management • Radio Link Authentication For each of these components, the deliverable reports on: Finalized Component and Prototype Status • Description of the achieved design maturity, available prototypes, and implementation progress. Achieved KPIs • Summary of performance, efficiency, and trustworthiness targets met, with quantitative indicators, where available. Component / Partner Interactions and Input to WP6 • Identification of partner roles, interfaces, and how each single component provides input for later demonstrators. Research Outlook / Road to Product • Discussion of open research challenges, technical next steps, and potential pathways for evolving prototypes towards product readiness. This deliverable therefore provides the consolidated picture of all digital components developed in WP4 and sets the technical foundation for their upcoming integration and exploitation in the following work packages. D4.4 – Final Report on Trustworthy and Efficient Digital Components 5 | 46 Table of Contents 1 Introduction .............................................................................................................................................. 9 2 Processing Layers and COREnext Platform Architecture ............................................................. 11 3 Summary of Results from D4.2 and D4.3 ....................................................................................... 13 4 RISC-V-based Acceleration ................................................................................................................ 15 4.1 Programmable Many-Core RISC-V Accelerator for PHY Processing: TeraPool .......................................... 15 4.1.1 Finalized Component and Prototype Status ................................................................................................... 15 4.1.2 Achieved KPIs ............................................................................................................................................................... 15 4.1.3 Component/partner Interactions and Input to WP6 .................................................................................. 17 4.1.4 Research Outlook / Road to product ................................................................................................................. 17 4.2 Programmable Vector Processing Accelerator .......................................................................................................... 18 4.2.1 Finalized Component and Prototype Status ................................................................................................... 18 4.2.2 Achieved KPIs ............................................................................................................................................................... 19 4.2.3 Component/partner Interactions and Input to WP6 ................................................................................. 20 4.2.4 Research Outlook / Road to product ................................................................................................................. 21 4.3 FEC Accelerator ...................................................................................................................................................................... 21 4.3.1 Finalized Component and Prototype Status ................................................................................................... 21 4.3.2 Achieved KPIs .............................................................................................................................................................. 23 4.3.3 Component/partner Interactions and Input to WP6 ................................................................................. 24 4.3.4 Research Outlook / Road to product ................................................................................................................ 25 4.4 MAC Scheduling Accelerator ........................................................................................................................................... 25 4.4.1 Finalized Component and Prototype Status .................................................................................................. 26 4.4.2 Achieved KPIs ............................................................................................................................................................... 27 4.4.3 Component/partner Interactions and Input to WP6 ................................................................................. 29 4.4.4 Research Outlook / Road to product ................................................................................................................ 29 5 Isolation and Orchestration ............................................................................................................... 30 5.1 FPGA Multi-Tenancy .......................................................................................................................................................... 30 5.1.1 Finalized Component and Prototype Status ................................................................................................. 30 5.1.2 Achieved KPIs ............................................................................................................................................................... 31 5.1.3 Component/partner Interactions and Input to WP6 .................................................................................. 31 5.1.4 Research Outlook / Road to product ................................................................................................................. 31 5.2 Digital Signal Processor Virtualization .......................................................................................................................... 31 5.2.1 Finalized Component and Prototype Status ................................................................................................... 31 5.2.2 Achieved KPIs .............................................................................................................................................................. 32 5.2.3 Component/partner Interactions and Input to WP6 ................................................................................. 33 5.2.4 Research Outlook / Road to product ................................................................................................................ 33 5.3 M³ Microkernel-Based System ........................................................................................................................................ 33 5.3.1 Finalized Component and Prototype Status .................................................................................................. 34 D4.4 – Final Report on Trustworthy and Efficient Digital Components 6 | 46 5.3.2 Achieved KPIs .............................................................................................................................................................. 35 5.3.3 Component/partner Interactions and Input to WP6 ................................................................................. 35 5.3.4 Research Outlook / Road to product ................................................................................................................ 36 5.4 IoT Management (WINGS) ................................................................................................................................................ 36 5.4.1 Finalized Component and Prototype Status .................................................................................................. 36 5.4.2 Achieved KPIs .............................................................................................................................................................. 38 5.4.3 Component/partner Interactions and Input to WP6 ................................................................................. 39 5.4.4 Research Outlook / Road to product ................................................................................................................ 39 5.5 Radio Link Authentication ................................................................................................................................................. 39 5.5.1 Finalized Component and Prototype Status ................................................................................................. 40 5.5.2 Achieved KPIs .............................................................................................................................................................. 42 5.5.3 Component/partner Interactions and Input to WP6 ................................................................................. 44 5.5.4 Research Outlook / Road to product ................................................................................................................ 44 6 Conclusion ............................................................................................................................................. 45 List of Figures Figure 1: Overview of digital components ................................................................................................................. 11 Figure 2: Comparison of average utilization for different operand queue (OPQ) depths, number of VRF banks, and chime lengths C (the ratio of vector length and processing throughput). We compare our approach to a basic and a state-of-the-art optimized VRF. The thick line delimits the maximum achievable utilization with an ideal conflictless VRF. .................................................................. 20 Figure 3: A 5G-NR parity-check matrix is utilized to build a fully unrolled LDPC decoder capable of supporting flexible code rates ranging from 0.5 to 0.846. ............................................................................. 22 Figure 4: Floorplan of the implemented rate-flexible unrolled decoder, with highlighted hardware iteration blocks. .................................................................................................................................................................. 23 Figure 5: BER performance of the rate-flexible unrolled decoder. .............................................................. 23 Figure 6: Inference latency of single AIMOS forward pass on various NVDLA configurations. ....... 27 Figure 7: Average throughput of three different QoS-profiles. Error bars denote 99% confidence intervals. ................................................................................................................................................................................ 28 Figure 8: Performance comparison of the LDPC workload between M³ and an RFSoC. .................... 34 Figure 9: Trust Manager Flowchart [D4.3] .............................................................................................................. 37 Figure 10: Trustworthiness gains for various device and task counts compared to load balancing baseline algorithm. ........................................................................................................................................................... 38 Figure 11: Close-set vs. open-set paradigms ......................................................................................................... 40 Figure 12: Experimental setup. .................................................................................................................................... 40 Figure 13: Overview of the data preprocessing hyperparameters ................................................................ 42 D4.4 – Final Report on Trustworthy and Efficient Digital Components 7 | 46 Figure 14: Overview of the ML pipeline at inference .......................................................................................... 42 Figure 15: Results of the closed set scenario .......................................................................................................... 43 Figure 16: The classification accuracy of our ML model (Y-axis) vs. device temperature (X-axis) .... 44 List of Tables Table 1: Key Performance Indicators per acceleration components ............................................................ 13 Table 2: Key Performance Indicators per orchestration component ........................................................... 14 Table 3: Key Performance Indicators of commercial SoA platforms for software-defined lowerPHY processing ................................................................................................................................................................... 16 Table 4: KPIs comparison for LDPC encoders ....................................................................................................... 24 Table 5: Sample LDPC decoding times with software and AAL .................................................................... 32 D4.4 – Final Report on Trustworthy and Efficient Digital Components 8 | 46 Acronyms and Definitions WP Work Package NOMA Non-Orthogonal Multiple Access 5G Fifth Generation NR New Radio 6G Sixth Generation OAuth Open Authorization AI Artificial Intelligence OFDM Orthogonal Frequency Division Multiplexing CNN Convolution Neural Network OFDMA Orthogonal Frequency-Division Multiple Access CP Cloud Provider OPS Operations per Second CP Cyclic Prefix O-RAN Open Radio Access Network Alliance CRC Cyclic Redundancy Check OSR Oversampling Ratio DMA Direct Memory Access PA Power Amplifier DNN Deep Neural Network PBO Power Back-Off DPU Data Processing Unit PDCP Packet Data Convergence Protocol DRAM Dynamic Random Access Memory PHY Physical Layer DRL Deep Reinforcement Learning PUSCH Physical Uplink Shared Channel DSP Digital Signal Processor QAM Quadrature Amplitude Modulation DU Distributed Unit QoS Quality of Service FEC Forward Error Correction RAN Radio Access Network FFT Fast Fourier Transform RISC-V Reduced Instruction Set Computer V FPGA Field Programmable Gate Array RLC Radio Link Control IoT Internet-of-Things RRC Radio Resource Control IP Intellectual Property RRM Radio Resource Management ISA Instruction Set Architecture RU Remote Unit KPI Key Performance Indicators SDR Software Defined Radio LDPC Low Density Parity Check SIMD Single-Instruction Multiple-Data LLR Log-Likelihood Ratio TA Trusted Authority LTE Long Term Evolution TCDM Tightly Coupled Data Memory MAC Media Access Control TCU Trusted Communication Unit MIMO Multiple Input Multiple Output TEE Trusted Execution Environment ML Machine Learning TTI Transition Time Interval MMSE Minimum Mean Squared Error UE User Equipment MPSoC multi-processors system-on-chip D4.4 – Final Report on Trustworthy and Efficient Digital Components 9 | 46 1 Introduction The evolution from 5G to Beyond-5G and 6G networks will enable new classes of applications such as extended reality (XR), autonomous driving, industrial automation, and large-scale IoT infrastructures. These use cases, first defined in Deliverable D2.1, pose stringent requirements: ultra-low latency, massive connectivity, high reliability, energy efficiency, and strong guarantees of trustworthiness. Addressing these challenges requires a holistic design approach, spanning efficient digital signal processing, innovative hardware architectures, and built-in mechanisms for isolation and secure execution. The COREnext project tackles these challenges by developing a disaggregated and trustworthy computing architecture for 6G. Building on the use cases and requirements defined in WP2, Deliverable D3.1 translated them into a system-wide architecture. This architecture combines heterogeneous acceleration, efficient interconnects, and mechanisms for trust and attestation into a coherent platform. It identifies a set of analogue and digital components as building blocks developed in Work Packages 4 and 5, which in turn provide input back into the architectural evolution and to the system-level validation in WP6. Within this framework, Work Package 4 (WP4) focuses on the digital components. Its dual objectives are (i) to design heterogeneous hardware accelerators that enable energy-efficient and programmable processing across the radio access network (RAN), and (ii) to develop mechanisms for trustworthy computation and orchestration that guarantee isolation and secure execution across heterogeneous resources. Together, these digital building blocks form the foundation for demonstrators in WP6 and for the exploitation and innovation activities in WP7. The work in WP4 has been structured into a sequence of deliverables: • D4.1 “Concept for Hardware Security Primitives and Heterogeneous Acceleration” introduced the architectural foundations, identifying RISC-V–based accelerators as enablers for power-efficient processing, and outlining hardware security primitives to support isolation and orchestration. • D4.2 “Heterogeneous Acceleration for Efficient Processing” reported progress on the accelerator components, including a programmable many-core RISC-V accelerator, a vector processor, a forward error correction (FEC) accelerator, and a MAC scheduling accelerator. It also presented quantitative KPIs on performance and efficiency. • D4.3 “Trustworthy Computation and Orchestration” presented mechanisms to provide trustworthiness at different levels, including FPGA multi-tenancy, DSP virtualization, the M³ microkernel-based system, IoT management, and radio link authentication, with their prototype status and trustworthiness KPIs. This deliverable, D4.4 “Final Report on Trustworthy and Efficient Digital Components”, concludes the work of WP4. It consolidates the final prototype status of all components, summarizes their achieved KPIs, reports on their role in partner interactions and input to WP6 demonstrators, and outlines research outlooks and roadmaps towards product readiness. The remainder of this document is structured as follows: Chapter 2 describes the COREnext platform architecture and its layered processing model, drawing from D2.1, D3.1, and D4.1. Chapter D4.4 – Final Report on Trustworthy and Efficient Digital Components 16 | 46 Table 3: Key Performance Indicators of commercial SoA platforms for software-defined lower-PHY processing Platform PHY Processor ISA Multi-Core 5G split NVIDIA AX800 Ampere GPU BlueField-3 DPU NVIDIA Yes (8192c) 8 EdgeQ/S-series TXU Processor ARM Neoverse-E1 RISC-V ARM Yes (60c) 6-7.2 Picocom/PC802 Ceva XC12 RISC-V No (25c) 7.2X Marvell/Octeon10 ARM Neoverse-N2 DSP Processors Accelerators ARM Yes (<36c) 7.X Qualcomm/X100 N.A. N.A. N.A. 7.X General-purpose graphic processing units (GP-GPUs) achieve high-performance parallelization and keep software versatility. They are nowadays the main computing platforms for deep learning applications, and they are also considered good options to fill the flexibility/performance gap required by 5G and beyond. In fact, aiming for the reuse of existing GP-GPU cloud infrastructure in the domain of 5G, NVIDIA fostered RAN virtualization3. Wireless processing software libraries with CUDA support were developed to run on commodity cloud hardware, such as the AX800 converged accelerator, which achieves 36.56-Gb/s (downlink) and 4.79-Gb/s (uplink) throughput. With 350-W peak power consumption, AX800 usage is recommended in a cloud infrastructure. GP-GPU-based RAN processing, and therefore, targets 5G split 8, where none of the PHY functions is implemented in the BS, putting high requirements on the data rates of the network fronthaul: 100 Gb/s. EdgeQ S-Series4, Picocom PC8025, Marvell Octeon106 and Qualcomm X1007 are heterogeneous platforms all containing one or more programmable components. They implement the 5G split 3 https://ieeexplore.ieee.org/document/10310082 4 https://www.edgeq.io/technology/ 5 https://picocom.com/products/socs/pc802/ 6 https://www.marvell.com/products/data-processing-units.html 7 https://www.qualcomm.com/news/onq/2023/03/how-we-won-the-acceleration-architecture-debate D4.4 – Final Report on Trustworthy and Efficient Digital Components 17 | 46 7.X, where the PHY functions up to decoding of the received signals are offloaded to the BS. For all these platforms, vendors offer pre-built libraries of kernels with the hardware. Our approach is aligned with this trend; it can be used to implement a software-defined version of split 7.X and it offers additional advantages. First, it has at least 10× more cores than all the clusters used in industry platforms for deployment at the network’s edge. Its processing elements are, however, smaller and architecturally simple. The core complex occupies only 80 kGE and a SubGroup instance, including 64 cores and 1 MiB of memory occupies 2.3 mm2 in 12 nm. The ARM NeoverseN2 in Marvell’s Octeon10 is bulkier; a single core occupies 1.3 mm2 in 5 nm. Second, it offers competitive power consumption. It consumes 5.54 W on average for PUSCH uplink. This processing is similar to the downlink workload described by [https://www.qualcomm.com/news/onq/2023/03/how-we-won-the-accelerationarchitecture-debate], which in turn consumes ∼18 W on the X100 card. Third, it proposes an efficient novel shared-memory architecture. The work on TeraPool showed how this can be used to implement an in-line processing pipeline, where the L1 memory is used as a low-latency compute buffer8.. 4.1.3 Component/partner Interactions and Input to WP6 The post placement and routing PPA analyses on the TeraPool provided in D4.3 are available in the context of WP6 for power and area-cost of programmable acceleration solutions for gNB lowerPHY processing. 4.1.4 Research Outlook / Road to product Future research directions include and are not limited to: 1. The exploration of RVV ISA-extensions applied to gNB processing, in synergy to TUD results on the WP4 programmable vector accelerator component. The integration of multiple RVV engines in TeraPool was partially explored9. 2. The exploration of more area-efficient NoC-based solutions for the cores-L1 memory interconnect, which was partially addressed10. 3. The integration of domain specific accelerators in the TeraPool Tiles, with the purpose of addressing mixed AI-telecommunications workloads, as foreseen by IMT-2030 agenda11. 8 https://ieeexplore.ieee.org/document/11038837 9 https://ieeexplore.ieee.org/abstract/document/10992996 10 https://arxiv.org/abs/2508.02446 11 https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2030/pages/default.aspx D4.4 – Final Report on Trustworthy and Efficient Digital Components 18 | 46 4.2 Programmable Vector Processing Accelerator Fixed-function accelerators provide excellent efficiency and performance but are challenging to virtualize. Programmable platforms are more efficient but less efficient in comparison. Our aim is to fill the gap on the performance-flexibility trade-off curve between general-purpose processors and fixed-function accelerators with programmable vector processing accelerators. Like other single-instruction multiple-data (SIMD) architectures, Vector processors distribute the instruction fetch and decode overhead over a vector of data items. The functional units (FUs) inside then process the data vectors in parallel. They do so in a pipelined fashion—in contrast to conventional so-called “packed-SIMD” extensions. Thus, the former exploit not only data-level but also instruction-level parallelism—a potential for higher utilization of the FUs. Another advantage of the vector approach is its enhanced scalability gained by decoupling the software vector length from the underlying implementation. The same binary can run on a variety of implementations optimized for different key performance indicators. We set out to improve vector processing instruction set architectures (ISAs) in a way that optimizes chaining, i.e., the pipelined instruction execution inside the vector processor. Our goal is to increase the utilization of the FUs. Increased utilization comes with better performance and potentially lower energy consumption because of reduced leakage. To this end, we take a closer look at the internals of state-of-the-art open-source vector processors running selected communications signal processing kernels and model different vector processor microarchitectures. 4.2.1 Finalized Component and Prototype Status We made two optimizations to vector processors microarchitectures. Our first optimization proposal is the dual vector load which loads two vectors that are operands to a follow-up binary operation in parallel to bring the execution of the latter instruction forward. Theoretical analysis of this ISA extension showed that it is beneficial for compute-bound and some memory-bound programs. The highest possible speedup is 33 % and we achieved a speedup of 21 % in an implementation with about 2 % area overhead12. Our second optimization concerned the vector register file, which we identified as a major bottleneck. The bottleneck is even more severe when vector processor works at a high utilization. To study the problem, we have built a cycle-accurate software model of a vector processor with multiple architectural options. The model allows to study the impact of bank conflicts on the runtime and the utilization of the functional units. We analysed the degradation by and the characteristics of VRF access conflicts thoroughly. If left unmanaged they can easily more than halve the utilization. However, one can manage them by avoidance, resolution, and mitigation. We 12 https://ieeexplore.ieee.org/document/10121996 D4.4 – Final Report on Trustworthy and Efficient Digital Components 19 | 46 invented dynamic bank layout to overcome the suboptimal conflict avoidance of static bank layouts and an optimized round-robin arbitration for mixed-width arithmetics13. 4.2.2 Achieved KPIs We measured the utilization and runtime of selected vector processing kernels and compared an ideal vector processor and state-of-the-art designs with our optimizations. Overall, our VRF architecture with dynamic bank layout and a width-aware arbitration achieves performance gains for a wide range of vector processor design parameters—especially for long chime lengths—and allows for a trade-off. One can save power and area-hungry operand queues (buffers between the VRF and the FUs) at no performance degradation. One can also keep the deep operand queues and increase the performance and runtime. For an average configuration (eight banks and a vector length that is eight times the processing throughput) we measured an increase of the average utilization from 83 % to 85 %, closer to the 89 % that would be possible with an ideal VRF. This increase corresponds to a performance increase of 3 %. With longer vectors (vector length is 32 times the processing throughput), when utilization is higher, we measured an increase of the average utilization from 87 % to 89 %, closer to the 92 % that would be possible with an ideal VRF. This increase corresponds to a performance increase of 3 %. The results are plotted in Figure 2. 13 https://dl.acm.org/doi/10.1145/3702002 D4.4 – Final Report on Trustworthy and Efficient Digital Components 20 | 46 Figure 2: Comparison of average utilization for different operand queue (OPQ) depths, number of VRF banks, and chime lengths C (the ratio of vector length and processing throughput). We compare our approach to a basic and a state-of-the-art optimized VRF. The thick line delimits the maximum achievable utilization with an ideal conflictless VRF. 4.2.3 Component/partner Interactions and Input to WP6 A research collaboration is ongoing with ETHZ. ETHZ is exploring the integration of tiny vector coprocessors in the ManyCore cluster described in section 3.1. TUD is providing support to extend the co-processors with dual vector-load. TUD also collaborates with BI to integrate the Ara vector processor14 into the M3 platform for trustworthy heterogenous Multi-Processors Systems-on-Chip (MPSoCs), which is used in the WP6 demonstrators. 14 https://ieeexplore.ieee.org/document/8918510 D4.4 – Final Report on Trustworthy and Efficient Digital Components 21 | 46 4.2.4 Research Outlook / Road to product We have not implemented the proposed vector processor optimizations as digital circuits, yet. Doing so will yield more accurate insights into the area saving. Our optimizations might need modifications if they elongate the critical path. 4.3 FEC Accelerator An LDPC accelerator for a microcontroller leverages an unrolled LDPC decoder to achieve highthroughput forward error correction while offloading computationally intensive tasks from the main CPU. Unlike traditional iterative decoders, the unrolled architecture pre-instantiates the full decoding graph in hardware, eliminating the need for control flow and memory accesses for intermediate messages. This results in deterministic low latency and highly parallel processing, which are particularly beneficial for real-time communication systems. In this configuration, the microcontroller handles protocol-level tasks and system control, while the LDPC accelerator—integrated as a hardware peripheral—executes the decoding process with minimal CPU intervention. The unrolled design enables the accelerator to process multiple bits per clock cycle, significantly reducing the number of cycles per codeword. Key benefits of such an architecture include: • Ultra-low latency, critical for time-sensitive applications. • Scalability to support different code rates and block lengths with configurable parameters. This makes an LDPC accelerator with an unrolled decoder particularly well-suited for IoT devices, 5G wireless modules, and other embedded systems where both performance and power efficiency are crucial. 4.3.1 Finalized Component and Prototype Status During the most recent reporting period, IHP introduced code-rate flexibility into the accelerator design. The earlier version of the decoder was limited to operating with a single fixed LDPC code rate. The new implementation features a VHDL core capable of dynamically varying the FEC rate across the range 0.5 to 0.846. For achieving this flexibility, the design employs a 5G-NR LDPC parity-check matrix with dimensions 704 × 1408 (see Figure 3). This matrix is constructed from base graph 1 using a lifting factor of Z=32. Under the 5G-NR specification, the first 2Z=64 columns are subject to puncturing and are excluded from data transmission. Unlike the standard, our ASIC implementation prioritizes support for multiple code rates over full compliance with the 5G-NR protocol. Puncturing of the first 2Z columns is implemented as an optional feature, and for the results presented in this work, it was left disabled. Consequently, the resulting code functions as a basic rate-½ LDPC code. This configuration, while enabling flexibility, is not entirely standardcompliant and may lead to a slight reduction in Eb/N0 performance. To accommodate higher code rates, the design integrates hardware-based rate matching, adopting a strategy similar to that employed in 5G-NR LDPC implementations. D4.4 – Final Report on Trustworthy and Efficient Digital Components 22 | 46 Figure 3: A 5G-NR parity-check matrix is utilized to build a fully unrolled LDPC decoder capable of supporting flexible code rates ranging from 0.5 to 0.846. The ½-rate parity-check matrix depicted in Figure 3 defines 704 check nodes, where each row specifies how a check node is connected to the corresponding codeword bits. The figure highlights three critical regions, marked with red rectangles, that play distinct roles in enabling code-rate flexibility. Part A represents the core section of the matrix, consisting of 128 check nodes. This region is highly interconnected, with complex quasi-cyclic dependencies. Any attempt to remove rows or columns here would disrupt the matrix structure. Therefore, this part remains fixed and unaltered, serving as the core check rows. Part B highlights a diagonal sub-matrix, where each redundancy bit in the codeword is associated with exactly one check node. By selectively disabling check nodes in the rows indexed between 128 and 704, redundancy bits can be removed one by one without affecting the remaining parity relationships—provided the deactivation starts from the rows with the highest indices. This property is crucial for implementing adaptive code rates in hardware. Part C corresponds to the check nodes linked to the redundancy bits disabled in Part B. When a redundancy bit in Part B is deactivated, the associated check node in Part C is also turned off, maintaining consistency in the decoding process. The flexible code rate is achieved by sequentially disabling check nodes, each responsible for one redundancy bit. This approach allows for the removal of up to 576 redundancy bits, reducing the original (1408,704) code with R=0.5 to an (832,704) code with R=0.846. Consequently, the architecture supports 576 distinct code configurations, offering fine-grained rate adjustment across the entire range 0.5 ≤ R ≤ 0.846. Importantly, this capability is not limited to the 5G-NR parity matrix. Any parity matrix featuring a single diagonal sub-matrix in its lower-right corner can enable this form of fully flexible code-rate operation. The hardware mechanism for adjusting the code rate, as outlined earlier, is both simple and efficient to implement. The process involves skipping the computations for any check node whose row index exceeds a configurable threshold provided as an external parameter. This threshold can take any value between 128 and 704, defining which check nodes remain active. Each check node with an index greater than 128 is equipped with a 9-bit comparator, which determines whether the external parameter is higher or lower than the node’s index. Based on this comparison, the check node is either enabled or disabled. When disabled, the node remains physically present in the hardware but is functionally bypassed, with all of its output edges forced to zero. To ensure compatibility across all supported code rates, the decoder’s input and output interfaces always accommodate the full set of redundancy bits required for the lowest rate (R=0.5). In cases D4.4 – Final Report on Trustworthy and Efficient Digital Components 23 | 46 where certain redundancy bits are not needed (for higher code rates), zeros are inserted in their positions. As a result, the overall hardware complexity remains equivalent to that of a fixed ½-rate decoder, while enabling full code-rate flexibility through this lightweight control logic. The implemented chip layout is shown in Figure 4. Figure 4: Floorplan of the implemented rate-flexible unrolled decoder, with highlighted hardware iteration blocks. 4.3.2 Achieved KPIs This section presents the achieved performance key performance indicators (KPIs). 4.3.2.1 Bit error rate (BER) performance Figure 5 illustrates the BER performance of the designed chip in comparison with a floating-point simulation. In the high-rate configuration (R=0.846), the hardware shows only a ~0.2 dB loss relative to the floating-point MATLAB reference. For the R=0.5 configuration, however, the hardware implementation requires a longer accumulator in the variable nodes than the high-rate design. This limitation results in an approximate 0.5 dB performance gap compared to the floatingpoint model. The gap can be minimized by enhancing the variable node architecture. Therefore, further fine-tuning of the unrolled decoder is essential to achieve optimal performance across the entire range of supported code rates. Figure 5: BER performance of the rate-flexible unrolled decoder. D4.4 – Final Report on Trustworthy and Efficient Digital Components 24 | 46 4.3.2.2 Chip KPI and comparison to the decoders from the literature Table 4 provides a comparison between our flexible-rate implementation and other state-of-theart high-speed LDPC decoders reported in the literature. To the best of our knowledge, this work represents the first unrolled LDPC decoder that not only supports dynamic code-rate adjustment but also achieves a throughput in the range of several hundred Gb/s, while offering unprecedented flexibility with respect to code-rate configuration. Table 4: KPIs comparison for LDPC encoders 15 16 17 COREnext implementation at R = 0.846 at R = 0.500 Technology 28 nm FD-SOI 16 nm FinFET (*) 28 nm 28 nm Implementation Place&Route Place&Route Place&Route Place&Route Corner Typical-case Worst-case Worst-case Setup: Worst-case; Hold: Best-case Coded throughput 588 Gb/s 1000 Gb/s (**) 1218 Gb/s 962 Gb/s 1628 Gb/s Inf. throughput 494 Gb/s 833 Gb/s (**) 1015 Gb/s 814 Gb/s LDPC Code (2048, 1723) (1027, 856) 802.11n (648,540) 5G-NR (832,704) 5G-NR (1408,704) Code rate 0.841, const. 0.833, const. 0.833, const. 0.846, flexible 0.500, flexible Number of cores 1 12 1 1 Algorithm Finite-Alphabet, Unrolled Layered, Cores duplication Min-Sum, Unrolled Min-Sum, Unrolled Flexible Rate No No (***) No 576 steps, range [0.500, 0.846] Iterations 5 4 5 5 Quantisation 3 bit 5 bit 4 bit 4 bit Core Area 16.2 mm2 2.24 mm2 5.49 mm2 17.36 mm2 Core utilisation 65.9% 69% 36% 35% Clock freq. 862 MHz 1000 MHz 1880 MHz 1156 MHz Latency 69.6 ns 38 ns 19.68 ns 36.3 ns Area efficiency 36 Gb/s/mm2 446 Gb/s/mm2 222 Gb/s/mm2 47 Gb/s/mm2 Energy efficiency Max. 22.7 pJ/b 7.5 pJ/b at 3 dB; 12.74 pJ/b at 4 dB 27.25 pJ/bit 41.88 pJ/bit SNR at BER = 10-6 ≈ 4.9 dB ≈ 4.75 dB ≈ 4.8 dB ≈ 1.9 dB SNR at BER = 10-7 ≈ 4.95 dB ≈ 5.25 dB ≈ 5.0 dB ≈ 5.05 dB ≈ 2.35 dB 4.3.3 Component/partner Interactions and Input to WP6 Although the implementation of the LDPC accelerator was carried out exclusively by IHP, we actively engaged with our project partners throughout the development process. We regularly sought their feedback, shared intermediate results, and encouraged open communication to ensure alignment with the broader goals of the project. This collaborative approach helped us refine the design and assess its potential relevance to various use cases within the consortium. In the context of Work Package 6 (WP6), it is important to note that direct integration of the accelerator into a demonstrator is not currently foreseen. However, the developed accelerator offers a high-throughput error correction capability that aligns well with the performance 15 R. Ghanaatian et al., “A 5 88-Gb/s LDPC Decoder Based on Finite-Alphabet Message Passing,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems. 2017. 16 M. Li, V. Derudder, K. Bertrand, C. Desset, and A. Bourdoux, “High-Speed LDPC Decoders Towards 1 Tb/s,” IEEE Transactions on Circuits and Systems I: Regular Papers, pp. 1–10, 2021, 17 L. Lopacinski et al., “Ultra high speed 802.11n LDPC decoder with seven-stage pipeline in 28 nm CMOS,” in IEEE 95th Vehicular Technology Conference, 2022, pp. 1–5. D4.4 – Final Report on Trustworthy and Efficient Digital Components 25 | 46 requirements anticipated for next-generation communication systems. As such, it holds significant potential for future integration into the platform envisioned within the scope of this project 4.3.4 Research Outlook / Road to product The successful development and validation of the rate-flexible unrolled LDPC decoder mark a significant milestone in advancing high-speed error correction technologies. While the current implementation demonstrates outstanding performance in terms of throughput and flexibility, several research and development steps are envisioned to transition this prototype into a commercial-grade product. 4.3.4.1 Short-Term Outlook In the immediate future, the focus will be on optimizing power efficiency and reducing implementation complexity. Techniques such as advanced clock gating, power gating of inactive nodes, and pipeline optimization will be further explored. Additionally, migrating the design to smaller technology nodes (e.g., 7 nm or 5 nm) is expected to significantly lower energy per bit while maintaining or increasing throughput. 4.3.4.2 Medium-Term Outlook For broader applicability, the decoder architecture will be extended to support additional LDPC code standards beyond 5G-NR, such as DVB-S2X, Wi-Fi 7, and emerging optical communication standards. Furthermore, integration with microcontrollers and system-on-chip (SoC) platforms will be investigated to create versatile solutions for both embedded and high-performance applications. 4.3.4.3 Long-Term Road to Product To achieve a market-ready product, the following steps are essential: • Industrial-Grade Verification – performing exhaustive testing under real-world operating conditions to ensure robustness and reliability, demonstration in network stack. • Standardization Compliance – ensuring full compatibility with target communication standards and certification requirements. • System Integration – collaborating with industry partners to integrate the decoder into commercial modems, baseband processors, and network equipment. • Commercialization – establishing a production pipeline with silicon foundries and defining a cost-effective manufacturing process. Ultimately, this research paves the way for next-generation LDPC accelerators that combine extreme throughput, dynamic code-rate adaptation, and energy-efficient operation. With further refinement and industrial collaboration, the presented decoder has the potential to become a key enabler for future wireless, optical, and satellite communication systems. 4.4 MAC Scheduling Accelerator The MAC scheduler is an integral unit of the Data Link Layer (DLL) and is responsible for distributing available physical resources to user equipment (UE) in the network while adhering to given Quality D4.4 – Final Report on Trustworthy and Efficient Digital Components 32 | 46 This makes OAI an experimental platform enabled with state-of-the-art computing technologies enabling various experimental use cases like technological comparative studies, testing of capabilities and compliance of novel computing architectures. OpenAirInterface with the AAL integration is available through EURECOM’s Gitlab. 5.2.2 Achieved KPIs Among the many libraries available for channel coding – the most intensive computing task in the 5G network stack –, AAL is implemented by only one library supporting 3 state-of-the-art accelerators: 2 engineering samples and one commercial product. One accelerator can be shared by up to 16 network instances. But in practice, the performance of the accelerator may further limit the number of network instances sharing the accelerator. An evaluation of this limit for the accelerators integrated with OAI is being driven by EUR within WP6. One of the purposes of the channel coding accelerators is to reduce the cost of computing devices dedicated to channel coding in the network by reducing the number of general-purpose CPU cores necessary for a network workload and replacing them with the accelerator. If the device is properly designed, the resource and energy costs of the network with the accelerator are inferior to the costs without the accelerator. Another purpose of the channel coding accelerator is to achieve a better best-effort processing time than software. The commercial grade accelerator introduced in OAI with AAL gives a significant boost in comparison to the preexisting software implementation. This boost can be illustrated by comparing the best-effort LDPC decoding time of a slot achieved with software and AAL acceleration for some scenarios specified in the standards. This metric is important to consider for determining if the implementation can match the latency requirements enforced by the standard. Table 5 gives as examples these times for some sample cases among the most demanding cases of the standard: Cases Software decoding time AAL decoding time 100 MHz bandwidth, 30 kHz SCS, 8 RX antennas, MCS 20, 5.9 dB SNR 2823µs 136µs 40 MHz bandwidth, 30 kHz SCS, 4 RX antennas, MCS 2, -2.1 dB SNR 359µs 38µs 40 MHz bandwidth, 30 kHz SCS, 4 RX antennas, MCS 16, 11.2 dB SNR 1545µs 71µs Table 5: Sample LDPC decoding times with software and AAL D4.4 – Final Report on Trustworthy and Efficient Digital Components 33 | 46 A more extensive study of the performance giving a global overview of the performance of the accelerator should be part of the comparative study conducted within WP6. 5.2.3 Component/partner Interactions and Input to WP6 The experimental platform OAI with its capabilities enabled within WP4 as well as the experience gained in performing this enhancement are used in the scope of WP6. In Task 6.2, the experience gained about accelerator architecture allows us to design a relevant execution scenario for the M3 baseband workload simulation scenario that is tested by the Barkhausen Institute (BI). OAI with AAL also allows us to generate some reference processing times that are compared with the times achieved by the M3 platform while simulating the same task. These materials are used by EUR and BI to author the paper “Hardware-level Isolation of Dataflows for Trustworthy 5G/6G Signal Processing”, which has been submitted to a GLOBECOM workshop. The purpose of the paper is to demonstrate the ability of the M3 platform to perform in executing realistic digital signal processing workloads. Within the scope of Task 6.3, OAI with AAL enabled is leveraged by EUR to make performance evaluations and technology comparative studies. The purpose of these studies is to better know the real performance achieved by state-of-the-art computing architectures as a reference point for the novel architectures developed by partners, especially Kalray (KAL) with its accelerated RISC-V platform. 5.2.4 Research Outlook / Road to product The ultimate purpose of the integration of the O-RAN AAL in OAI is to offer an experimental mobile network software that can serve for the testing, comparison and promotion of novel components developed by partners within COREnext and beyond. It is indeed essential for a new computing solution to be broadly advertised, and its capabilities proven to the research and engineering world in order that end-product integrators choose this solution rather than another one. 5.3 M³ Microkernel-Based System M³ proposes a new system architecture based on a hardware/software co-design. On the hardware side, M³ builds upon a tiled architecture, where each tile is extended by a new hardware component called Trusted Communication Unit (TCU). The TCU both isolated the tiles from each other and allows to selectively establish communication channels for message passing and memory access. On the software side, M³ runs a small microkernel on a dedicated kernel tile, and applications and operating-system services on the remaining user tiles. This reduces the trusted computing base, because the security-critical kernel is kept small and most of the functionality of the operating system (e.g., file systems, network stacks, and drivers) is provided by unprivileged user tiles. User tiles can use existing communication channels, but only the M³ kernel is allowed to establish such channels. By default, no communication channels exist and thus tiles are isolated from each other. It has been demonstrated before that this design has advantages for heterogeneous platforms due to the common interface for all tiles provided by the TCU, and that all tiles can be efficiently multiplexed among multiple mutually distrusting applications. Furthermore, it has been shown that D4.4 – Final Report on Trustworthy and Efficient Digital Components 34 | 46 M³ offers superior isolation between applications compared to traditional approaches. Within COREnext, we also demonstrated its advantages regarding real-time guarantees and investigated its suitability for future mobile-communication infrastructures that run radio-signal workloads with low latency requirements. We are also in the process of enabling trusted execution environments on M³. The following gives more details on these three topics. 5.3.1 Finalized Component and Prototype Status Real-time Properties of the M³ Platform Within COREnext we investigated the real-time properties of the M³ platform. By construction M³ has the advantage that tiles are isolated from each other by the TCU and lack shared caches or TLBs. This reduces timing jitter significantly and enables local reasoning: the real-time analysis can be performed locally on a per-tile basis. To investigate this advantage, we measured the jitter for cross-tile communication and compared it with cross-core communication on Linux and the microkernel NOVA. Since communication on M³ bypasses the OS kernel and avoids interrupts, it achieves a significantly lower round-trip latency of about 300–540 cycles on our FPGA platform. This latency is orders of magnitude lower than on Linux (about 16000 cycles) and NOVA (about 7000 cycles). Furthermore, we observed a jitter of about 100 cycles on M³ and 3000–4000 cycles on Linux and NOVA. We also found that due to the remaining globally shared resources NoC and DRAM, other tiles can influence the performance of memory-intensive workloads on a victim tile by up to a factor of 5. To mitigate this effect and enable local reasoning even in such noisy environments, we added a token-bucket traffic shaper to the TCU, configurable per process. Our measurements showed that limiting background traffic to 8 MiB/s reduces interference to under 1 %. We published these findings on the 30th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) in the paper “Core-Local Reasoning and Predictable Cross-Core Communication with M³”. Hardware-level Isolation for Signal Processing Figure 8: Performance comparison of the LDPC workload between M³ and an RFSoC. D4.4 – Final Report on Trustworthy and Efficient Digital Components 35 | 46 In a collaboration with EURECOM, we studied whether the M³ platform is suitable to run signalprocessing workloads with low-latency requirements. We evaluated the performance of M³ in comparison to a real Radio Frequency System on Chip (RFSoC) featuring eight FEC computation units. On M³, we developed a data-flow framework that allows arbitrary data streams between tiles including fan-in and fan-out. Based on that, we emulated the signal processing workload by replicating the communication pattern and data sizes and spinning for the execution time of the FEC units. As can be seen in Figure 8: Performance comparison of the LDPC workload between M³ and an RFSoC., M³ can run latency-critical workloads in an efficient way that is competitive to stateof-the-art systems. However, due to the different hardware platforms, the results have to be interpreted with a grain of salt. The results are described in the paper “Hardware-level Isolation of Dataflows for Trustworthy 5G/6G Signal Processing”, which has been submitted to a GLOBECOM workshop. Core-Independent Trusted Execution Environments Trusted Execution Environments (TEEs) enable secure data processing by isolating a program from all other software on a system. However, current TEEs are often limited to CPUs and tied to a specific instruction set architecture, making them challenging to use in heterogeneous environments. We are therefore designing core-independent TEEs on M³ where the isolation between TEEs is enforced by the TCU – a separate hardware component. We evaluate the implications in terms of performance, hardware costs, and trusted computing base size on our FPGA-based hardware platform. 5.3.2 Achieved KPIs We have shown that M³ does not only provide low-latency communication across tiles (300-500 cycles roundtrip time), but can also efficiently execute signal-processing workloads, achieving similar results as state-of-the-art hardware. At the same time, M³ provides superior isolation between the individual components of the workload. Finally, the additional isolation was demonstrated to have negligible impact for mobile communication signal processing workloads. We conclude that the latency targets for running the desired digital workloads on M³ has been achieved while maintaining and with TEEs even strengthening its isolation properties. The protection afforded by M³ relies on a Trusted Computing Base that is orders of magnitude smaller than comparable commodity architectures, contributing to its enhanced attack resilience against both software and hardware vulnerabilities. 5.3.3 Component/partner Interactions and Input to WP6 We collaborated with partner EURECOM (EUR) on emulating realistic signal processing workloads on the M³ platform. We are also in discussions with Ericsson (EAB) about running their fingerprinting AI workload on M³. At the point of writing this deliverable, this collaboration with WP5 is still in an exploratory state. Conceptually, the M³ platform can incorporate the RISC-V and accelerator components developed in WP4 as parts of its tile-based design. Full integration of all results is beyond the scope of D4.4 – Final Report on Trustworthy and Efficient Digital Components 36 | 46 COREnext, but the methods of integrating accelerators has been demonstrated with M³ in earlier publications and acceleration is also part of our work with EURECOM on running signal processing on M³. For WP6, the security protection and hardware integration aspects of M³ are part of Task 6.2. The project has developed a demonstrator, which was already presented at EuCNC to showcase M³’s unique selling point of protecting a system against vulnerable hardware and software. We intend to extend this demonstrator for the final review. It has also been used repeatedly within BI to present security research results to regulators and other societal stakeholders. 5.3.4 Research Outlook / Road to product Partner Barkhausen Institute (BI) continues to advance M³ towards higher TRL. We are currently working to scale the platform in two directions: Within a nationally funded projects we are scaling down the hardware footprint to fit for Internet-of-things use cases. Together with industry and research partners, we are also investigating to scale the platform up towards datacentre and DPU applications. We intend to productize M³ at some point, probably within the context of a spin-off company. However, research efforts to further advance the scale and capabilities of M³ are necessary to become competitive with comparative industrial offerings. The trustworthiness awarded by the platform’s security properties remains a key advantage, which highlights its roots in European values. 5.4 IoT Management (WINGS) As highlighted in previous deliverables D4.1, D4.2 and D4.3, IoT has transformed everyday objects into smart, interconnected devices, now embedded in homes, workplaces, and public spaces. With their growing role in critical systems and sensitive data handling, ensuring device trustworthiness, reliability, security, and privacy, is essential for user safety and system integrity. To address this, a Trust Manager component has been developed integrating a trust manager orchestrator, a trust evaluation function and ML grouping techniques among others. Edge IoT devices like drones and collaborative robots (cobots) interact with the Trust Manager Orchestrator to enable secure and efficient operations. After clustering these devices, each group of devices is evaluated using tailored trust metrics. The trust evaluation function calculates a trust index for each device, which is sent to the trust manager orchestrator to maintain an up-to-date trust profile. To optimize performance, computational tasks are offloaded based on each cluster’s capabilities—such as processing power, memory, and network strength. The orchestrator then uses the trust index and task requirements to select the most suitable input node, ensuring secure, efficient, and adaptive task execution across the network. 5.4.1 Finalized Component and Prototype Status The Trust Manager component integrates several key functionalities for IoT device management (see Figure 9). It includes: • K-means clustering for grouping the devices with similar characteristics to streamline trust evaluation and task assignment. D4.4 – Final Report on Trustworthy and Efficient Digital Components 37 | 46 • Trust manager orchestrator which assigns tasks to the most trustworthy and capable devices in the network. • Trust evaluation function which calculates a trust index for each device class based on multiple metrics such as: o Availability (% of time the device was active and responsive) o Reliability (frequency of successful task execution within a time threshold) o Security (secure communication, e.g., Transport Layer Security-TLS-enabled communication) o Data privacy compliance (e.g., encryption protocols in transmission) o Data integrity (e.g., validating right format of values, checking for duplicates, source validation) o Energy consumption – efficiency in task handling o Battery level of battery-powered devices o Multi-connectivity capabilities (4G/5G, Wi-Fi, NB-IoT, BT, etc., with adaptive RAT selection) Figure 9: Trust Manager Flowchart [D4.3] Each metric is normalized and is weighted based on its importance and recency of data (using exponential decay to prioritize newer info. The output is a trust score ranged from 0 to 1. These scores together with real-time data related to the performance, resource usage (e.g., CPU, memory), battery life of each device, and topology graph are fed to the trust manager orchestrator to output the optimal placement of computational workloads and tasks to the available devices and servers. The trust manager orchestrator makes decisions based on the trust index, assigning tasks to the most reliable devices and offloading computational tasks to devices that are capable of handling them (based on their resource availability). This component has been demonstrated in a simulated environment with inputs from IoT devices such as drones and cobots as described in the following subsection. D4.4 – Final Report on Trustworthy and Efficient Digital Components 38 | 46 5.4.2 Achieved KPIs The Trust Manager component has been evaluated under varying task and device scales in a simulated experimental setup. The trust manager component was compared with a baseline load balancing algorithm and the trustworthiness calculated was the sum of the trust scores of the devices chosen each time for the task placement. The experimental setup was 20-100 devices and 20-900 workloads/tasks. As shown in Figure 10, the Trust Manager has demonstrated significant improvements in trust-based orchestration: • Up to 53% higher trustworthiness in task allocation compared to baseline load balancing approaches. • Scalability, since it was successfully evaluated with up to 100 devices and 900 tasks. • Efficiency, having real-time trust index computation using normalized and weighted metrics with exponential decay for recency prioritization. • Improved performance with increased device diversity, enabling better task-device matching. • The more the tasks are, the lower the gains observed due to limited solution space and the more the devices are, the higher the gains observed due to richer allocation options. These KPIs validate the effectiveness of the Trust Manager in enhancing the security, reliability, and efficiency of IoT networks. Figure 10: Trustworthiness gains for various device and task counts compared to load balancing baseline algorithm. D4.4 – Final Report on Trustworthy and Efficient Digital Components 39 | 46 5.4.3 Component/partner Interactions and Input to WP6 The Trust Manager has been developed primarily by WINGS ICT Solutions, with potential integration into platforms from other project partners. The trust index output can be embedded into other platforms to evaluate connected devices or hardware components. The component supports WP6 goals by providing a robust mechanism for secure and efficient IoT device orchestration in experimental setups. 5.4.4 Research Outlook / Road to product The growing role of IoT devices in critical systems and sensitive data handling, calls for device trustworthiness, reliability, security, and privacy, which is essential for user safety and system integrity. The proposed Trust Manager component can be one solution in future evaluation of trustworthiness of devices for integrating a trust manager orchestrator, a trust evaluation function and ML grouping techniques among others. As a result, we foresee that Edge IoT devices like drones and collaborative robots (cobots) interact with the Trust Manager Orchestrator to enable secure and efficient operations. Currently, the solution is experimental and shown as an initial proof of concept but in the future can be part of a product suite for ensuring the trustworthiness. 5.5 Radio Link Authentication This section explores the use of Machine Learning (ML) techniques for Radio Frequency Fingerprinting (RFF). These techniques have recently become more promising for Physical Layer Security, as advances in ML methods and computational capabilities make RFF more feasible for modern telecommunication systems, including 5G and beyond. The basic background of RFF is that each transmitting device has minor manufacturing imperfections and operation impairments that result in unique, subtle characteristics or discrepancies in the radio signals it emits. Recent advancements in machine learning and artificial intelligence have indeed demonstrated significant effectiveness in extracting subtle patterns from extensive data. These discrepancies, although often very limited, can be measured, processed and detected, allowing to create a ‘fingerprint’ of the device. The hardware impairments can manifest in imperfections such as quadrature imbalance, phase noise, frequency jitter, power amplifier (PA) in-band distortion, intermodulation distortion and reference spurs. In real deployments, RFF could be most beneficial as an extra security layer on top of classic cryptography in controlled private networks (factory floors, labs, campus or government sites), where the number of radios is limited and the environment is stable. Even there, security is tricky since an insider, or a cloned unit may try to spoof a legitimate device with the same hardware and signal. We want a model that not only separates known devices but also does not wrongly push an unseen one into the “closest” known class. This leads to the open-set problem. Focus on the open set challenge Among the existing ML challenges present in literature, we decided to focus on the open set challenge as motivated earlier. D4.4 – Final Report on Trustworthy and Efficient Digital Components 40 | 46 In traditional RFF identification, a classifier is trained on signals from a fixed set of devices, each assigned to its own class label. The model is then evaluated on these same known classes, which defines the closed-set classification problem: any new transmission at inference time is forced into one of the enrolled device classes. However, in open-set environments, unauthorized or previously unseen devices may appear. To handle such cases, systems must determine whether a signal belongs to one of the known (enrolled) devices or to an unknown source, which is treated as an anomaly class. This is known as an open set recognition problem. Thus, from a Machine Learning perspective, a close-set scenario should be tackled as a classification task over the enrolled device classes, while the open-set scenario (more complex and extended scenario, closer to reality) should be tackled by extending this to include an additional anomaly class for unknown devices. Figure 11: Close-set vs. open-set paradigms 5.5.1 Finalized Component and Prototype Status Experimental setup and data description To develop and evaluate the close and open set scenarios we used an in-house python-controlled SDR-based hardware platform as schematized below: Figure 12: Experimental setup. D4.4 – Final Report on Trustworthy and Efficient Digital Components 41 | 46 We are using three different transmitters: - one Ettus USRP B210 software defined radio, - two Ettus USRP B205mini-I software defined radio. All three transmitters are connected to Keysight RF switch inputs. We connect an Ettus USRP B210 SDR to the output of the switch, preceded by a 30dB attenuator to protect the receiver hardware. The radio link is being wired to remove the channel effects which would add another layer of complexity to the ML task and thus could divert the focus from the primary ML problem under consideration and alter our conclusions. The TX and RX SDRs and the RF switch are controlled using an in-house python dashboard, which loads the IQ files to transmit, configures the selected SDR for transmission, configures the RF switch, configures the receiver SDR and synchronously transmits and records the transmitted IQ data. Transmitted IQ data waveforms are generated using an internal 5G NR simulator. The recorded IQ data are then sorted into datasets and transmitted to the ML dashboard for further use. Our data collection exploited high-gain operation to push the power amplifiers into their nonlinear regimes, i.e. maximizing device-specific hardware imperfections as RF fingerprints. We ran the wired tests with Signal-to-Noise Ratio between 10 and 50 dB. This range is realistic and close to over-the-air use. In this range the device features still stand out above the noise. The receiver used in-band IQ with 2.5 GHz bandwidth. Out-of-band parts can also hold device cues (e.g., intermodulation), but in practice they are hard to use: automatic gain control and filters are a trade-off, strong nearby signals can disturb, and small out-of-band energy is often lost in noise. Data preprocessing and model design We re-used the learnt knowledge from our previous studies and in particular deliverables D4.3 regarding the influence of the model hyperparameters and architecture on the performance such as accuracy or inference latency; in our experiments, best performance was achieved by a relatively shallow, 1-dimensional Convolution Neural Network (CNN) with only a few thousand trainable parameters in the presence of 3 classes. The Deep Learning approach allows relatively lightweight data preprocessing at training and inference compared to traditional statistical methods. It indeed consists of collecting raw IQ samples sent by each device, which are then sliced with a non-overlapping sliding window of length 256 (i.e., stride = slice length): it produces examples of shape (256, 2) where the two channels are I and Q values are stacked together. At training, we balanced per-device slice counts, shuffled, and fed these into ML that learnt each radio’s unique RF fingerprint; we also used different transmissions (batches) for the model evaluation to prevent data leakage.