Requirements and Enabling Technologies of Agent Protocols for 6G Networks
draft-hw-ai-agent-6g-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Chenchen Yang , Huanhuan Huang, , Arashmid Akhavain , Faye Liu , Xueli An, , Weijun Xing, , Jinyan Li , Aijun Wang , Yang Wencong, | ||
| Last updated | 2025-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hw-ai-agent-6g-00
Network Working Group Chenchen Yang,
Internet-Draft Huanhuan Huang,
Intended status: Standards Track Arashmid Akhavain,
Expires: 21 January 2026 Faye Liu,
Xueli An,
Weijun Xing,
Huawei
Jinyan Li,
Aijun Wang,
China Telecom
Wencong Yang,
China Unicom
20 July 2025
Requirements and Enabling Technologies of Agent Protocols for 6G
Networks
draft-hw-ai-agent-6g-00
Abstract
Agent application will be surely the common trend for a long time in
future, while agent protocols are so popular that more and more
protocols are being worked out. The telecommunication industry plays
a pivotal role in the Agent ecosystem. The overall technology
success hinges on how telecommunication industry could adopt the
latest AI trends in order to handle its specific usage scenarios and
performance requirements, e.g., in the coming 6G era. This document
will provide the first attempt to analyze the agent protocol
requirements and relevant enabling technologies based on mobile
communication system specific characteristics.
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 21 January 2026.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 1]
Internet-Draft Short Title July 2025
Copyright Notice
Copyright (c) 2025 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Characteristics of Mobile Network . . . . . . . . . . . . . . 4
2.1. Resource dynamicity . . . . . . . . . . . . . . . . . . . 4
2.2. Guaranteed Quality of Service (QoS) . . . . . . . . . . . 4
2.3. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Multi-domain Interoperation . . . . . . . . . . . . . . . 5
2.5. Security, Privacy and Trust . . . . . . . . . . . . . . . 5
2.6. Session-level Operation . . . . . . . . . . . . . . . . . 6
2.7. Systems Coexistence . . . . . . . . . . . . . . . . . . . 6
3. Agent Protocols Requirements . . . . . . . . . . . . . . . . 6
3.1. Multi-agent system covering terminal, network and
service . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. QoS Assurance for Multi-agent Communication . . . . . . . 7
3.2.1. Agent traffic may consist of multiple “Parts” and
multi-modal data： . . . . . . . . . . . . . . . . . . 7
3.2.2. Heterogeneous QoS requirements among multiple
“Parts”： . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Burst Agent traffic . . . . . . . . . . . . . . . . . 7
3.3. Agent Service Continuity . . . . . . . . . . . . . . . . 8
3.4. Agent Task-Oriented Resource Management . . . . . . . . . 8
3.5. Intent-based Interaction . . . . . . . . . . . . . . . . 9
3.6. Security, Privacy and Trust . . . . . . . . . . . . . . . 9
3.7. Agent Governance . . . . . . . . . . . . . . . . . . . . 9
3.8. Backward Compatibility and Forward Compatible . . . . . . 10
3.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
3.10. Isolation . . . . . . . . . . . . . . . . . . . . . . . . 10
3.11. Tool Invocation . . . . . . . . . . . . . . . . . . . . . 11
3.12. Knowledge Retrieval . . . . . . . . . . . . . . . . . . . 11
4. Enabling Protocol Technologies . . . . . . . . . . . . . . . 11
4.1. Agent Governance Layer . . . . . . . . . . . . . . . . . 12
4.1.1. Registration and Discovery . . . . . . . . . . . . . 12
Chenchen Yang,, et al. Expires 21 January 2026 [Page 2]
Internet-Draft Short Title July 2025
4.1.2. Publish and Subscribe . . . . . . . . . . . . . . . . 12
4.1.3. Agent Communication . . . . . . . . . . . . . . . . . 12
4.1.4. Multimodal Data Management . . . . . . . . . . . . . 13
4.2. Meta Protocol Layer . . . . . . . . . . . . . . . . . . . 15
4.3. Security, Privacy and Trust Layer . . . . . . . . . . . . 15
4.4. Transport Layer . . . . . . . . . . . . . . . . . . . . . 16
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Informative References . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
6G as the next generation mobile communication technology will play
an essential role in the entire society digitalization process. On
one hand, 6G will provide better connectivity compared to 5G, and on
the other hand, 6G will go beyond connectivity, for instance,
features like native-AI and integrated communication and sensing will
enable new business revenues. It could be expected that enormous
amount of new use cases and services could be enabled by 6G.
However, increased new features as well as increased demands of
various use case scenarios will also bring challenges on 6G system
design. For instance, how to enrich Telco scope services but remain
operationally efficient? How to provide per user network
customization without scaling up the service provisioning complexity?
How to speed up new service delivery and identify relevant
standardization requirement to ensure interoperability?
Carrying these questions in mind, 6G is seeking answers by utilizing
promising technologies like agentic AI (empowered by foundation
model), which gained a lot of attention in recent years. Agentic AI
technology is rapidly evolving as businesses embrace autonomous
systems to streamline operations, enhance decision-making, and
personalize/customized user experiences. Therefore, agentic AI could
become the essential cornerstone of 6G [1]. Such technology trend is
quickly adopted by telecommunication field, for instance, ETSI and
3GPP have launched relevant studies in this scope. ETSI outlined its
vision of AI Agent based Core network in [2] and provided a detailed
study on use cases and requirements in [3]. 3GPP studied agent
services in 3GPP R20 SA1 [4]. Moreover, the work task#3 on AI and
agent has been adopted in 3GPP SA2 6G SID [5].
Chenchen Yang,, et al. Expires 21 January 2026 [Page 3]
Internet-Draft Short Title July 2025
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Characteristics of Mobile Network
2.1. Resource dynamicity
Mobile networks provide wireless connectivity services in a dynamic
environment with resource volatility and link unreliability. To
deliver high-quality connectivity services, networks utilize adaptive
mechanisms such as real-time resource scheduling, multipath
transmission, and dynamic retransmission schemes to mitigate the
uncertainty of radio resources and links. Unlike fixed networks with
static infrastructure, mobile systems must continuously calibrate
resource allocation to maintain link quality and ensure resilience
while sustaining service continuity for diverse applications.
2.2. Guaranteed Quality of Service (QoS)
Guaranteed QoS is a fundamental design principle in mobile networks,
enabling customized performance to meet heterogeneous application
demands. By establishing differentiated resource priorities,
networks enforce strict guarantees:ultra-reliable low-latency
transmission for critical industrial data transmission, prioritized
bandwidth allocation for real-time services (e.g., voice calls, video
conferencing), and flexible throughput for non-urgent traffic (e.g.,
email, file downloads). Such differentiation is also extending to
multi-modal services, e.g., XR service and digital twins, enabling
consistent performance across use cases and empowering mobile
networks as unified platforms for diverse digital services.
2.3. Mobility
Mobility management, a core feature of mobile networks, enables
continuous connectivity as terminals move across different locations.
Networks trigger seamless handover based on the radio conditions to
maintain communication without interruptions. Sometimes network
could allocate resources in advance by prediction to reduce latency
during transitions. This comprehensive mobility management framework
supports various usage scenarios, from stationary to high-speed
mobility and cross-regional roaming, making mobile networks essential
for critical applications that require constant access.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 4]
Internet-Draft Short Title July 2025
2.4. Multi-domain Interoperation
Mobile communication network is multi-technology and multi-business
domain in nature and it is important to establish a cohesive
connectivity ecosystem for different network operators, network
tenants and service providers. From the technology perspective,
inter-operator roaming leverages standardized protocols to empower
subscribers to access partner networks, ensuring seamless global
connectivity. Even within the same Mobile Network Operator (MNO)
environment, different network tenants can share the network under
the control of the MNO to achieve a better service performance
especially for 6G new services like sensing, AI and computing. On
the other hand, cross-domain collaboration supports mobile
communication network and Over-The-Top (OTT) service providers to
exchange capabilities via capability exposure to provide better
services for end users. This interoperability not only enhances
resource utilization but also unlocks novel use cases, facilitating
the development of a unified, scalable network infrastructure that
supports diverse applications.
2.5. Security, Privacy and Trust
The security capabilities of each generation are continuously
improving. The security architecture defines security domains, end-
to-end security mechanism, roaming security, and backward compatible
security measure. Achieving a balance between security and service
performance is the principle for security capability design.
Supporting multiple security mechanisms and being able to switch
between them is essential.
Privacy preservation can be achieved by encryption, anonymization,
zero-knowledge proofs, privacy computing, etc. The network provides
users with privacy protection based on the data lifecycle.
In terms of trust, the centralized trust model and the 3rd party
endorsement model co-exist alongside with the multi-lateral trust
model. The first two trust models provide single-point trust. The
latter multi-lateral trust model offers multiple roots of trust/
consensus trust, which facilities the fast establishment of cross-
trust domain connections.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 5]
Internet-Draft Short Title July 2025
2.6. Session-level Operation
In conventional mobile communication network design, PDU session
serves as the fundamental granularity for connectivity service
management. Through session management, mobile networks perform
resource allocation and policy enforcement at the QoS Flow level,
where individual service flows (e.g., video calls, IoT telemetry, or
cloud gaming streams) are mapped to dedicated QoS flows with specific
performance characteristics. Session management systems continuously
monitor Key Performance Indicators (KPIs) such as data rate, latency,
and packet loss ratio, enabling dynamic resource adjustment to
maintain connectivity service performance. This session-level
operation effectively bridges end-user QoS requirements with network
resource optimization, making it a key part of network design.
2.7. Systems Coexistence
In the actual deployed commercial networks, systems based on legacy
and state of the art standards operate concurrently due to gradual
deployment cycles, varying terminal lifespans, and global differences
in upgrade timelines. For example, in some regions, 4G and 5G
networks are operated alongside even older 3G systems. Even within a
single generation, almost every 1 or 2 years, a new release is
published and some features are updated accordingly. The coexistence
of systems from different generations and releases presents
challenges especially considering the backward and forward
compatibility.
3. Agent Protocols Requirements
3.1. Multi-agent system covering terminal, network and service
As proposed by ETSI [2], agentic AI technology could innovate the
mobile communication network architecture design, and 6G core network
could be established as a multi-agent system. There will be a broad
scope of agents, for instance 3GPP specified agents versus non-3GPP
agents, network agents versus UE agents, etc. These agents interact
and collaborate with each other to form a new communication paradigm,
and they could invoke different types of resources to support the
communication. Such resource could be for instance toolbox, memory,
connectivity resource, computing resource, etc. Under this context,
6G goes hand in hand with agentic AI technologies. 6G may utilize
agent protocols and relevant enabling technologies to enable the
following mobile network specific scenarios:
1. *6G network agents interaction:* 6G network internal agents
collaborate with each other, and invoke relevant resources;
Chenchen Yang,, et al. Expires 21 January 2026 [Page 6]
Internet-Draft Short Title July 2025
2. *UE agent/resource and network agent/resource:* 6G network agent
and UE agent collaborate with each other, 6G network agent
invokes resources on UE side, or vice versa;
3. *Service exposure:* Expose 6G network agent services and
resources to 3rd parties;
4. *Service consumption:* Consuming agent services and resources
from 3rd parties.
3.2. QoS Assurance for Multi-agent Communication
Agent traffic as the following characteristics:
3.2.1. Agent traffic may consist of multiple “Parts” and multi-modal
data：
Multi-agent communication traffic can contain several “Parts” (e.g.,
the smallest unit of content within a Message or Artifact [6]). The
data types of different Parts may be different and multi-modal (e.g.,
text, file, document, image, structured data, real-time audio stream,
video streaming).
The sizes of different Parts can be different and the transmission
modes may be also different (e.g., real-time steaming, Server-Sent
Events (SSE), or Push Notification).
Given these traffic characteristics above, dedicated QoS framework
should be designed for better performance.
3.2.2. Heterogeneous QoS requirements among multiple “Parts”：
Heterogeneity between Messages and Artifacts: An agent service flow
may contain Messages and/or Artifacts, their QoS requirements are
different, e.g., the Message’s requirement (e.g., timeliness,
accuracy, delay) is stricter.
Heterogeneity for “Parts” within a same Message or Artifact: The QoS
requirement (e.g., delay, deadline to be sent to peer endpoint) for
the different Parts of a same Message or Artifact may be the same or
not.
3.2.3. Burst Agent traffic
Agent service flow can be burst traffic: dynamic QoS should be
guaranteed and network resources should be adjusted in real-time when
the agent service flow is burst traffic instead of periodic traffic.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 7]
Internet-Draft Short Title July 2025
The characteristics of agent traffic above provides possibilities to
optimize QoS schemes and resource scheduling. The overall QoS of an
agent service flow should be guaranteed while the network resource
consumption is minimized. Parts with different QoS requirements may
be sent via different resources. For example, network resource
allocated to Parts of SSE/Streaming mode should keep active all the
time, but network resource allocated to Parts of Push Notification
mode can be (de)activated (e.g., released or suspended) flexibly.
The 6G network can adjust the resource scheduling and management
mechanism based on the different modes.
3.3. Agent Service Continuity
The continuity of agent service (e.g., message or task processing
result) should be guaranteed, e.g., in the mobility scenario for UE-
agent, or when the network addressing are changed. Additional
singling overhead for link (re)establishment and connectivity
disruption possibilities should be reduced. For instance, how to
wake up the equipment that hosts the agent. Agent instances can be
deleted or moved from one device to the other. Mobility handling in
such situations need to be carefully tackled. In addition, assume
that we have an agent on equipment that is currently running a task.
In the middle of the task, the equipment shuts down, but before it
does, the agent should be moved (sent) to another hosting equipment.
How to handle this situation and how the agent is notified?
3.4. Agent Task-Oriented Resource Management
The interaction between agents is typically task-oriented, where task
is a collection of actions to satisfy the user requirements. An
agent (i.e. agent client) may request another agent (i.e. agent
server) to perform a task [6]. It can query the task status during
the execution process and receive the results upon task completion.
As described in section 2.6, the mobile network operates based on
sessions. The traditional mobile network mainly performs
communication resource management to establish the UE-oriented
sessions and guarantee the QoS of a connectivity for a UE. However,
in an agentic system where multiple agents may collaborate to perform
a task, the network shall manage and schedule multi-dimensional
resources (such as communication resource, AI resource, computing
resource, data resource, etc.) to guarantee the QoS of a task.
Thus, a task session is required to support the communication of
different agents in network. And the network schedules resource and
guarantees QoS based on task granularity. Task information, e.g.,
task identifier, needs to be carried when Agents exchanges message or
task results, to associate with the corresponding task.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 8]
Internet-Draft Short Title July 2025
3.5. Intent-based Interaction
AI Agent is an automated intelligent entity capable of reasoning,
decision-making, executing tasks autonomously to achieve a specific
goal. A consumer provides the high-level goal description that needs
to be realized, instead of the step-by-step execution instruction,
based on which the agent can make execution plans through the local
AI model and invoke the proper tools to perform the task. Thus,
Agent protocols should support Agents to interact with each other or
with consumers through intents, to make the agent interaction
flexible enough.
3.6. Security, Privacy and Trust
The security control flow provides the access security control, the
secure transportation, and the cross-domain secure collaboration
capabilities, which is also important to agent protocol, as agents
will be one of the main communication end-point for both terminal and
network. Various cryptographic algorithms ensure the security of
transmission channels and the implementation of different levels of
security measures according to different policies.
The transmission of user consent and service visibility messages
between the network and the terminal side ensures that the
subscribers can be aware of the data usage purposes agreed upon
between the operator and the subscriber. AI Agent brings new
possibility to interact with each other with multi-modal information,
in this case, the procedure of user consent and service visibility
would not be ignored.
3.7. Agent Governance
AI Agents of different skills, capabilities, and vendors need to
discover each other when they collaborate to perform a task. It is
important to manage and control the agent information to enable an
agent to find others from a massive number of candidates.
The agent protocol has to support the agent (de-)registration, update
and discovery with an authority that may be deployed in central or
distributed way. It needs to consider how this authority to ensure
agent behaviors, agent skill set or capability publish, ensure
trustworthiness and discovery among agents, when designing the
protocols.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 9]
Internet-Draft Short Title July 2025
The effective publish-subscribe and request-response mechanisms for
discovering agents with required skills or capabilities are needed.
Wake up calls of equipment that hosts the agents need to be supported
as well. This is also related to service continuity which should be
maintained by the agentic ecosystem.
3.8. Backward Compatibility and Forward Compatible
As mentioned in 2.4 and 2.7, networks consist of multiple
stakeholders/parties with various UE, network, and protocol versions.
Therefore, agent protocols should be flexible, backward-compatible,
forward-compatible, potentially self-evolving (e.g., protocol self-
generation and negotiation, protocol version self-upgrade or merge)
in the future, and easy to evolve. More specifically, agent
protocols should be built upon existing network functions and
systems, while also remaining adaptable to future network
architecture/functions designs and system evolutions.
3.9. Extensibility
Agent protocols exist across multiple domains, such as UE, RAN, CN,
and DN. Additionally, service, data, and capability exposure may
originate from different networks. Therefore, agent protocol should
support the expanding and scaling of agents so that any type of
agents (e.g., Network autonomy agent and integrated sensing-AI Agent)
can be seamlessly integrated to the whole agent system. To achieve
this, task-based communication should be supported to enable rapid
service subscription and publishing between agents. ## Flexibility
AI Agents are capable of self-learning and self-evolving, which
implies that skills, capabilities, and accepted input and output
modalities may change as time goes. The agent protocol shall be
designed to be sufficiently flexible, allowing fast adaption to
expected changes.
Moreover, the protocol data objects and agent profiles exchanged
within the protocol shall be designed with flexible fields that are
easy to scale and modify without re-design.
3.10. Isolation
The messages or traffic flows of mobile network usually have
different-level of security or delay requirements. For example,
request messages from UE have higher security requirement than that
for common traffic flows. Thus, agent messages or traffic flows with
different performance requirements shall be decoupled and isolated to
facilitate differentiated processing.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 10]
Internet-Draft Short Title July 2025
3.11. Tool Invocation
The key feature of an agent is that it can invoke tools to execute
tasks autonomously. When AI Agents are introduced into 6G network,
various network capabilities, network functions and even the 3rd
party application functions can serve as tools to be invoked and used
by agents.
It is an important aspect to enable agents to invoke the required
tools accurately. Thus, it needs to consider how to enable the Agent
protocols to describe tools’ information explicitly and sufficiently
such that agents can easily identify target tools and easily learn
how to use them.
Different tools have different implementation methods and invocation
approaches. How to enable agents to flexibly invoke different tools
to support plug-and-play of future tools also needs to be considered.
3.12. Knowledge Retrieval
AI Agents need flexibly access to 6G network internal or external
data sources or knowledge bases to retrieve additional information
that may not be present within the local knowledge of an agent model.
The following issues need to be considered for Agent protocol design:
* *Metadata filtering:* how to filter the un-related data, e.g.
through time label, data type label.
* *Data representation:* how to represent data of knowledge so as to
improve transmission efficiency, such as represented as vectors or
graphs.
* *Retrieval mechanism:* how to search and retrieve the required
data, e.g. through similarity, key words, Token, natural language,
etc.
4. Enabling Protocol Technologies
Given the agent protocol requirements elaborated above, the following
enabling technologies can be investigated and standardized in IETF,
e.g., in terms of Agent governance layer, Meta protocol layer,
Security control layer, and Transport layer. Different features
should be provided in each layer, which will also be investigated and
introduced by 3GPP potentially.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 11]
Internet-Draft Short Title July 2025
4.1. Agent Governance Layer
4.1.1. Registration and Discovery
As shown in section 3.7, an authority is required to govern the
available AI Agents in the mobile network. The new agent will
register its agent profile to the authority, request to update the
agent profile when the agent skills or capabilities are changed, and
de-register from the authority when the agent is not used anymore.
The agent profile contains the key information about the agent, such
as agent role description, skills, capabilities, identifier, input
and output schema, vendor information, URL, etc.
The authority will store and maintain the agent profile of all the
available agents. When an agent wants to discover a target agent by
providing required agent description, the authority needs to perform
a search and matching between the provided description and the role
or skill description of registered agents, e.g. through cosine
similarity computation or Jaccard similarity computation [7][8].
4.1.2. Publish and Subscribe
The AI Agents can subscribe to the authority about the agent
information of specific set of agents so as to acquire their real-
time updates. The agent subscription can support various forms, such
as through agent ID, role type, skill type, etc.
When the profile of an agent is updated or the agent is de-
registered, the authority shall notify the other agents that
subscribed to the information of this agent as to prevent them from
sending inappropriate requests to the agent.
In addition, if there is no registered agent can perform the task
requested by an agent, or all available agents are in regions where
the request agent cannot render the task, the agent ecosystem can
also provide a registration mechanism such that an agent posts its
interest and gets notified as soon a new suitable agent comes and
registers with the ecosystem and comes online.
4.1.3. Agent Communication
In the mobile network, an agent may need to communicate with other
agents, resources (e.g., tools, data, or APIs), underlying
infrastructure (e.g. base stations, computing platform), and users
(e.g. UEs, applications). For different communication objects,
various protocol methods and data objects are needed to be defined.
To enable the flexible and intent-based interaction for agents, the
data objects are usually semi-structured, where the contents or
Chenchen Yang,, et al. Expires 21 January 2026 [Page 12]
Internet-Draft Short Title July 2025
values of each field are not pre-defined and only the key labels are
inserted to improve the understandability and completeness.
For the communication between agents, Google A2A defines several
methods based on JSON RPC 2.0, such as _message/send_, _task/get_,
_task/cancel_ [6], to support initiating a new task, updating or
deleting an existing task, querying the current status of a task,
subscribing the information of specific tasks. The data object
“_Task_” is exchanged with the methods, which includes the
information such as task identity, requirements, context, states,
outputs, etc. They can be applied to the mobile network with proper
extension combining mobile network characteristics. For example, the
task QoS information, network status and resource information also
need to be exchanged. And an agent can also refuse a task due to
reasons such as limited network resources and transmission buffer.
For the communication between agents and resources (such as tools,
data, APIs), the methods need to support AI Agents to invoke various
network and service functions, in order to trigger and execute
suitable network actions and operations, or to query network operator
data, network running log data, beyond connectivity data (e.g.,
sensing data, AI data), etc.
The methods for the communication between agents and users are
required to support a user to request a service (e.g. AI, sensing),
update or release a service, acquire the service status or result,
etc.
4.1.4. Multimodal Data Management
The data exchanged by agents are multi-modal, which can be text,
image, audio, video, structured data, etc. For example, A2A protocol
defines three types of data structures [6], i.e., TextPart,
ProfilePart and DataPart, to respectively carry texts, profile and
structured data. More kinds of data structures, such as AudioPart
and VideoPart, may be needed, e.g., a UE may initiate a request to
the agent in the mobile network through audio. Agent protocols
should be designed with the principle that the Agent data with
different modalities can be distinguished, based on which 6G network
can provide differentiated QoS assurances. For example, on one hand,
the Agent protocol can support to encapsulate data of different
modalities to distinct data structures. On the other hand, the 6G
network may establish different resources for transmitting various
modalities of data to perform QoS control and guarantee.
Besides, there shall be a closely integration design between the
agent ecosystem and the underlying network. For example, the
equipment hosting the agent may enter sleep mode when the agent is
Chenchen Yang,, et al. Expires 21 January 2026 [Page 13]
Internet-Draft Short Title July 2025
not executing task, and it needs to be woken up by a client agent so
that the server agent can process the multi-modal data from the
client agent to perform the task.
Multi-modal data is heterogeneous, meaning that data from different
modalities differ in structure, semantics and representation, but
they complement each other from various perspectives on the same
subject. Processing and analysis of multi-modal data are quite
challenging, which requires to consider multiple impact factors, such
as data alignment, feature extraction, etc. Thus, the following key
technologies shall be adopted.
- Data pre-processing technology: it includes data cleaning (removing
noise and redundant data), data standardization (converting data from
different modalities into a unified format), data augmentation
(increasing the diversity of data through operations such as
rotation, scaling).
- Feature extraction technology: it includes text, image, audio,
video feature extraction, etc.
- Data alignment technology: it is to ensure the consistency of data
across time, spatial location, and semantics.
- Fusion technology: it is to integrate diverse data to enhance its
completeness, accuracy, and usability.
* *Data pre-processing technology*: it includes data cleaning
(removing noise and redundant data), data standardization
(converting data from different modalities into a unified format),
data augmentation (increasing the diversity of data through
operations such as rotation, scaling).
* *Feature extraction technology*: it includes text, image, audio,
video feature extraction, etc.
* *Data alignment technology*: it is to ensure the consistency of
data across time, spatial location, and semantics.
* *Fusion technology*: it is to integrate diverse data to enhance
its completeness, accuracy, and usability
Chenchen Yang,, et al. Expires 21 January 2026 [Page 14]
Internet-Draft Short Title July 2025
4.2. Meta Protocol Layer
As mentioned in 3.8, 3.9 and 3.10, agent protocols should allow for
customization or privatization of the protocol while maintaining the
standardized agent protocols. Capabilities such as self-negotiation,
self-generation and self-evolving of agent protocol should be
supported to solve the compatibility problem, while protocol release
control is required to accommodate the co-existence of multi-releases
of those cross-operator and cross-domain agents. Additionally, agent
protocols should be able to call tools and data by calling network
functions.
Meta protocol layer should support the self-negotiation of agent [9].
Agent itself can decide the modality of interaction message like
text, voice, etc.
Considering the co-existence of multi-party and cross-domain agents
inside of the whole agent system, both the standardized protocol and
negotiated protocol can be potential options.
4.3. Security, Privacy and Trust Layer
As mentioned in 3.6, agent protocols should consider the requirements
of security, privacy and trust. Some of the enabling technologies
are listed as below:
- Distributed Identity (DID) system for AI Agents
Based on the mobile network oriented DID system, the network offers
rapid authentication and key establishment based on multiple roots of
trust, fine-grained authorization, and selective privacy disclosure
via agent protocols. Simultaneously, the DID system supports the
security of cross-domain, e.g. working for different groups of AI
Agents, connections through the same DID translation and related
policies.
- Distributed ledger
Distributed ledger technology provides a foundation of trust for
multi-party collaboration, which will be common case for AI Agents
ineraction. Acting as a bridge of trust, it enables different
systems holding credentials issued by various authoritative
institutions to achieve mutual trust. As a consensus infrastructure,
it offers tamper-proof functionality and transparent auditability for
critical information.
- Ciphertext-based computing technology
Chenchen Yang,, et al. Expires 21 January 2026 [Page 15]
Internet-Draft Short Title July 2025
Considering the elimination of user privacy concerns, ciphertext-
based computing technology provides the capability of "computing
without knowing" for network queries and computations on user data.
Agent protocols should include this option to ensure that data
privacy at different levels can be handled in an acceptable manner.
- Quantum-safe technologies
Quantum-safe technologies include post-quantum cryptography (PQC) and
its protocols based on cryptographic techniques, as well as quantum
secure transmission methods such as Quantum Key Distribution (QKD).
The preemptive deployment of quantum-safe technologies, such as PQC
migration, will prepare for defending against quantum attacks. The
algorithm set for agent protocols should consider quantum-safe from
day 1.
4.4. Transport Layer
As mentioned in 3.2, 3.3, 3.4 and 3.11, the Agent QoS and service
continuity should be guaranteed. Agent messages or traffic flows
with different performance requirements shall be decoupled and
isolated. The following potential technologies for transport layer
protocols can be investigated:
* *To support stream multiplexing, collaboration and grouping:*
e.g., different “Parts” of agent traffic with different sizes can
be sent in parallel via a group of transport streams to enable
them to arrive to peer node synchronously within a strict delay
budget, or sent asynchronously with different priorities within a
same stream if synchronous arrival to peer node is not needed.
The balance between the complexity of transport connection
establishment and the flexibility of scheduling should be
considered.
* *To support a reliable and efficient transmission mechanism for
agent traffic:* A) Stream multiplexing of multiple agent traffic
data streams, B) Traffic steering, switching, splitting of
multiple agent traffic data streams.
* *To natively support connection migration, quick link
establishment*: so that agent service continuity could be
guaranteed in mobility scenarios.
* *To support burst agent traffic transmission*: Burst traffic
information can be encapsulated in protocol header for better QoS
guarantee and resource real-time scheduling and adjustment. The
QoS (e.g., latency and timeliness) is guaranteed toward the whole
burst data set of agent traffic rather than a specific packet.
Chenchen Yang,, et al. Expires 21 January 2026 [Page 16]
Internet-Draft Short Title July 2025
5. Summary
A hierarchical consideration of agent protocol is definitely
important to meet different kinds of requirements, e.g., from 6G
network. Collaborations between IETF, ETSI and 3GPP and
collaborations across different work groups (e.g., for agent
protocol, transport protocol, and security) of IETF are required.
6. Reference
6.1. Informative References
[1] Li, Xu, Weisen Shi, Hang Zhang, Chenghui Peng, Shaoyun Wu, and
Wen Tong. "The Agentic-AI Core: An AI-Empowered, Mission-Oriented
Core Network for Next-Generation Mobile Telecommunications."
_Engineering_ (2025).
[2] ETSI GR ENI 051 V4.1.1, “Experiential Networked Intelligence
(ENI); Study on AI Agents based Next-generation Network Slicing”,
2025.02.
[3] ETSI ENI ISG 055 Early Draft, “Use Cases and Requirements for AI
Agents based Core Network”, 2025.06.04.
[4] 3GPP TR 22.870 (V0.2.0): “Study on 6G Use Cases and Service
Requirements; Stage 1 (Release 20)”.
[5] 3GPP SP-250806: "Study on Architecture for 6G System".
[6] A2A Protocol. "Specification". https://a2a-protocol.org/latest/
specification/, 2025.
[7] D. Gunawan, C. A. Sembiring, M. A. Budiman, “The
implementation of cosine similarity to calculate text relevance
between two documents”, Journal of physics: conference series, 2018.
[8] S. Bag, S. K. Kumar, M. K. Tiwari, “An efficient
recommendation generation using relevant Jaccard similarity”,
Information Sciences, 2019.
[9] Marro, Samuele, Emanuele La Malfa, Jesse Wright, Guohao Li, Nigel
Shadbolt, Michael Wooldridge, and Philip Torr. "A scalable
communication protocol for networks of large language models." arXiv
preprint arXiv:2410.11905 (2024).
Chenchen Yang,, et al. Expires 21 January 2026 [Page 17]
Internet-Draft Short Title July 2025
7. Security Considerations
This document should not affect the security of the Internet.
8. IANA Considerations
This memo includes no request to IANA.
9. Appendix
10. Normative References
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Authors' Addresses
Chenchen Yang,
Huawei
Lianqiu Lake, Qingpu District
Shanghai
201799
China
Email: yangchenchen7@huawei.com
Huanhuan Huang,
Huawei
Lianqiu Lake, Qingpu District
Shanghai
201799
China
Email: huanghuanhuan9@huawei.com
Chenchen Yang,, et al. Expires 21 January 2026 [Page 18]
Internet-Draft Short Title July 2025
Arashmid Akhavain,
Huawei
303 Terry Fox Drive, Kanata
Ottawa K2K 3J1
Canada
Email: arashmid.akhavain@huawei.com
Faye Liu,
Huawei
9 North Buona Vista Dr.
SINGAPORE 117674
Singapore
Email: liufei19@huawei.com
Xueli An,
Huawei
Riesstr. 25
80992 Munich
Germany
Email: Xueli.An@huawei.com
Weijun Xing,
Huawei
Lianqiu Lake, Qingpu District
Shanghai
201799
China
Email: xingweijun1@huawei.com
Jinyan Li,
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: lijinyan@chinatelecom.cn
Aijun Wang,
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Chenchen Yang,, et al. Expires 21 January 2026 [Page 19]
Internet-Draft Short Title July 2025
Email: wangaj3@chinatelecom.cn
Yang Wencong,
China Unicom
No. 9 Shouti South Road, Haidian District
Beijing
100044
China
Email: yangwc27@chinaunicom.cn
Chenchen Yang,, et al. Expires 21 January 2026 [Page 20]