Solutions for enabling agentic sensing with network optimization

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 May 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

Integrated Sensing and Communications (ISAC) is emerging as a key enabler for next-generation wireless networks, integrating sensing and communication functionalities within a unified system. By leveraging the same spectral, hardware, and computational resources, ISAC enhances network efficiency while enabling new capabilities such as high-resolution environment perception, object detection, and situational awareness. This paradigm shift is particularly relevant for applications requiring both reliable connectivity and precise sensing, such as autonomous vehicles, industrial automation, and smart city deployments. Given its strategic importance, ISAC has gained significant traction in standardization efforts. The ETSI Industry Specification Group (ISG) on ISAC has produced a set of group reports covering ISAC use cases and deployment scenarios [ETSI-GR-ISC-001], system and RAN architectures [ETSI-GR-ISC-003], security, privacy, trustworthiness and sustainability [ETSI-GR-ISC-004], and the integration of computing with ISAC [ETSI-GR-ISC-005]. In 3GPP, service requirements for ISAC have been specified [TS22137], the architecture enhancements to support sensing in the 5G System have been studied [TR23700-14], and ISAC is also part of the use cases and service requirements identified for 6G systems [TR22870]. Furthermore, research initiatives within the IEEE and IETF are investigating how ISAC can be integrated into network architectures [I-D.ietf-green-use-cases], spectrum management, and protocol design, making it a critical area of development in the evolution of wireless networks.¶

There are sensing scenarios and use cases that involve a distributed sensing task, in which multiple sensors participate and contribute with (raw or pre-processed) sensing data, which is processed by a sensing service (e.g., fusing sensing measurements from the different sensors). This sensing service needs to be executed on some kind of sensing processing/computing function which receives raw (or preprocessed) data from multiple sources, potentially of different (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from different radio technologies). This processing might impose time synchronization constraints on the reception of the different parts of data, as well as potentially specific computing and/or AI/ML capabilities on the processing node. The integration of computing with ISAC, including the selection of the nodes where sensing data is processed, is analyzed in [ETSI-GR-ISC-005].¶

The selection of the nodes that participate as sensors and sensing processing functions in a given distributed sensing task and the configuration of the network to facilitate the sensing task, and optimize both the sensing and the network operation, are not independent. However, achieving an overall optimal configuration is not a trivial task, especially when multiple optimization metrics and/or constraints are considered.¶

In distributed sensing, sensing KPIs (e.g., accuracy, refresh rate, confidence level, latency) are tightly coupled with radio, compute, and transport configurations. Moreover, mobility, traffic load, and environmental dynamics continuously alter the relationship between configuration and achieved sensing performance. Static or centrally pre-computed deterministic configurations can therefore become suboptimal or infeasible at run time. An agentic AI approach enables distributed decision-making, coordination among sensing and networking entities, and adaptive reconfiguration to sustain sensing KPIs under dynamic conditions¶

We assume a generic network architecture, where IETF CATS [I-D.ietf-cats-framework] and GREEN [I-D.ietf-green-use-cases] architectural considerations and solutions can be of application, though the solution can be generalized to scenarios based on different architectures.¶

We assume that there is a network function in charge of the coordination and configuration of the distributed sensing task, aware of which nodes in the network can participate as sensor nodes, and potentially of the capabilities of potential sensing processing nodes. This network function can be, for example, the Sensing Control Function (SCF), i.e., the control part of the Sensing Function (SF) considered in the 3GPP study on the architecture to support sensing [TR23700-14] (see also [ETSI-GR-ISC-003]), or a Gateway Sensing Function (GSF), also discussed in [TR23700-14].¶

We also assume that there is a network function in charge of managing the network configuration of the network, such as an SMF/AMF in a 3GPP 5G architecture.¶

We assume that there are AI agents, which might run on network nodes (such as terminals, radio access nodes or infrastructure nodes), of two types: AI agents for Sensing (AIaS) and AI agents for Networking (AIaN). These agents can run tasks aimed at finding an optimal configuration for sensing and connectivity, respectively and can interact among them to pursue these goals.¶

The interactions among AI agents described in this document are an instance of the agent-to-agent communication patterns being addressed by the IETF AGENTPROTO working group [I-D.agentic-ai-usecases-requirements], and of the AI agent use cases identified by 3GPP for 6G systems [TR22870] (e.g., collaborative AI agents, or data collection and fusion in multi-agent scenarios), whose implications on agent communication protocols are discussed in [I-D.stephan-agentproto-6g-usecases]. Similarly, the discovery of the AI agents involved in a sensing task relates to the work of the IETF DAWN working group [I-D.kay-dawn-use-cases]. Architectural principles for the use of agentic AI in autonomous networks are discussed in [I-D.jadoon-nmrg-agentic-ai-autonomous-networks]. This document does not define any new agent communication or discovery protocol; it focuses on the information exchanged and the actions triggered among sensing and networking agents.¶

A given network function or application function might request a specific sensing task (with associated requirements, e.g., in terms of accuracy) to the SCF directly or indirectly via the NEF and/or GSF, which can then request several AI agents for Sensing to select a sensing configuration and interact with the AI network agents to ensure the network is configured as needed. Note that the sensing task request might have some associated requirements, specific to the task (such as accuracy, or privacy) but also global ones, such as energy consumption, etc.¶

2. Terminology

The following terms are used in this document:¶

Agent Network:

The set of AI agents involved in a given task and the relationships among them (e.g., which agent delegated which sub-task to which other agent), which can be represented as a graph of agents and their capabilities.¶

AIaN:

AI agent for Networking.¶

AIaS:

AI agent for Sensing.¶

AMF:

Access and Mobility Management Function (3GPP).¶

AN:

Access Node, a radio access node (e.g., a base station or an access point) that can also act as a sensing node.¶

GSF:

Gateway Sensing Function. A gateway sensing network function considered in [TR23700-14] for the authorization of sensing service requests and the capability registration of sensing entities, when a sensing service involves multiple sensing service areas.¶

ISAC:

Integrated Sensing and Communications.¶

NEF:

Network Exposure Function (3GPP).¶

SCF:

Sensing Control Function, responsible for configuring and triggering distributed sensing performed by a group of sensing entities. In [TR23700-14], the SCF is the control part of the SF.¶

Sensing Entity:

An entity acting as a sensing transmitter and/or a sensing receiver [TS22137], such as a terminal or an AN. Note that in [TR23700-14] the sensing entity is restricted to the gNB.¶

SF:

Sensing Function. Logical network function supporting a sensing service, which may comprise an SCF and one or more SPFs [TR23700-14].¶

SMF:

Session Management Function (3GPP).¶

SPF:

Sensing Processing Function, participates in a distributed sensing function processing raw (or pre-processed) sensing data to determine the sensing result [TR23700-14].¶

This document also uses the terms "discovering entity", "discovered entity", "capability card" and "minimum discoverable information" as defined in [I-D.farrel-dawn-terminology].¶

3. Enabling agentic AI distributed sensing with network optimization

We describe next an example of operation and signaling for a distributed sensing task to be configured and dynamically optimized based on agentic AI for sensing and networking. An AI agent for Sensing and an AI agent for Networking run on several network nodes (terminals, access nodes and processing nodes) and might interact to agree on a sensing and networking configuration that overall meets the sensing requirements while optimizing other metrics (such as privacy and energy consumption).¶

/_\ AI agent for Sensing
 _
|_| AI agent for Networking
                       _________
                      |  _      |
                      | |_| /_\ +-----\
                      |_________|      \   ____________________________
                    Access Node #1      \ |                            |
         _________                       \|  _________                 |
        |  _      |                       | |  _      |                |
        | |_| /_\ |                       | | |_| /_\ |                |
        |_________|                       | |_________|    _________   |
        terminal #1                       |  Processing   |  _      |  |
                       ______________     |   node #1     | |_| /_\ |  |
                      (              )    |               |_________|  |
 _________           (     object     )   |                  SCF       |
|  _      |           (______________)    |                            |
| |_| /_\ |                               |  _________                 |
|_________|                               | |  _      |                |
terminal #2                               | | |_| /_\ |                |
                                         /| |_________|                |
                            _________   / |  Processing                |
         _________         |  _      | /  |  node #2                   |
        |  _      |        | |_| /_\ +-   |____________________________|
        | |_| /_\ |        |_________|
        |_________|      Access Node #2
        terminal #3

Figure 1 shows a high-level picture of the architecture.¶

In the following, we describe an exemplary procedure showing how different agents can interact to configure a distributed sensing task. The focus is on the interactions, the information exchanged and what actions might be triggered.¶

 _________   _________   _________      _________   _____   _____
|  _      | |  _      | |  _      |    |  _      | |  _  | |     |
| |_| /_\ | | |_| /_\ | | |_| /_\ |    | |_| /_\ | | |_| | | /_\ |
|_________| |_________| |_________|    |_________| |_____| |_____|
terminal #1 terminal #2    AN #1         SPF #1     netw.    SCF
   |   |       |   |       |   |          |   |     ctrl.     |
   |   |  (0.AI agents discovery and registration)    | 1.Sensing task
   |   |       |   |       |   |          |   |       |     request
   |   | 3.Agentic sensing |   |       2.Sensing task request |<---
   |   |     task request  |   |<-----------------------------|
   |   |<----------------------|          |   |       |       |
4a.Agentic net req.  4b.Agentic net req.  4c.Agentic net req. |
   |<--|       |   |       |<--|          |<--|       |       |
4a.Connectivity request    |   |          |   |       |       |
   |------------------------------------------------->|       |
   |   |       |   |       |4b.Connectivity request   |       |
   |   |       |   |       |------------------------->|       |
   |   |       |   |       |   |          |4c.Connectivity request
   |   |       |   |       |   |          |---------->|       |
   |   |       |   |       |   |          |   |   (network    |
   |   |       |   |       |   |          |   |    config.)   |
   |   |       |   |       | 5b.Connectivity response |       |
   |   |       |   |       |<-------------------------|       |
   |   |       |   |       |   |  5c.Connectivity response    |
6a.Agentic net resp.       |   |          |<----------|       |
   |-->|       |   6b.Agentic net resp.  6c.Agentic net resp. |
   |   |       |   |       |-->|          |-->|       |       |
   |   |       |   |       |   |7.Agentic sensing task resp.  |
  7.Agentic sensing task resp. |<-------------|       |       |
   |   |---------------------->|          |   |       |       |
   7.Agentic sensing task resp.|          |   |       |       |
   |   |       |   |---------->| 8.Sensing task response      |
   |   |       |   |       |   |----------------------------->|
   |   |       |   |       |   |          |   |       |       |
   |  (9.Monitoring actions to trigger reconfig. if needed)   |
   |   |       |   |       |   |          |   |       |       |

Figure 2 shows the message sequence chart of an agentic AI-enabled multi-sensor distributed sensing which is explained next:¶

0. We assume AI agents for Sensing have been trained with some data, possibly based on their own local knowledge and potentially enriched with additional data. We also assume they have some knowledge about other neighboring agents and that there could be some type of centralized/distributed repository where they are registered. The mechanisms used by AI agents to discover each other (e.g., an AIaS discovering AIaN or other AIaS instances in the same administrative domain or in cooperating domains) are out of scope of this document; mechanisms such as those being developed in the IETF DAWN working group [I-D.kay-dawn-use-cases] [I-D.king-dawn-requirements] could be used. Note that DAWN focuses on initial discovery; the selection of the agents to involve in a given sensing task remains a decision of the requesting agent (or of the SCF).¶
1. The network receives a sensing request. A sensing managing entity, such as the SCF, receives this request and decides to delegate that request, or part of that request to some AI agents for Sensing running in the network. For example, the initial request received by the network may be for a XR/multi-media service (which explicitly or implicitly require sensing services), while the sensing request that is delegated to AI Agents may be created to meet the sensing requirements of the initial request. SCF would decide which specific sensing request should be processed via AI agents and which part of the sensing could be done using sensing "traditional" (i.e., not using agentic AI) methods.¶

2. Based on the information and metadata associated to the sensing request (e.g., location of the intended sensing), the SCF determines to use AI Agents for executing the sensing task, and sends a request to the AI agent for Sensing at the chosen sensing entity (Access Node #1 [AN#1], in our example). In this step the SCF may determine to use AI Agents based on any combination of:¶

   1. an indication received in the initial request that AI Agents can/must be used.¶
   2. Received policy information, indicates that AI Agents can/must be used.¶
   3. Fast reactions to changes in contextual information and availability of resources is required.¶
   4. The overall service requirements allow for delays and errors incurred due to potential conflicts among agents and performance oscillations. These may be specified as threshold values.¶

   This request might include the following information:¶

   1. Sensing task description: metadata indicating what is the sensing task, sensing accuracy (spatial and temporal), whether the sensing task involves stationary or mobile targets, Time information associated with the sensing task (e.g., a time period), etc.¶

   2. Sensing data governance requirements about privacy, security and trustworthiness such as for example what sensing data can be processed where in the system and what pre-processing and processing might be allowed to happen with the data, its fusion framework with other data and its exposure to application function or network function. Examples (non-limiting) of encoding of this are:¶

      1. Processing of raw sensing data: only local at the originating node / local or remote processing allowed / partial processing allowed remotely.¶
      2. Trustworthiness of data: any generated data is trusted / only data from a list of explicit sources is trusted / data has to be signed by a trusted source to be trusted.¶
      3. Confidentiality of exchanged data: all data (processed or not) must be encrypted (specifying the mechanism to be used to encrypt it), data (raw/partially processed/processed) must be encrypted, all data can be sent in clear.¶
      4. List of trusted generating entities/administrative domains.¶

      Allowed types of sensing fusion, e.g., a combination of the following possible options: only with raw data of some kind, mixing data partially processed with raw data, mixing different types of sensing technologies, mixing different levels of trustworthiness, etc. If the nodes involved in the sensing task belong to different administrative domains, additional mechanisms might need to be used to guarantee/prove that the processing and/or confidentiality of the sensing data is enforced. An example would be the use of a private or public blockchain.¶

   3. Allowed level of agentic AI interactions. This parameter, which might be expressed in different ways, indicates how different agents are allowed to interact towards completion of the intended task. For example, the requester may indicate that the agent receiving the request has to perform the required actions without interacting with other sensing agents, or without interacting with networking agents, or which limitations to apply in regards of other agentic interactions (e.g., agent ownership limitations). It also includes whether the involved agents are responsible for monitoring the sensing task to trigger alerts and propose reconfiguration actions if needed. This parameter may also indicate the maximum size of the agent-to-agent communication hops, or tiers or number of worker Agents used for executing part of a task or in whole. This may be seen as the maximum size or depth of the agent-to-agent network (graph). When this parameter is sent from one agent to another agent (as in step 3.d), it may adjust the value to be the (maximum size) relative to that specific agent node/hop (for example, allowed_level_of_agentic_AI_interactions = allowed_level_of_agentic_AI_interactions - 1).¶
   4. Additional network requirements, such as energy consumption metrics.¶
   5. List of AI agents available (optional, as this might be known by the receiving AI agent based on its local context and/or other AI agent discovery mechanisms, see step 0). This list might convey, for each agent, information similar to the "minimum discoverable information" defined in [I-D.farrel-dawn-terminology].¶

3. The receiving AI agent for Sensing (in this example AIaS@AN#1) processes the request and based on the parameters received and its knowledge of the local context and prior training, decides whether it can honor the received request and whether it can interact with other agents. In this example, the agent decides to interact with three additional AI agents for sensing (@terminal#1 and @terminal#2, @processing node/SPF #1) to basically configure a multistatic active sensing (involving terminals #1 and #2 and AN#1) with the sensing processing done at processing node/SPF #1. AIaS@AN#1 sends an Agentic sensing task request, which includes the following parameters:¶

   1. Sensing task description: metadata indicating what is the intended sensing task, sensing accuracy (spatial and temporal), whether the sensing task involves stationary or mobile targets, etc.¶

   2. Intended sensing task configuration, including parameters such as:¶

      1. Static/Multi-static.¶
      2. Active/passive sensing.¶
      3. Sensing technology (e.g., WiFi, 5G).¶
      4. Other participant node's IDs.¶

   3. Sensing data governance requirements about privacy, security and trustworthiness such as for example what sensing data can be processed where in the system and what pre-processing and processing might be allowed to happen with the data, its fusion framework with other data and its exposure to application function or network function. Examples (non-limiting) of encoding of this are:¶

      1. Processing of raw sensing data: only local at the originating node / local or remote processing allowed / partial processing allowed remotely.¶
      2. Trustworthiness of data: any generated data is trusted / only data from a list of explicit sources is trusted / data has to be signed by a trusted source to be trusted.¶
      3. Confidentiality of exchanged data: all data (processed or not) must be encrypted (specifying the mechanism to be used to encrypt it), data (raw/partially processed/processed) must be encrypted, all data can be sent in clear.¶
      4. List of trusted generating entities/administrative domains.¶

      Allowed types of sensing fusion, e.g., a combination of the following possible options (non limiting): only with raw data of some kind, mixing data partially processed with raw data, mixing different types of sensing technologies, mixing different levels of trustworthiness, etc. If the nodes involved in the sensing task belong to different administrative domains, additional mechanisms might need to be used to guarantee/prove that the processing and/or confidentiality of the sensing data is enforced. An example would be the use of a private or public blockchain.¶

   4. Allowed level of agentic AI interactions. This parameter, which might be expressed in different ways, indicates how different agents are allowed to interact towards completion of the intended task. For example, the requester may indicate that the agent receiving the request has to perform the required actions without interacting with other sensing agents, or without interacting with networking agents, or which limitations to apply in regards of other agentic interactions (e.g., agent ownership limitations). It also includes whether the involved agents are responsible for monitoring the sensing task to trigger alerts and propose reconfiguration actions if needed. An example of a possible encoding of the allowed level of agentic AI interaction is the following:¶

      0. no delegation,¶
      1. local AIaS may interact with local AIaN,¶
      2. local AIaS may delegate/talk to other sensing nodes, but those cannot delegate it further,¶
      3. local AIaS may delegate/talk to other sensing nodes, which can delegate it to N-2 levels.¶

      When agent-to-agent interactions span multiple hops, the requests and responses belonging to the same sensing task need to be correlated, and the associated context (including the remaining allowed level of agentic AI interactions) propagated along the chain of agents. This is aligned with the agentic dialog management functionality and requirements being discussed in the IETF AGENTPROTO working group [I-D.agentic-ai-usecases-requirements].¶

   5. Additional network requirements, such as energy consumption metrics.¶

   How an agent decides that additional sensing tasks need to be performed in order to honor/complete the received sensing task is out of the scope of this document. It is up to the specific agents' implementation and the knowledge they have of the local context.¶

4. The receiving agents process the request, and similarly to what was done in the previous step, decide whether they need to do additional agent interactions. On each hop, the "allowed level of agentic AI interactions" is decreased by 1. Following the example encoding above, a receiving AIaS can interact with its local AIaN if the received value is at least 1, and can delegate further to other AI agents for Sensing only if the received value is greater than 1. (Non-limiting) examples of these sub-tasks are:¶

   • Perform an isolated sensing task targeting a specific goal (i.e., track an object in a given geographic area, with an intended accuracy, sensing technology and energy constraints).¶
   • Configure the network and/or specific network elements to support a given connectivity level to transport the data generated by other agents.¶
   • Find out which types of sensing, and with which level of trustworthiness/security/privacy are allowed to be used by certain nodes and/or in a given geographic area.¶
   • Etc.¶

   Let's assume for the sake of this example, that the following actions are required:¶

   1. AIaS@terminal#1 needs to interact with its local AI agent for Networking (AIaN@terminal#1) to ensure that the radio interface of terminal#1 is configured as required by the sensing task.¶
   2. AIaS@AN#1 needs to interact with its local AI agent for Networking@AN#1 to request a guaranteed communication path to the processing node#1. As a result of this, AIaN@AN#1 sends the required request to the networking control entity (in this example SMF/AMF), which then performs the required configuration.¶
   3. AIaS@processing-node#1 needs to interact with its local AI agent for Networking@processing-node#1 to request a guaranteed communication path to AN#1 and terminals #1 and #2. As a result of this, AIaN@processing-node#1 sends the required request to the networking control entity (in this example SMF/AMF), which then performs the required configuration.¶

   Note that it might also be possible that the request for guaranteed communication paths (e.g., between the processing node #1 and terminals #1 and #2) could also be triggered by AI agents running on the terminals.¶

5. As a result of the requests (4b and 4c) for guaranteed communication paths to the AMF/SMF, the AMF/SMF performs the required configurations and responds back to the AI agents for networking (5b and 5c).¶
6. The AI agents for networking respond back to the AI agents for sensing, after completing their tasks.¶
7. Each involved AI agent that was tasked with a given action responds back to the initiating AI agent. In this example, AIaS@terminal#1, AIaS@terminal#2 and AIaS@processing-node#1 respond to AIaS@AN#1, including the result of the operation.¶
8. Once all the required configurations are completed, the initial agent (AIaS@AN#1) responds back to the SCF with a sensing task response, providing the result of the sensing task request (success/failure) and about the resulting sensing (and networking) configuration. At this point, the distributed sensing task is ongoing. This may also include information of the established Agent Network (see Section 2), e.g., a graph of agents and their capabilities.¶

9. SENSING and CONNECTIVITY MONITORING. Depending on whether the agents were instructed to perform continuous monitoring or not, different options are possible:¶

   1. Monitoring performed by the agents. In this case, agents monitor the activity and local context for variations that, according to its previous training and knowledge, might require corrections. If that is the case, the conducted actions are notified back to the SCF, through the chain of involved agents. Examples of monitoring include: (i) Measuring (passively or actively) connectivity between sensing sources and processing node, (ii) Measuring estimated sensing precision, (iii) Measuring energy consumption associated with the sensing task. The monitoring can include additional parameters, such as: (i) specific thresholds for each/some monitored parameters and associated actions if those threshold are passed, (ii) Frequency of monitoring.¶
   2. Monitoring performed by the network. In this case, "legacy" monitoring mechanisms are used, which might trigger reconfiguration actions (in a similar fashion to the initial sensing task request).¶

4. IANA Considerations

N/A.¶

5. Security Considerations

The use of AI agents to configure sensing and networking resources introduces security and privacy risks, some of which are discussed in this section. This is a first list that will be extended in future versions of this document.¶

AI agents need to be authenticated independently of the entity (e.g., the SCF or an application function) on whose behalf they act. The authorization delegated along a chain of agents needs to be scoped and bounded; the "allowed level of agentic AI interactions" parameter provides one such bound, but it is only effective if receiving agents can verify it has not been tampered with and enforce it. Delegated authorization across chains of AI agents is one of the aspects being considered in the IETF AGENTPROTO working group [I-D.agentic-ai-usecases-requirements].¶

Agent-initiated configuration actions, such as the connectivity requests sent by an AIaN to the network control entity (e.g., SMF/AMF), can modify the behavior of the network. These requests need to be authorized by the network control entity, and should be auditable so that the operator can trace which agent triggered a given configuration change and on behalf of which original request.¶

Information used to discover AI agents should be integrity protected, and its visibility controlled, as it may reveal network topology or the sensing capabilities available in a given area [I-D.kay-dawn-use-cases]. Persistent identifiers used to correlate agent interactions may also enable tracking of sensing tasks or of their targets.¶

Sensing data is privacy sensitive. The sensing data governance requirements described in Section 3 (e.g., where raw data can be processed, confidentiality and trustworthiness of the exchanged data) need to be propagated and enforced by all agents involved in a sensing task, including when nodes belong to different administrative domains. Security, privacy, trustworthiness and sustainability aspects of ISAC are analyzed in [ETSI-GR-ISC-004].¶

Further architectural security considerations for agentic AI in autonomous networks are discussed in [I-D.jadoon-nmrg-agentic-ai-autonomous-networks].¶

6. Acknowledgments

The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe SUSTAIN-6G (Grant Agreement No. 101191936), MultiX (Grant Agreement No. 101192521), PRIME-6G (Grant Agreement No. 101272485) and DISCO6G-CM.¶

Authors' Addresses