Deliverable D2.3 Interim overall 6G system design

A holistic flagship towards the 6G network platform and system, to inspire digital transformation, for the world to act together in meeting needs in society and ecosystems with novel 6G services Deliverable D2.3 Interim overall 6G system design Hexa-X-II project has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe research and innovation programme under Grant Agreement No 101095759. Date of delivery: 30/06/2024 Version: 1.1 Project reference: 101095759 Call: HORIZON-JU-SNS-2022 Start date of project: 01/01/2023 Duration: 30 months Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 2 / 155 Document properties: Document Number: D2.3 Document Title: Interim overall 6G system design Editor(s): Zhenhua Zou, Patrik Rugeland (EAB) Authors: Zhenhua Zou, Patrik Rugeland, Josué Castañeda Cisneros, Selim Ickin, Flávio Brito, Mårten Ericson (EAB); Sylvaine Kerboeuf, Abdelkader Outtagarts, Dinh Thai Bui, Huy Tran, Mathieu Boussard, Vincent Verdot (NFR); Akshay Jain, Ozgur Akgul, Mohammed Elbamby, Mohamed Abdelaziz (NFI); Pawani Porambage, Jyrki Huusko, Dinaj Attanayake (VTT); Alperen Gundogan, Panagiotis Botsinis, Sameh Eldessoki (APP); Betul Guvenc Paltun, Elham Dehghan Biyar, Merve Saimler, Ferhat Karakoc (EBY); Pilar Andres Maldonado, Abolfazl Amiri (NDK); Stefan Köpsell (BI); Pol Alemany, Raul Muñoz, Ricard Vilalta, Behnam Ojaghi (CTT); Sokratis Barmpounakis, Christina Karousatou, Vasilis Tsekenis (WIN); Vangelis Sfakianakis, Alexandros Stylos, Grigorios Kakkavas, Ioannis Tzanettis, Anastasios Zafeiropoulos (ICC); Bin Han (TUK); Antonio de la Oliva (UC3); Xosé Ramón Sousa (OPT); Markus Staufer (NGE); Ignacio Labrador Pavón (ASA); Anton Krause, Philipp Schulz, Ana B. Martínez (TUD); Pietro G. Giardina, Erin Seder, Giada Landi, Giacomo Bernini (NXW); Diego López, Antonio Pastor, Riccardo Nicolicchia (TID), Ignacio Labrador Pavón (ASA). Contractual Date of Delivery: 30/06/2024 Dissemination level: PU1 Status: Final Version: 1.1 File Name: Hexa-X-II D2.3 Revision History Revision Date Issued by Description 0.1 20/10/2023 Hexa-X-II WP2 Template for Deliverables/IRs 0.2 12/2/2024 Hexa-X-II WP2 Table of content 0.3 10/04/2024 Hexa-X-II WP2 For internal review 0.4 08/05/2024 Hexa-X-II WP2 For external review 0.5 05/06/2024 Hexa-X-II WP2 GA submission 1.0 30/06/2024 Hexa-X-II WP2 Final version submitted to EC approval 1.1 04/07/2024 Hexa-X-II WP2 Editorial fix of duplicated Figure 7-4 1 SEN = Sensitive, only members of the consortium (including the Commission Services). Limited under the conditions of the Grant Agreement PU = Public Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 3 / 155 Abstract This document is the third deliverable of Hexa-X-II work package 2 – “Interim overall 6G system design”. The document provides an interim overall 6G system design. The adopted approach is to first analyse and recommend enablers in technical areas of architecture, radio interface and protocols, E2E service management and automation, security, privacy and system level resilience. These enablers are from the Hexa-X-II project and other SNS-JU projects. This document then provides a refinement of the system blueprint after a knowledge graph-based selection methodology for the recommended enablers. Lastly, a refinement and expansion of the requirements for the 6G E2E system, and updates on the system level proof of concepts are included. Keywords 6G, system requirement, E2E system, architecture, radio interface, radio protocol, management and orchestration, privacy, security, resilience, SNS-JU projects, overall design, E2E system level evaluation, Proof of Concept Disclaimer Funded by the European Union. The views and opinions expressed are however those of the author(s) only and do not necessarily reflect the views of Hexa-X-II Consortium nor those of the European Union or Horizon Europe SNS JU. Neither the European Union nor the granting authority can be held responsible for them. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 4 / 155 Executive Summary This report is the third public deliverable of Work Package 2 (WP2) of Hexa-X-II, titled D2.3 “Interim overall 6G system design”. The report provides an interim overall 6G system design via analysis, recommendation and selection of the most relevant technical enablers for the 6G end-to-end (E2E) system. Hexa-X-II is the flagship project and has a responsibility to not only propose new aspects but to embrace what other projects do and promote them. The technical enablers to be evaluated are both the ones developed within the Hexa-XII project and the ones proposed by other Smart Networks and Services Joint undertaking (SNS-JU) projects. These enablers include architecture, protocols, radio interface, devices, management & orchestration, as well as E2E security enablers. This analysis and recommendation of enablers is the basis for an interim selection of pertinent enablers for the E2E system and will guide the refinement of the E2E system blueprint. The end-to-end system requirements outlined in [HEX223-D22] are expanded and refined. The functional requirements are divided into use case related and operational functional requirements. The use case related functional requirements are extended with those identified in [HEX223-D12], while the operational functional requirements are expanded with inputs from other SNS-JU projects as well as an analysis of the sustainability key value requirements from [HEX223-D12]. Regarding technical requirements, a need to group requirements per use case is identified, and an additional requirement on transmission jitter identified by several SNS-JU projects is presented. The enablers analysed and recommended in this deliverable are categorized further into four areas. A recommendation of architectural enablers is provided considering the most relevant enablers for datadriven architecture, network modularization, flexible topology, networks beyond communication, and virtualization and cloud transformation. Recommended enablers are mainly based on their importance to the 6G system and some parameters, such as: maturity, high-level functionality, dependency on other enablers, importance towards migration, fulfilment of system design principles, etc. In addition, further architectural enablers developed in other SNS-JU projects expand the architectural enabler analysis. The SNS-JU projects enablers regarding deterministic communication and optical transport solutions have not been studied in the Hexa-X-II project and are identified to be further investigated. An interim enabler recommendation related with radio interface and protocols is provided. The recommendation is based on the high-level consideration for the design of the 6G radio interface and protocol illustrated in the second deliverable D2.2 from WP2 [HEX223-D22], as well as the system impact of an enabler on radio protocol/interface and 6G E2E system. In a short summary, we have analysed radio protocol enablers, enablers from other technical areas but with an impact on radio interfaces and protocols, as well as relevant enablers from other SNS-JU projects. More specifically, innovations on radio protocols include paradigm shift proposals on a flatter and more modular structure for radio resource control protocol to meet an even more demanding requirements in 6G and a dual configuration of user plane protocols to address the complex toolbox approach in fifth generation (5G). Innovations on the radio protocol also have enablers on the evolution track to further improve key performance indicators (KPIs), e.g., data recovery and recording for low latency and high reliability, ciphering and integrity protection in lower layers, mobility based on information beyond radio conditions (e.g., UE contextual and compute offloading aware) and a separation of idle and connected mode signalling to support network energy saving. Then enablers from architecture, higher layers, physical layer techniques and future devices are recommended. These enablers have both an impact on and a need of the support of the radio interface and protocol. Examples of such enablers include application and network interaction for service differentiation, AI enablers, network of networks, multi-connectivity, beyond communication functionalities enablers (e.g., compute offloading, and joint communication and sensing), multi-radio spectrum sharing, energy efficient radio design, inclusive radio interface, intelligent radio air interface, flexible spectrum access solutions, and novel 6G device class and enhancements from 5G devices. Additionally, enablers from other SNS-JU projects not studied in this project are highlighted, one on dependable time-critical communication and another one on the full-fledge integration of the non-terrestrial network (NTN) components into the 6G system. The latest work regarding the intent-based management and orchestration topic is presented. It significantly advances the definition of an intent-based management automation framework, crucial for the intent-based digital service manager (DSM). It has introduced refinements to the DSM's functional architecture and outlined Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 5 / 155 a new workflow that illustrates the interaction among the framework's components. This effort ensures a cohesive operational environment that supports advanced management capabilities. To achieve the functionalities of the DSM, we have further developed a comprehensive set of nine enablers presented in presented in Hexa-X-II deliverable D2.2 [HEX223-D22]. These enablers are thoroughly described, detailing their internal architecture, the specific components they interact with from the functional architecture, and their external interfaces with other enablers. Furthermore, the workflow within these enablers is clarified, showcasing their internal interactions and reinforcing the framework's integrative approach. Additionally, key enablers related to network service management and orchestration from Work Packages 3 and 6, as well as enablers from other Smart Network Systems (SNS) projects, have been identified. Lastly, we have recommended specific management and orchestration enablers for further analysis in the End-to-End (E2E) blueprint. This recommendation aims to ensure that the most effective and innovative enablers are considered, helping to refine the overall strategy and implementation of network management within the intent-based framework. Core Security, Privacy and Resilience (SPR) functionality is analysed following a detailed, fine-grained pattern, associated, as already noted in [HEX223-D22], with the threats the SPR functionalities address and the mechanisms to detect these threats and to mitigate their impact in E2E system operation and behaviour. These fine-grained mechanisms, termed as SPR controls, are the targets of the provided analyses and further experimentation. From these base controls, different enablers are identified, discussing their general interfaces and technology readiness level (TRL), identifying their stages: conceptual, laboratory, and already demonstrated. Together with this discussion SPR enablers from this project, the applicability of a number of other SPR enablers in development within other SNS JU projects is also analysed. The analysis and the recommendation of these enablers in the above four technical areas are used as inputs to provide a refinement of the system blueprint. To reach this objective, a knowledge graph (KG) based method is proposed to provide a selected set of enablers for a given set of requirements. The KG method takes the enablers, use cases, requirements, KPIs, key value indicators (KVIs), functionality provisioned, and meta data as inputs, and down-selects the enablers based on boundary conditions such as priority, maturity, and the ability to satisfy design principles and support as many use cases as possible. Parallelly, an update of the 6G E2E system blueprint introduced in [HEX223-D22] has been proposed. This update reflects the progress of work on the various individual enablers and how they are interacting in the E2E system. This update encompasses enhancements across the various layers and the pervasive functionalities of the 6G system. Notably, significant refinements have been made in the network layer. The 6G Beyond Communications Functions now detail functionalities to realize new services expanding beyond the communication capabilities. From the perspective of the pervasive functionalities, the management and orchestration approach is intent-based and complemented with multi-platform orchestration functionality. The related enablers provide a synergetic orchestration of network services and network applications over the cloud continuum, which may be owned and administered by different stakeholders. Closed loop controls, possibly AI/ML based, play a crucial role in achieving an increased level of automation toward autonomy in the 6G network operations. Finally, an overview of the implementation and the results obtained so far from the first system Proof-ofConcept (PoC) (named System-PoC A) accompanied with some new simulation results is given. Specifically, System-PoC A mainly focused on smart network management aspects in the context of developing and testing a state-of-the-art automated inventory management solution for efficient and accurate warehouse operations with the employment of autonomous mobile robots and drones among others. The studied scenario aimed at the optimal placement of the various inventory management services, e.g., warehouse location assignment to devices, workload assignment depending on the available resources, etc. The targeted KPIs in this scenario are measured to demonstrate gains in terms of performance of the management and orchestration (e.g., execution time of the solution), environmental sustainability (in terms of power consumption) and social sustainability (in terms of trustworthiness). Next, a preview of System-PoC B is presented by briefly discussing the new enablers that are to be incorporated (building upon System-PoC A). Moreover, a description of the ComponentPoCs of System-PoC B is given, followed by a discussion on the Component-PoCs’ integration plans to System-PoC B. A detailed description of System-PoC B implementation along with its results is planned to be reported in the upcoming D2.4 deliverable. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 6 / 155 Table of Contents Executive Summary ..................................................................................................................... 4 1 Introduction ......................................................................................................................... 22 1.1 Objective of the document ........................................................................................... 22 1.2 Structure of the document ............................................................................................ 23 2 Refinements of requirements for 6G E2E system ............................................................ 24 2.1 Functional requirements ............................................................................................... 24 2.1.1 Use case related functional requirements ................................................................ 24 2.1.2 Operational functional requirements ....................................................................... 24 2.2 Technical requirements ................................................................................................ 26 3 Architecture enablers ......................................................................................................... 27 3.1 Hexa-X-II architectural enablers .................................................................................. 27 3.1.1 Data-driven architecture .......................................................................................... 27 3.1.2 Network modularization ......................................................................................... 28 3.1.3 New access and flexible topologies ........................................................................ 29 3.1.4 Network beyond communications .......................................................................... 30 3.1.5 Virtualisation and cloud transformation (IoT-edge-cloud continuum) ................... 32 3.2 Additional architectural enablers from other SNS-JU projects .................................... 33 3.2.1 Non-terrestrial networks ......................................................................................... 33 3.2.2 In-X subnetworks .................................................................................................... 33 3.2.3 Deterministic communication ................................................................................. 34 3.2.4 X-haul solutions ...................................................................................................... 35 3.3 Architectural enabler recommendation ........................................................................ 35 4 Radio interface and protocol enablers .............................................................................. 37 4.1 Radio protocols ............................................................................................................ 37 4.1.1 Flexible radio protocols .......................................................................................... 37 4.1.1.1 6G RRC design .................................................................................................. 37 4.1.1.2 Design options for user plane ............................................................................ 39 4.1.1.3 Data Recovery and reordering mechanisms ...................................................... 40 4.1.1.4 Ciphering and integrity protection ..................................................................... 44 4.1.1.5 SDAP protocol for beyond communication services ......................................... 48 4.1.2 Mobility Procedures ................................................................................................ 49 4.1.2.1 Data-driven mobility .......................................................................................... 49 4.1.2.2 Computation aware mobility ............................................................................. 50 4.1.2.3 Separation of IDLE mode and CONNECTED mode signalling ........................ 51 4.1.2.4 Enhanced special cell (SpCell) change with UE initiation ................................ 52 4.2 Support for architecture and higher layer enablers ...................................................... 54 4.2.1 Application-NW interaction for service differentiation and QoS/QoE management54 4.2.1.1 Low-latency scheduling ..................................................................................... 54 4.2.1.2 Ad-Hoc radio bearer and inline signalling ......................................................... 56 4.2.1.3 Dynamic adaptation of QoS resources for interactive services ......................... 58 4.2.2 Integration of Architectural enablers ...................................................................... 60 4.2.2.1 AI enablers ......................................................................................................... 60 4.2.2.2 Network connectivity evolution enablers .......................................................... 60 4.3 Support for radio and future device enablers ............................................................... 62 4.3.1 Integration of radio enablers ................................................................................... 62 4.3.1.1 Joint communication and sensing ...................................................................... 62 4.3.1.2 Energy efficient radio design ............................................................................. 62 4.3.1.3 Inclusive radio interface via TN/NTN enhancements........................................ 63 4.3.1.4 Intelligent radio air interface design .................................................................. 63 Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 7 / 155 4.3.1.5 Flexible spectrum access solutions spectrum sharing and coexistence, low-latency random access .................................................................................................... 64 4.3.2 Integration of device enablers ................................................................................. 65 4.4 Additional radio interface and protocol enablers (SNS-JU) ........................................ 65 4.4.1 Dependable time-critical communication on radio interfaces................................. 66 4.4.2 TN/NTN integration on radio interfaces ................................................................. 66 4.5 Enabler recommendation for radio protocol and interfaces ......................................... 66 4.5.1 Radio protocols ....................................................................................................... 67 4.5.1.1 Flexible radio protocol ....................................................................................... 67 4.5.1.2 Mobility procedures ........................................................................................... 68 4.5.2 Support for architecture and higher layer................................................................ 68 4.5.3 Support for radio and future devices ....................................................................... 69 5 Management and orchestration enablers .......................................................................... 71 5.1 Intent-based management automation framework and enablers .................................. 71 5.1.1 Intent-based digital service manager functional architecture .................................. 71 5.1.2 Intent translation and provisioning enabler ............................................................. 74 5.1.2.1 Novelty and maturity ......................................................................................... 74 5.1.2.2 Internal architecture ........................................................................................... 74 5.1.2.3 External interfaces ............................................................................................. 75 5.1.2.4 Workflow ........................................................................................................... 75 5.1.3 Data fusion mechanisms based on telemetry data enabler ...................................... 76 5.1.3.1 Novelty and maturity ......................................................................................... 76 5.1.3.2 Internal architecture ........................................................................................... 76 5.1.3.3 External interfaces ............................................................................................. 77 5.1.3.4 Workflow ........................................................................................................... 77 5.1.4 Intent closed loop coordination enabler .................................................................. 77 5.1.4.1 Novelty and maturity ......................................................................................... 77 5.1.4.2 Internal architecture ........................................................................................... 77 5.1.4.3 External interfaces ............................................................................................. 78 5.1.4.4 Workflow ........................................................................................................... 79 5.1.5 Intent conflict administration enabler ..................................................................... 79 5.1.5.1 Novelty and maturity ......................................................................................... 80 5.1.5.2 Internal architecture ........................................................................................... 80 5.1.5.3 External interfaces ............................................................................................. 80 5.1.5.4 Workflow ........................................................................................................... 81 5.1.6 Human-machine intent interface design enabler ..................................................... 81 5.1.6.1 Novelty and maturity ......................................................................................... 81 5.1.6.2 Internal architecture ........................................................................................... 81 5.1.6.3 External interfaces ............................................................................................. 82 5.1.6.4 Workflow ........................................................................................................... 82 5.1.7 Intent-driven placement enabler .............................................................................. 82 5.1.7.1 Novelty and maturity ......................................................................................... 82 5.1.7.2 Internal architecture ........................................................................................... 82 5.1.7.3 External interfaces ............................................................................................. 83 5.1.7.4 Workflow ........................................................................................................... 83 5.1.8 Declarative intent reconciliation enabler ................................................................ 84 5.1.8.1 Novelty and maturity ......................................................................................... 84 5.1.8.2 Internal architecture ........................................................................................... 84 5.1.8.3 External interfaces ............................................................................................. 84 5.1.8.4 Workflow ........................................................................................................... 85 5.1.9 Intent reporting enabler ........................................................................................... 85 5.1.9.1 Novelty and maturity ......................................................................................... 85 5.1.9.2 Internal architecture ........................................................................................... 85 5.1.9.3 External interfaces ............................................................................................. 87 Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 8 / 155 5.1.9.4 Workflow ........................................................................................................... 87 5.1.10 3rd Party services enabler ........................................................................................ 88 5.1.10.1 Novelty and maturity ......................................................................................... 88 5.1.10.2 Internal architecture ........................................................................................... 88 5.1.10.3 External interfaces ............................................................................................. 90 5.1.10.4 Workflow ........................................................................................................... 90 5.2 Network service management and orchestration related enablers ............................... 90 5.3 Additional M&O enablers from other SNS-JU projects .............................................. 92 5.4 Enabler recommendation ............................................................................................. 92 6 Security, privacy, and resilience. Controls and enablers ................................................ 95 6.1 The concept of SPR controls ........................................................................................ 95 6.2 Proposed security, privacy and resilience controls ...................................................... 96 6.2.1 Confidential computing........................................................................................... 96 6.2.2 Topology attestation ................................................................................................ 97 6.2.3 Anomaly detection in disaggregated environments ................................................ 98 6.2.4 Support for secure and privacy-enhanced machine learning .................................. 99 6.2.5 Facilitating crypto transition ................................................................................. 100 6.2.6 Evolved LoTAF .................................................................................................... 101 6.2.7 Context awareness for physical layer security ...................................................... 102 6.2.8 DTand ML-enabled physical layer anomaly detection ....................................... 102 6.2.9 A threat analysis for JCAS .................................................................................... 104 6.2.10 Deception techniques for physical security........................................................... 105 6.3 An E2E resilience evaluation ..................................................................................... 106 6.4 Integrating results from other SNS-JU projects ......................................................... 107 6.5 Recommendations on security, privacy, and resilience ............................................. 108 7 Overall 6G system design ................................................................................................. 110 7.1 Enabler selection methodology .................................................................................. 110 7.2 Features for recommended enablers ........................................................................... 111 7.3 Implementation of selection methodology with practical considerations .................. 112 7.4 System blueprint refinement ...................................................................................... 119 7.4.1 Updates to the 6G E2E system blueprint .............................................................. 119 7.4.2 Mapping selected enablers in the 6G E2E system blueprint ................................. 121 7.4.3 Alignment of the system blueprint design with the sustainability objective ......... 122 8 E2E-system level evaluation ............................................................................................. 124 8.1 Overview of E2E system evaluation and validations ................................................. 124 8.1.1 Overview of System-PoC A .................................................................................. 124 8.1.2 New E2E simulation results of System-PoC A ..................................................... 127 8.2 Components of System-PoC B - elements of the 6G network architecture ............... 128 8.2.1 Component-PoC#B.1 - AI-assisted E2E lifecycle management of a 6G latency-sensitive service across the compute continuum .................................................................. 128 8.2.2 Component-PoC#B.2 - training and inference of collaborative distributed machine learning model on a dynamically changing heterogeneous 6G architecture environment .. 132 8.2.3 Component-PoC#B.3 - trustworthy flexible topologies in 6G, leveraging on “beyond communication” aspects ....................................................................................... 134 8.2.4 Component-PoCs integration plans to System-PoC B ......................................... 135 9 Conclusion and next step .................................................................................................. 136 References ................................................................................................................................ 138 ANNEX A ................................................................................................................................. 144 A.1 Intent translation & provisioning example workflow ................................................ 144 A.2 Data fusion mechanisms based on telemetry data ...................................................... 146 A.3 Intent closed loop coordination example workflow ................................................... 146 A.4 Intent-driven placement example workflow .............................................................. 147 Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 9 / 155 A.5 Intent conflict administration workflow example ...................................................... 148 A.6 Human-machine intent interface design example workflow ...................................... 149 A.7 Declarative Intent Reconciliation example workflow ................................................ 150 A.8 Intent reporting workflows ......................................................................................... 151 A.9 Intent reporting data model ........................................................................................ 154 A.10 Intent third party services ........................................................................................... 154 Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 16 / 155 ISAC Integrated Sensing and Communication ISL Inter-Satellite Links I-SSB Idle mode SSB IT Information Technology JCAS Joint Communication and Sensing KG Knowledge Graph KMS Key Management System KPI Key Performance Indicator KVI Key Value Indicator L2 Layer 2 L4S Low Latency low Loss Scalable LCID Logical Channel Identifier LDPC Low-Density Parity-Check LEO Low-Earth Orbit LLS Lower Layer Split LoS Line-of-Sight LoT Level of Trust LoTAF LoT Assessment Function LTM L1/L2 Triggered mobility M&O Management and Orchestration M2H Machine to Human M2M Machine to Machine MAC Medium Access Control MBB Mobile Broadband MC Multi-connectivity MCG Master Cell Group MD Management Domain MEC Multi-access Edge Computing MgtN Management Node MIB Master Information Block MIMO Multiple Input Multiple Output Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 17 / 155 MIP Mixed Integer Programming ML Machine Learning MLOps Machine Learning Operations MLOps-aaS MLOps as a Service mMTC Massive Machine Type Communication MNO Mobile Network Operator MnS Management Service MRSS Multi-Radio Spectrum Sharing MSC Message Sequence Chart M-SSB Mobility SSB MTBF Mean Time Between Failure MTC Machine Type Communication MTTR Mean Time To Repair MU-MIMO Multi-User MIMO NAS Non-access Stratum NBI North-Bound Interface NDT Network Digital Twin NF Network Function NLP Natural Language Processing NPN Non-Public Network NR New Radio NTN Non-terrestrial Network NW Network NWDAF Network Data Analytics Function OFDM Orthogonal Frequency Division Multiplexing ON Offloading Node OpEx Operating Expenses oPoT Ordered Proof of Transit OSS Operative Support Systems P4 Programming Protocol-independent Packet Processors PA Power Amplifier Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 18 / 155 PCell Primary Cell PCF Policy control function PCR Periodic Cadence Report PD Packet Delay PDB Packet Delay Budget PDCP Packet Data Convergence protocol PDU Protocol Data Unit PDV Packet Delay Variation PER Packet Error rate PHY Physical PII Personally Identifiable Information PLD Physical Layer Deception PLS Physical Layer Security PoC Proof-of-Concept PoT Proof of Transit PQC Post-Quantum Cryptography PRB Physical Resource Block PT Physical Twin PUCCH Physical Uplink Control Channel QFI QoS Flow Identifier QKD Quantum Key Distribution QoE Quality of Experience QoS Quality of Service RA Remote Attestation RAN Radio Access Network RAT Radio Access Technology RB Resource Block RE Reconciliation Engine RedCap Reduced Capabilities REST Representational State Transfer RHDRBL Reliable High Data Rate with Bounded Latency Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 19 / 155 RIC RAN Intelligent Controller RLC Radio Link Control RLF Radio Link Failure RPC Remote Procedure Call RPU Radio Processing Unit RRC Radio Resource Control RRM Radio Resource Management RSS Received Signal Strength RT Real Time RU Remote Unit Rx Reception SA Standalone SA5 Service and system aspects work group 5 SAU Simultaneous Active Users SBI South-Bound Interface SCell Secondary Cell SCG Secondary Cell Group SCTP Stream Control Transmission Protocol SDAP Service Data Application Protocol SDN Software Defined Network SDO Standard Developing Organization SDU Service Data Unit SeMF Sensing Management Function SH Sub header SIB System Information Block SIC Successive Interference Cancellation SKEX Symmetric Key Exchange SKG Secret Key Generation SLA Service Level Agreement SMF Session Management Function SN Sequence Number Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 20 / 155 snCP Subnetwork CP SNS-JU Smart Networks and Services Joint Undertaking SO Segment Offset SpCell Special Cell SPR Security, Privacy, and Resilience SR Scheduling Request SRB Signalling Radio Bearer SSB Synchronization Signal Block SU Sensing Unit SW Software TAU Tracking Area Update TB Transport Block Tbps Terabit per second TCB Trusted Computing Base TCP Traffic Control Protocol TEE Trusted Execution Environment TLA Trust Level Agreements TM Forum TeleManagement Forum TN Terrestrial Network TRL Technology Readiness Level TRP Transmission Point TSN Time-Sensitive Networking Tx Transmission UAV Unmanned Aerial Vehicle UCI Uplink Control Information UE User Equipment UL Uplink UM Unacknowledged Mode UP User Place UPF User Plane Function URLLC Ultra-Reliable Low-Latency Communication Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 21 / 155 VoLTE Voice over LTE VoNR Voice over NR WLAN Wireless Local Area Network WN Worker Nodes WT WLAN Terminal XAI Explainable AI XR Extended Reality ZSM Zero-touch network and Service Management Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 22 / 155 1 Introduction Hexa-X-II is the 6G Flagship project under the European Union Horizon Europe research and innovation program Smart Network and Services Joint Undertaking (SNS JU) [HEXA2]. This document is the third public deliverable of Work Package 2 (WP2) – Interim overall 6G system design. Hexa-X-II is leading the way toward the next generation 6G end-to-end (E2E) system design, based on integrated and interacting enablers. To meet this ambition, the first deliverable of WP2 (D2.1 Draft foundation for 6G system design [HEX223-D21]) has set up a comprehensive methodology for the design of a 6G E2E system including ten principles, a E2E system blueprint, and a structured design process, also published in [HEX2-KPJ+24]. The architecture design principles prioritize environmental sustainability, digital inclusiveness, and trustworthiness, considering their impact on the 6G E2E system. The blueprint is described corresponding to the infrastructure, network centric application, and application layers, as well as the pervasive functionalities and the relevant technological innovations. Following the design principles and the system blueprint, the design process is defined iteratively as two-way approaches, consisting in i) key performance and value indicators-based design process and ii) top-down versus bottom-up alignment process. This iterative system design process involves a strong collaboration across the technical work packages (WP2-WP6) that are investigating innovative enablers in the 6G ecosystem. This process encompasses a continuous top-down versus bottom-up alignment. In the top-down approach, the 6G system blueprint is derived from the requirements outlined by the use cases and the underlying architecture design principles. Conversely, in the bottom-up approach, the enablers are elaborated from the work packages, tackling various aspects of the 6G system. These enablers are then analysed for their seamless integration into the 6G E2E system blueprint. Furthermore, the recommendations generated during this process provide valuable feedback to the technical work packages, aiding in the refinement of the enablers and contributing to the iterative enhancement of the overall E2E system blueprint. This deliverable constitutes an evolution of the foundation of the system blueprint unveiled in the second deliverable of deliverable of WP2 (Foundation of overall 6G system design and preliminary evaluation results [HEX223-D23]). 1.1 Objective of the document The objective of this document is to provide an interim overall 6G system design based on analysis, recommendation, and selection of the most relevant technical enablers for the 6G end-to-end system. In Hexa-X-II, an enabler is defined as any technical asset that makes it possible to realize or enhance a 6G capability. It is recursive, e.g., 6G system enables new use cases, 6G radio is an enabler of 6G system to achieve system requirements. A 6G technical enabler can be further classified into different types that are extensible, e.g., architecture, system component, process, algorithms, etc. With the above in mind, this document firstly analyses technical enablers in the below four areas: architecture, radio interface and protocols, management and orchestration, as well as E2E security enablers. Only mature enablers developed within the Hexa-X-II project and proposed by other Smart Networks and Services Joint undertaking (SNS-JU) projects are included in the analysis. • Some of the technical enablers developed within the Hexa-X-II project are disclosed in previous documents [HEX223-D12, HEX223-D22, HEX223-D33, HEX223-D43, HEX223-D53, HEX223D62]. This document summarizes and analyses only mature enablers developed in WPs other than WP2. In addition, this document provides the intermediate design of technical enablers developed by Hexa-X-II WP2 and some of their preliminary component-level evaluation results. These WP2internal enablers are related to radio interface and protocols, E2E service management and automation, as well as security, privacy, and system level resilience. • Although the technical scope of Hexa-X-II is substantial, by necessity it cannot cover every aspect of 6G research. In parallel to Hexa-X-II, several complementary SNS-JU projects have a dedicated focus on narrower scopes. In particular, the so-called Stream B projects, focusing on “research for revolutionary technology advancement towards 6G” (where Hexa-X-II also belongs) are particularly relevant to Hexa-X-II. Of the 18 Stream B projects that started concurrently with Hexa-X-II, nine Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 23 / 155 projects have been identified, i.e., 6G-NTN covering non-terrestrial networks, 6G SHINE covering subnetworks, DETERMINISTIC6G and PREDICT-6G covering bounded and deterministic communication, FLEX-SCALE covering solutions for optical transport networks, DESIRE6G covering management and orchestration platform, HORSE, RIGOROUS and as well as the Stream A project ACROSS covering security aspects. Although there might be relevant aspects in the remaining Stream B projects, these are either similar in scope to the work in Hexa-X-II or not yet having publicly released any deliverables by the time of publishing this report at June 2024. Similarly, the progress of the Phase 2 Stream B projects that begun in 2024 will be considered for the future deliverables of Hexa-X-II. The recommendation of the technical enablers in those four areas is then performed and based on their priority and relevance to the 6G E2E system, with recommendation criteria presented in detail for each area. Those criteria among others integrate the ability of enablers to fulfil the 6G system requirements derived from the 6G use cases, in terms of functionalities, operations, technical and key values requirements. Initial 6G system requirements have been identified in the previous deliverable D2.1 [HEX223-D2.2] and refinements are covered in this deliverable. Other recommendation criteria relate to the fulfilment of the 6G design principles identified in D2.1 [HEX223-D2.1], the maturity of the enablers in terms of their technology readiness level, and their closeness to be integrated into the system proof-of-concepts of Hexa-X-II. This analysis and recommendation of those technical enablers is the basis for the selection of pertinent enablers for the E2E system and guides the refinement of the E2E system blueprint to fulfil the 6G use cases, KPIs and sustainability aspects. The document also reports new evaluation results from the first iteration of the system level proof-of-concept (System-PoC A). Additionally, it contains the selected components for the second iteration of the system level proof of concept (System-PoC B). 1.2 Structure of the document This document is structured as follows. Chapter 2 provides a refinement and expansion of the requirements identified for the 6G E2E system. In the Chapters 3, 4, 5 and 6, the technical enablers are analysed and recommended. • Chapter 3 describes architectural enablers both from Hexa-X-II WP3 as well as other SNS-JU projects, such as 6G-NTN, 6G SHINE, DETERMINISTIC6G, PREDICT-6G and FLEX-SCALE. • Chapter 4 describes radio interface and protocol enablers, including radio protocol enablers from Hexa-X-II WP2, radio protocol enablers needed to support architecture and higher layer enablers from Hexa-X-II WP3, radio interface enablers to support radio technologies and future device from HexaX-II WP4 and WP5, as well as radio interface and protocol enablers from other SNS-JU projects, such as 6G-NTN and DETERMINISTIC6G. • Chapter 5 describes enablers for management and orchestration, including intent-based management and network service management from both Hexa-X-II WP2 and Hexa-X-II WP6, along with enablers from other SNS-JU projects, such as DETERMINISTIC6G, DESIRE6G, HORSE, and RIGOROUS. • Chapter 6 describes enablers for security, privacy, and resilience from Hexa-X-II WP2 and other SNSJU projects such as RIGOUROUS, HORSE, and ACROSS. Chapter 7 proposes a methodology for enabler selection among enablers recommended in previous chapters and describes the updated view of the overall 6G system design. Chapter 8 describes the E2E system level evaluations, including the system-level proof-of-concepts (PoCs) and presents some new results for SystemPoC A. Chapter 9 concludes the report and includes the next step of WP2. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 24 / 155 2 Refinements of requirements for 6G E2E system The requirements for the 6G E2E system can be categorized as functional or technical requirements, i.e., what type of functionality the system need to offer, as well as what performance the system need to deliver. The functional requirements can further be categorized based on the stakeholder, i.e., considering whether the enduser of the service or the operator that delivers the service. 2.1 Functional requirements The Hexa-X-II deliverable D2.2 [HEX223-D22] listed a range of functional requirements, related to either use cases, i.e., from an end-user point of view, or the operation of the network. In parallel, the deliverable D1.2 [HEX223-D12] described numerous use cases and categorized them into use case families, with further elaboration on one representative use case per use case family. 2.1.1 Use case related functional requirements In addition to the requirements listed in section 2 of D2.2, i.e., Ubiquitous connectivity, Indoor coverage, Extreme connectivity (high bitrate), Mobility support, Pervasive AI/ML, Efficient sleep states, Compute as a Service, Intent-based interfaces, Reliability, Positioning/sensing, Ultra-low-cost, Energy neutral, Predictable low-latency E2E communication, Security/Privacy, Resilience, and Service continuity, the Hexa-X-II project has identified the following additional requirements in this deliverable: Data synchronization As more users experience and consume common digital services e.g., a joint immersive experience, it will be important to be able to ensure accurate time synchronization between them. If multiple users are to interact simultaneously with the same digital object, they need to be accurately time synchronized from an end-user point of view. Immersive mapping as a service As the 6G network will collect vast amounts of sensing data, it will be important for the network to be able to compile, analyse, and distribute this sensing data as an immersive mapping service to different consumers of the service. Affordability For the sake of social sustainability, it will be important that at least basic levels of 6G services and devices should be affordable to be able to bridge the digital divide. For instance, the 6G system should be designed to cost-efficiently expand the service coverage with flexible topologies and integration of non-terrestrial networks, as well as fully leverage on AI capabilities for automation to reduce the operating expenses (OpEx) enabling cheaper services to be offered. Improved human-machine interaction It is expected that 6G will incorporate new devices with unparalleled interfaces to improve human-machine interaction, e.g., immersive audio/visual mobile experiences as well as haptic. Interoperability To provide service continuity, it will be important that the 6G devices can interwork with other wireless technologies, especially supporting fallback to e.g., fifth generation (5G). Standardized interfaces will continue to be relevant to keep specific open interfaces, e.g., lower-layer split (i.e., between MAC and PHY or within PHY) should be considered to make the network more flexible and more manageable. 2.1.2 Operational functional requirements The Hexa-X-II deliverable D2.2 [HEX223-D22] listed several operational functional requirements, i.e., Flexible radio protocols, Mobility procedures, Improved access convergence, Native AI/ML capabilities, Multi-connectivity, Intent-based management, Seamless orchestration across the compute continuum, 6G Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 25 / 155 service delivery across multiple digital service providers, and New 6G capabilities exposure. In addition, several SNS-JU projects, have identified further requirements: Object recognition and tracking: To provide sensing service, the 6G network should be able to recognize and track objects [DES23-D21]. AI/ML training and inferencing complexity and model generalization capability: With the implementation and integration of AI/ML models in the 6G system, it will be vital to monitor and evaluate different AI/ML models’ complexity, in both training and inferencing. In addition, the scalability of the AI/ML models will depend on how easily it will be to generalize the AI/ML models [CEN23-D51]. Scalability: In Hexa-X-II, network scalability has been identified as a design principle [HEX223-D21]. However, to implement this, it will be important to define specific requirements to achieve efficient and sustainable networks. To provide this, it will be important that the network can scale from small number of nodes or users to the largest number of nodes and users expected for the use case with similar performance [DES23-D21]. Extreme transport capacity: Any mobile network will need to be able to efficiently transport the data from the base station to the core network, and further to the remote servers. To handle the increased capacity of 6G, [FLE23-D21] identified a need for transport capacity of beyond 100 Terabit per second (Tbps). Security: As outlined [HEX223-D22], security will play a significant role in 6G. Since there are several SNSJU projects dedicated to the security aspects of 6G, a wide range of security requirements can be found in e.g., [RIG23-D22], [HOR23-D21], [PRI23-D22]. However, another dimension of the operational requirements are the sustainability aspects which have been covered in Hexa-X-II D1.3 [HEX224-D13], which put requirements on the key value indicators (KVI): Key value requirements: In addition to the functional requirement, D1.1 [HEX223-D11] have identified several key value requirements that may need to be counterbalanced towards the functional requirements. The 6G system may provide significant improvements to the environmental, social, and economic sustainability, e.g., in terms of improved resource efficiency, reduced greenhouse gas (GHG) emissions, improved societal services (e.g., education, healthcare, etc.), improved safety and resilience, and trust in the services. All of these are expected to lead to e.g., improved productivity, profitability and new business or job opportunities. However, it will be important to be vigilant towards, and try to mitigate, the associated costs. • Environmental requirements: The new 6G services may require new devices and network equipments, which increases the material and energy consumption as well as the amount of electronic waste, and it will be important to minimize this impact. • Social requirements: Even if the 6G system promises reduced inequality by providing connectivity to all, the fact remains that the high-end devices offering the most of the 6G services may be too expensive for a large portion of the population. Similarly, certain aspects of the 6G technologies may become too complicated to use without the proper education or experience, leading to an increase in information technology (IT) illiteracy, unless care is taken to design the 6G systems to counter this, e.g., using well-designed AI based user interfaces, using well-designed artificial intelligence (AI) based user interfaces. Thus, it will be important that the benefits of the technology can be made available to all. In addition, as more and more aspects of our lives become digitalized, we become more vulnerable to privacy incursions and hacking attempts which need to be counteracted. • Economic requirements: It will be important to design the 6G system so that it can be deployed gradually, when and where needed. In addition, several 6G services rely on heavy computations, e.g., sensing, compute offloading, and AI-as-a-service (AIaaS) and it will be important to ensure that the cost of these new services does not exceed the benefits they provide. Depending on the application, use case, and technology used, this comparison may be straight forward, e.g., improved energy efficiency though AI optimization vs. increased energy consumption of the AI model. However, in other cases it may be much more complicated, e.g., to predict the potential changes in user behaviours and their subsequent impact. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 32 / 155 satisfying the required latency, trustworthiness, power consumption, and resilience. The proposed enabler ensures that both the QoE for the communication as well as the required resiliency and quality of computation are achieved, such that the 6G design principles of (#5) Resilience and availability and (#1) Support and exposure of 6G services from [HEX223-D21] are met, hence, making this enabler essential for the evolution towards 6G. Application-/device-specific BCS optimisation enabler focuses on tailoring network operations to the specific needs of applications and devices, enhancing the efficiency and effectiveness of BCS data consumption. This enabler encompasses mechanisms for optimizing the placement and resource allocation of application functions, considering computational and communication resources and security/privacy constraints relevant to BCS services and respective produced data (e.g., sensing data). It facilitates the accommodation of diverse use cases with optimized support, ensuring data privacy, security, and trustworthiness while ensuring end-to-end latency and reliability, and improving network load management and energy efficiency. 3.1.5 Virtualisation and cloud transformation (IoT-edge-cloud continuum) The Virtualisation and Cloud transformation area considered in [HEX224-D33] aims to develop a cloud platform for 6G requirements. The off-the-shelf clouds from e.g., Amazon and Microsoft, are suitable for a big subset of multimedia applications, but it has its limitations when it comes down to supporting the upcoming latency sensitive 6G use cases. Therefore, the focus is on solutions for how to transform current cloud technologies towards 6G telco grade cloud platforms also including resources in the edge and extreme edge, so it fits applicable 6G requirements such as management, latency, security, and connection reliability, etc. The following enablers are considered for this area: Integration and orchestration of extreme edge resources in the computing continuum enabler proposes new architectural mechanisms for the multi-access edge computing (MEC) framework to incorporate the extended compute continuum and account for the extreme edge devices (computing resources located in UEs or on their close neighbourhood). To support extreme edge exploitation as part of the infrastructure, it is necessary to evaluate and develop the required interfaces and orchestration mechanisms that can deal with this heterogeneous, dynamic, and volatile extreme edge environment. Integration and orchestration of extreme edge is already part of standards developing organization (SDO), e.g., third generation partnership program (3GPP), European telecommunications standards institute (ETSI). Multi-domain/multi-cloud federation enabler comprises the capability to aggregate cloud services provided by multiple domains and providers into a single, coherent cloud, see Figure 3-5. To this end, the cloud continuum should provide interfaces for cloud services and the 6G Core network should provide interfaces for network services, so that an operator can control resources from different cloud providers in an homogeneous way. Figure 3-5 Multi-domain/multi-cloud federation and orchestration [HEX223-D32]. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 33 / 155 3.2 Additional architectural enablers from other SNS-JU projects Of the 19 SNS-JU projects that started concurrently with Hexa-X-II, five projects have been considered for the architecture enablers [SNS22]. 3.2.1 Non-terrestrial networks Even though 5G Advanced has begun introducing support for NTN [38.300], the progress is piecemeal and there are many remaining questions. The SNS-JU project 6G-NTN is focusing on developing solutions for NTN and to see how these can be integrated into the 6G networks [6GN24]. One major aspect that 6G-NTN is considering, is the NTN architecture, whether to support a transparent or regenerative architecture, i.e., whether the satellite houses a relay or a full base station [38.821]. The transparent architecture has recently been standardized in 3GPP, while the regenerative architecture is still being evaluated [6GN23-D31]. For 6G, it may be beneficial to support both, but in order to keep in line with the 6G design principles, extraneous deployment options should be minimized to avoid market fragmentation. The main options are: Transparent satellite payload: In this option, the base station (i.e., next generation node B (gNB))) is located on the ground and the only function of the satellite or high-altitude platforms (HAPS) is to act as a repeater with only RF processing such as frequency conversion, amplification, and beam management. gNB-DU Onboard: The DU unit is onboard the satellite and the CU units on the ground station [6GN23-D31]. Full base station / gNB onboard: In this option, the base station capabilities and functionalities are located onboard the satellite or HAPS implementing the mobile base station including the complete radio unit (RU), gNB distributed unit (DU) and gNB central unit (CU) for user and control planes [6GN23-D31]. Full base station and partial/full Core Network functions onboard: The mode will include either the full implementation of gNB and CN functions of the user and control plane in the NTN node (Satellite or HAPS) or with only partial CN functions being implemented in the NTN node [6GN23-D31]. The full implementation of gNB and CN would however increase the complexity and power consumption. Another concept developed by 6G-NTN is the multi-tiered 3D network deployments, where high-altitude geostationary (GEO) satellites are deployed together with low-earth orbit (LEO) and HAPS to supplement each other’s coverage. One option for inter-satellite links being explored is free-space optical links. In addition to the radio protocols and interface enablers, 6G-NTN contributes to the end-to-end system architecture by introducing the multi-layer architecture enablers and network topology of NTN integration with terrestrial networks. This includes the UE, non-terrestrial nodes such as HAPS and satellites, and radio links, as well as the definition of relevant communication links and their characteristics between the multilayered satellite and terrestrial network nodes (GEO, LEO, HAPS, and terrestrial network) and user equipment. As said in Section 3.1.3, the 6G NTN work to some extent is included in the network of network enabler in in Section 3.1.3. However, the work in 6G NTN goes much more in detail of the NTN work and define specific enablers within the NTN area which is not considered in this project. 3.2.2 In-X subnetworks The work in 6G-SHINE [6GS24-D22] regarding In-X subnetworks, aims to provide short-range highperformance wireless connectivity for use cases including robots, industrial production modules, vehicles, classrooms, etc. According to [6GS24-D22], In-X subnetworks are expected to be located at the edge of the 6G network of networks. One main topic of [6GS24-D22] is the radio resource management for “In-X subnetworks”. The In-Xsubnetworks can operate standalone but can also be part of a larger 6G ecosystem benefiting from connection to a wide area/enterprise parent network. Several different topics are included here such as centralized/distributed radio resource management (RRM), dynamic spectrum sharing between 6G and In-X subnetworks, dynamic and elastic computational offloading from subnetworks to 6G edge-cloud. The main Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 34 / 155 enabler from [6GS24-D22] complements the work in network of networks (see in Section 3.1.3) regarding the management node concept and the flexible topology for 6G System PoC-B. 3.2.3 Deterministic communication Dependable time-critical communications (also known as time sensitive networking (TSN) [23.501]) are expected to play a vital role in future 6G networks for use cases that require more dependable (and low) latencies, e.g., extended reality (XR), adaptive manufacturing and mobile automation. Two SNS-JU projects focus on this aspect, i.e., DETERMINISTIC6G [DET23-D21] and PREDICT-6G [PRE23-D21]. DETERMINISTIC6G focuses on strict guarantees in packet delay (PD) and packet delay variation (PDV). Here we list a few interesting enablers in DETERMINISTIC6G [DET23-D21] that complement the enablers of [HEX223-D22] (note that several topics are grouped into a single enabler for convenience): Time sensitive networks enabler with the following aspects: • Packet delay correction: The solution, among others, can be (generalized) timestamp-based, using the 3GPP protocol stack, and/or be based on the number of radio retransmissions. • Improved ultra-reliable, low latency communication (URLLC): According to DETERMINISTIC6G, 5G URLLC is one of the main enablers to support time-critical communication standards that have been defined for fixed networks, like IEEE 802.1 time-sensitive networking (TSN) [TSN24] and IETF DetNet [IETF23]. URLLC provides reduced latencies over the airinterface, but comes at a cost, since more resources are allocated to reduce the latency. In [DET23-21] enhanced URLLC is discussed and analysed. • Data-driven latency characterization: One method is the mixture density networks (MDNs) based models that leverage extreme value theory for accurate tail latency characterization. [DET23-21] also investigates centralized and federated latency prediction architectures. • RAN resource management: A problem optimizing the number of hybrid automatic repeat request (HARQ) retransmissions is presented to support the requirements of augmented reality (AR) /XR applications. Wireless-friendly, adaptive end-to-end scheduling algorithms enabler [DET23-D31]. DETERMINISTIC6G considers novel algorithms to calculate wireless-friendly E2E schedules that explicitly consider stochastic PD with large PDV along an E2E communication path. PREDICT-6G focuses on improving the data plane architecture, to support inter-domain coordination and integration that ensure an overview of the available resources to provide the bounded latency, as well as E2E management services which ensures the time synchronization in the network and monitors, orchestrates, and predicts the optimal path for maintaining the time constraints. The PREDICT-6G deliverable D2.1 [PRE23-D21] introduces two enablers for cross-domain determinism: Cross-domain flow splitting and joining where the packet/flow replication/elimination context is transferred between domains to be able to coordinate along the E2E path. Domain-border gateways (GWs) where multiple GWs along different paths can handle routing between them to ensure proper traffic flow. Furthermore, the project introduces a number of enablers at layer 2 (L2): Dynamic Scheduling where the uplink (UL) and downlink (DL) intervals are dynamically designed depending on current traffic needs. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 35 / 155 Scheduling and queuing models with mixed traffic classes which aims to optimize the data flow utilizing that the deterministic services may not have strict requirements of low latency and jitter and/or high throughput at the same time. 3.2.4 X-haul solutions The FLEX-SCALE project focuses on novel high-speed, secure, and energy-efficient x-haul solutions [FLE23D21]. Considering the 6G E2E system model, the key application areas for FLEX-SCALE enablers are especially on midhaul and backhaul. The aim is to enable a high speed and energy efficient transport network, by e.g., utilizing software defined network-controlled transceiver and switching technologies. As the flexibility and reconfigurability are key requirements for the future RAN and CNs, and flexible configuration for e.g., RAN split modes could be needed, enablers to control the optical switching and routing nodes are needed. The key enablers from FLEX-SCALE include flexible and programmable transceivers, to be used for software defined networking control in aggregation, metro and core routers. This would enable also, for example, the flexibility in end-to-end 6G system to arrange load balancing in RAN and CN and enable efficient resource use of telco cloud solutions for NF and application. This enabler is not present in Hexa-X-II project and is therefore a candidate enabler. 3.3 Architectural enabler recommendation The 6G architectural enablers developed in Hexa-X-II and other SNS-JU projects represent a toolbox, aimed to provide more flexible, intelligent, efficient, and effective networks that can support the expected 6G services. Section 3.1 and Section 3.2 have already listed a subset of architecture enablers from [HEX223-D32] and [HEX224-D33] and complementing enablers from other SNS-JU projects. This section gives a high-level summary and further recommendation of the most important enablers. For the data driven architecture framework enablers, we recommend the DataOps, MLOps, and AIaaS enablers. These enablers will necessitate a redesign of the network, to allow fluid data sharing across the network, as well as dynamic network configurations to leverage the insights brought by AI/ML. These AI/ML tools are still at their infancy, but the development is exponential so that the 6G networks must be designed to incorporate them as they improve. For the network modularisation area, the 6G network modularisation and the E2E service design in modular 6G enablers are recommended. These enablers aim to improve the overall flexibility of the network, without increasing complexity. This is done by designing a more modular architecture design than 5G (e.g., network functions) that can scale and place functionality according to the current and future needs of the network dynamically. Another enabler that is recommended is the MRSS, since it is expected to be a key enabler for the migration to 6G and address spectrum scarcity by repurposing existing 5G spectrum. In the new access and flexible topologies area, the recommended enablers are network of networks and multiconnectivity. The network of networks enabler is a main enabler for achieving global coverage, where it includes the study areas on NTN and subnetworks that are also relevant to other SNS-JU projects, e.g., 6GNTN and 6G-SHINE, respectively. The multi-connectivity enabler aims to improve mobility reliability and user throughput by data aggregation from more than one cell. Since service coverage extension and mobility are important for a successful 6G, it justifies these enablers to be recommended. Additionally, offloading is expected to be more in focus, and subnetworks may aid in enabling local offloading between trusted devices. To address some 6G use cases defined in [HEX223-D12], it will also be important to incorporate the novel beyond communication services in 6G, namely sensing and compute offloading, that will be provided to users and applications through open APIs. Therefore, we recommend the compute offloading protocols, signalling and procedures and the JCAS protocols, signalling and procedures enablers. The compute offloading protocols, signalling and procedures enabler is a service that is expected to be more in focus in 6G, hence it is naturally to include this enabler in the recommendation. The JCAS protocols signalling and procedures enabler is another relevant beyond communication service that 6G will bring. Enablers related to the support of JCAS will require innovations in the radio interface (including PHY layer and radio protocol support) and base stations interactions with the core network and other base stations (more an architecture research question). Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 36 / 155 In the integration and orchestration of extreme edge area we recommend integration and orchestration of extreme edge and the multi-domain/multi-cloud federation enablers. These enablers may evolve the cloud platform towards a cloud platform more suited for 6G. This includes extending the cloud continuum to the edge and extreme edge, so it fits applicable 6G requirements such as management, latency, security and connection reliability etc., and also enable operators to control resources from different cloud providers in a homogeneous way. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 37 / 155 4 Radio interface and protocol enablers In this chapter, we first describe enablers related with generic enhancements to 3GPP radio protocols (i.e., MAC, RLC, PDCP, SDAP and radio resource control (RRC), see [38.300]) in Section 4.1, followed by details on how the radio protocols will support enablers from architecture and higher layer in Section 4.2, enablers from radio and future devices in Section 4.3, and enablers from other SNS-JU projects in Section 4.4, respectively. Finally, Section 4.5 summarizes this chapter with a recommendation of enablers. 4.1 Radio protocols This section presents innovations for the design of 6G radio protocols within Hexa-X-II project. Two main research areas are discussed in this section: flexible radio protocols (including user plane (UP) and control plane (CP)) and mobility procedures that have been the focus of radio protocols for generations. The described enablers consider the lessons learned from 5G and follow the visions for 6G that are presented in the previous Hexa-X-II deliverable [HEX223-D22]. 4.1.1 Flexible radio protocols Radio protocol enablers related to control plane design, user plane design, data recovery and reordering, and security in access stratum are presented in the following subsections. 4.1.1.1 6G RRC design In mobile networks, the control plane function uses the RRC protocol to configure the UE [38.331]. For this purpose, the RRC protocol provides messages and data structures that are defined using the Abstract Syntax Notation One (ASN.1) [ASN.1]. Here we list some learnings in 5G. • NR’s RRC ASN.1 messages may be large and deeply nested (i.e., many levels of hierarchy). This made the data structure difficult to use and even more difficult to extend as 5G evolved. Traditionally, RRC messages have employed tree-like data structures aimed to reflect the hierarchy of protocols, channels, and signals that they configure. Due to 5G NR’s architecture options (E-UTRA-NR dual connectivity (EN-DC), NR standalone (SA), NR-DC, etc.), the support for dual connectivity (DC), carrier aggregation (CA) and bandwidth parts (BWPs), the tight coupling of commonand dedicated signalling as well as due to the large number of configuration parameters for the physical layer, RRC messages became large and deeply nested. • Some of the well-established RRC principles that were meant to keep the encoded messages small, resulted in the opposite when used in practice. o For instance, unnecessarily size-restricted fields, where e.g., the field ControlResourceSetId was limited to an upper bound of 11 (i.e., 0-11) in Rel-15 even though 16 values could have been coded with the same number of bits, but already in Rel-16 a new ControlResourceSetIdr16 field had to be introduced to extend this upper bound to 15 (i.e., 0-15). o Another limitation is the lists of small elements which refer to each other, e.g., the channel state information reference signal (CSI-RS) configurations, where the resource sets and resources are configured in separate lists and refer to each other by means of integer IDs. The initial idea was that resources that were grouped to a “resource set” share most of their properties in practice but they must anyway be signalled for every “resource”. o Each resource and each resource set are typically used (i.e., referenced) once, so that the claimed benefit of being able to re-use parts of the configuration did not materialize. • Finally, the ASN.1 structure has traditionally been used to enforce or prohibit certain parameter settings and to tie configurations to procedures. The way how cell-specific parameters were inherited for the UE’s dedicated configuration is an example of the former, while the way how handover-related parameters were structured and tied to userand control plane procedures demonstrates the latter. Those design choices were supposed to reduce unnecessary options and testing. But they tend to create ambiguities and implementation errors and they are difficult to change when the initially excluded options are meant to be enabled in a later release. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 38 / 155 • The same RRC configuration is often repeated many times for the same UE, which is an inefficient use of radio resources. A balance is needed between achieving a high operational efficiency and a reduced system power consumption. In this subsection, two considerations for 6G RRC design are presented. Both target a simpler RRC design structure and reduced RRC signaling to configure the UE. In the first consideration, a few recommendations for RRC design that will impact ASN.1 structure are proposed. In the second consideration, a modular RRC design built with RRC “profiles” that describe RRC configurations is proposed. For the first RRC design consideration, one should consider a flat RRC structure which relies on specifying the 6G RAT only for a single standalone architecture option, with a single spectrum aggregation solution and without a higher-layer protocol split (F1); this will greatly simplify the 6G RRC data structure [HEX23-D53]. Additionally, it is proposed to improve RRC configuration signalling in 6G regarding BWPs and serving cells. In 5G NR, those were primarily tools for grouping features and their configuration parameters and thereby often caused more problems than they solved, e.g., more parameters than initially envisioned are included in the BWP (thus creating one hierarchical level below the serving cell concept). Another example is that PCell being an anchoring cell is a single point of failure. Avoiding those hierarchy levels flattens the ASN.1 structure and would make it easy from a signalling point of view to introduce features that span across carriers (e.g., CA) or transmission points (e.g., distributed MIMO). If it is considered beneficial to pre-provide several RRC configuration variants to a UE and to switch among those by smaller and (presumably) faster “triggering messages”, a flatter 6G RRC structure supports that too. The flat RRC structure can apply to more scenarios than what was achieved by 5G NR’s BWP concept. Furthermore, the 6G RRC ASN.1 structure should not enforce nor prohibit procedures. Restrictions, if any, should be described in procedural text and would be associated with UE capabilities. By these principles the 6G RRC structure makes it, for example, easy to realize various mobility schemes with a unified control plane framework. 6G RRC should continue supporting “delta signalling” as one way to limit the RRC signalling when updating the UE’s configuration, i.e., the UE keeps some part of a previous configuration and only the difference is reconfigured by RRC signaling. Differently from fourth generation (4G) and 5G, the 6G RRC protocol should use a simple yet efficient in-line definition of delta signalling with a simplified procedure. In this delta signalling, UE releases all optional fields if they were configured previously but are absent in the newly received RRC configuration message (NR’s “Need R” option). An ASN.1 parameterized type should be used to define signalling by which the network can request the UE explicitly to maintain a leaf of the configuration tree (which NR realizes by the “Need M” flag). This seemingly small change simplifies the network implementation significantly since the target node is not required to de-configure features which the source node might have used but which the target node does not support itself during handover. That is, if the network does not tell the UE explicitly to keep an optional part of the configuration, the UE releases it by default. The parameterized ASN.1 type simplifies this for both UE and network implementation since it remains visible in the compiled ASN.1 structure (rather than hidden in comments, field descriptions and conditions) and thereby allows automating the procedure to “release”, “keep” or “modify” the corresponding part of the configuration when generating or parsing an RRC message. For the second RRC design consideration, to create a 6G system in which the power saving capability is built in from the beginning, both network and devices need to be enabled to use power saving mode in any operational state to ensure a native energy efficient system, as illustrated in Figure 4-1. The power saving mode is considered as the starting UE mode and each additional circle represents an activity on top of this power saving mode. As the expected UE’s activities per case increase, the amount of power consumption needed increases too. A modular RRC design would enable fast transitions between distinct operational modes such as power saving, MIMO with minimum signalling overhead and latencies. Both the UE and the network would benefit from reduced latency, power consumption and effective resource utilization through efficient data transmission. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 39 / 155 Figure 4-1 Power Saving vs. UE activity: Separate RRC profiles for each use case. A modular RRC could be built with RRC “profiles”, which would be RRC configurations that the UE and the network store. RRC profiles can be tailored to suit UE operation of different form factors (such as low-cost, smartphone, high-end, etc.) and performance profiles (such as low latency, power-saving, voice, massive MIMO for fixed wireless access (FWA), etc.). Therefore, the information elements configured for different RRC profiles may include parameters related to configurations like DRX, MIMO layers, CSI-RS, BW usage, etc. A profile would be negotiated between the UE and the network to ensure that both UE capabilities and network feature implementation support are considered, and the stored profile would be subsequently applied at the network request without having to re-signal the parameters. Each defined profile would be linked to UE capabilities and the requested service category (e.g., voice call or mobile broadband, MBB). The profiles would be valid in a single cell or in a set of cells and retained through state transitions. RRC profiles thus facilitate power-efficient system by efficient switching to power saving mode from any UE state. 4.1.1.2 Design options for user plane In this subsection, a two-stack approach for the user plane radio protocol stack is proposed. The proposal targets to simplify the complex toolbox approach adopted in 5G that relies on configuring the same radio protocol stack to support a wide range of services (e.g., data rate ranging from kbps to Gbps). The main issue with a single stack approach is that while some optimizations (e.g., flexible L2 PDU header design) can be considered desirable for low-bitrate services to achieve flexible operation, the same optimizations become irrelevant and even harmful when dealing with very high bitrate services, specially considering potential hardware (HW)-based L2 processing. Thus, instead of having one complex stack mixing all mechanisms and optimizations, this design option proposes a two-stacks approach: 1. One radio protocol stack designed for low bitrate services with maximum coverage (e.g., bit-level optimizations) and reliability (e.g., RLC automatic repeat request (ARQ)) – referred to as the Anchor Protocol Stack (APS). 2. Another radio protocol stack designed for high bitrate services, where the focus is on a processingfriendly and implementation-friendly design employing the concept of radio processing units (RPUs) – referred to as the fast protocol stack (FPS). One example of the protocol split between APS and FPS and between different RPUs in FPS is depicted in Figure 4-2. This example illustrates that the data (both CP data and UP data) can be distributed to: (1) either APS or FPS stacks (but not both at the same time); and (2) different RPUs within FPS in order to handle the same high bitrate data flow in parallel. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 40 / 155 Figure 4-2 Two stacks for the user plane in 6G with RPU concept to facilitate parallel processing. It should be understood that both stacks rely on the same radio protocols (SDAP/PDCP/RLC/MAC) and although the model used relies on using the term stack, an equally valid model would be to use the terms tracks or paths to refer to two distinct configurations of the same radio protocols, as long as the separation between the two remains clear in order to guarantee a set of assumptions that can benefit implementation. With a two-stacks approach, all types of devices can be natively supported and the need for introducing branches dedicated to some UE types (e.g., machine type communication (MTC) and reduced capabilities (RedCap)) disappears, where a simple device may only implement the first stack (APS), while more complex and capable device would implement both stacks, and on the FPS, the higher the bit rates the device supports, the larger the number of RPUs. To facilitate the provision of very high bitrate services, all the processing in FPS should be as fast as possible. With 6G, there is an opportunity for the FPS design to be more friendly towards high-bitrate processing by pushing aside optimizations meant for low-bitrates, natively allow parallelism, and enable hardware-based processing. Looking at 5G NR UP, L2 processing mainly consists of processing headers. This includes generating headers on the Tx side, as well as interpreting and taking actions according to the headers on the Rx side. Therefore, the headers should be as simple as possible, specifically they should be in fixed positions and of fixed length even if that means increasing the overhead by a few bits as it hardly matters for very high bitrate services. Fixed headers would significantly speed up processing of the headers and would even allow hardware acceleration. Examples for L2 header design for FPS: • Fixed sequence number (SN) length for all layers where needed, e.g., fixed 32-bit SN (full COUNT) for PDCP. • Fixed RLC unacknowledged mode (UM) header with SN and segment offset (SO) always present. • Fixed logical channel identifier (LCID) length and fixed size length field for MAC. In this way, the processing would be predictable, making it a much easier target for hardware (HW)-based processing, resulting in better scalability and reduced power consumption, both of which are critical, especially at the UE side. 4.1.1.3 Data Recovery and reordering mechanisms There are data recovery loops in cellular networks that are used to ensure reliability of transmission. These loops are situated at the various layers of the protocol stack. For example, in a legacy 5G system, for the physical and medium access control layer (PHY and MAC), HARQ is used to ensure reliability and at the RLC layer, ARQ is used to ensure reliability. RLC ARQ is a technique that is used to recover packets that were not recovered by the lower layer hybrid automatic repeat request, i.e., due to time-outs or false-positive acknowledgement errors. In this subsection, two optimizations for data recovery and reordering are presented. Both optimizations explore cross-layer interactions to enhance data recovery [HEX2-UAJ+24]. In the first optimization, RLC and PDCP layers interactions are used to avoid RLC window blocking or unnecessary delays, influencing PDCP Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 41 / 155 reordering. In the second optimization, RLC and MAC layers interactions are used to early terminate RLC timers associated with retransmission processes. The first optimization, focuses on RLC and PDCP interactions, was introduced in [HEX223-D22]. This optimization provided a mechanism to avoid RLC window blocking or unnecessary delays, by allowing window moving operations based on certain additional delays. RLC window blocking happens when there are RLC PDUs that were not yet successfully received by the RX RLC entity and hence block the RLC window [38.322] from moving forward allowing subsequent packets to be transmitted. The window movement is commenced when a certain amount of retransmission attempts was not successful or when less important data (i.e., using higher layer information either in the radio protocol stack, network stack or application layer to decide on data importance) is affected by block error rate (BLER) and RLC retransmissions. The TX RLC entity would receive a NACKed Sequence Numbers (SN) from the RX RLC entity, and upon this TX RLC entity may send information back to the RX RLC entity that the NACKed SNs shall be skipped advancing both the TX and RX RLC entities windows. Additionally, RX reordering, which happens in PDCP in 5G [38.323], can be unblocked, with the RLC informing the reordering function about the gap(s) so that the reordering window may be updated accordingly. This scheme has multiple realization possibilities on top of legacy 3GPP specification (i.e., namely 5G), that is going to be further delved into in the following. As a first realization example a new RLC control protocol data units (PDU) type can be introduced to indicate the window movement operation (e.g., by indicating a new RX_NEXT) or indicating which RLC SNs that shall be skipped. The RX RLC entity would then in turn inform the reordering function (i.e., receiving PDCP entity in 5G) about the gap(s) due to skipped RLC SN(s), hence updating the reordering window and unblocking packet delivery to higher layers. This can be realized in a minimally invasive way, by introducing new control RLC PDUs types to what is already available in [38.322]. Figure 4-3 gives a possible realization of the above based on 5G [38.322], with examples indicating either a new RX_NEXT or an SN to be skipped (i.e., IGNORE_SN). This would entail the need to introduce new control PDU types as an increment to those already present in 5G, which could be realized by utilizing the control PDU type (CPT) field and additionally introducing those two additional PDU types. The following realization would result in a lower overall latency in bad radio conditions, as well as no data stall and unnecessary RRC reestablishments. Figure 4-3 Realization of window movement via new RLC control PDU type. Another possible realization, would be to repurpose the RLC retransmissions for new data transmissions, leading to the avoidance of unnecessary retransmissions and using the transmission instances for sending more relevant data. In this realization, the to-be-retransmitted RLC PDU Complete Segment with SN=x is repurposed and filled with a new PDCP PDU instead of the less important, or outdated packet. This means however, that PDCP SNs will be sent out in an out-of-order manner compared to legacy. This should not pose an issue though as in case of active in-order-delivery in PDCP, the packets would be reordered and delivered in-order to higher layers. Otherwise (i.e., PDCP out-of-order delivery) reordering is anyway assumed to take place in higher layers. Note that according to the current 3GPP 5G specification [38.322] and how RLC Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 48 / 155 is to only transport sensitive MAC CEs in protected zones. RRC messages could still be protected by the PDCP in this variant. This way, many transport blocks may not contain a protected zone at all. Another variant could be to transport all traffic except MAC subPDUs carrying user plane PDUs in protected zones, thus maximizing the amount of control traffic that is protected and executing the crypto operations for all this traffic on a single protocol layer, the MAC layer. 4.1.1.5 SDAP protocol for beyond communication services In this subsection, a modification to SDAP layer for beyond communication services is proposed. In 5G, the user plane data traffic is transmitted from the UE to the gNB in the RAN via the air interface on DRBs. The data is then forwarded to the user plane function (UPF) via the N3 interface on so-called QoS flows. The UPF then forwards the data to the appropriate IP address. A similar mapping is applied for user plane data traffic to the UE from data network beyond UPF. In order to be able to map the data between the DRB and the correct QoS-flow, 5GS introduced a new protocol layer, namely the service data application protocol (SDAP). The main feature of this protocol layer is to add a new header to the PDUs with a QoS-flow identifier (QFI) [37.324]. The proposal targets the optimized handling of data generated by beyond-communication services that 6G will introduce, such as integrated sensing, CaaS, or AIaaS. These services will generate large amounts of data within the network, which are not destined for an external IP address. Thus, if the 5G method of routing data from the UE was used, i.e., transmitting it via the DRBs and the QoS-flows to the gNB and then the UPF, respectively, the additional superfluous processing in the UPF and time to transmit data to and from UPF risk become a bottleneck that introduces latencies. Therefore, in 6G, assuming for beyond communication services a user-plane-like approach is used to gather data from the UE, it would be better to directly forward the data from the base station to the appropriate network function (NF). To facilitate this, the SDAP header can be modified, to replace the QFI with a generic Service-flow identifier (SFI). The QFI is currently 6 bits, which account for 2^6= 64 unique QFIs. This allows to configure as many different QoS-flows as the maximum number of DRBs, although this many is seldom used. By repurposing two bits in the legacy QFI to e.g., Service-flow Type and one of the bits to an extension field, there would still be three bits left, i.e., 8 different SFI would be available without increasing the overhead. For lower priority traffic, the extension bit could be used, and a separate octet could be used for the extended SFI as can be seen in Figure 4-11. Figure 4-11 New SDAP header with a) extension bit E=0, b) extension bit E=1, c) Type field and extension bit E=0, d) Type field and extension bit E=1. Thus, this would allow the base station to identify which NF the data should be forwarded to, and which type of Service flow should be used, as can be seen in Figure 4-12. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 49 / 155 Figure 4-12 Protocol stack for mapping new Service flows to data radio bearers (SNFSensing NF, CompNF – Computing NF, GNF – “Generic” NF). 4.1.2 Mobility Procedures Following the analysis of the state of the art and some initial proposed enablers for mobility in [HEX223-D22], this section focuses on providing more details and additional enablers for mobility procedures in 6G. Those enablers are targeting optimizations on mobility decision, mobility procedure operation, mobility awareness, and enhanced IDLE/CONNECTED mode related signaling are presented in the following subsections. 4.1.2.1 Data-driven mobility In [HEX223-D22], a data-driven mobility procedure was introduced where it was proposed to use contextual events (e.g., radio/traffic events) for mobility decisions. In 5G, the mobility decisions rely on the preconfigured signal measurement events only [38.331]. The latter may increase UE energy consumption, due to the need for performing frequent measurements. Additionally, this may cause additional delay, due to the need for L1 and L3 filtering at the UE side; delay which may lead to radio link failures. The data driven mobility mechanism may leverage the capabilities of UEs and result in a more informed decision. This may be achieved by considering not only the signal measurements, but also the information collected by the different UE sensors as well as utilizing the UE traffic pattern prediction. Figure 4-13 shows a potential realisation of data driven mobility. At step 1, the UE and the network performs capability exchange where the UE shares its capability to perform contextual mobility decisions and the network may configure the contextual events. The contextual events are meant to notify a change in the context of the user (e.g., user entering a tunnel while on a phone call, that will trigger a change in the connectivity with the network). Further details on the contextual events will be provided in the future deliverables. After the capability exchange and configuration, the contextual events are defined including, but not limited to, the triggering conditions, UE prediction window and granularity, confidence interval, etc. Moreover, if the network needs private individual UE data (e.g., location of UE), the network can share inference models with the UE where such models are trained by private federated learning (FL) that preserves users’ privacy [HEX224-D33]. The interruption time during mobility may be further reduced by leveraging the experiences of the other UEs. The UE aggregation unit and data-driven control unit were introduced in [HEX223-D32] to perform privacy-preserving data collection and learning which is based on the privacy-preserving cryptographic protocols [CB17]. Section 4.2.2.1 provides further details of this protocol based on the contribution in [HEX224-D33]. At step 2 in Figure 4-13, the UE may share contextual mobility forecast report with the network. This report may include the list of cells/base stations expected to be used along with expected time window. The network may use this information for utilization of the available resources e.g., contention-free preambles used during handover, preparation of RRC reconfiguration of the potential target cells, etc. The network may also share the average/predicted load on those cells with the UE at step 3. This information may help the UE to determine if the predicted cells satisfy the QoS requirements of the UE. For example, if one of the cells’ load, on the trajectory of the UE, is high, the UE may reduce the measurements of that cell to save energy and consider Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 50 / 155 other less loaded potential cells along the trajectory to trigger handover. Step 4 is optional and may be used if the UE prediction changes within the prediction window (e.g., if the UE’s trajectory changes). In the last step, the UE performs the handover decision to change the serving cell. The triggering condition of handover is kept flexible, one option would be that the UE may share the contextual event with the network and the network may decide to handover the UE to a new cell (i.e., like baseline handover). Another option may allow for the handover execution to be decided by the UE based on UE specific conditions or network-controlled conditions (e.g., like conditional handover). Figure 4-13 Data-driven mobility realization example. 4.1.2.2 Computation aware mobility The emergence of new use cases as stated in [HEX223-D12] requires reliable compute capabilities offered by the network such that the UEs may offload some of the computations to the edge (i.e., RAN), reducing the processing requirements on devices and hence allowing for more compute-intensive applications. This requirement introduces a new dimension to mobility procedures. The next-generation mobility procedure should not only aim for reduced communication interruption time, but also for a reduced computation interruption time during mobility. As stated above, the mobility procedures in 5G rely on the signal measurements, however, this may not be sufficient for computation offloading use cases, if the target cell does not satisfy the computation requirements of the UE. For example, in Figure 4-14 the UE moves from cell 3 towards to cell 1 and cell 2 and even if the signal measurements of cell 1 are higher than cell 2 for the UE, cell 2 may have more computation resources. So, triggering the handover to cell 1 may degrade the QoE of the user. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 51 / 155 Figure 4-14 Illustration of problem statement of computation aware mobility. Computation-aware mobility procedures allow the UEs to evaluate its own computation requirements as well as the computation capabilities of the base stations(s) before initiating mobility procedures (e.g., baseline handover or conditional handover) to the target base station. The UE and the network exchange capabilities and define the computation events and computation requirement reports. The network may use the computation requirements of the UE for target cell selection, handover preparation and configuration of the target cells. Additionally, the network may also share the computation capabilities of the neighbouring cells with the UE, to allow the UE and its applications to early adapt the offloading scheme and support the target cell selection for handover execution in a conditional mobility scenario. The QoE of the UEs may be increased by configuring and performing handover only to the NBs that satisfy the computation requirements of the UE. Finally, the network won’t execute a handover to a cell that satisfies communication requirements but does not satisfy computational requirements which can help the network make more efficient use of radio resources. Further details on the proposed solution will be delved into in the coming deliverable. 4.1.2.3 Separation of IDLE mode and CONNECTED mode signalling In 5G, the UE measures the synchronization signal block (SSB) in IDLE mode to determine which cell has the best signal to camp on, as well as to obtain the system information (SI) needed in case it needs to connect to the network. The same signal is used by CONNECTED mode UEs to be able to perform mobility measurements on the serving and neighbouring cells. Since the requirements for the IDLE mode and CONNECTED mode measurements are quite different; the IDLE signals must always be available in the entire coverage area so that all UEs can have the necessary configurations to connect to the network, whereas in CONNECTED mode, the signals need to be frequent to obtain accurate and up-to-date measurement signals for mobility. As the same signals are used for both procedures, the signals have to be available everywhere, transmitted by all base stations and be transmitted frequently, which prevents the network from turning off nodes that are not used. In 6G, the SSB should be decoupled between IDLE and CONNECTED modes, i.e., maintaining the structure for simplicity of UE implementation, but varying in the spatial and temporal distribution. This could be achieved by defining multiple separate SSBs as can be seen in Figure 4-15: • I-SSB (idle mode-SSB), used in IDLE mode. It is transmitted on the idle mode search grid. The master information block (MIB) field in the I-SSB provides information how to receive (idle-mode) system information. • M-SSB (mobility SSB), used for mobility in CONNECTED mode. It is transmitted periodically, aperiodically, in bursts, or not at all, as dynamically decided by the network. This is the signal used for mobility measurements, unlike NR where the same SSB as used in idle mode forms the basis for mobility measurements. The MIB in the M-SSB does not point to any system information, but Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 52 / 155 preferably contains an identity associated with a specific beam or transmission-reception point (TRP) in the network. The UE does not need to be configured with a specific list of M-SSBs to search for but can “blindly” find the M-SSBs transmitted (similar to how it can detect any 5G SSB being present in 5G). • E-SSB (extended periodicity SSB), used in connected mode. It is periodically transmitted with a long (extended) periodicity. The MIB in the E-SSB provides information how to receive (at least) the global cell ID to assist automatic neighbour relations (ANR) in the network. • D-SSB (dynamic or dedicated SSB) used in connected mode to measure serving cell, e.g., can be used as quasi co-location (QCL) root and thus associated with less additional overhead than a MSSB or E-SSB. Figure 4-15 The different SSB types envisioned for 6G. Even though multiple SSB types would be defined, except I-SSB, not all need to be present in all types of deployment. 4.1.2.4 Enhanced special cell (SpCell) change with UE initiation In [HEX223-D22], enhanced SpCell change procedure was introduced, where the UE initiates a handover to a non-serving cell without waiting for the configuration from the serving cell. The proposed UE-initiated SpCell change procedure is less complex and more efficient in terms of over the air signalling compared to conditional handover (CHO) and L1/L2 triggered mobility (LTM), as early cell preparation is not required. Figure 4-16 shows further details on the signalling aspects to realize the idea with a message sequence chart (MSC). The enhanced SpCell change procedure may be applied even when there is no AS-context established between the UE and the target SpCell. This means that the UE is neither having the configurations nor the security context of the target SpCell and the target SpCell is having no information about the UE (i.e., neither the capabilities, nor security context.) The execution condition to trigger handover to the target SpCell is either left to the UE or provided by the network. There are three possible realization options to trigger handover: 1. Full network control: The network may have full control on the list of candidate target SpCells and execution condition of each target SpCell. For example, the target SpCell execution condition is fulfilled, if all measurements are associated with the target candidate SpCell. In this case the network would execute a UE-initiated SpCell access procedure that would be guarded by an RRC timer (i.e., similar to T304 in NR [38.331]). 2. Partial network control: The list of candidate target SpCells is provided to the UE, but the execution condition may be decided for example based on suitable criteria received in System Information Blocks (SIBs) (e.g., SIB1 in NR) or any other method defined in 3GPP. If a candidate target SpCell fulfils the SpCell Access criteria, then the UE shall trigger a UE-Initiated SpCell access procedure that would be guarded by an RRC timer (i.e., similar to T304 in NR). Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 53 / 155 3. Full flexibility: The network neither provides candidate SpCell lists nor execution conditions to the UE, and the UE may determine the execution condition based on either a suitable criterion or any other method defined in 3GPP. Once the execution condition is satisfied, UE#1 initiates a random access (RA) procedure to the selected target SpCell (i.e., SpCell#2). It is up to the UE implementation to perform the RA procedure without being disconnected from the source SpCell, if possible. As shown in Figure 4-16, RACH message#1 and message#2 follow the legacy approach, but message#3 includes information identifying the UE and indicating the SpCell access request. For example, the RRC SpCell access request message may include source SpCell cell global identity (CGI) and cell radio network temporary identifier (C-RNTI), named as “Long AS-Identity”. At step 4 and 5, the target SpCell can use the UE identity to retrieve the UE context from the source SpCell. Based on the retrieved UE context, the target SpCell prepares RRC messages containing the new UE AS-Context configurations (i.e., RRC configurations, security configurations, etc.) of the target SpCell. Then at step 6, the target SpCell requests from the source SpCell in a transparent container to prepare the air-message for the UE. The source SpCell using the current UE AS-context security configurations (i.e., source SpCell security configuration currently active on UE side) integrity protects and ciphers the target SpCell RRC message received at step 6. The source SpCell stops further communication to the UE and forwards user-plane data to the target SpCell. At step 7, the source SpCell returns the secured air-message to the target SpCell. At step 8, the target SpCell may transmit random access message#4 to indicate random access success and upon reception, the UE disconnects from the source SpCell (i.e., if not disconnected before like in dual active protocol stack (DAPS) case), resets MAC and suspends all RBs except signalling radio bearer (SRB) 0/1. At step 9, the target SpCell may send target SpCell configuration, which is ciphered, and integrity protected using the source SpCell security context. Upon reception of this message, the UE deciphers, and integrity verifies using the source SpCell security configurations and applies the target SpCell AS-Context configuration. At step 10, the UE may send feedback to the target SpCell using the target SpCell configurations and continue the connection with the target SpCell. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 54 / 155 Figure 4-16 Potential detailed messaging exchange to enable UE initiated SpCell change. 4.2 Support for architecture and higher layer enablers This section presents further innovations for the design of 6G radio protocols, focused on leveraging application-network interactions for an enhanced overall 6G system following the lessons learned from 5G and the ambitions for 6G already presented in the previous Hexa-X-II deliverable [HEX223-D22]. Additionally, it presents the integration of the different architectural enablers from WP3 in the radio protocols [HEX223-D32, HEX224-D33], focusing mainly on AI enablers and network connectivity evolution. 4.2.1 Application-NW interaction for service differentiation and QoS/QoE management Proposals on utilizing application-network interactions for 6G service differentiation and QoS/QoE management enhancement are presented in the following subsections. Those proposals are either newly introduced proposals or a continuation of the ones presented in Hexa-X-II deliverable [HEX223-D22]. 4.2.1.1 Low-latency scheduling In [HEX223-D22], a new scheme for UL scheduling is proposed, namely low-latency scheduling, where the UE indicates what traffic characteristics (e.g., number of upcoming streams, packet sizes, cadence, jitter constrains, expected packets arrival time, etc.) to expect via a new reporting mechanism, called periodic cadence report (PCR), sent to gNB. This is expected to enhance the dynamic grant, as well as the configured grant scheduling. As highlighted in [HEX223-D22], this would be particularly useful for latency-critical use cases, like immersive telepresence, where the UL latency (i.e., from UL packet arrival to actual transmission) shall be minimal. This applies also for the minimization of setup latency which may be the predominant latency adder in short data sessions (e.g., hypertext transfer protocol (HTTP) bursts). To further elaborate on details Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 55 / 155 for the PCR, Figure 4-17 shows a more in-depth MSC overview with PCR for UL scheduling. Such PCR may be sent by the UE either periodically or based on specific events (e.g., via MAC control element (CE)), such as when the buffers are emptied to inform when the next UL grant is expected or upon change of traffic patterns or upcoming scheduling changes (e.g., to allow applications to adapt to jitter). Once a PCR is sent, a PCR prohibit timer shall be introduced to avoid abuse of frequent PCRs changing the grant scheduling back and forth. Figure 4-17 Periodic Cadence Report (PCR) mechanism. Another way to achieve low latency scheduling, is to introduce a service specific scheduling request (SR) as a further enhancement to the regular SR used in legacy dynamic grant methods. The idea is that the NW may configure multiple SR configurations for different applications, services, QoS flows or traffic profiles, for example they could be different in time domain (i.e., slot location), and/or different in frequency domain (i.e., physical resource block (PRB) location), and/or different cyclic shift of the physical uplink control channel (PUCCH) sequence (i.e., similarly to a different cyclic shift of a Zadoff-Chu sequence). This would allow the SR to carry more information about what service is coming up. Figure 4-18 shows an MSC for low latency scheduling via service specific SRs with multiple options, where in the first option, the NW continues the same opportunistic scheduling based on the indicated SR until nothing is left to send (e.g., indicated via Padding or dedicated MAC CE). In the second option, the NW adapts the opportunistic scheduling based on newly indicated SR(s) for different services. For the third option, the NW would rely on buffer status reports (BSR), UE BS PCR based scheduling Data Transmission CONNECTED UL Grant (fits to UL needs) AS Security establised UL TB (MAC CE: PCR) buffers emptied UL Grant grant scheduling at UL ETA UL TB (MAC CE: PCR) adapt scheduling PCR Prohibit Timer Start Pattern changed PCR Prohibit Timer Expiry X Data Transmission Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 56 / 155 as in legacy, for adapting the scheduling based on UE buffers. Finally, the service specific SR mechanism can be combined with PCR, where a service specific SR can deliver a starting point for the NW to operate on and provide better fitting and then the PCR mechanism can offer further refinement on the expectations from UE side over time that is more fine-granular than a BSR. Figure 4-18 Low latency scheduling via service specific scheduling request (SR). In conclusion, with the PCR, the service specific SR, or a combination of both, the proposed schemes offer an alternative to the legacy UL scheduling (i.e., dynamic, and configured grant) that reduces the overall latency, catering for the different anticipated 6G use cases. 4.2.1.2 Ad-Hoc radio bearer and inline signalling In 6G, due to new services and QoS requirements, it is anticipated that more DRBs with different settings are required compared to legacy 3GPP technologies (e.g., 4G, 5G). Currently, most networks are configured with one default bearer for internet and one bearer for voice (voice over LTE (VoLTE) or voice over NR (VoNR)). However, with the new anticipated services, the radio bearers (RBs) shall be more dynamic with their needs over time. Hence, the setup, reconfiguration, and release shall be leaner than in the current solutions. Today this requires a service request via non-access stratum (NAS) signaling and the execution of RRC BSUE Option3 Option2 Option1 UL TB (MAC CE: Padding) Scheduling Request (for Service Y) UL TB (MAC CE: BSR) Scheduling Request (for Service X) CONNECTED UL data AS Security establised buffers get empty Pattern changed UL Grant (fits to UL needs of Service X) stop scheduling for Service X UL TB (for Service X) adapt scheduling for Service y adapt scheduling based on BSR UL Grant (fits to UL needs of Service X) UL Grant (fits to UL needs of Service Y) UL Grant (fits to UL needs according to BSR) start scheduling for Service X Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 57 / 155 reconfiguration [38.331], which can get very large as they contain configurations of PHY (master cell group (MCG)/secondary cell group (SCG)), L2, and measurement configuration. It would be resource and energy consuming to exchange those frequent and big messages, having as a result a negative impact on the latency and UE power consumption. Therefore, the aim is to introduce a new mechanism that would allow for the setup, reconfiguration, and release of RBs in a more dynamic fashion based on application or services requirements. To achieve that, a new MAC CE based inline signaling approach is introduced where a UE would start with only the best effort bearer (i.e., as long as this serves the purpose of all current services), and if the buffers get filled due to heavy background traffic or requirements change, adapt the settings of the best effort bearer or open up a new DRB quickly (i.e., inline) to overcome this situation. Figure 4-19 gives an example MSC showing an UL example with different options for DRB setup, reconfiguration, and release. It is assumed that an initial phase took place where preloaded UE contexts or default configs for different traffic profiles are shared between the UE and the NW with a common secure IDs uniquely identifying them. In the first option the UE indicates via a MAC CE the setup of a new DRB using one of the pre-shared secure IDs indicating a specific DRB configuration to be setup at the NW side in an ad-hoc manner. The following two options show a DRB reconfigurations example either a complete one or just a delta modification to the already setup DRB. The fourth option is an inline MAC CE signaling DRB release to the NW. Note that this is shown for UL examples, but the same concept can be applied for DL being controlled by the NW. In the upcoming deliverable, further details on the signaling will be shared. Finally, with this approach more application awareness and UE intelligence will come in play as well as an expected reduction of signaling overhead (i.e., cell capacity, latency, etc.) may be achieved. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 64 / 155 AI and ML techniques for the design and optimization of wireless communication air interfaces. The AI/MLdriven air interface design is applied to learn single or multiple functionalities at the transmitter side, at the receiver side, or both at transmitter and receiver sides to increase flexibility, efficiency, performance, and adaptability to network and environment changes. Intelligent transmitter design aims to develop AI/ML-based algorithms to assist in the following processes associated to MIMO transmissions: • beamforming in the presence of imperfect channel state information, • antenna muting by identifying those sets of antennas muting patterns which guarantee the target spectral efficiency with the lowest possible number of active antenna elements, • selection of UEs that can be grouped in clusters and served together in multi-user MIMO, under partial channel information, and • resource allocation for the selection of the most suitable access points that should serve the UEs in networks with distributed MIMO architectures. In principle, the implementation of these algorithms would not require any particular changes in the standard. However, MAC and RRC layers might need adjustments to handle the communication and coordination of AIdriven decisions. The use of proprietary algorithms suggests a lower impact on the PHY. In addition, enhancements at the transmitter side are planned with a new flexible multicarrier waveform that can adapt its parameters depending on the environment. Furthermore, an optimized coded modulation scheme is investigated making use of AI/ML techniques. These approaches are likely to impact the physical layer most significantly and may need adjustments to modulation, coding, synchronization techniques and resource allocation. Minor changes might be required in the MAC layer to handle potential changes in latency or resource allocation. In the RRC layer, new signalling procedures would be needed for carrier configuration and resource allocation in the case of the new waveform, and to support the capabilities for the new coded modulation scheme. On the receiver side, AI/ML-based techniques are also explored for compensating for non-linearities in power amplifiers (PAs) and for improving channel state information (CSI) acquisition schemes. In both cases, there could be an impact of the PHY layer, the extent of which would depend on the adjustments required on the transmitter side. Furthermore, potential adjustments might be needed in RRC for signalling. Since the algorithms proposed for the intelligent receiver primarily operate within the receiver’s processing chain, their impact is expected to be more limited compared to the transmitter side. Various AI/ML-based methods are proposed [HEX224-D43] for joint design and application at the transmitter and receiver. These methods aim to enhance overall performance by jointly learning waveforms and receiver processing in MIMO scenarios, improving the accuracy of CSI algorithms, optimizing the energy efficiency of low-density parity-check (LDPC) channel encoding and decoding schemes, and enhancing multi-user MIMO (MU-MIMO) schemes. In general, these approaches would require minimal adjustments in the RRC layer to update signalling messages. The impact on MAC would be moderate, with the highest expected impact on PHY. Some potential changes that can be foreseen are the introduction of new learned waveforms in the standard, specification of new algorithms, involving demodulation, synchronization techniques, coding/decoding, and potential hardware adjustments. 4.3.1.5 Flexible spectrum access solutions: spectrum sharing and coexistence, low-latency random access Flexible spectrum access solutions encompass two key areas: spectrum sharing and coexistence, and lowlatency random access. Spectrum sharing and coexistence approaches aim to develop realistic radiation models with more accurate assumptions, establish a TN/NTN coexistence architecture, including sensing and AI/ML support, and design multi-radio access technology (RAT) spectrum sharing schemes that allow a smooth 5Gto-6G migration through efficient co-utilization of spectrum bands. These approaches may necessitate the implementation of novel mechanisms for power control, reference signals, beamforming, and spectrum sensing functionalities, potentially impacting the PHY. Changes in the MAC layer is also anticipated, driven by the need to adapt resource allocation and scheduling methods. Furthermore, potential adjustments to error correction mechanisms might impact the RLC layer. The RRC Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 65 / 155 layer is expected to be influenced by signalling modifications related to power control, resource allocation, and configuration parameters of the UE. Low-latency random access, closely related to spectrum sharing and coexistence, focuses on low-latency algorithms during initial access to spectrum as well as during established connection sessions. PHY and MAC layers might need to implement mechanisms for initial access, beam management, and scheduling. 4.3.2 Integration of device enablers The previously published Hexa-X-II deliverable D5.2 provides an exhaustive device characterization for the envisioned use cases for 6G network [HEX223-D52]. This analysis is the basis of the classification of device types foreseen for 6G, together with their associated radio requirements and technological enablers. Based on the work presented in D5.2, 6G device classes can be divided into two categories: • Novel 6G device classes: In this category, the devices are expected to be novel compared to 5G device types. The device classes identified include: reliable high data rate with bounded latency (RHDRBL), high reliability and low latency (HRLL), energy neutral (EN). Among the radio protocols, the last category has a higher impact as it may introduce additional procedures and information exchanges between the RAN node and the UE. RHDRBL and HRLL device classes have less strict QoS requirements on latency/reliability compared to URLLC device types in 5G. However, they have additional requirements on data rate. As a result, these device classes may introduce additional considerations in radio resource management logic at the base station and the packet scheduler. This is because they may require additional toolboxes on the radio protocol to achieve a better trade-off among performances, including also energy cost, spectrum efficiency. EN device class relies on energy-efficient design and operation for energy harvesting beyond other IoT device classes known currently. Considering the energy harvesting operation while maintaining radio connectivity will require RRC extensions to enable an efficient energy management at the UE side and the RAN node side (e.g., energy-aware selection/adaptation of parameter settings for uplink and downlink transmission and energy-aware scheduling). • Enhancements from 5G devices: In this category, the devices targeting the relevant 5G use cases (i.e., massive machine type communication, enhanced mobile broadband, and ultra reliable low latency communication) will continue enhancing their design objectives in 6G. From radio protocols, the support of this category may introduce stricter QoS requirements and QoS control, evolving the current 5G mechanisms available in the radio interface for 6G (e.g., capacity enhancements, latency control, assistance information, etc). One point to highlight is that novel 6G device class such as EN devices will require innovations in the 6G radio interface [HEX224-D53], the conventional RRC connection between the UE and the RAN node requires many handshakes for keeping alive the connectivity, not only considering access stratum (AS) exchanges between the UE and the RAN node, but also NAS exchanges between the UE and the core that RRC protocol piggybacks. Investigations for EN support point to a potential need of connectionless protocols for the UE and the network communication (for both AS and NAS levels) and related new behaviours to be supported in the radio interface to accommodate EN device operation (e.g., UE harvesting periods). The benefit of connectionless protocols is that it saves the EN devices the need to register to the network frequently, as their use of the network connectivity is different compared to other device classes. As a result, this shift will impact radio interface protocols significantly, for example: UE identification and authorization mechanisms, radio resource allocation, access to radio resources, security mechanisms, RRC state machine and related UE reachability and availability mechanisms per state, RRC procedures and exchange of new information elements describing EN device capabilities/expected behaviour, etc. 4.4 Additional radio interface and protocol enablers (SNS-JU) In addition to the enablers investigated in Hexa-X-II presented in the previous sections, other European projects are researching key areas for 6G radio interface and protocol design. The details of some of these European projects have been mentioned in Section 3.2. This section explores the complementary research aspects and innovation areas related to radio interface and protocol in two of those projects (DETERMINISTIC6G [DET24] and 6G-NTN [NTN24]). Enablers in the two projects explore specific Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 66 / 155 requirements (i.e., dependable time-critical communication) and use cases (i.e., integration of NTN) that are not explicitly considered in Hexa-X-II WP2 enablers yet and so would be a complement to enablers in the area of flexible radio protocol and mobility procedures. 4.4.1 Dependable time-critical communication on radio interfaces Certain enablers are needed in 6G to realize dependable time-critical communication on the radio. Dependable time-critical applications require strict guarantees in PD and PDV beyond optimizing average throughput and latency current applications need. To support dependable time-critical communications, DETERMINISTIC6G has identified data-driven latency characterization will serve as a bridge for the interworking between wired and wireless systems [DET23-D21]. From radio protocol perspective, to achieve data-driven latency characterization, efficient RAN resource allocation is required. DETERMINISTIC6G discusses many of the advances in the state of the art in resource allocation that aim to ensure reliable and predictable communication services. Still, there are also many challenges to achieve the needed delay reduction. One of the areas DETERMINISTIC6G investigates is solutions for streamlining the repetition and retransmission processes (e.g., reducing retransmission delays, minimizing resource utilization, and optimizing the retransmission strategy for different types of applications) [DET23-D21]. For example, HARQ retransmissions in combination with resource allocation methods. To evaluate it, DETERMINISTIC6G is working on a system model that considers packet arrival rate, number of required repetitions, the state of the communication channel, and the available time budget. This study can complement the findings of data recovery mechanisms presented in this report and [HEX223-D22]. Another area DETERMINISTIC6G is studying is latency prediction architectures, the framework assumed is based on 3GPP TR 37.817 [37.817] where the support of AI enabled RAN intelligence is achieved by means of a data collection function that gathers relevant data for uplink and downlink traffic (e.g., network conditions, traffic conditions, latency) at different network entities tightly synchronized. In this 5G reference framework, it is envisioned the gNB may be one of the locations to train latency prediction models. Once the latency prediction models are trained, the gNB can estimate the latency distribution in the future. Using this prediction, the actor function in the gNB can for example optimize resource allocation, provide information to data collection function, etc. 4.4.2 TN/NTN integration on radio interfaces The 6G-NTN project ambition is to research and develop the innovative technical, regulatory, and standardization enablers needed to ensure the full-fledge integration of the NTN component into the 6G system. To achieve it, there are many design drivers and TN-NTN integration aspects under investigation that will involve innovations from radio protocols, such as AI driven RRC, energy efficient service delivery in multi access technology network (i.e., NTN/TN), interference mitigation through AI driven RRM, access protocols enhancements to optimize mobility (e.g., improved user experience when the UE switches its connection from one network type to another network type) [Chu24]. Furthermore, the different functional split options between TN-NTN will introduce new challenges to address in 6G. For example, for a split option where the full base station onboard, one of the challenges to address in 6G is that NG in 5G was not designed to support a moving base station [6GN23-D31]. 4.5 Enabler recommendation for radio protocol and interfaces In this section, we provide recommendations for enablers on radio protocol and interface. Since the interface between device and base station remains to be one of the most important multi-vendor interfaces in 6G, all enablers related with radio interface and protocols are of great importance in 6G standardization. In addition, the enablers fulfil KPI, KVI, and design principles in the project one way or another. Regarding the criterion for recommendation, as mentioned in Chapter 2, enablers that can fulfil the E2E system requirements are the first criteria to be considered as enabler recommendations. Section 3.1 of Hexa-X-II deliverable D2.2 [HEX223-D22] listed high level considerations for the design of the 6G radio interface and protocol. Such considerations are used also as a decision-basis for enabler recommendations. In addition to those, the system impact of an enabler is considered in the recommendation. In other words, a priority is given to those enablers with both a large system impact and a great potential to fulfil the 6G ambition and these enablers require both integration consideration and a need for further analysis and development. Lastly, only Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 67 / 155 the enablers with the technology readiness level (TRL) level larger than two are recommended and more enablers might be included in the future deliverables once their maturity level is good enough, e.g., enablers from other SNS-JU projects are not recommended due to low TRL levels. In a high-level summary, these enablers evolve radio interface and protocol based on 5G learnings and new requirements from 6G. Some enablers are related with unique breakthroughs within the radio protocol itself (e.g., flexible radio protocol on RRC, user plane, ciphering and integrity protection, data recovery, and mobility procedure related with IDLE and CONNECTED mode separation). Some enablers leverage on latest technological breakthroughs from other areas like AI and computer offloading and integrating them into the mobility procedure. Lastly, some other enablers are to support technologies from the physical layer and devices and new concepts from the higher layers related with the architecture. All these enablers are on the concept study level at the moment. The details of the enablers are described respectively in the previous sections in this chapter and the rest of this section herein gives a summary of each recommended enabler. Section 4.5.1 describes the enablers on radio protocol itself. Radio protocol support for enablers from upper layers and architecture is in Section 4.5.2. Lastly, Section 4.5.3 includes radio interface and protocol support for physical layer enablers including radio technologies and future devices. 4.5.1 Radio protocols The enablers can be categorized into the area of user plane protocols (i.e., MAC, RLC, PDCP), control plane protocols (e.g., RRC) and a specific mobility procedure area that has been the focus of the radio protocol in previous generations. 4.5.1.1 Flexible radio protocol In the area of the control plane, the single most important area is the RRC protocol, which the base station utilizes to configure the device with various radio features. RRC relates to, e.g., mobility procedures, configuration of data recovery mechanisms, supporting configuration of features in PHY layers (like sensing) and higher layers (like compute offloading). It is essential to carefully design RRC protocol to avoid deployment issues and enable the fulfilment of the KPI/KVI/principles that are promised by other individual enablers. This requires that the RRC protocol supports key use cases and deployment scenarios, while also being easy to extend in later releases. One of the key 5G learning was that use cases will not happen if the implementation cost of complex features, exceeds the business value of the use case. In this area, RRC signaling structure should be re-thought together with signalling optimizations that are motivated from the learnings in the 5G deployment. For example, RRC without many hierarchy levels could be built on assuming a single architecture option, a single spectrum aggregation mechanism, no higher layer split within RRC, and using a modular RRC design in which the UE is configured with different profiles and a profile is switched on by a simple signalling. The RRC design must allow fast, secure, reliable, profiled, and self-recovering control plane operation, for accelerated procedures and energy-efficient operations. Another key component is the UP. One paradigm shift enabler is to tackle the complex toolbox adopted in 5G for a wide range of services. It is not easy to freely mix and match different tools in the same box, since the same tool can be considered as desirable for one service but harmful for other services. This creates issues for device implementation and also a very complex configuration task at the base station, as there will be many combinations of devices that support only a subset of tools. A dual configuration for radio protocol is designed with flexible scalability for supporting high bit rate services. The essence is a complexity/implementation-friendly design of the user plane including enabling parallel processing as one of the main targets for 6G UP design. With a two-stacks approach, all types of devices can natively be supported. The dual configuration for radio protocol anchors well with the design principle and the details remain to be worked out in the future deliverables. There are multiple enablers to further enhance the performance. The first is the enabler on data recovery and reordering mechanism, which utilizes cross-layer interaction to avoid RLC window blocking and hence unnecessary delays by allowing RLC window moving operations. This would result in reduced latency while at the same time ensures the enhanced reliability offered with retransmissions, ensuring that the 6G objective of resilience and availability is achieved. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 68 / 155 Another enabler focuses on ciphering and integrity protection, where it introduces the idea of moving the ciphering and integrity protection functionality from PDCP to MAC layer to ensure the protection of the L2 headers and control elements that were kept unprotected in legacy 3GPP cellular systems (e.g., 5G). This enabler, hence, ensures that the 6G objectives of network scalability and persistent security and privacy are achieved. Yet another enabler is the introduction of SDAP for beyond communication services to distinguish between data, sensing, and computational traffic to be properly routed to the correct network function. This is to support UE based sensing or computational offloading with a large amount of data, and it is necessary to modify the radio interface to efficiently handle the associated data transfer. 4.5.1.2 Mobility procedures Mobility procedures are an integral part of the radio interface and protocols, and accordingly multiple enablers were introduced in this chapter to ensure that such integral aspect is designed to ensure that the different 6G principles from [HX223-D22] are achieved. One enabler is on data driven mobility. It introduced UE contextual events, which rely on the UE capabilities of understanding radio environment and traffic patterns to proactively initiate handover and/or cell preparation (e.g., for CHO and LTM). This can enhance quality of experience of the users during mobility and reduce network/UE overhead. This enabler, hence, ensures that the 6G objectives of flexibility to different network scenarios and resilience and availability are achieved. Additionally, the enabler of computation aware mobility was introduced, where the computation requirements of the users and the computation capability of the network are considered when preparing target cells and executing handover. Hence, it is essential to adapt the mobility procedures to the 6G use-case of compute offloading [HEX223-D12]. This enabler, hence, ensures that the 6G objectives of support and exposure for 6G services and capabilities, flexibility to different network scenarios and resilience and availability are achieved. Lastly, the enabler of a separation of IDLE mode and CONNECTED mode signalling is both a steppingstone toward sustainability target and a paradigm shift for the mobility procedure. By separating the requirements for IDLE and CONNECTED mode, the network can turn off nodes (e.g., those only transmitting signals for CONNECTED mode UE) to reduce network energy cost, if such a node is not serving any UEs. This promising concept needs to be complemented with mobility procedure related enablers, e.g., if a device moves into the coverage and needs to perform data transmission, then how to turn on the network nodes that have been in sleep. The details are left for future deliverables. 4.5.2 Support for architecture and higher layer In this subsection, various enablers related to architecture and higher layers are summarized. We first recommend three enablers on application and network interaction to support higher layer. This is followed up by a list of other architecture enablers (detailed description in Section 3.3) that are also important in the radio protocol domain in the sense of their impacts on the radio protocol. Application-NW interaction for service differentiation and QoS/QoE management The application-NW interaction for service differentiation and QoS/QoE management has three studies of interest. The first is the low latency scheduling, where the UE indicates what traffic characteristics to expect via a PCR, sent to the NW. This is expected to enhance the dynamic grant, as well as the configured grant scheduling by ensuring that the grants are tailored to the UE’s needs. As a result, it would ensure an overall reduced latency as well as an enhanced overall utilization of NW resources. The second study is for ad-hoc radio bearer and inline signalling, where it introduces a new mechanism that would allow for the setup, reconfiguration, and release of RBs in a more dynamic fashion based on application or services requirements. The third study is for “dynamic adaptation of QoS resources for interactive services”, where a new resource type for 6G QoS is proposed. This proposed adaptive resource type enables a more flexible management of service provisioning in RAN compared to current 5G resource types. AI enablers, as stated in Section 3.3, may impact the radio protocols and hence its integration and subsequent requirements on the E2E system design should be considered. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 69 / 155 Network of Networks, as stated in Section 3.3, includes research on subnetworks and NTN. Subnetworks will have an impact on the RAN protocol stack for CP and UP procedures, both regarding the communication between UEs within the subnetwork and the interaction between the MgtN and the overlay network. As far as NTN is concerned, the split of the RAN protocol stack between a ground base station and a satellite will be different based on the selected architecture. Furthermore, the multi-hop procedure of an NTN architecture that supports ISL will impact the RAN. More details about this enabler may be found in [HEX223-D33]. Multi-connectivity, as stated in Section 3.3, includes research on CA/DC and aggregation of different access technologies. As stated in [HEX223-D33], the CA/DC research includes procedures for adding and activating an SCell/PSCell faster when transitioning from idle to connected mode and for allowing control signaling to be performed via SCells. Furthermore, aggregating cellular and WLAN on the RAN level will have an impact on the RAN protocol stack. Beyond communications functionalities: As mentioned in Section 3.3, the research areas of compute offloading and JCAS would have an impact on the radio protocols. Regarding compute offloading protocols, signalling and procedures, the newly introduced roles and functionalities (e.g., ON, CompN, CCN) and the proposed procedure of performing compute offloading as described in [HEX223-D33] would impact the radio protocols. JCAS protocols, signalling and procedures will require innovations in the radio interface and its interactions with the core network, with further analysis of enablers in this area needed considering the proposed radio design principles as mentioned in Section 3.3 and described in [HEX223-D33]. MRSS, as stated in Section 3.3, should be an inherent feature in 6G radio design, allowing future generations to share the spectrum. 4.5.3 Support for radio and future devices In this subsection, enablers related with radio technology and future devices, which potentially have impacts on radio interface and protocols and thus, a need to integrate, are summarized. Note that a flexible radio protocol described in the Section 4.5.1 should support novel PHY techniques and future devices, e.g., a flexible control plane protocol that can efficiently configure new features and a flexible user plane protocol that can accommodate specific needs of future devices. The integration among those is left for future deliverables. JCAS PHY is a new identified 6G service while its impacts span from end-to-end. Similar to the support of JCAS service from the network architecture point of view, the support of it on the PHY layer can be considered as an important enabler. As previously mentioned, from the radio interface standpoint, this enabler is expected to significantly impact the radio interface, and its integration may require substantial changes. Energy efficient radio design: The high flexibility of radio design is a key feature for achieving a high degree of energy efficiency. This flexibility can be effectively leveraged across a wide range of use cases. While configuration within standard specifications is feasible in some instances, to fully benefit from the advantages of flexible radio design and thereby maximize energy efficiency, substantial modifications beyond the specifications will be required. Inclusive radio interface: This enabler aims to promote inclusiveness by integrating NTNs and TNs. Specifically, the inclusive radio interface focuses on enhancing TN/NTN integration by reducing signalling overhead and minimizing interruption time during handover. The implementation of these approaches might necessitate changes to the radio interface. Intelligent radio air interface design: This enabler focuses on developing AI/ML-based techniques for the design and optimization of the wireless communication air interface. Incorporating AI/ML into the air interface design has the potential to enhance the flexibility, efficiency, and performance of the system. It is recommended to conduct further evaluation of its potential impact on the 6G system. Flexible spectrum access solutions: This enabler focuses on addressing spectrum sharing, TN/NTN coexistence, and low-latency random access, which are key topics contributing to sustainability, inclusiveness, and trustworthiness. Incorporating the proposed spectrum access solutions to the 6G system would require modifications to the air interface. Novel 6G device classes and enhancements from 5G devices: Since 5G devices will not be able to fulfil all the envisioned use cases for 6G, an exhaustive analysis has been conducted to identify the properties that Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 70 / 155 devices should possess. This analysis encompasses a wide range of device characteristics, grouped into the following groups: energy, data rate, latency, reliability, and availability. Consequently, new 6G device classes (EN, RHDRBL, HRLL) have been defined, and enhancements to existing 5G device classes (e.g., mMTC) have been identified. The integration of these device classes into the 6G system is anticipated to necessitate modifications, which would be investigated further. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 71 / 155 5 Management and orchestration enablers This chapter focuses on identifying all possible enablers within the Hexa-X-II and other SNS-JU projects in order to define a framework that allows to achieve a complete management and orchestration, with a special focus on intent-based elements. To do so, the first Section 5.1 presents, at the intent layer, all the updates and modifications of the intent-based digital service manager-intent management entity (DSM-IME) presented in [HEX223-D22] together with the associated enablers identified by that deliverable. Then, in the Section 5.2, a summary of the enablers that Hexa-X-II has proposed at the network service management and orchestration level is presented. Moreover, to achieve a complete view of all the available possibilities, Section 5.3 presents the existence of other interesting enablers defined in other SNS-JU projects that may assist and/or complete the Hexa-X-II framework. In the last Section 5.4, there are evaluations of the priorities of all the proposed enablers to be integrated, together with a set of requirements that enablers need to be accomplished from an E2E system point of view. 5.1 Intent-based management automation framework and enablers Based on the work presented in [HEX223-D22], this section describes the latest work regarding the intent framework being studied, with the new changes and evolutions applied to the intent-based DSM-IME functional architecture (subsection 5.1.1). In order to accomplish its functionalities, more details and specific aspects of the multiple intent-based enablers are also presented (subsections 5.1.2 – 5.1.10). 5.1.1 Intent-based digital service manager functional architecture Since its publication in D2.2 [HEX223-D22], the DSM-IME functional architecture has experienced some changes and evolutions to unify actions related to the core management of intents and to properly identify the specific intent management functions, the intent report functions and those internal functions that the users do not need to know about, but that assist to the main functions. To this end, and as presented in [HEX2-AMO+24], the functional architecture has evolved to the version illustrated in Figure 5-1. Compared to its previous version, the “Intent/interface Handler” module changed its name to “Intent Interface” and its functionalities were extended by placing the functionalities within the “Intent Management” module. This last module has disappeared, making the whole architecture a bit less complex. Within the functionalities, the old “Intent Report Configuration” has evolved to the “Intent report management” functionality. Figure 5-1 Updated DSM-IME functional architecture. The old “intent fulfilment internals” module has been updated to “Intent Fulfilment”, removing the need of the word “internals” as it is already implied with the direct interaction between the digital service customers /digital service provider (DSC/DSP) and the “Intent Interface” module. Within its functionalities, there are two Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 72 / 155 important modifications. First, the addition of the “Intent Translation” functionality which focuses on the translation from the intent data object into the right requests to send towards the service management domains (MDs) and the resource (MDs). Secondly, the functionalities about the governance and coordination of the generated closed loops (CLs) have been joined into a single functionality called “Intent CL Governance and Coordination Service” as they are closely related and it is expected that if an intent management solution applies to one, it will also apply to the other. In order to present how the different components within the functional architecture shown on Figure 5-1 interact, Figure 5-2 illustrates a workflow with all the steps to deploy an intent-based request towards the provisioning of a service required by the DSC/DSP’s tenants using pre-defined service level agreements (SLA) already defined in the system for each kind of tenant. The workflow begins with the “Intent request and feasibility check” phase, when a user or system (e.g., DSC/DSP) sends an intent-based request identifying a service with its requirements (step 1) defining a certain level of quality (i.e., in terms of security or performance). The request is received by the Intent Interface module, which processes and creates the intent instance (step 2) based on the requested services and its associated KPIs/KVIs targets using technologies such as natural language processing (NLP). Then, this request triggers a verification process against the contracted SLA based on the profile of the tenant who is requesting the service using the 3P Profiling module (step 3) to ensure it aligns with the contracted SLA objectives. Once this verification is complete and if everything is ok (KPIs/KVIs identified and SLA verified), the intent instance artifact is completely created and stored (Step 4) and the requester is notified about the completion of this process (step 5). With the intent data object ready, the Intent Interface module forwards the created intent to the Intent Fulfilment module the intent fulfilment request is initiated (step 6) and the system takes care to map the intent into executable services, applying logic to meet the KPI/QoE targets based on the contracted SLA. Additionally, it identifies one or more CL policies to meet the KPI/KVI targets outlined in the contracted SLA (step 7). Once the executable tasks of the CLs (i.e., policies) are selected, it is of high importance to check the feasibility of fulfilling the intent (step 8), for example by requesting about the available resources in domains (i.e., Network, Cloud, Applications, etc.) below. With the incoming outcomes of this process, an intent report data object is created and the feasibility outcome (i.e., intent is feasible or not and the reasoning) is recorded (step 9) by the Intent Reporting module. At this moment, the second phase of the workflow called “Intent Closed-Loop Fulfilment & Evaluation” begins with the request to the Intent-driven CL Control for fulfilment evaluation module to instantiate the necessary CL elements based on the previously identified executable services and their associated policies (step 10) information. It is worth to mention that, depending on the policies, one or more CLs may be created to properly fulfil their specifications. The activation of a CL involves the execution of provisioning tasks such as requesting the service deployment to the Service MD module (i.e., next-generation OSS) to meet the KPIs/KVIs (step 11) and configuring it through (step 12) the Resource MD module. The Service MD module then responds to the service deployment request (step 13) and subscribes for monitoring parameters (step 14). Finally, the CL applies the last tasks before an intent may be considered fully deployed (i.e., provisioned and activated). The intent’s parameters (step 15) monitoring is conducted, followed by a KPIs/KVIs analysis (step 16). Based on the analysis, the CL must decide whether the intent KPIs/KVIs targets are accomplished or not. If KPIs/KVIs targets are not met (step 17), the workflow includes a decision point where the intent-related resources may be reconfigured based on the defined policy. Finally, to complete the fulfilment and evaluation phase, a reporting task is generated (step 18) to document the current intent status using the associated report object previously created during the feasibility step. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 73 / 155 Figure 5-2 Intent-based deployment workflow. The last phase in the workflow is the “Intent Conflict & Resolution”. In this phase, the CL KPIs/KVIs are frequently monitored (step 19) to identify any conflicts between one or more intents: when a new intent is being deployed, when a re-configuration is done over an existing one that may affect another intent, or when expectations among intents are being unmet. The incoming data is analysed (step 20) and, if a conflict is detected (step 21), a conflict resolution needs to be applied. In this situation, it is important to consider how to manage the conflicts as different approaches are possible. As introduced by the 3GPP [28.836], a conflict resolution model may be applied depending on who the intents consumers (i.e., requester/owner) are. This means that depending if the two (or more conflicted) intents belong to the same owner or to multiple owners, the right resolution policy needs to be applied. On the one hand, when two intents belong to different owners, the conflict resolution should be as fair as possible and probably managed by the system itself. In this case, an example for the policy resolution may be the use of priorities or classes and the system keeping those intents with higher priority. On the other hand, if two conflicted intents belong to the same intent consumer, the conflict resolution decision may be also left to Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 80 / 155 requirements of the intents while serving them after they have been deployed. For example, when one intent is already assured in the DSP and another intent arrives, then a conflict would happen if two requirements would try to reserve the same set of resources. Another example occurs while fulfilling a requirement for an intent, if an action taken to fulfil such requirement impacts another intent’s target, then there is a conflict between the intent’s expectations. The proposed enabler is mainly responsible of preparing report(s) and evaluate action(s) to provide an input to intent report and closed loop coordination enablers. 5.1.5.1 Novelty and maturity The proposed enabler is novel. It considers some of the specifications for intents in different standardization forums; however, it introduces new functionalities and interfaces not described in these forums and publications. For example, it generalizes the conflicts between intents and it is able to propose solutions for such conflicts, without stopping and/or removing conflicting intents. Currently the enabler is at a conceptual level since it has not been implemented or prototyped in a publication to demonstrate the enabler’s functionality; however, there are plans for publication to show how different types of conflicts can be administered using the enabler. 5.1.5.2 Internal architecture This enabler is divided in three blocks as shown in Figure 5-6. The first detects intent conflicts in two scenarios: when validating the intent (i.e., verifying no conflict within expectations) and when continuously monitoring the intents once deployed (i.e., identifying problems between two or more intents). The second block proposes actions and predicts their effects to mitigate the conflict. Finally, the third block, generates a detailed description of the intent conflicts. Figure 5-6 Intent Conflict Administration internal architecture. 5.1.5.3 External interfaces The Intent Conflict Administration architecture relates with some external enablers such as the Intent Report, Intent Translation and Provisioning, and CLC. To provide a clear communication between our enabler and the external enablers listed in this Section, some interfaces need to be designed. The first interface is the interface between the Intent Conflict Administration enabler and the Intent Reporting enabler. The intent definition, coming from the Intent Translation & Provisioning enabler, contains the information regarding how and when a report should be generated using the functionality of the Intent Reporting enabler; yet, it lacks the information about conflicts (either within and between intents). This information is provided through the interface between the Intent Conflict Administration enabler and the Intent Reporting enabler. The proposed interface outcome can be defined initially with a Boolean value: True in case of conflict; otherwise, False. In addition to that, the interface provides information to the intent owner about the intents involved in this detected conflict (e.g., which intents are involved in the conflict). It is important to highlight that this information can only be sent if they are from the same intent owner. If, for example, the intent conflict is caused by intents belonging to different owners, only the information regarding to the intent belonging to the intent’s owner will be listed. This is done for privacy issues. The last outcome of this interface is the timestamp to provide information in case of asynchronous messages. Thus, the output is a tuple (conflict result, intents involved, timestamp). This conflict information will be added to the intent’s report as specified by the owner in the Intent Reporting enabler. Intent Translation and Provision Interface: This interface is used to verify if intent expectations can be met before being deployed in the network. Thus, the intent owner’s ID to identify who sent the request are required. Next, the intent definition which contains all the expectations, requirements, context, and all information defined in the intent model supported by the DSP are required. Optionally, there could be additional information related to the provision of the intent. Therefore, the input tuple is (intent owner ID, intent Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 81 / 155 definition, additional information). The return value of this interface will be a Boolean value describing if this intent expectation can be met or not. CLC Interface: the third interface is related to the outputs of our enabler regarding the proposed actions that could be done to resolve the intent conflicts. The proposed actions/commands of this enabler can be sent to the CLC enabler following the TUPLE (action, Intent Information, timestamp) sent to the NBI of the CLC, as detail on Section 5.1.4.3. The first parameter is the proposed action supported by the closed-loop coordination enabler. The second parameter contains the information of the intent involved in the call, and the third parameter is the timestamp of the call. 5.1.5.4 Workflow The workflow considers the three main components of our architecture, namely the intent conflict detector, solver, and reporter. The detector collects the intents, analyses, and detects conflicts. After a conflict has been detected, the solver proposes action to solve the conflict by predicting possible outcomes of actions, since an action can entail unwanted side-effects. After, the reporter will collect information and distribute it back to notify there is a conflict. Each of these components interacts with the other enablers. More details of how these interactions happen within internal components and other enablers is detailed in Annex A.5. 5.1.6 Human-machine intent interface design enabler The main objective of this enabler is to allow users/applications from different domains/verticals to express the intents in their own domain language without any telecom/network knowledge. Hence, the users/applications are not restricted to use the network domain language or any standardized data objects, e.g., from 3GPP. To achieve this, the internal architecture of this enabler can be structured as shown in Figure 5-7. It can be noted that, this enabler sheds more lights on the interpreter module presented within subsection 5.1.2. 5.1.6.1 Novelty and maturity The novelty of this enabler comes from the fact that users/applications are not restricted to use the network domain language or any standardized data objects. Existing solutions expects a predefined syntax and a network domain language to be used when expressing the intents, assuming the in-depth telco knowledge of the users. Regarding the maturity level, this enabler is currently at a conceptual phase that is yet to be implemented. 5.1.6.2 Internal architecture Figure 5-7 Human-machine Intent Interface Design internal architecture. The internal architecture of this enabler consists of the following modules: - Interpreter: As mentioned in Section 5.1.2, it is the module responsible for creating a 3GPP data object from a received intent/request. The intent is received from a user/tenant that is either a human operator or a machine (e.g., a running application code) in a language specific to the user’s domain. - Interpretation models database: A database storing different interpreters for different domains and different intent structures, e.g., natural language, graph, etc. - Interpretation experiences database: A database storing all previously interpreted intents to be used for improving the relevant interpreter. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 82 / 155 5.1.6.3 External interfaces The interpreter interacts with different components through 2 interfaces, NBI and SBI. The NBI is a bidirectional interface that enables the users to express their intents to the network and receives feedback. Dependent on the user type, either human operator or a machine (e.g., a running application code), this interface could be: - Human to machine (H2M)/machine to human (M2H): Enables the definition of business or service objective by the human operator and provides insights back to the user. - Machine to machine (M2M): Enables applications to express their needs in their domain language and provides insights and actionable feedback to the applications. The SBI allows the interpreter to interact with other modules in the IME through the Manager, which was introduced in Section 5.1.2. Those modules are: - 3P Profiling: Allows the interpreter to request and receive the relevant profile of the user, which will help with the interpretation process. - Closed loop governance and coordination services: Allows the interpreter to initiate an interpretation CL. This CL would support the monitoring of the intent and if a deviation from the application-level goals is detected, the CL governance and coordination services should be able to differentiate between a deviation due to inaccurate interpretation and that due to insufficient network capabilities and execute the right management decisions accordingly. 5.1.6.4 Workflow The main objective of this enabler is to allow users/applications from different domains/verticals to express the intents in their own domain language without any prior telecom/network knowledge. When the NBI receives an intent, that is not expressed in a prespecified language and data object structure, e.g., like the one defined by 3GPP [28.312], it consults the interpreter to interpret the received intent into a language and data structure that is understandable by the IME. Workflows that describe the process of intent creation and how it is monitored afterwards, are introduced in detail on Annex A.6. 5.1.7 Intent-driven placement enabler As introduced in [HEX223-D22], the intent-driven placement enabler focuses on intent fulfilment mechanisms and extensions to support intent-driven compute placement in the cloud continuum. Implications on other functional components of the DSM are not elaborated upon in the following as they are minor or straightforward application of these functional components. In a nutshell this enabler requires deriving the execution domain (agent) to contact and request orchestration through the MCEF, taking into account the current state through compute domain telemetry, as well as spawning and maintaining a (set of) closed-loop(s) in charge of reacting to changes notified through the compute domain telemetry or other sources of context information to adjust placement to maintain according to the intent expression. Such other sources may include for example network degradation information imposing to deploy a component closer to the user to maintain the fulfilment of the intent or the current open common vulnerabilities and exposures (CVEs) information to be confronted with the considered compute hosts to fulfil an intent on “running on a host with no open CVE”. In this deliverable, cross-DSP scenarios are not illustrated and will be addressed in the next deliverable. 5.1.7.1 Novelty and maturity This enabler is a concept study item the necessary extensions of current intent-based approaches to support compute placement. 5.1.7.2 Internal architecture This enabler is embodied in specialization/extensions of a number of DSM components as illustrated in Figure 5-8. From a logical perspective, it exposes two logical interfaces, NBI and SBI, described in the following subsection. Note that the functioning of the included DSM functions may imply interaction with other DSM functions but those are not part of the enabler as illustrated by the dashed box. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 83 / 155 NBI: this logical interface receives well formed (e.g., following the 3GPP intent data model) intent from the intent interface group and in particular intent interpreter function. Figure 5-8 Intent-driven placement enabler high-level architecture. Intent Translation: the enabler relies on the addition of placement handling capability/logic to the intent translation function (e.g., realized through the intent translation & provisioning enabler), to support translating placement-related intent expressions into actual compute placement-oriented intent data object, checking parameters against 3P profile and current state of relevant domains (e.g., from data fusion), and to issue a set of executable service management tasks towards domain managers and trigger the intent CL governance and coordination service. Intent CL Governance and Coordination Service: Intent CL governance is extended to select and instantiate intent-driven CL control for fulfilment evaluation components dedicated to placement decisions enforcement. Intent CL Instances Execution, Monitoring & Decision: to support placement and adaptation to contextual changes (e.g., detected through data fusion mechanisms based on telemetry data enabler or through direct domain manager interactions). SBI: this logical interface is the interface to the MCEF and beyond to the domain managers. 5.1.7.3 External interfaces The logical northbound interface of this enabler is the interface exposed by the intent translation functional component, exemplified in the API presented for the enabler in subsection 5.1.2.3. Specifics of this enabler lie more in the intent description extensions that are needed to support placement decisions. These are likely realized through microservice descriptors extensions to include target features of the infrastructure components on which these microservices are required/preferred to be deployed. Those extensions may be explicit references to target execution domains (e.g., requesting execution on a particular extreme edge device or the edge cloud serving the latter) or may have to be derived from broader intent description requirements (e.g., requesting execution on resources trusted by or belonging to a given actor; or more indirectly requesting an SLA that implies the selection of certain execution domains and specific networking configuration), and need to be mirrored in closed-loop capabilities able to realize corresponding monitoring/decision/execution. 5.1.7.4 Workflow The intent-driven placement workflow is a subcase of the general intent processing workflow, triggered by the reception of an intent requiring compute orchestration and placement in the cloud continuum. In a nutshell, when an intent fulfilment request containing explicit or implicit placement constraints is received at the NBI from the intent interface component, the intent fulfilment component determines which intent-driven closed- Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 84 / 155 loop instances should be started to trigger compute placement onto appropriate compute domains through the SBI and adapt to subsequent changes. More details can be found in Annex A.4. 5.1.8 Declarative intent reconciliation enabler Upon the creation of an intent, one or more CLs are initiated by the CL governance to fulfil the intent requirements. Particularly, each CL defines goals and a set of actions to deliver these goals. In addition, CL coordination can modify the goal of an existing CL if there is a conflict between intents. In both cases (CL initiation and coordination), this enabler keeps track of the information and updates the workflow accordingly. The set of actions is composed by the reconciliation engine into a pipeline which specifies the order of execution and the corresponding domain controller in charge. Both CL goals and pipelines are specified and stored in a Git repository as the source of truth. For each CL, an Agent is deployed to execute the pipeline on the related resource domains and continuously monitors the domain state to ensure the desired state is fulfilled. 5.1.8.1 Novelty and maturity This enabler presents a novel approach to handle intent instances and streamline the delivery of intent lifecycle management pipelines. It leverages the GitOps principle from IT and Cloud domains, as well as predicates the current work on intent-driven autonomous networks from standardization bodies (e.g., ETSI ZSM, TM Forum, 3GPP, etc.). Particularly, the enabler defines a set of syntaxes, under the context of the Hexa-X-II project, to compose and configure CL delivery pipelines, which are translated from CL goals and actions. In addition, this script is stored and versioned in a declarative manner, which facilitates the monitoring and adaptation throughout a CL lifecycle. The maturity of this enabler is at the conceptual level. 5.1.8.2 Internal architecture The internal architecture of this enabler is depicted in Figure 5-9 and specified as follows. • WebUI: allows the tenant to manage and audit the CL goal and workflow (pipeline of CL actions), observe the workflow execution time, keep track of which action is being executed, etc. • Git Server: acts as a source of truth to store CL instances and pipeline information, sends webhook to notify the reconciliation engine for any update in CL, provides access control mechanism. • Reconciliation Engine (RE): deploys agent to be in charge of a CL pipeline, monitors the status of the deployment to ensure the desired state is maintained, interacts with the Git server to update CL pipelines. • Agent: is an entity that executes tasks or invokes managed entity in resource domains via the management capabilities exposure framework (MCEF) according to a pipeline. • Database: stores the CL goals, pipeline and monitoring information. Figure 5-9 Declarative Intent Reconciliation internal architecture. 5.1.8.3 External interfaces The enabler provides two interfaces to view and modify the information regarding CL instances (goals and actions). First, tenants can use the interactive WebUI to directly change the CL instance. Moreover, the current state of the pipeline and all monitoring data of domains can also be observed from this interface. Second, other modules (i.e., intent translation & provisioning, CL governance and coordination, etc.) in IME can leverage the REST APIs to communicate with the enabler as follows. … Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 85 / 155 Table 5-4 Declarative Intent Reconciliation REST API. Operation Method Endpoint Input Output Create a CL instance POST /intent CL data object CL ID Modify a CL instance PUT /intent/{id} CL data object Status (OK/NOK) Query a CL instance GET /intent/{id} --- CL data object Delete a CL instance DELETE /intent/{id} --- Status (OK/NOK) Create a pipeline POST /pipeline Pipeline data object Pipeline ID Modify a pipeline PUT /pipeline/{id} Pipeline data object Status (OK/NOK) Query a pipeline GET /pipeline/{id} --- Pipeline data object Delete a pipeline DELETE /pipeline/{id} --- Status (OK/NOK) Furthermore, the agent uses the interfaces that are provided either by the MCEF or domain controllers to realize the pipeline. 5.1.8.4 Workflow The functionalities of this enabler are considered in two scenarios: CL initiation and CL coordination. In the first case, each agent is created upon the initiation of a new CL. Throughout the CL life cycle, the agent is in charge of managing and executing the set of actions (pipeline) on resource MDs. In the second case where a conflict between CLs has occurred, one or more CL’s goals need adapting, thus triggering pipeline updates. Subsequently, existing agents that are involved in the conflict resolution process will perform reconfigurations on resource MDs. A detailed description of the interaction and the workflow between internal components and other external enablers in both scenarios is specified in Annex A.7. 5.1.9 Intent reporting enabler This enabler provides the functionality needed to expose the information associated with the intent-based management actions. This information reflects the status of the intent in three scenarios, i.e., feasibility, conflict management and fulfilment. The 3GPP Service and system aspects work group 5 (SA5) document [28.312] exposes in its definitions some details about the reporting activities. The TM Forum explores the capabilities needed in the [IG1253] document and defines it over an intent common model on the document [TR290B]. The ETSI ZSM [ZSM011] proposes also detail of reporting activities based on the TMForum [IG1253]. 5.1.9.1 Novelty and maturity The concept of intent teporting has its origins in the IBN group of 3GPP with its first definition. Support from ETSI-ZSM and TM Forum also is considered as they define some use cases for intent reporting. The enabler is defined in the context of Hexa-X-II considering the proposed architecture and integrating several technologies for their build. In terms of maturity this enabler is creating a preliminary implementation to analyse the scenario defined and propose updates in the concept. Additionally, the integration with intent translation and provisioning enabler and intent conflict administration as event source for launch the reporting activities is under evaluation. 5.1.9.2 Internal architecture The reporting activities are initiated with some notification about the actions to report. An event that indicates a change in the status of an intent is consumed by the components included in the enabler generating an action for gathering the related information, creating the response object, and publishing it on the established channel. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 86 / 155 Depending on the information associated with the report, this could be a single report per action (only one is generated and notified) or a single report summarized per action (some reports need to get information several times in a period resulting in one notification, several reports generated and a final summarized report as final response). Also, several reports could be generated over time periodically . Figure 5-10 Intent Reporting internal architecture. The information associated with the action could be gathered by the report management (this implies knowledge and some measurement capabilities about the E2E service which is not desirable) or establish a subscription over the information required generated by some measurement or observability system. The components of the architecture are the following: • Report DB: Stores the information needed for report management. It generates notifications associated with change of status of report or periodic events for adequate monitoring and reporting. o Repo spec: The definition of the report needs to be flexible because of the different kind of reports and the information managed. It is included in a module where it can be defined the specification of the characteristics of the report, considering its future extension using TMForum Open API data models. o Report instances: The built reports created over the specifications should be stored for querying their information when it is necessary. It is relevant for audit and certification purposes and as basis for optimizations. o Repo config: This module includes the set of actions selected by the consumer for receive the information including the period and the elements selected to be considered in the reports. • Notification Collector: The activities associated with the report actions are launched when the feasibility, conflict or fulfilment is performed. Some events are notified to the MCEF component, and this initiates the actions described in the workflow. The notification collector processes the event with a subscription to the specific channels and listening for relevant information. • Recommender: This module is called when the feasibility check has not passed the validation and a new approach with different expectations is offered to the customer based on the knowledge of the managed domain. The recommendation process could find a less restrictive expectation using some kind of calculation or based it on past experiences. • Impact analysis: This component is used when the conflict among two or several intents need to be reported and the intents and related services are affected. Trying to solve the conflict, some kind of impact analysis is useful to take a decision that solves the conflict. The impact could be evaluated on several ways, number and kind of customers affected, priority, type of E2E service and others. • Prediction: The fulfilment report could gather information in a period and then summarize these values offering a consolidated value. Also, it would be valuable in some reports to include a prediction of the future values for customer’s interests. An elastic definition of the reporting elements to be interchanged between the management service (MnS) producer (responsible for deriving activities for networks and services or other intent(s)) and MnS consumer (The entity consuming an MnS) [28.533] is needed. The Annex A.9 contains a proposal for intent report. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 87 / 155 5.1.9.3 External interfaces The enabler has interfaces with the rest of the architecture components consuming notifications, using information of the other components, offering, and notifying the own data: • Intent Database Notifications: This is the source of the processes associated with the report management. Some of the statuses of each instance of intent are related with the three major reporting processes feasibility, conflict, and fulfilment. The notifications are published and consumed via subscription through the MCEF component. • Intent Database: This component is part of intent translation and provisioning enabler (see Figure 5-3) and stores the information related with the intents supported by the reports and part of the information stored is used for getting complementary information from other components and create the report as desired. • Service Portfolio: When the design of the E2E service is not feasible, based on the information of the intent, the report management could use a process that recommends changes in the intent expectations for achieve a satisfactory request aligned with the capabilities that manage the MnS Producer. Service portfolio stores the offering SLA over services that helps in build the recommendation. • Conflict Coordinator: The enabler intent conflict administrator in subsection 5.1.5 has the responsibility of managing the conflicts that affects the intent management. There are conflicts in the target and expectations of an intent and in the relationships among one intent to another. These internal MnS provider conflict notifications should be consumed by the enabler and then processed and reported to the MnS consumer. The enabler needs access to the close loops environment for getting information in the evaluation of the impact of a conflict. The information stored in the reports database is generated by the enabler so only the query of the report is considered externally. When the report is ready, a notification with the link to the data is sent to the MCEF. The most important aspect of the query call is the kind of filters when a periodic report is used. The specification of the reports and the configuration of how to be consumed could be defined externally using a CRUD interface to include the definition and perform the changes if it is needed. The optional components are not defined in detail, so only a functional interface is included: • Impact analysis: For a defined intent or a set of them, evaluate the impact from different perspectives trying to get a context information for a better decision based on impact. This could be used by other modules for decision making. The interface could be a REST interface with a GET operation for simple calls and a POST for an async that could take time to concrete. • Recommendation: For an intent request with its expectations and targets offer an alternative proposal based on the knowledge context and other internal constraints that could supply. Usually, it will take some time in its analysis, so an async REST interface would be desirable with a POST operation. • Prediction: The functionality of this module could be included in the observability components of each close loop. There are two possible external uses, offer this prediction in a common and centralized point for the close loops getting a better control and governance of the data in the E2E service or the individual predictions of the other components managed by its close loops. The interface again could take some time so a REST interface with a POST operation will be preferred. 5.1.9.4 Workflow The reporting activities have three different scenarios associated with the actions of the intent management: • Feasibility report: Informs about the success or failure of the feasibility action when it is finished. In the case of failure, a recommendation with different expectations could complement the response. When the action has been successfully an expiration date should be included. • Conflict report: Informs about a conflict in the intent definition or execution. If it happens on the definition only one intent is considered (bad combination of target and expectations). In the intent execution the conflict happens when other intents have similar expectations or targets, and the report should be complemented with an impact analysis for a better decision to solve the conflict. • Fulfilment report: Informs about the evaluation of the proposed KPIs in the service to achieve the intent expectations. The evaluation period should be configured. Also summarized monitoring could be included and optionally an estimation of the KPIs. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 88 / 155 Detailed workflows are described in the Annex A.8. 5.1.10 3rd Party services enabler The focus of this enabler is the characterization from the DSP perspective of the following items: • tenants that are going to access to the Hexa-X-II system, capturing the information in the form of a third-party profile, and • service offerings support business with a characterization of assets managed, which will be later linked to tenants according to well-defined SLAs. The service offerings should offer some SLAs (at least onboarding time, deployment time and running KPIs) The agile integration of third-party capabilities and services enrich the product offering to the customers. Complex service delivery tasks where DSP’s own services are integrated with external services and resources become simpler. With the information declared in its components and the updates generated by the running services, it will create a dynamic and optimized design of the service in the service delivery phase. This design will help in the convergence of the services and products offered with the expectation of the end users. It is also in charge of the high-level management of partnership actions with other DSPs in multi domain administrative scenarios. 5.1.10.1 Novelty and maturity The third-party services enabler is a concept used to integrate all the required information from a third party for support a dynamic provision based on intent management. This concept allows a granularity in the interaction of several tenants with the DSPs. The tenant characterization is defined in 3GPP SA5 [28.804], [28.824]. In terms of maturity this enabler is a concept that propose a solution for tenant and service offering characterization. 5.1.10.2 Internal architecture Figure 5-11 Product components. A MnS is a set of offered capabilities for management and orchestration of network and services [28.533]. In the scope of a DSP this management is domain layered, as shown in previous figure, at product or E2E service, service management layer (SML), network management layer (NML) and digital capabilities. In the intent based management, the user defines the desired product (an E2E service that has a value for an end user) and the Hexa-X-II DSP enablers will dynamically design, build, and deploy a set of assets in the SML and NML to achieve the functional and performance requirements. The management components use the lower level (network, resource, or capability layer) for configuring some resources from different domains, technological and administrative connecting them for create a complete relationship among the resources, functionality and performance. The services offered in the DSP architecture need to be characterized in their components and to define which are the relationships and dependencies among them. This definition will make possible a quick design process where new services are built over the composition of more atomic items creating complex services and products in an agile way. When a new service is designed and deployed is offering its functionality to a tenant or an end user with several KPIs. The architectural components need to maintain the desired values of these KPIs (performance, faults, cost, latency, and other indicators) using several techniques of management. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 89 / 155 Figure 5-12 Enabler architecture components. The enabler architecture has two main blocks that define the scope of the high-level components, see Figure 5-12: • the service offering that includes the service characterization with its flavours (SLAs, coverage), relationships with other services and • the ownership and the third-party profile in which the information related with the user is included, the permissions, the trust level in federation scenarios, services contracted and SLAs. The elements included in each third-party profile component could be exposed and consumed for its external management creating complex relationships for new services design. The service offering includes the following components: • Service catalog: Includes the characterization of each service and component. The link among the services and the resources or capabilities are defined in the specialized catalogs of each managed domain. External interactions use queries over specific service definitions or service definitions discovering calls. • Federation management: Accessing to external service components could be reached using federation techniques. Each management domain should be responsible for managing the components of their interest. It is recommended to use a common federation interconnection scheme for a whole administrative entity. • External catalog: Includes the information of external resources/services used to create the service characterization. The catalog translation should understand the external reference and expose it internally for their consumption. All external catalogs should be aggregated in this module. • Catalog translation: Define the transformations needed in the characterization of assets from an external service/resource catalog to include the external assets in the definitions of the DSP’s service catalog. • Alternatives and priorization: Define the different possibilities to explore in the whole catalog including own and external components to be explored in the product design phase and considering prioritization leaded for defined constraints (e.g., business requirements) The third-party profile is responsible for maintaining the information of the linked services that support and order products during the running lifecycle where several administrative domains can interact. It is a supra service inventory that includes the DSP’s proprietary services and capabilities, as well as external ones used for supporting the product: • Service inventory: Based on the characterization of the product designed in the service catalog exposes the defined values for the characterization, the running relationship among the components and the associated SLAs. Some of the elements considered could be from other administrative domain and the translation was made on the service offering components. • External monitor and fault detection: Access to the detailed data of the assets that are owned by other DSP administrative domain and need to be analysed for performance and SLA purposes. • Federation management: Access to the management information of the running instances for the services when third parties are used. • Access control: Manages external access to the exposed internal service management data and manages the access to the other service administrative domains for recovering data derived from management activities. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 96 / 155 These two principles are well-aligned with those identified for security services by ETSI ISG ZSM [ZSM24], as shown in Figure 6-1. [ZSM24] defines a set of security interfaces the project intends to use as foundation, validate and extend as needed. The identification of the specific threats associated with 6G networks, their structuring into threat families, and the corresponding security enablers were made in [HEX223-D22], where specific controls were as well identified in the discussion of the enablers associated to each threat family. This chapter describes in detail those SPR controls, how their validation is being performed or planned, and concludes with an update on the SPR enablers, as associated to the discussed security controls. 6.2 Proposed security, privacy and resilience controls This section introduces the SPR controls on the basis of the analysis performed on the threats and potential safeguards, detection mechanisms, or countermeasures. Each subsection below summarizes the status of the analysis of these controls and proposes, whenever applicable, the corresponding interfaces for their use within the general E2E architecture. 6.2.1 Confidential computing Confidential computing addresses security threats related to the compute infrastructure running telco network functions. The goal of confidential computing is to reduce the trusted computing base (TCB) and to protect workloads from attacks originating from a potentially malicious compute infrastructure. In the context of 6G and (maybe already 5G networks), confidential computing can be applied to protect telecommunication (cloudnative core and RAN) network functions (so called cloud native network functions known as CNFs) in a cloud native environment (which uses e.g., Kubernetes as orchestrator [KUB23]). Thus, confidential computing is especially appropriate, if the network operator and the provider of the compute infrastructure (e.g., a public cloud service provider) are different entities and the network operator does not fully trust the cloud infrastructure. Confidential computing as defined by the confidential compute consortium consists of two components, i.e., running code in a trusted execution environment (TEE) and remote attestation (RA) [CCC23]. A TEE is an isolated environment, which allows the execution of code and handling of data protected from other (potentially malicious) applications even with higher privileges. RA is the ability of a code to prove to external entities that it is not manipulated and indeed running inside a TEE. An architectural approach can be to run entire CNFs in a TEE (see Figure 6-2). The credentials (private key and X.509 certificate) used to protect the traffic between CNFs are provisioned from a key management system (KMS) to the CNFs as part of RA, i.e., a CNF gets credentials only after proving that it is running in a TEE. To minimize the impact on the source code of the CNF, the combined RA and credential provisioning is executed by an init agent, which is independent form a specific CNF, but linked to the CNF and jointly executed with the CNF in the TEE. Container TEE / Attester CNF main() telco functionality} > launch enclave Init Agent > get and mount secrets > launch application KMS / Relying Party Attestation and Provisioning: Provide evidence and securely transfer secrets from KMS to enclave Attestation Server / Verifier Define secrets and access policies Verify evidence Interface to other CNFs using provisioned secrets Operator Figure 6-2 Possible architecture for provisioning of secret into confidential CNFs subject to successful remote attestation. As part of ongoing research work the basic validity of this approach could be verified by small test clouds using open-source 5G core networks [Lee24, OAI24] and open-source key management system [EDG24] and Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 97 / 155 TEE frameworks [Occ24, Gra24, SCO24]. Deployment of a CNF in a TEE including combined provisioning and remote attestation could be achieved for some of the tested TEEs without modifications to the CNFs source code. Others require some modifications since e.g., not all system calls or network protocols (e.g., stream control transmission protocol, SCTP) are supported. Performance impact is visible but not prohibitive, at least for scenarios which require highest security level. Note that the above approach does not address the issue of workload confidentiality. That is, a malicious cloud infrastructure has still access to the CNF executable and could run the CNF in an own environment, e.g., to make use of a proprietary artificial intelligence model embedded in the CNF. To prevent such attacks, images need to be encrypted before sharing with the cloud infrastructure and only decrypted in an attested TEE [COC24]. Further research questions include the analysis and quantification of the performance overhead related to TEEs, analysis of the need for a layer abstracting different approaches to realize TEEs, and the need for standardization of the key management system (as new architecture element) and of the combined attestation and provisioning protocol. In the course of this research the advantages/disadvantages of process-based TEEs (like Intel SGX) and virtual machine-based TEEs (like AMD SEV or Intel TDX) will be compared. 6.2.2 Topology attestation This control is based on the mechanisms for proof of transit (PoT), originally conceived within IETF WG SFC [IETF13]. The PoT approach is intended to validate the paths a flow takes in the network by sharing a small segment of metadata added to each packet. This metadata is updated at each node or service crossed along the path until reaching the end of it. A central controller divides a secret into as many parts as there are nodes participating in the system and sends it through a secure channel, following Shamir’s Secret Sharing Scheme (SSS) [Sha79]. The set of secrets is managed by the controller and applied by the verifying node, which is the last one on the path subject to verification. When the last node receives the PoT data, it compares the received value with its secret to validate whether the packet followed the correct route. To ensure the established order, ordered proof of transit (oPoT) is proposed in [BBM+21], which extends the PoT scheme by adding symmetric masking between nodes. Figure 6-3 Proof of transit (PoT) concept, base for the topology attestation control. Furthermore, [BBM22] defines a specific in-band operational field to include PoT parameters to support path verification, but not the ordered version, and [ALL+19] explores the use of quantum-safe key distribution to provide the masks applied by oPoT. Given that PoT is a data plane-oriented technology, the use of programmable data plane mechanisms constitutes the base tool for their validation and characterization, as well as for identifying patterns for a potential implementation applying hardware-based more efficient features. The evaluation of topology attestation mechanisms is being performed using programming protocolindependent packet processors (P4) [BDG+14], as depicted in Figure 6-3, with a series of P4-enabled nodes, responsible for all the (O)PoT-related logic: adding/removing headers, calculating parameters, and sending Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 98 / 155 metrics. The controller is in charge of configuring the nodes with a P4 program containing the necessary (O)PoT logic, as well as sending parameters for calculations performed in the nodes. The ingress and egress nodes are the two hosts that generate and receive traffic, which is verified by (O)PoT. Finally, a collector whose task is to process the metrics received by the nodes and send them to a database for subsequent analysis. To validate the use and impact of these elements, they are being integrated within different topologies and control planes, and subject to different traffic patterns in an NDT environment that allows the controlled repetition of the defined experiments. The experiments include the identification of the relevant interface to the topology attestation control, specifically connected to the NBI of the PoT controller, and its integration in a more general SDN environment, as well as the support of a direct enabler interface if required. 6.2.3 Anomaly detection in disaggregated environments The RAN architecture is gradually evolving from a closed, unified infrastructure in a conventional RAN to a more open, disaggregated and softwarized one. Despite the advantages coming with this approach, it brings up challenges in terms of managing security and incorporating adaptive security solutions. Digital twin (DT) has greater applicability in guaranteeing the deployment and functioning of a resilient and intelligent disaggregated RAN in 6G. The use of NDT has the potential to facilitate the management of communication resources in wireless networks [HEX2-ARP+24]. NDTs provide new possibilities for safe integration of AI/ ML algorithms into the network management framework as they provide a way to train the utilized models with up-to-date data from the physical networks, as well as to test the consequences of the resulting network management decisions outside the actual production network environment. This enables the identification of potential network disruptions and anomalies, and leveraging data collected to train ML models for anomaly detection and can be utilized in disaggregated RAN architectures. Disaggregated RAN architectures provide flexibility and scalability but introduce challenges in managing and securing diverse components. For instance, the disaggregated architectural impacts can be identified with respect to distributed data handling and hierarchical architectures for data processing. Anomaly detection becomes paramount in ensuring the integrity and optimal performance of the network. In the disaggregated RAN scenarios, the application of FL is one approach for enhancing anomaly detection capabilities by allowing distributed model training across edge devices. This approach takes the advantage of the distributed nature of disaggregated RAN components, allowing for collaborative model training without the need for centralized data collection. An evaluation of an FL-based anomaly detection use case was conducted, aligning with the reference architecture of disaggregated RAN (see Figure 6-4). Initially, federated client models within disaggregated RAN nodes are trained using locally available data, and model vectors are communicated to the relevant firstlevel aggregators hosted in RAN intelligent controllers (RICs). Following aggregation, the calculated aggregator model vector is sent back to each local trainer in the same cluster, making the completion of a cluster round. After a predefined number of cluster rounds, first-level aggregators transmit their model vectors to the second-level aggregator located in a centralized RIC. Subsequently, the global aggregator averages the received models and transmits the global model vector back to all federated clients, concluding one FL global round. The goal is to detect malicious UEs that are distributed across the network and to identify the slice type based on the performance indicators generated at the gNB per UE. For this use case, the NDT security data collector can be used as a trusted data source for FL model training. Moreover, model training is conducted in a federated manner to avoid performance degradation since ML models trained centrally would lose performance when deployed in an actual distributed environment. Besides, using NDT, malicious data can be generated. In the next deliverable D2.4, it is planned to provide further results obtained from this experiment obtained by emulating the scenario. The preliminary results with the testbed set up are also presented in [HEX2-RAP+24]. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 99 / 155 Figure 6-4 Logical experimental setup considered for FL-based anomaly detection in disaggregated RAN architecture. 6.2.4 Support for secure and privacy-enhanced machine learning The primary threats to network availability come from denial of service (DoS) and distributed denial of service (DDoS) attacks [HEX2-FTA23]. These threats overload the targeted online service with false data, making it tough for authorized users to use the service. To detect and prevent DDoS attacks, intrusion detection systems (IDS) are employed. These systems play a critical role in monitoring network activity and identifying suspicious behaviour that may indicate a potential DDoS attack. Advancements in AI and ML have enhanced the capabilities of IDS in detecting anomalies resulting from DDoS attacks. However, while the integration of ML methods can improve DDoS detection, their susceptibility to adversarial attacks may introduce new vulnerabilities, potentially allowing attackers to circumvent defence mechanisms. Various approaches have been investigated in the literature to strengthen IDS systems against such adversarial threats [AKN+19, NNA21]. Nonetheless, current solutions require integration during the training phase and direct application within the ML model used by the IDS. This makes the pre-trained models susceptible to analysis by attackers, who can then adjust their strategies to exploit the weaknesses of the model. Additionally, a significant portion of these solutions overlook the features targeted during the attacks themselves, neglecting to consider the specific attributes of the attack vectors. A solution based on improving IDS to increase its protection against DDoS attacks that use adversarial approaches to avoid detection is proposed. eXplainable AI (XAI) to identify certain features changed by attackers, identifying altered network traffic intended to mislead the IDS is used. In addition to optimizing IDS performance, this approach also improves the trustworthiness of the IDS. The suggested solution consists of three modules as illustrated in Figure 6-5. Feature engineering module: traffic data is collected and aggregated into a single dataset. The module then preprocesses the data to extract relevant features, which the detection module will use to identify DDoS traffic. Intrusion detection module: MLbased DDoS attack detection model is trained on pre-processed network data. During run-time, the detection module examines network data using the updated feature sets to identify and raise an anomaly warning indicating the kind of attack. Our novelty appears in the adversarial detection module; in run-time, the XAIbased adversarial attack detection module gives interpretable explanations for the network data that was preprocessed in the feature engineering module, as well as the decisions of the ML-based DDoS attack detection model. The adversarial detection module then determines if an adversarial attack exists by comparing the topk important features of two different explanations. If this occurs, the system notifies the intrusion detection module to alter the policy for feature selection and extraction to have the most discriminative feature set for detecting DDoS attacks. This way the system will be developing the ability to adapt and optimize its reactions in real time, eliminating the need for human involvement. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 100 / 155 Figure 6-5 Adversarial Attack Detection by Using XAI on the DDoS Attack Detection Example. Enhancing Security and Privacy Simultaneously in Federated Learning FL is a privacy-aware collaborative ML technique where the clients execute local training and send the local model updates to the server. Although the local training data is not sent to the server, the local model updates may leak some information [NSH19]. To prevent information leakage, secure aggregation is proposed [MOJ+23]. Also, the security of FL process should be addressed because the clients can try to disturb the training of global ML model by performing some poisoning attacks. To prevent such attacks, the server should analyse the local model updates. However, usage of secure aggregation prevents the server from performing such analysis. Thus, it is a challenge to provide both privacy and security simultaneously. There are some solutions [KOB21, KKC+23, RSW+22] addressing this problem, but they generally need to use additional heavy cryptographic operations, peer-to-peer communication topology, or two or more non-colluding servers. We propose a lightweight solution based on partial secure aggregation. With this approach, the server can only access some pieces of the local model updates, which allows the server to perform security analysis and prevents sensitive data leakage. The clients should not be able to learn which pieces of the local model updates will be sent in cleartext in advance, otherwise they can try to poison only the hidden parts. Thus, the clients should first send the whole local model updates in an encrypted format and then the server should choose randomly which parts to be opened. Then the clients should send the requested local model update pieces in cleartext with required parameters for the server to perform the encryption operation and to check if the computed encryption result equals to the received encryption result. Some preliminary experiments were performed to validate if this approach helps to prevent data leakage and poisoning attacks. The privacy attack in [ZLH19], where the attacker uses the publicly shared gradients during collaborative learning to obtain the private training data, was applied. The value of the gradients for the hidden part of the local model updates to were changed to ‘0’ value and it was observed that the attack does not work, and so the attacker will not be able to construct the private training data. For the poisoning attacks, the setup with nine honest clients and one malicious client who adds noise in gaussian distribution to its local model update was simulated. The server performed the anomaly detection on the opened local model update pieces by checking the distance between each client local model update pieces. It was observed that the distance was easily distinguished for the malicious client’s local model update pieces. Regarding communication and computation overhead, the proposed solution duplicates the number of rounds required for synchronization, and the server needs to execute encryption operation for the opened local model update pieces. When compared with other security and privacy enhanced FL solutions, it can be observed that this partial secure aggregation solution is more promising especially in mobile communication setting because it does not require non-colluding servers, peerto-peer communication, heavy additional cryptographic operations, and it provides a kind of framework (i.e., it is independent of the secure aggregation schemes). 6.2.5 Facilitating crypto transition Implementations of post-quantum cryptography (PQC) primitives includes a wide variety of rapidly evolving software, including several versions of reference and optimized implementations. This evolving ecosystem is Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 101 / 155 being integrated in widespread security libraries. An exemplar approach for this integration is liboqs [OQS22], and the different forks of open secure sockets layer (OpenSSL) addressing PQC and PQC/traditional hybrid schemes with promising results. Key hybridization, combination and derivation have been active cryptographic research lines to enhance crypto primitives for years. Among the current transition strategies to quantumresistant cryptography, a relevant trend is to explore the combination of PQC with the information theoretically secure quantum key distribution (QKD) key exchange. Additionally, in an elastic, cloud-native software infrastructure, • it is necessary to rely on adaptive key distribution mechanisms; • it should be able to address different operational conditions and to provide the adaptability required by the long transitional periods implied in telco infrastructure economic lifecycles; • it should be becoming able to support the essential goals of agility (i.e., incorporating new mechanisms as they evolve) and pliability (i.e., integrating the new crypto primitives with well-established management principles). The 6G network is the first network architecture being devised under these new considerations on cryptographic functionality, and therefore is of the utmost importance to evaluate the architectural, functional and performance implications of the crypto transition. With this evaluation, it will be possible to establish an E2E security architecture that addresses the quantum-resistance challenges with little or no impact on network features. Ongoing experiments explore the transition to PQC through modules loadable at run-time, allowing to plug new PQC algorithms, schemes, and protocols in the existing software ecosystem, keeping a consistent interface with current software. Regarding the hybridization approach, the goal is to explore the building of a Universal Quantum-Secure Key Distribution layer made of hybridizing QKD and PQC to secure IPSec and other secure communication protocols, using as base recent key distribution interfaces as [QKD19] and [QKD20], as well as initiatives like the new symmetric key exchange (SKEX) proposal within the IETF. 6.2.6 Evolved LoTAF Based on the proposal originally formulated in the Hexa-X project [HEX23-D13], work in defining and evaluating a level of trust (LoT) assessment function (LoTAF) has continued in Hexa-X-II. Following the trust lifecycle shown in the Figure 6-6 below, the LoTAF control and its associated enabler, is intended to incorporate functionality to ensure a continuous LoT evaluation. The LoTAF is going to take advantage of an NDT framework [RRM+23] that monitors and shapes raw data deploying external components such as a cloud continuum emulator and/or virtual replicas of mobile communication network functions. To bridge the gap between LoTAF and the NDT, the former is continuously collecting and analysing its objective trust indicators from NDT, forming a knowledge graph between the trustor and the trustee, by making use of graph queries to identify relevant patterns or series of changes in the graph that may impact the LoT, keeping track of real-time events and shifts in telemetry values, according to the lifecycle depicted in Figure 6-6. Figure 6-6 Trust life-cycle phases following the guidelines in [ITU21]. When it comes to trust analytics, the first step is to analyse and evaluate the LoT of other suppliers in which the user (trustor) has an interest. At this point, the LoTAF plays the role to bridge the gap between assurance and trust. Therefore, LoTAF takes into consideration both objective trust indicators, which are strictly defined Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 102 / 155 and straightforwardly measured, and subjective trust indicators, which come from indirect/social trust or reputation influenced by third parties. When it comes to objective trust indicators, they judge only unbiased attributes without the intervention of trustor’s opinions, views, experiences, or attitudes. Considering a cloud continuum scenario, LoTAF contemplates objective trust indicators (first-hand information), such as stability, reliability, scalability, integrity, availability, or credibility. On the other side, subjective trust indicators (second-hand information) are usually non-technical attributes but rather personal feedback, attitudes, or perspectives. Therefore, LoTAF considers characteristics such as reputation or personal experience entail stakeholder attention. 6.2.7 Context awareness for physical layer security The effectiveness and secrecy rate of secret key generation (SKG) methods based on physical layer security (PLS) heavily depends on the specific characteristics of the wireless channel at the moment in time the PLSbased key generation is executed. Therefore, such algorithms must be context aware to adapt their parameters and provided properties based on the environment. The overall goal is to provide algorithms which implement context awareness for PLS-based SKG scheme for 6G networks. In an earlier measurement campaign conducted to implement the SKG protocol in the presence of eavesdropper [HEX2-MMC+23], it was found out that the SKG rates are highly dependent on the multipath channel. The channel characteristics such as LoS, non-LoS, and mobility affect the SKG rates. In addition to this, the correlation of the observations at the eavesdropper also plays an important role in the information leaked and hence the achievable SKG rates. In order to securely implement the protocol, the worst-case scenario in terms of leakage to the eavesdropper needs to be identified and this information must be compressed in order to guarantee the confidentiality of the generated keys. Context aware security can help in achieving higher SKG rates rather than the traditional SKG implementation. Since the SKG rates depend on the randomness of the observed data in the environment, identifying the context i.e., the channel environment is crucial in this regard. The following steps are envisioned as part of context aware PLS demonstrator for SKG. • Identify classes of environments with set values of SKG parameters: Here, the environment will be classified into LoS, non-LoS etc. and the worst-case scenario in terms of leakage will be identified. Based on this, the appropriate parameters for the SKG protocol will be identified and stored. • Identify during operation which class corresponds to the environment: Based on channel impulse response, received signal strength, etc., the class of the environment will be identified during the signal exchange phase. Using this information, the keys will be generated using the corresponding design parameters. • Demonstrator for Hexa-X-II: We envision to create a demonstrator using Universal Software Radio Peripherals (USRPs) as legitimate users and eavesdropper. This demonstrator will allow to influence the environment and observe the adaption of the PLS-based SKG algorithm. 6.2.8 DTand ML-enabled physical layer anomaly detection Wireless communication is based on an open medium, making it vulnerable to interference which can degrade the performance of the communications system. This might have particularly severe consequences for the critical use cases that are anticipated for 6G, such as mobile robotics or human-machine cooperation. Thus, it is essential to detect such interference, no matter whether it is intentional (jamming) or unintentional. We consider unexpected signal interference as radio frequency spectrum anomaly and propose in the following a DT of the radio environment to detect such anomalies. The objective is to develop a general (i.e., not bound to certain anomaly type such as a specific jammer type) yet sensitive detection framework. Hereby, the DT serves as an enabler for integrating contextual awareness in the anomaly detection process instead of purely using spectrograms as input for the anomaly detection. Due to the examined use case, we focus on a DT of the radio environment, which comprises the physical environment as well as transmitters and the propagation characteristics. DTs are seen as enabler for a variety of use cases in 6G, e.g., monitoring or data generation for training ML models. More comprehensive, multi- Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 103 / 155 purpose DTs are discussed in the literature as well. However, for the scope of current research the focus is only on use case-relevant aspects. Yet, an integration of the use case into a multi-purpose DT seems reasonable in the future. Figure 6-7 System architecture for a DT of the radio environment to enhance spectrum anomaly detection [KKS+23]. To discuss the required interfaces, first the proposed system architecture, depicted in Figure 6-7 is introduced. The physical twin (PT) represents the real-world system with regular transmitters and potentially also jammers or other anomaly sources present. Moreover, sensing units (SUs) collect data samples for the comparison between the PT and the DT. The sensing task can also be taken over by the base station, but a denser sensing network typically leads to significant detection performance improvements. A CU is bundling all information and running the DT. That information is: • Positions of regular transmitters: They are assumed to be accurately known in a 6G system. However, we do not focus on the specific localization technology, but assume this to be known, only impaired by a random localization error. • Information on the physical environment: Those are for instance the location and material of walls, machinery, etc. and are required for propagation modelling. That information could originate from cameras, lidar, etc., but in the future also from JCAS. • Information on the radio resource management (RRM): The CU has information available on the resource allocation in the cellular system, i.e., which UE or BS is allowed to transmit at which time in which resource block. • Information from the SUs on the spectrum usage: To be able to compare between the DT and PT, the SUs provides information to the CU on the spectrum occupation. This could be for example spectrograms, but in a simpler approach also just received signal strength (RSS) values in the monitored band. The general idea is that the transmitter locations as well as the physical environment are known. With this, ray tracing can be run to estimate the RSS values at SUs. As has been shown in the literature, ray tracing can be substituted by ML models trained on ray tracing data to reduce the computational complexity tremendously [BQZ+22]. If there is an unexpected deviation between the actually measured RSS values and the RSS values expected from the DT, an anomaly is presumed. As the DT will never be a perfect replication of the PT, the challenge is to differentiate whether observed deviations between measured and expected RSS values originate from model inaccuracies or if there is an additional device transmitting a signal which is not expected. Unsupervised ML methods seem to be a promising solution for this challenge, as they allow to generalize from normal samples to identify deviations that differ in their characteristics. Moreover, supervised ML methods can be integrated in the framework for instance for jammer classification. If they are trained carefully, they typically offer a high sensitivity to known jammer types. In addition, if the jammer type can be determined and potential further features can be extracted (e.g., the jammed subcarriers), that information can be used to tailor suitable countermeasures. Note, that the proposed system is intended for application in small-scale Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 104 / 155 networks in a licensed band, particularly non-public networks (NPNs), as there all regular transmitters should be known by the cellular system. This listing of required information above allows to discuss the interfaces that are required. Hereby, the following necessary interfaces are identified: • Interface to the RRM: For an accurate representation the information about which device is allowed to transmit when and on which frequency resources is essential. • Interface to the localization entity: For executing ray tracing, the information on localized transmitters needs to be accessible. • Interface to the JCAS entity: If JCAS is used to build the model of the physical environment, that information also needs to be accessed. Between the SUs and the CU, we assume a wired connection which does not need to belong to the 6G system. A wired connection offers the advantage that the information flow can be maintained even under severe jamming attacks. As the research on the proposed system is in a rather early stage, further investigations on the design / mapping of the interfaces are required. Considering O-RAN, one reasonable approach from initial investigations seems to implement an xApp which serves as a gateway between the low-level information from the RAN and the CU. 6.2.9 A threat analysis for JCAS Architecture considered for threat analysis: Aligning with the architectural concepts outlined in [WGM+23], [Hua23], [PJA+23], [BQZ+23], the emergent JCAS architecture depicted in Figure 6-8 is used for threat analysis. The detailed interfaces and the threat analysis are specified in [HEX2-DUN+24]. On the network side, the following sensing-specific functions are considered: sensing processing function (SPF), sensing control function (SCF), sensing policy, consent and transparency management (SPCTM). In addition to sensing-specific functions, there is a sensing store that stores sensing specific data, logs and policies in the network. The network exposure function brings the network capabilities to the applications and serves the sensing requests. The sensing unit (SU) can be independent (e.g., at the gNB) or part of the UE, which transmits the signals to the targets and then captures the reflecting signals from them. The third-party data may be considered during the sensing processing sessions, and based on requirements, the disclosure/transparency data may be sent to third parties. Figure 6-8 JCAS architecture considered for threat analysis. Trust domains: Based on the ownership, roles, responsibilities, and access requirements, different trust boundaries are defined in the considered JCAS architecture. The trust boundaries separate the architecture into following trust domains: Application, third party, target, SU, UE(SU), and network components. Moreover, as the network components might be administered by different entities, we also examine the interfaces between the sensing functions in our threat analysis. Threat analysis: Both STRIDE [MS06] and LINDDUN [MKR+11] models have been considered for security and privacy threat analysis. The STRIDE model focuses on the security threats that could be exploited by adversaries to compromise confidentiality, integrity, or availability. On the other hand, the LINDDUN model Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 105 / 155 aims to understand the potential privacy implications of dealing with personally identifiable information (PII) during data processing activities, including data collection, storage, use, transfer, and disposal. Due to the inclusion of some common threats in both threat models, the following are selected for the threat analysis: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, linkability, identifiability, unawareness, and non-compliance. For threat analysis, the low-level data flow diagrams (DFD) have been designed to comprise more details about the processes, control and data flows, and interactions. Based on the detailed DFDs and the trust domains of the entities, an initial threat analysis has been completed. For each interface, a list of threats has been compiled. The threat analysis also considered the interfaces between different processes and inside the network. In the next steps, more fine-grained threat analysis with detailed risks and vulnerabilities shall be conducted. Design of security and privacy controls: Based on detailed threat assessment, the security and privacy controls shall be designed while adhering to the key principles defined in the standards. The security controls are to be designed in the interest of safeguarding the confidentiality, integrity, and availability of information. During the design of privacy controls, the entities need to be defined based on their role in possessing, storing, or processing PIIs. Then, in different layers (privacy settings layer, identity and access management layer, PII layer), different privacy controls will be devised while specifying which control is essential for which functionality. 6.2.10 Deception techniques for physical security The technique of physical layer deception (PLD) aims at addressing the inherited challenge of defending against eavesdropping in wireless systems, i.e., eavesdroppers can easily pry into the channel with a low cost and barely any risk (e.g., of being detected). Leveraging the superiority of legitimate channels over eavesdropping channels, it enables to deceive the eavesdroppers with falsified information, and therewith raise the risk of eavesdropping in two possible ways: 1) on the user plane, the deceptive information can be falsified in particular ways to cause direct loss of interest to the eavesdroppers, 2) on the control plane, the radio interface protocol can be designed in such a way, that the eavesdroppers can be deceived by the falsified information to expose itself. A pioneering design of the PLD approach is illustrated in the Figure 6-9 below, where for each individual message p, a random key k is independently selected to cipher the message [HEX2-HZS+23]. The ciphertext m is then non-orthogonally multiplexed with k in the power domain and jointly transmitted. The key length and the power mixing ratio PM/PK are jointly optimized, so that the key k is protected from eavesdropping via PLS, and the ciphertext m intentionally exposed. While the legitimate user can decode both m and k through successive interference cancellation (SIC), the eavesdropper is likely failing to obtain k but can only obtain m. With such proper design of the cipher, that m and p share the same feasible codeword set, the eavesdropper will be deceived to take the ciphertext as the original message. Furthermore, this deceptive approach shall be randomly applied on only part of the messages, so that the eavesdropper is eliminated from exploiting the knowledge of this mechanism for any insight (e.g., excluding m from the possible p), even when the design is a common knowledge. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 112 / 155 Dependency on other Enablers An enabler might have a dependency on other enablers which are being explored across the Hexa-X-II project or other SNS-JU projects. Existence of standard Interfaces The enablers, which have dependency on each other, may or may not have readily available standardized interfaces. Use case applicability The use cases (established in the Hexa-X-II deliverable D1.2 [HEX23D12]) to which the enabler is applicable. Fulfilment of design principles The design principles that a given enabler fulfils. Note that the detailed level of enablers’ impact on the functional and technical requirements discussed in Section 2 are not considered in this iteration of the analysis. In particular with respect to methodology described in Section 7.1, required and provisioned KPI and KVI and network statistics are not available at this stage. Consequently, it does not provision any details on the compliance/impact of the 6G E2E system on the sustainability pillars as they require further evaluation with PoCs and simulations. With this background, the meta-data values for all the recommended enablers were collected. For the sake of brevity, these collected values have been represented in Table 7-2 for a subset of 6 enablers. A more detailed version of the meta-data collection is provided in [JOK+24]. 7.3 Implementation of selection methodology with practical considerations Based on the metadata values provided, the methodology described in Section 7.1 is used to construct the full knowledge graph as shown below in Figure 7-2. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 113 / 155 Table 7-2 Meta-data values for Enablers Enabler name Recommendation based on prioritization High-level functionality Maturity (TRL level) Standards requirements Relevance to migration Additional hardware requirements Dependency on other enablers Requires new interfaces Applicable use cases * Design principles addressed Data recovery mechanisms High Optimizations of retransmission schemes TRL 2 Yes No No No No 1,2,3,4,5,6 5 Ciphering & Integrity Protection High Enhance the ciphering and integrity protection TRL 2 Yes No Not sure, to be determined No No 1,2,3,4,5,6 4,6 Intelligent transmitter and receiver High Signal processing functions TRL 6 Yes No No MLOps No 1,2,3,4,5,6 N/A Intelligent receiver High Receiver related algorithms TRL 6 No No No MLOps No 1,2,3,4,5,6 N/A 6G network modularisation High Network functions layer, might also have limited impact on Pervasive functionalities TRL 1 Yes Yes No No No 1,2,3,4,5,6 3,4,5,6,7,8,9 MLOps High Pervasive functionalities - AI Framework TRL 2 Yes No No DataOps, AIaaS, arch. means & protocols No 1,2,3,4,5,6 2,3,6,10 * 1-Seamless Immersive Reality, 2-Cooperating Mobile Robots, 3-Network-Assisted Mobility, 4-Realtime Digital Twin, 5-Human-Centric Services, 6-Ubiquitous Network Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 114 / 155 Figure 7-2 Full noisy knowledge graph with red nodes representing use cases, green nodes representing design principles and the blue nodes representing the recommended enablers, with the edges depicting their dependencies. From Figure 7-2, the full KG, consisting of all enablers recommended in Chapters 3, 4, 5 and 6, use cases, design principles and their linkages, is quite noisy as it consists of enablers that are not yet selected. Subsequently, we prune the graph by utilizing priority, maturity, and the ability to satisfy design principles and support as many use cases as possible. Note that, in this iteration, we do not perform the functionalitybased clustering step shown in Figure 7-1. The enabler functionalities, even if similar as described in the metadata, will vary depending on the context such as the enabler domain (e.g., RAN, core etc), the layers where the enabler is active (infrastructure, network function, application, etc.) or the involved protocol layers (e.g., PDCP, MAC layers), the type of UEs, the mobility, etc. For example, consider the enablers intelligent transmitter, intelligent receiver, and intelligent transmitter & receiver. All three of these enablers reside at the RAN physical layer. Moreover, their high-level functionality, as stated in [JOK+24], is signal processing functions and receiver related algorithms. Note that, while they could be clustered into a single enabler based on their functionality and the layer location, each of them performs a significantly different task. Specifically, while intelligent transmitter provisions AI-based signal processing functionality for the transmitter side, the intelligent receiver offers the same for the receiver side. Moreover, the training of the intelligent transmitter and receiver is done differently, i.e., the transmitter and receiver are independently trained. On the other hand, the intelligent transmitter and receiver offer the joint functionality of the intelligent transmitter and intelligent receiver. However, the training of the transmit and receive ends/sides is done jointly. Hence, given that similar differences between other enablers also exist, we defer the clustering analysis to the next iteration of the 6G E2E blueprint. The pruning of the NG is performed by setting the parameters for pruning as presented in Table 7-3. Specifically, the priority threshold is set to 1, wherein 1 signifies High priority. Additionally, the maturity threshold is set to 3, wherein initially all enablers with maturity level greater than 3 are selected. Next, enablers with High priority and a high value of edge connectivity are selected. The edge connectivity parameter specifies the cumulative sum of the edge weights. Such a measure allows for selecting enablers that have existing interfaces towards other inter-dependent enablers as well as those that are applicable to the most use cases and fulfil the most design principles. Note that, a value above 10 for edge connectivity, i.e., cumulative sum of edge weights for a given enabler (node in the KG), was observed to be fulfilling the design principles as well as catering to all set of use cases. It also provides a system that is sparse in terms of the number of enablers that are needed for fulfilling the design principles as well as serving all the use cases. On the other hand, it must be stated here that since the KPI and KVI related values were not available at the time of the analysis, for the sake of simplicity of analysis the value for the edge connectivity parameter needed to be chosen using a slightly ad-hoc approach. Hence a threshold of 10 was selected for the edge connectivity Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 115 / 155 parameter. However, in the subsequent iterations when these details are available a more specific heuristic shall be developed and utilized to define the value of the edge connectivity parameter. Table 7-3 Graph Pruning Parameters Parameter Value Priority 1 Maturity >3 Edge connectivity >10 After pruning we obtain a subset of 27 enablers from a superset of 52 enablers that are rated as High on priority [JOK+24]. These selected enablers are listed in Table 7-4 and the corresponding pruned knowledge graph is presented in Figure 7-3. Figure 7-3 Pruned knowledge graph for enabler selection. Table 7-4 Selected Enablers by utilizing KG method Category Enabler Name Service Exposure Management capabilities exposure framework Beyond communication services AIaaS 6G network functions modularization & E2E design 6G Network modularisation E2E service design in modular 6G Flexible radio integration & protocols Modular RRC Interaction with Application layer Application-NW interaction for service differentiation and QoS/QoE management Intelligent radio interface Intelligent transmitter Intelligent receiver Intelligent transmitter and receiver Spectrum sharing, coexistence Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 116 / 155 RIS system integration New devices Identification of 3 new 6G device classes (RHDRBL, HRLL, EN) Intent-based management Intent Translation & Provisioning Multi-platform orchestration Multi-agent systems for multi-cluster orchestration Decentralised Orchestration system Cloud continuum integration Integration and orchestration of extreme edge resources in the computing continuum Closed loop control Real-time Zero-touch control loops automation and coordination system AI/ML-based control algorithms for sustainability. Security & privacy controls (pervasive functionalities) Confidential Network Deployment Quantum-Safe Cryptography LoTAF Trustworthy AI AI framework MLOps Architectural means and protocols Data framework Monitoring and Telemetry Framework Data fusion mechanisms based on telemetry data DataOps Note that, given this selection, it was observed that certain enablers that will be essential towards the initial/first release 6G E2E system have not been selected due to the selection criteria. Specifically, enablers that ensure the smooth migration from 5G towards 6G alongside the beyond communication services, such as sensing and localization, due to their low TRL level and/or lack of dependency on other enablers [JOK+24] were not selected by the KG method. Moreover, the overarching enabler for security and privacy that considers other aspects of security and privacy (e.g., JCAS security and privacy) beyond the selected trustworthy AI, LoTAF, confidential network deployment and quantum safe cryptography, was also not selected due to the lower TRL provided in [JOK+24]. Additionally, multi-cloud/multi-domain federation and federated orchestration system, which are important enablers for management and orchestration from multiple clouds/domains, were not selected as they have TRL 3 and low edge-connectivity value. Network digital twin creation mechanisms which enable more robust zero touch closed loop management through reconfigurations on the digital twin before deciding on the most apt deployment strategy on the real network, was not selected as it has TRL 2. Next, enablers such as radio protocols for beyond communication and separation of IDLE mode and CONNECTED mode signalling, which are important enablers for efficient radio protocol implementation and beyond communication functions, were not selected as they are at TRL 2. This applies similarly to enablers related to mobility procedure, such as data-driven mobility and computation aware mobility. Furthermore, JCAS waveforms and frame structures and JCAS resource allocation, which are important aspects for layer-1 and layer-2 operations of the JACS in the radio access network, were not selected due to the prioritization being at “Medium” and a TRL 2, respectively. Lastly, JCAS related enablers, such as JCAS security and privacy as well as the sensing protocols and signaling, were not included as they are at TRL 2. However, given their importance from a technical and operational perspective for the 6G E2E system (c.f. Chapter 2), it is proposed to add the following enablers as part of the pragmatic considerations: Chapter 3 on architecture enablers: • Network migration Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 117 / 155 • Network of networks • Multi-connectivity • Compute protocols, signalling and procedures • Multi-domain/multi-cloud federation Chapter 4 on radio interface and protocol enablers: • Flat RRC design • Radio processing units for user plane • Ciphering and integrity protection • Data recovery mechanisms • SDAP (radio) protocols for beyond communication services • Separation of IDLE mode and CONNECTED mode signalling • Data driven mobility • Computation aware mobility • JCAS protocols, signalling and procedures • JCAS waveforms and frame structures, • JCAS resource allocation Chapter 5 on management and orchestration enablers: • Federated orchestration system • Network Digital Twin Chapter 6 on security, privacy and resilience • JCAS security and privacy Moreover, given that other reconfigurable intelligent surfaces (RIS) related enablers, such as RIS assisted transmission and RIS hardware, have a priority of medium to low, the RIS system integration enabler, which is selected by the KG method and listed in Table 7-4, is de-prioritized for this iteration of the 6G E2E system blueprint. Consequently, via Table 7-5, we present the final list of selected enablers after utilizing a combination of the KG method and pragmatic considerations. Note that there is an order in presenting the category, i.e., physical layer, radio protocol layer, architecture, M&O, and security. Table 7-5 Updated list of selected enablers after the pragmatic considerations. Category Enabler Name Intelligent radio interface Intelligent transmitter Intelligent receiver Intelligent transmitter and receiver Spectrum sharing, coexistence JCAS PHY JCAS waveforms and frame structures JCAS resource allocation New devices Identification of 3 new 6G device classes (RHDRBL, HRLL, EN) Flexible radio interface and protocol Modular RRC Flat RRC design Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 118 / 155 Separation of IDLE mode and CONNECTED mode signalling Ciphering & integrity protection Data recovery mechanisms SDAP protocol for beyond communication services Radio processing units for user plane Mobility procedure Data driven mobility Computation aware mobility Interaction with Application layer Application-NW interaction for service differentiation and QoS/QoE management Smooth path from 5G Network migration 6G network functions modularization & E2E design 6G Network modularisation E2E service design in modular 6G New access and flexible topologies Multi-connectivity Network of networks Cloud continuum integration Multi-domain/multi-cloud federation Integration and orchestration of extreme edge resources in the computing continuum Beyond communication services AIaaS JCAS protocols, signalling and procedures Compute protocols, signalling and procedures AI framework MLOps Architectural means and protocols Data framework Monitoring and telemetry framework Data fusion mechanisms based on telemetry data DataOps Service Exposure Management capabilities exposure framework Intent-based management Intent translation & provisioning Synergetic orchestration Multi-agent systems multi-cluster orchestration Decentralised orchestration system Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 119 / 155 Federated orchestration system Closed loop control Real-time zero-touch control loops automation and coordination system AI/ML-based control algorithms for sustainability. Network digital twin Network digital twin creation mechanisms Security & privacy controls (pervasive functionalities) Confidential network deployment Quantum-safe cryptography LoTAF JCAS security and privacy Trustworthy AI 7.4 System blueprint refinement 7.4.1 Updates to the 6G E2E system blueprint Figure 7-4 Updated 6G E2E system blueprint. An updated version of the E2E system blueprint introduced in [HEX223-D22] is presented in Figure 7-4. It reflects the progress of work on the various individual enablers and how they are interacting in the E2E system. It includes the following updates: - The network centric application layer is renamed application enablement platform layer to better capture its nature. This layer is devoted to act as a catalyst for new use cases by providing applications an easy access to the full range of 6G capabilities to build upon to enrich their applications. As such, it is the main access to the services of the 6G system as a platform which is controlled by the service exposure that has Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 120 / 155 been newly introduced and is detailed later. As defined in [HEX223-D21] and [HEX223-D22], the APIs box represents the abstracted APIs from the network and M&O services providing a further abstraction level to simplify their use for non-experts and augmented with additional services from e.g., the network applications, that can be leveraged by the developer of the applications of the application layer. In addition, aggregation of services, i.e., the action to compose services from a set of capabilities of different 6G service providers, e.g., over multiple networks, is also provisioned in this layer. - More details have been provided for the 6G beyond communications functions in the network functions layer. The blueprint now depicts the functionalities to realize such new services expanding beyond the communication capabilities as follow: o SeMF responsible for facilitating an efficient coordination of sensing procedures, considering various aspects such as sensing requirements, sensing capabilities, sensing constraints, etc. o AIaaS functions (AIaaSF) responsible for providing accessible AI capabilities as pre-built AI models, datasets, algorithms, and tools into applications, thereby eliminating the need for application developers to build and manage their AI infrastructure. The AIaaS functions are exposing AIaaS APIs via the service exposure box toward application and network. The innetwork exposure supports any other functions in the RAN, core, beyond communication and management for heterogeneous AI/ML techniques and services. It is worth emphasizing that AIaaS is built upon the set of the AI and data collection frameworks of the pervasive functionalities, integrating with e.g., MLOps and DataOps in this set. o The dots are representing other 6G beyond communication functions that would possibly be defined in the future steps. - The 6G core network function box in the network functions layer has been redrawn to better capture that the 6G CN functions will be an extension of 5G CN instead of a subset. - How to expose resulting data and relevant service capabilities in a secure, privacy-preserving, and efficient manner is crucial for the 6G network platform. This motivates the representation of a service exposure framework into various white boxes at the infrastructure layer, the network functions layer, the application enablement platform layer, as well as in the M&O box. The service exposure exposes service APIs to external entities (e.g., other services, application developers, network service developers, service providers, etc.). It provides the necessary means for service APIs discovery, secured access control and enforcement. It’s worth emphasizing that service in the service APIs is used in the broadest sense of the term and encompasses data, resource, and control. It is represented at the different layers of the system blueprint as follows: o Service exposure of the infrastructure layer provides accessibilities to data, resources, and controls from the network infrastructure and from the compute continuum. The latter could also provide CaaS to the application enablement platform layer and the application layer. o Service exposure of the network functions layer provides accessibilities to data, services, and controls of both communications and beyond communications capabilities to application developers and verticals customers. o Service exposure of the M&O provides accessibilities to operations services via APIs or intentbased APIs. o Service exposure of the application enablement platform layer is to expose the above sets of APIs with a further abstraction level (simplified for non-experts) augmented with additional services from e.g., the network applications. Furthermore, it provides accessibilities to APIs of services aggregated from different stakeholders (e.g., operators, third party network application providers) for the needs of the end-user applications. - The pervasive functionalities have been revisited from the perspective of their scope. They are no longer shown to be in direct control (represented by the bold dotted vertical line) on or by the application layer but interact via service exposure of each layer. In particular, the perimeter of the M&O is limited to the assets of the 6G platform. As such, it includes the management and orchestration of the infrastructure (network and compute continuum), the network functions and services, as well as the network applications, so called as they are centred on network capabilities or under network operator control to provide enriched services to vertical applications. It does not include direct control of the components of the applications from third parties (OTT applications). - Based on the recommendations on Hexa-X-II enablers in Chapter 3 and 6 and on the further down selection made in Section 7.2, it emerges the importance of enablers for the 6G system of a unified management Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 121 / 155 and orchestration of network services and network applications over a cloud continuum across multiple domains, owned and administered by different stakeholders, and characterized by underlying heterogeneous technologies platforms. Hence, such a functionality has been integrated and represented by the multi-platform orchestration box inside the M&O block. - Similarly, the recommendations related to M&O enablers make strong emphasis on the (possibly AI/ML based) closed loop controls as essential for an increasing level of M&O automation toward autonomy in the 6G network operations. This has been reflected by the new closed loop control box that support and complete the already represented intent based management (IBM) box inside the M&O. - Lastly, there will be multiples interactions between the various sets of stakeholders of the 6G ecosystem. As the market is becoming more disaggregated, multiples stakeholders will be engaged in the value creation of the 6G platform, moving away from a linear value chain toward a multi-sided value chain. This leads to the definition of new roles as already described in [HEX223-D22]. There is a decoupling of the individual capability providers from the capability operator managing E2E services composed from capabilities provided by individual capability providers. Besides, digital service providers will be able to receive intent requests from applications and vertical customers and translates those intents to actuate services (incl. operation/control) APIs from appropriate capability operators. The composition of 6G services will indeed involve the multiplication of exposed interfaces from multiples domains, including north bound interfaces as well as east-west interfaces. Representation of all possible multistakeholder interfaces would complexify the system blueprint. Instead, it is invoked with the multistakeholder box surrounding the various layers and domains of the 6G platform. 7.4.2 Mapping selected enablers in the 6G E2E system blueprint In order to provide further insights, each selected enabler from Section 7.3 is mapped to the 6G E2E system blueprint in Figure 7-5. Figure 7-5 Mapping of selected enablers in 6G E2E system blueprint. It highlights how the selected enablers cover the different parts of the E2E system blueprint, mainly in the network function layer and in the pervasive functionalities. The enablers related to the management and orchestration are leveraging the cloud continuum of the infrastructure layer via the multi-cloud/multi-domain federation and synergetic orchestration over the cloud continuum. The interaction between the network and the application is enabled by NW-APP interaction for the enhancement of QoS/QoE mechanisms, and by the intent-based interaction for the operation of the 6G services. Novel 6G services that go beyond the communications services are well supported, with the AIaaS enabler and a collection of enablers related to Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 128 / 155 Figure 8-4 Comparison of the execution time (left) and the scores (right) achieved with increasing number of workloads having a fixed number of compute nodes (43) for the functionality allocation algorithm and PuLP GLPK MIP solver [HEX224-D63]. 8.2 Components of System-PoC B - elements of the 6G network architecture System-PoC B is designed to build upon System-PoC A by incorporating new enablers (e.g., pervasive technologies, network functions) and additionally, by assuming that not all of the network and cloud domain resources, application components and devices are contained in the same domain and/or geographical location. Therefore, it is required to orchestrate all involved components in a coherent and synchronised way. Furthermore, the integration of the new enablers as well as the enhancement of the previous ones, will allow to broaden the sustainability aspects already considered in System-PoC A, e.g., to investigate the data exposure security (social sustainability), the dynamic replanning of available devices roles (environment sustainability), etc. A description of the Component-PoCs constituting System-PoC B follows. 8.2.1 Component-PoC#B.1 - AI-assisted E2E lifecycle management of a 6G latency-sensitive service across the compute continuum Following System-PoC A’s design principles and objectives, Component-PoC#B.1 regards the AI-assisted end-to-end lifecycle management of a 6G latency-sensitive service across the compute continuum on top of the expanded configuration of System-PoC A, i.e., the multi-domain network configuration. Specifically, the considered service consists of a microservices-based application pertaining to the domain of smart manufacturing, where low-latency communication is essential for coordinating robots and machinery, monitoring processes in real time, and ensuring safety through immediate response to anomalies. The examined use case involves a stationary robotic arm, controllable through an open-source API, which is assigned with performing a specific manufacturing task. At the same time, a smaller vehicle is controlled remotely by a human operator based on the video feed provided by an on-board camera, with the purpose of surveilling the location. To that end, sampled frames from the same video feed are provided as input to an MLbased object detector that generates an alert causing the operation of the robotic arm to pause when necessary (i.e., in our experiments, when the presence of human(s) is detected in the location/room where the arm is stationed). The main aspects been tested and validated are the multi-cluster deployment of the application graph, the optimized service placement, and various orchestration mechanisms including reinforcement learning based service autoscaling, computation offloading, live migration, and load balancing. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 129 / 155 Figure 8-5 PoC#B.1 6G latency sensitive application: Application graph depiction. Figure 8-5 displays a high-level overview of the architecture and the design of the developed latency-sensitive application. As can be seen in the depicted application graph, service placement takes place across three levels, with components being deployed at the device (green), edge (blue), and cloud (orange) level. Among them, the ML-based object detection component is selected to be scaled up as required based on the measured workload and delays, with the possibility of computation offloading to the cloud. A more detailed view of the application’s deployment is provided in Figure 8-6. In addition to the fine-grained internal structure, it is also visible that the provided functionality consists of two separate workflows: one related to the remote operation (teleoperation) of the smaller vehicle and another regarding the object detection and the alert generation task controlling the robotic arm’s operation. The main components of the remote operation workflow include a sender at the vehicle transmitting the native MJPEG video stream and an encoder at the edge that receives the video stream, encodes it to H264, and publishes it to the server, which in turn distributes the newly encoded stream via WebRTC [WEB24]. Finally, the remote operation centre at the cloud serves as the interface with the human operator, displaying the received video feed and accepting the remote-control input. The latter (i.e., the remote-control commands) are relayed to the vehicle via the bridge component that is also located at the edge. The object detection workflow consists of a sampler at the edge that receives the same video feed from the camera mounted on top of the vehicle, samples frames at a dynamically adjustable rate, and provides them as input to the object detector, which is built upon a pre-trained deep neural network suitable for real-time detection (YOLOv8). Based on the results of this real-time object detection, an alert is generated if an anomaly is detected (in our case, when one or more persons are detected) and the operation of the robotic arm is paused via the arm controller for safety reasons. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 130 / 155 Figure 8-6 PoC#B.1 6G latency sensitive application: Detailed deployment view. For the deployment of the application and the real-time orchestration of its services, a multi-cluster environment is considered, allowing the placement of the services across the different layers of the continuum as well as their autoscaling. The services described above are initially deployed considering a theoretically optimal deployment plan shown in Figure 8-6, and based on the evaluation of real-time data received the following orchestration actions are taken into consideration: • Service autoscaling: The different services are scaled up and down aiming at the minimization of the workflow end-to-end latency, while keeping resource usage to a minimum. • Service placement: Two cluster layers are considered. The services are moved from cluster to cluster with the same objectives, to identify the placement strategy that can guarantee end-to-end latency requirements with the minimum possible resource utilization. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 131 / 155 Figure 8-7 PoC#B.1 6G latency sensitive application: Deployment and orchestration actions. The multi-cluster environment along with the corresponding monitoring mechanisms are made possible using state-of-the-art tools (i.e., Karmada [KMD24], Zipkin [ZIP24], Prometheus [PRM24]) for propagating Kubernetes services to multiple clusters and collecting the corresponding data signals that provide feedback for the services’ operation. In specific, an experimental setup of two clusters, one at the Edge, closer to the Robot, and one to the Cloud are considered, with the specifications described in Figure 8-8. An observability platform is poised to collect the corresponding metrics for evaluating performance during the application’s operation: • Service computation and communication latency (milliseconds) • CPU usage (CPU time) • RAM (MB) • Workload (frame per second) The autoscaling and placement mechanisms evaluate the collected data and for every interval, the agent selects where the optimal placement is (taking into consideration resource and migration constraints) and how many replicas are needed for guaranteeing SLO satisfaction in terms of end-to-end latency requirements. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 132 / 155 Figure 8-8 PoC#B.1 6G latency sensitive application: Experimentation testbed. 8.2.2 Component-PoC#B.2 - training and inference of collaborative distributed machine learning model on a dynamically changing heterogeneous 6G architecture environment This component PoC#B.2 is a MLOps enabler for data driven architecture. It enables integration of edge and extreme edge resources in the compute continuum. It helps exposing the data at edge nodes in privacy preserving and efficient manner. This PoC is an implementation of a distributed learning technology called parallel split learning [WLQ+23]. Split learning enables privacy preserving training without the need of moving dataset from where they are collected. This is applicable in network analytics that require datasets from different places, e.g., network functions. In this case, in contrast to conventional way of collecting datasets related to the capabilities of various network functions, we instead propose to deploy ML model training capability directly at where these datasets are located. In this case, gNB can have one training entity in the cloud RAN (or OAM), and network functions such as AMF and session management function (SMF) can have co-located training entities at the core network. In the PoC, every training entity, e.g., one for gNB another for UPF via SMF, is considered as a separate Kubernetes pod, where they communicate over a shared message bus. There are 6 different Kubernetes pods, each containing separate neural networks that communicate each other in a given topology in Figure 8-9. There are 2 pods for gNB (one for physical layer data, one for MAC layer data), 2 for UPF (one for IP layer data, one serving for model generalization purposes), 2 output nodes (one for video bitrate estimation, and one for delay estimation). The generalization is obtained via the generalization node deployed between the input and output nodes as illustrated in Figure 8-9. This allows efficient training by sharing the generalization node with two output nodes, so that it learns common representation of input attributes coming from gNB and core network in a way that it can be reused as input to two use case tasks simultaneously. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 133 / 155 Figure 8-9 Split neural network setting that enables training an ML model collaboratively between network functions [HEX224-D33 - Section 8.1]. The latter helps addressing the operational specific functional requirements related to scalability and generalization to potentially many tasks. The generalization also would help reducing the number of ML models, which in turn reduces the large disk space needs due to reduced number of models to store. This directly helps addressing the environmental requirements. In addition, there are strict requirements related to the transport capabilities when moving data between nodes. With split learning, the need for large dataset sharing is removed and instead data compression via NN models are employed that act as encoders and decoders. The proposed solution necessitates architecture enhancements and protocols to support compute offloading that can then host neural network (NN) model layer offloading between distributed entities, which in return helps to sustain QoE for the communication by reducing the computation load and energy consumption at the end-user client. A sequence diagram illustrating the signal flow during split learning and model layer offloading is given in Figure 8-10. Figure 8-10 The sequence diagram of model generalization to multiple use cases and model layer offloading is illustrated in split learning setting. Even though, this PoC addresses to relax some of the requirements of 6G, it itself has a few requirements to be realized in a real implementation. First, accurate synchronization of data collected at different entities must be in place for the decentralized datasets to be correlated. This can be a timestamp along with a key identifier. For instance, in a video session, all distributed compute nodes can agree on the same user id, video session id and/or the timestamp to estimate the mean opinion score (MOS). Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 134 / 155 8.2.3 Component-PoC#B.3 - trustworthy flexible topologies in 6G, leveraging on “beyond communication” aspects Component-PoC#B.3 deals with the exploration of trustworthy and flexible network topologies within the realm of 6G technologies, emphasizing the "beyond communication" capabilities. The exploration is set within a warehouse, where the adaptation and dynamism of network structures are examined for inventory management applications. This scenario is particularly suitable for showcasing the PoC's objectives due to the inherent challenges presented by warehouse environments, such as signal interference, leading to inconsistent network coverage. Through the deployment of flexible network infrastructures, it becomes possible to ensure continuous operation and connectivity, mitigating potential downtimes caused by network disruptions, even in configurations lacking internet connectivity. This specific inventory management scenario is realized through a trio of Worker Nodes (WNs) consisting of two AMRs and a single autonomous UAV, all operational within a spatially defined area, as shown in Figure 8-11. This setup is designed to be adapted to a warehouse environment with pallet racks and various package types, requiring inspection and localization by the WNs across three dimensions. The entire operation is autonomously driven, managed remotely via an edge server situated within the warehouse, ensuring real-time oversight and task distribution. Each WN is equipped with visual and localization sensors, supported by a robotics software suite for autonomous navigation, and maintains bidirectional communication with the edge server through modern protocols, emphasizing multi-connectivity. This empowers the AMRs and UAV to collaboratively survey the warehouse, identifying items with precision, facilitated by custom-trained computer vision algorithms. Notably, the UAV is engineered for efficient operation, leveraging a docking mechanism on the AMRs for transportation, optimizing its energy consumption and enhancing safety. Figure 8-11 Flexible topology architecture [HEX224-D33]. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 135 / 155 The introduction of a flexible topology node (FTN) shows the PoC's core objective: to demonstrate the resilience and adaptability of 6G networks leveraging temporary, trustworthy network nodes within such industrial contexts and beyond. This FTN, in the form of an autonomous UAV, mirrors the worker node UAV in terms of autonomy and connectivity capabilities, tasked with maintaining seamless communication with the edge server for up-to-date information on WN activities and locations. The assumption here is the infrastructure's compatibility with stable public 5G networks, crucial for the FTN's operational efficacy. More specifically, in scenarios where network connectivity is compromised, whether through local network failures or tasks extending beyond current coverage areas, WNs transition into a "paused" state, halting operations safely until connectivity is restored. This is critical for re-establishing network links, where WNs actively seek connection with the network via the FTN's credentials. The FTN's role is pivotal in reassessing and modifying the network topology to ensure uninterrupted connectivity, thereby showcasing the flexible topology's capacity to overcome environmental challenges and maintain operational integrity. The process of topology formulation within the warehouse setting begins upon network reconnection, utilizing AI/ML methodologies to construct a network architecture that is both resilient and adaptable. This structure prioritizes nodes based on a trust metric, which considers reliability, performance, and operational needs, ensuring efficient data flow and minimizing energy consumption. The FTN dynamically adjusts its positioning and network parameters to maintain connectivity, highlighting its importance in facilitating uninterrupted warehouse operations. Note that, coordination and trust among the WNs and FTN are essential for task execution, where the FTN's dual-network capabilities play a central role in extending coverage and offering computational resources to nodes in connectivity shadows. This continuous evaluation of node trustworthiness and performance ensures that network resources are allocated efficiently, particularly in critical operations, thereby enhancing the security and reliability of the network environment. Through this dynamic topology management, the Component-PoC#B.3 underscores the transformative potential of 6G networks in addressing the complex demands of modern warehouse operations, ensuring continuity and efficiency even in the face of connectivity challenges. 8.2.4 Component-PoCs integration plans to System-PoC B System-PoC B is designed to depict an E2E, multi-domain scenario, supported by synergetic monitoring and orchestration mechanisms. In this context, synergetic monitoring and orchestration is realised via a cooperative mechanism, in which performance and resource availability metrics are exposed by multiple domain agents (e.g., resource/service/network orchestrators) in a unified and standardised manner. Decision making with regard to service orchestration/re-configuration relies on the analyses of those multi-domain monitoring data, towards higher efficiency and flexibility. This scenario also considers aspects related to automated service onboarding, synergetic orchestration of a 6G latency-sensitive service over multiple network and edge/cloud computing platforms and the intelligence/automation features that can be introduced through the exploitation of AI technologies (Component-PoC#B.1 features). Another way of exploiting this multi-domain setup is to exhibit whether the information that is stored across the multiple computation nodes can be used to train a joint machine learning model with the goal of predicting selected KPIs at reasonable accuracy levels and with reduced computation and network overhead compared to a defined baseline (Component-PoC#B.2 features). Last, Component-PoC#B.3’s scenario, introducing network beyond communication aspects, such as exposure of compute/communication resources and flexible topologies, was designed following System-PoC B’s narrative so that its integration can be straightforward. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 136 / 155 9 Conclusion and next step This deliverable has summarized the work carried out in work package 2 (WP2) since the completion of the last deliverable D2.2, including refinement of requirements of the 6G end-to-end (E2E) system, technical enabler developments within WP2, selection and recommendation of enablers from other WPs within the project and SNS-JU projects such as 6G-NTN, 6G-SHINE, DETERMINISTIC6G, PREDICT-6G, FLEXSCALE, DESIRE6G, HORSE, RIGOROUS, and ACROSS, and an update on the E2E system level evaluation. Finally, the document has provided a refinement of the system blueprint. In this deliverable, we have outlined the E2E system requirements, stemming from the use cases defined in [HEX223-D12], noting additional use case related functional requirements that are needed to deliver the use cases, as well as supplementary operational functional requirements defined in other smart network and services joint undertaking (SNS-JU) projects that will be needed to realize the 6G system. The technical requirements has summarized the [HEX223-D12] requirements per use case, the outcome of which outlines the need for challenging combinations of requirements. In the upcoming deliverables, it will be important to examine how the requirements will be fulfilled, which parts of the E2E system are most affected, and which technological enablers are best suited. An overview of architectural enablers within the project has been presented, along with their recommendations. The enablers are recommended based on their importance to the 6G system and other considerations such as maturity, high-level functionality, dependency on other enablers, importance towards migration, fulfilment of system design principles, etc. Additionally, recommended architecture enablers include non-terrestrial networks, local subnetworks, deterministic communication, as well as optical transport solutions, all of which are from other SNS-JU projects such as 6G-NTN, 6G-SHINE, DETERMINISTIC6G, PREDICT-6G, and FLEX-SCALE, respectively. Enablers for radio interface and protocols and its overall design have been discussed. Various enablers have been listed with a first-time analysis in the sense that it has potential impacts on the radio interface and protocol and thus a need to integrate in the overall radio design and 6G system design. There will be continued analysis throughout the lifetime of this project, due to that many such enablers are working in progress and not mature yet, including the ones identified from other SNS-JU projects. More precisely related with the next steps, • For enablers on radio techniques and future device, the next step is to cross-check the detailed description of the enablers and see if the radio protocol stack can cope with it, e.g., a flexible control plane protocol that can efficiently configure new features and a flexible user plane protocol that can accommodate specific needs of future devices. • For enablers on architecture and higher layer protocols, those study areas are brought up as early as possible and they are expected to have standardization impact on network infrastructure and UE vendors, and regulators. The detailed impact and systemization would have to be left after those enabler descriptions are more concrete. • For enablers on radio protocols itself, there are some paradigm shift proposals on control plane and user plane. The details are however missing and would expect to be continuously evolved for the rest of the project. For recommended enablers on the evolution track, the solution seems to be built on 5G as the baseline and thus one needs to be careful to retrofit to the 6G radio protocol stack baseline using the same principle and guidelines therein. We have included the latest updates from the intent-based enablers presented in D2.2 and selection of those to bring a minimum viable solution. The deliverable also includes introduction to other close and interesting enablers from other SNS JU projects to know the context around Hexa-X-II and, maybe, identify possible future interactions with these other projects. The security, privacy and resilience (SPR) controls, as the base mechanisms for prevention, detection and mitigation of the threats identified in the initial assessment provided in D2.2 have been further analysed. From these security controls, a set of security enablers have been identified, together with enablers produced in other SNS JU projects that are considered relevant to enhance E2E SPR in 6G networks. Further work will focus on the evaluation of the different security controls, regarding their applicability and impact on general network features, and their integration with the identified enablers, according with the TRL assigned to them. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 137 / 155 A refinement of the E2E 6G system blueprint based on the selection of the recommended technology enablers has been provided. This refinement procedure has two steps. • Given the plethora of enablers that exist, it is vital to develop a mechanism to select the key enablers that should be integrated in the 6G system from its beginning to meet its requirements. A knowledge graph-based method has been proposed and it allows one to visualize and evaluate these myriad combinations, which can then be used to design/deploy 6G system. By pruning the knowledge graph, the selection of enablers has been conducted. However, due to the selection criteria, some enablers were not selected but essential toward the 6G system design. On one hand, they may have suffered from e.g., a lower level of maturity, or not yet fully specified interfaces or use-cases applicability but they should improve with the course of their on-going development inside Hexa-X-II. One the other hand, it must also be stated that the selection criteria have not considered the KPI and KVI related values as they were not available at the time of the analysis. Hence, for this current iteration, the set of selected enablers has been enriched from pragmatic considerations. However, in the subsequent iterations of the system design when all these details are available a more specific heuristic should be developed to refine the selection of enablers integrated in the final system blueprint design for the next deliverable D2.5 [HEX224-D2.5]. • Next the E2E 6G system blueprint has been refined to reflect the progress of work on the various individual enablers and how they interact in the E2E system. The selected enablers cover the different parts of the E2E system blueprint, mainly in the network function layer to support the novel 6G services (e.g., JCAS and AIaaS), to provide flexibility and scalability (e.g., network of networks, multi-connectivity, spectrum sharing, etc) and within the pervasive functionalities (for e.g., intent based, sustainable and trustworthy zero touch automation along with a synergetic orchestration over the cloud continuum, AIOps and DataOps). The importance of the security and privacy controls is also outlined with the prominence of a various set of enablers mitigating the main 6G threats. On the aspects related to sustainability, the aim is to ensure that the system blueprint is designed and can be operated in a way that is sustainable. The impacts of the selected enablers to the economic and environmental aspects of sustainability have been elaborated to check that the designed blueprint have the key enablers to achieve the objective in those two dimensions of sustainability. There has been a preliminary qualitative assessment analysis to be further completed when system evaluation results become available. The analysis of the impact on the third dimension related to social sustainability is also for the next step. Lastly, this deliverable has provided an E2E system level evaluation update. An overview of System-PoC A implementation along with a summary of the previously obtained results and a new set of results, has been presented, followed by an introduction to System-PoC B and its corresponding components. An extensive description of System-PoC B together with its results will be reported in the following deliverable D2.4. This deliverable is an interim overall design, and more work remain to be done in the final deliverable. Here are some further considerations for the next deliverable beyond what has been mentioned in previous conclusion per chapter. • The enabler selection methodology has been complemented with practical considerations. On one hand, it is due to that many enablers are not mature enough but should be an essential part of a cellular wireless system. On the other hand, it may be related to the categorization of enablers. Even though already mentioned in previous deliverables, there are still some remaining inconsistencies in the enabler definition, which can only be found out in the overall design. There is a need to further analyse, refine, and synergize them in the next deliverable. Examples include: the name does not describe what it is but rather what it aims to achieve, e.g., inclusive radio interface is about support of satellite and mobility procedure; some enablers are not technical but rather business-related, e.g., 6G device classes; the name of the enabler sometimes refer to a large technical area, e.g., intelligent air interface, and sometime refers to a specific technique such as re-ordering and recovery, and a good balance on defining an enabler scope must be struck in the next deliverable. • Enabler recommendation criteria are decided by each technical area, and a further harmonization is needed. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 144 / 155 ANNEX A A.1 Intent translation & provisioning example workflow In this subsection, two internal workflows are illustrated, first the enablers initialization process to know the domain resources available below (Figure 9-1) and then, once an intent is requested, how it is deployed (Figure 9-2). Figure 9-1 Intent Translation and Provisioning set-up process. To manage any incoming intent request, it is necessary to know which domains controllers and resources are available to, during the deployment, be able to identify the right actions to provide the intent. To do so, as illustrated in Figure 9-1, the Intent Translation and Provisioning enabler applies an automatic set-up process when it is initialized. Based on the known domains, the enabler will trigger a loop of GET requests to retrieve to resources from the Next-Generation OSS and each Domain Controller/Manager. First, the Intent Fulfilment gathers the information to generate the GET request and forwards it to the SBI-Connectors to reach all the required receivers (steps 1-3). Afterwards, the active controllers answer back with their information to be managed locally by the enabler (steps 4-6). Finally, the enabler makes use of the translation functionality to apply an abstraction process to identify the information that will be stored and used in other processes (steps 7,8). Finally, despite this process is called “Internal Set Up”, it is expected to update the resources knowledge periodically, so the enabler is always in the most updated status possible for the new intent requests and to update the existing intents if any associated resources has been turned down. With the enabler set-up is completed and resource information from Domain Controllers/Managers is known, it is ready to receive intent-based requests and apply the translation and provisioning process, see Figure 9-2. This one is structured in three main phases: Intent Creation, Intent Feasibility, and Intent Deployment (and activation). The first one begins, when the DSP/DSC requests it (step 1), the NBI identifies if the incoming request needs to be interpreted, for example by applying NLP and produces the intent with the right data structure and forwards it to the manager (steps 2-4). In case no interpretation is required, and the incoming request already has the structure (e.g., 3GPP [28.312]), the intent is directly forwarded to the manager (step 5). In both cases and once the request is sent to the manager, the enabler notifies the DSP/DSC about its acceptance and processing status (step 6). Meanwhile, the Manager component stores in the database the data object and forwards it to the Intent Fulfilment module (steps 7,8), which will process it to identify the executable services and policies to meet the intent expectations (step 9) and return them (step 10) to the Manager to apply them in the next phased of the workflow. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 145 / 155 The second phase starts when the Manager triggers the feasibility process to validate if the identified executables service and policies may be applied with the available resources (step 11), the request is processed by the Intent Fulfilment module (step 12) and once the outcome is generated, the feasibility result is forwarded to an external reporting enabler through the Intent Enablers Mappers (step 14), stored in the Intent DB (step 15) and its ID returned to the Manager (steps 16, 17). This way and in case it is not feasible, the Manager may notify about the intent report and the intent status to the DSP/DSC (step 18). Instead, if the intent is feasible, the enabler initiates the third and last phase of the process: Intent Deployment (and activation). For each identified executable service or police, the Manager generates the required request and sends it to the SBI-Connectors (step 19), which publishes into the IF the required requests (step 20). Then the IF forwards the messages to the right OSS/OCS & Domain Controllers/Manager entity (step 21), so the service is deployed where it is needed (step 22). Once done, the result is returned to the IF (step 23) and forwarded to the Manager (steps 24 and 25). Once all the executable actions are done, the manager stores the updated intent data object (step 26), requests to update the associated intent report (step 27) with the latest information (steps 28) using the right intent reporting enabler (step 29) and the Intent DB (step 30). Finally, once everything is ready, the DSC/DSP is notified about the intent status (steps 31 and 32). Figure 9-2 Intent Translation and Provisioning deployment process. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 146 / 155 A.2 Data fusion mechanisms based on telemetry data • Data collection • Collection of the different types of signals through a unified interface supporting the OpenTelemetry specifications. The defined data model (as in Hexa-X-II Deliverable 2.2 [HEX223-D22]) is considered for decoding the received signals. • The signals are then stored to the knowledge base’s corresponding backend through the corresponding APIs and their metadata are stored to a central relational database holding this information to facilitate data fusion. • Analysis • Upon data storage, the datasets are accessed and analysed individually for identification of abnormal events. • The identified events are analysed in correlation with each other for identifying the root causes of these events after getting access to the data fusion information. • Results become available in the form of reports or visualization mechanisms. • Mitigation actions are proposed for their resolution. • Real-time monitoring • The pub/sub mechanism provides an endpoint for external consumers to register specific topics for monitoring along with the corresponding data information (e.g., metric name, interval etc.) they require. • Then consumers are able to subscribe to these topics. • Whenever new data becomes available the corresponding topics are populated with the new information and published for the subscribers to receive. Figure 9-3 Internal workflow of the Data fusion mechanisms based on telemetry data. A.3 Intent closed loop coordination example workflow Figure 9-4 shows an example workflow for the Intent Closed Loop Coordination enabler reported in Section 5.1.4. For the sake of readability, the interfaces are not considered in the diagram. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 147 / 155 Figure 9-4 Example of CL conflict mitigation workflow. Step 1 - The Intent Conflict Detection module detects (Potential) conflicts between two or more CLs and invokes the Conflict Mitigation Logic through CLC NBI. Steps 2, 3 - The logic check the existence of the CLs, i.e., if the loops are registered to the CLC. In case one or more CLs are not registered in the CLC DB: Step 4 - An error is returned to the Intent Conflict Detection module. Otherwise: Step 5, 6 - The CLs are identified and specific policies and rules to be applied are selected from the Rules & Policies DB on the basis of the information sent by the Intent Conflict detection module and the characteristics of the CLs themselves. If the target CLs are local to the DSP: Step 7, 8 - The CLC executes operations on the CLs exploiting the interface exposed by the CL Governance. Then jump to Step 14. Otherwise: Step 9 – The CLC at the DSP invokes request a joint coordination with an external CLC, communicating the coordination decision. Here it is assumed that the CLC at DSP level has the authority to impose the coordination strategy. If the CLC decides to act to the local (DSP) CL: Step 10, 11 - The CLC executes operations on the CLs exploiting the interface exposed by the CL Governance. Otherwise: Step 12, 11 - The CLC waits for the external CLC to complete the operations to the external CLs. Step 13,14 – The CLC notifies the Intent Conflict Information and the Intent Conflict Detection modules that the coordination operations terminated. A.4 Intent-driven placement example workflow Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 148 / 155 In this subsection, the workflow for intent-driven placement is described through a generic example workflow illustrated in Figure 9-5. The process starts from the intent fulfilment request received by the Intent Translation function from the Intent Interface module (corresponding to step 6 in Figure 5-2). Intermediary generic steps (not directly relevant to the intent-driven placement enabler) are omitted, and the next step is actual triggering requests to the Intent CL Governance and Coordination Service to start adequate closed-loops out of the catalog/database of available closed-loop templates to be assigned to the considered intent object and given their required parameters or capabilities. In the pictured example the started Intent CL Decision retrieves the characteristics of the potential compute domains from the Intent CL Monitoring (via the integration fabric) to make its decision on compute placement and enforces it through the Intent CL Execution while informing the Intent CL Monitoring of the decision for further monitoring of the selected compute domain state to maintain intent assurance. As compute domain conditions evolutions are observed by the Intent CL Monitoring and cross relevant thresholds, the Intent CL Decision is triggered again to reconsider the placement. Figure 9-5 Intent-driven placement process A.5 Intent conflict administration workflow example We present the workflows for the three enabler’s responsibilities in Figure 9-6. It represents the detailed internal workflow of our proposed intent conflict administration enabler. As it is depicted in this figure, our enabler consists of three main components including: Figure 9-6 Detailed internal workflow of the proposed intent conflict administration enabler. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 149 / 155 • Intent conflict detector is responsible of collecting the intents in intent DB, analysis, and detection of potential conflicts. • Intent conflict resolver is responsible to resolve conflicts. following receiving conflicting expectations suitable actions to fulfil will be proposed, the impact of the actions on all the existing expectations will be predicted and finally the proposed actions along with their predicted outcomes will be evaluated and best possible action will be selected (as one optional step, this entity can provide inputs for the closed loop coordination enabler). • Intent conflict reporter is responsible of collecting the conflicting intents expectations and IDs and communicate it with the intent reporting enabler. Upon receiving intent(s) from intent translation and provisioning enabler (step 1), intent conflict detector checks the expectations and stores the intent(s) in the database (step 2). As discussed in previous section, we are considering two kinds of conflicts within and between intents. For the within intent conflict detection option, If the received intent contains explicit conflicting expectations, then the intent conflict detector marks this intent (step 3) and provide a report including the conflicting expectations and the intent IDs to intent conflict reporter (step 4). Afterward, the intent conflict reporter sends the information to Intent reporting enabler (step 5). For the between intents conflict detection option, the potential conflicts between intents will be detected (step 6), after extraction of the potential conflicting expectations (step 7) these expectations will be redirected to intent conflict resolver (step 8). The conflict resolver entity (propose, predicts, and evaluate) provides evaluated actions to resolve the potential conflicts (step 9). Among the evaluated actions, the most suitable one will be selected and optionally can be provided to closed loop coordination enabler (step 10). Then, a report regarding the conflict resolution, selected actions, intent IDs will be sent to intent conflict reporter to keep track of all the conflicting expectations (step 11). To retain the history of the conflicts a report will be sent back to intent conflict detector that assists this entity to detect the potential future similar conflicts in advance (step 12). In addition, a report will be provided to intent reporting enabler (step 13). A.6 Human-machine intent interface design example workflow The workflow of intent creation and monitoring is illustrated in Figure 9-7. The intent creation process could be seen as an expansion to steps 1-4 of the workflow presented in Figure 9-2. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 150 / 155 Figure 9-7 Human-Machine Intent Interface Design - Internal Workflow. First, the user/tenant expresses its intent in a general format using its own domain language. When the NBI identifies that the incoming intent doesn’t have a data object structure, e.g., like the one defined by 3GPP [28.312], it forwards the incoming intent to the interpreter (steps 1-2). When the interpreter receives the intent, it requests the relevant third-party data from the 3P Profiling module through the Manager (steps 3-5). These third-party data include more information on the tenant, its domain, contracted SLAs, etc. Dependent on the received third party data and the incoming intent, the interpreter fetches the relevant interpretation model from the respective database and interprets the incoming intent into an intent data object (steps 6-7). After that, it initiates an interpretation closed-loop within the Closed-loop governance and coordination module (steps 89). This interpretation closed-loop, as mentioned earlier in subsection 5.1.6, would support the monitoring of the intent and if a deviation from the application-level goals is detected, the CL governance and coordination module should be able to differentiate between a deviation due to inaccurate interpretation and that due to insufficient network capabilities and execute the right management decisions accordingly. Finally, the interpreter forwards the resultant intent data object to be deployed to the manager and confirms the reception of the intent to the user/tenant (steps 10-11). While monitoring the intent after being deployed, if the CL governance and coordination module detects a deviation of CL output from application-level goals, it should be able to determine the source of deviation (steps 12-13). If the deviation is due to inaccurate interpretation, a request to update the interpreter is sent through the manager (steps 14-15). When the interpreter receives the request, it fetches the relevant interpretation experiences from the respective database, update the relevant interpreter model, and store the updated model to the respective database (steps 16-18). A.7 Declarative Intent Reconciliation example workflow Figure 9-8 demonstrates the workflow of this enabler in two scenarios: CL Initiation and CL Coordination. For simplicity, the interfaces and database are not considered in this diagram. Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 151 / 155 Figure 9-8 Declarative Intent Reconciliation internal workflow. In CL Initiation, the CL instance data object is pushed to the Git repository by the CL Governance. This action triggers a notification from the Git server to RE. RE acknowledges that this is a Push event, thus it knows that a new CL is initiated. Then, RE asks the CL Governance for the set of actions to be executed. After receiving the decision, RE composes a pipeline of CL actions and deploys a dedicated agent to handle this CL. Also, RE pushes the pipeline data object to the same repository to keep track of the workflow. The agent parses the pipeline and executes the CL actions accordingly by sending the requests to Domain Controllers via the integration fabric. Once the deployment is done, the agent starts the monitoring process to ensure the correspondence between the desired and actual state. In CL Coordination, the existing CL instance information is modified by the CL Coordinator in the case when a conflict occurs. The new CL instance is updated by creating a new Pull Request. The Git server first verifies that the entity (i.e., CL Coordination) has the right to modify the CL data object, then allow the merge to the existing one. Subsequently, RE receives the notification of this Merge a Pull Request event via webhook from the Git server. Then, it queries the CL Coordinator for (potentially) new CL actions. RE composes a new pipeline and updates it on the repository. It invokes the corresponding agent to execute the new pipeline on the resource domains. Once deployed, the agent continuously monitors the domain states. A.8 Intent reporting workflows The three different scenarios associated with the actions of the intent management: • Feasibility report: The report is generated in the creation or modification of an intent instance where the IME evaluates if the e2e service proposed for fulfil the intent could be offered. The design of the e2e service should consider the constraints associated with the intent environment and the service management resources components. When the feasibility actions are completed, there are two options: Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 152 / 155 o Feasibility OK. The report informs that the feasibility has been evaluated and it could be actionable. An id, a timestamp and a FEASIBLE status should be generated. An expiration date parameter also should be offered. If the internal components of the e2e service will change, this evaluation should be launched. o Feasibility KO. In this case the response for the desired intent should be NOT FEASIBLE and optionally, the intent request could be evaluated with the service and resource components available (exposed in the Service Portfolio), and a recommendation engine could offer an alternative proposal. The proposal will be elaborated with the intent constraints and context to the MnS Consumer. The recommendation should be evaluated as a feasibility action later. The recommendation doesn’t design and activate the e2e service. Figure 9-9 Feasibility report workflow. • Conflict report: This report is generated when a conflict is detected. There are two scenarios to consider. The conflict detection could be internal to the intent and will be detected when a new intent is going to be created. If the conflict is external this could be detected in the Close Loop execution and the Close Loop Coordinator (enabler4) will notify which intents has the conflict. The conflict report will launch the generation of the report for the MnS Customer with the detail of the item included in the conflict notification. o Target conflict: This conflict happens when the intent is received and the evaluation of the conditions included in the intent has internal conflicts in the target o Expectation conflict: This conflict happens when the intent is received and the evaluation of the expectations included in the intent has internal conflicts. o Intent conflict: The Close Loop Coordinator detects a conflict among several intents through the detection in the Close Loop associated. Optionally an impact analysis could be done for helping in the decision. • Fulfilment report: This report gets the information about the KPIs of the components of the intent request and if it defined a global value for control if the service is offering the performance proposed. The evaluation is done mostly at QoS level because the availability at management and operational of systems and components. It will be desirable include some QoE metrics (close to the service execution) but this is not always possible. The report could offer an individual value at one time, generate several Hexa-X-II Deliverable D2.3 Dissemination level: Public Page 153 / 155 periodic measurements that are later summarized, launch several metrics with summarized and with the optional use of a prediction module. Figure 9-10 Conflict report workflow. [Document text truncated for crawler view.]