



DMSC Working Group                                                 X. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 23 November 2026                                         B. Liu
                                                     Huawei Technologies
                                                                  C. Lin
                                                    New H3C Technologies
                                                             22 May 2026


 Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
                   draft-li-dmsc-inf-architecture-07

Abstract

   This document presents an architectural framework for dynamic multi-
   agent collaboration from an infrastructure perspective.  It outlines
   the network requirements introduced by large-scale agents
   collaboration, and proposes a systematic approach to enabling Dynamic
   Multi-agent Secured Collaboration (DMSC) through infrastructure
   capabilities.  The architecture focuses on how network control and
   forwarding functions can actively participate in agent collaboration.

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 23 November 2026.

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.



Li, et al.              Expires 23 November 2026                [Page 1]

Internet-Draft              DMSC Architecture                   May 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Network Requirements  . . . . . . . . . . . . . . . . . . . .   4
   5.  DMSC Architecture Overview  . . . . . . . . . . . . . . . . .   5
     5.1.  DMSC Infrastructure Architecture  . . . . . . . . . . . .   5
   6.  Infrastructure Functions Enabling Active Network
           Participation . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Agent Identification and Capability Directory . . . . . .   8
     6.2.  Infrastructure-Level Agent Discovery  . . . . . . . . . .   8
     6.3.  Semantic Routing  . . . . . . . . . . . . . . . . . . . .   8
     6.4.  Secure Collaboration Capability and Policy  . . . . . . .   9
     6.5.  Operational Visibility  . . . . . . . . . . . . . . . . .   9
   7.  Deployment Usecases . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Fixed Network . . . . . . . . . . . . . . . . . . . . . .  10
     7.2.  Mobile Operator Network . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  14
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Intelligent agents have evolved rapidly in recent years, driven by
   advances in artificial intelligence models, computing platforms, and
   network connectivity.  Early forms of agents were typically embedded
   within isolated systems and designed to perform narrowly defined
   tasks under predefined conditions.  Their interactions with external
   entities were limited and often mediated by tightly coupled
   application logic [IoA].












Li, et al.              Expires 23 November 2026                [Page 2]

Internet-Draft              DMSC Architecture                   May 2026


   With the increasing availability of large-scale AI models, edge
   computing resources, and programmable network infrastructures, agents
   are becoming more autonomous, adaptive, and capable of operating
   across distributed environments.  Modern agents can perceive changes
   in their environment, make decisions based on local or shared
   information, and interact with other agents and tools in order to
   achieve complex objectives.  These interactions are no longer
   confined to static configurations or single administrative domains,
   but increasingly span devices, networks, and application platforms.

   As agents continue to proliferate, they are forming large-scale
   collaborative systems in which multiple agents dynamically discover
   each other, exchange information, and coordinate actions.  Such
   systems exhibit highly dynamic behavior, including frequent changes
   in agent population, roles, and interaction patterns.  The resulting
   agent ecosystems resemble an open, interconnected environment rather
   than a collection of isolated applications.

   The evolution toward large-scale, dynamic agent ecosystems introduces
   new challenges for the underlying network infrastructure.  While
   agents are capable of sophisticated reasoning and decision-making,
   their ability to collaborate effectively depends on the availability
   of common, scalable, and interoperable networking support.

   This document focuses on the architectural aspects of enabling
   dynamic multi-agent collaboration from a network and infrastructure
   perspective.  It examines how network control and forwarding
   functions can be extended to recognize agents as first-class entities
   and provide generic support for agent identification, discovery,
   semantic routing, and coordination.  The architecture is intended to
   support a wide range of agent types, including on-device agents,
   network-resident agents, and third-party agents, without imposing
   assumptions about their internal implementation.

   The scope of this document is limited to architectural concepts and
   functional building blocks.  It does not define specific protocols,
   data models, or security mechanisms, nor does it prescribe particular
   deployment scenarios or application workflows.  Instead, it provides
   a foundational framework upon which more detailed specifications,
   including protocol designs and security architectures, can be
   developed in subsequent documents.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .




Li, et al.              Expires 23 November 2026                [Page 3]

Internet-Draft              DMSC Architecture                   May 2026


3.  Terminology

   The following terms are defined in this draft:

   *  DMSC: Dynamic Multi-agent Secured Collaboration.  The framework
      and infrastructure enabling secure and efficient collaboration
      among dynamic agents.

   *  Agent: An automated intelligent entity capable of e.g interacting
      with its environment, acquiring contextual information, reasoning,
      self-learning, decision-making, executing tasks (autonomously or
      in collaboration with other Al Agents) to achieve a specific goal.

   *  Agent Gateway: The Agent Gateway is a functional entity that
      serves as the infrastructure for enabling interconnection and
      collaboration among agents.  While its core role remains
      consistent, it is inherently flexible in deployment and can be
      realized in various forms—ranging from a network service to a
      dedicated gateway—depending on the architectural and operational
      requirements of different network environments.

   *  Agent Management Center (AMC): It is the trusted infrastructure
      service responsible for agent identity lifecycle management and
      credential issuance.

4.  Network Requirements

   The proliferation of intelligent agents fundamentally reshapes
   interaction patterns and control dynamics in future networks.  Agent
   interactions are typically short-lived, context-dependent, and driven
   by task semantics rather than static endpoints.  Moreover, agents may
   dynamically join or leave collaborative groups, migrate across
   administrative domains, or change roles over time.  These
   characteristics introduce new requirements for network
   infrastructures, including agent-level identity management,
   capability-aware communication, scalable registration and discovery,
   cross-domain collaboration support, and adaptive routing, as also
   reflected in [draft-yu-ai-agent-use-cases-in-6g].[usecase]

   Collectively, these requirements indicate that future networks must
   go beyond passive connectivity and actively support dynamic multi-
   agent collaboration.  The core idea of Dynamic Multi-agent Secured
   Collaboration (DMSC) is to elevate key collaboration-related
   functions into the network infrastructure.  Instead of embedding all
   coordination logic within applications or agent frameworks, DMSC
   leverages infrastructure-level capabilities exposed through control-
   plane and forwarding-plane functions.  This approach enables the
   network to recognize agents as first-class entities, maintain high-



Li, et al.              Expires 23 November 2026                [Page 4]

Internet-Draft              DMSC Architecture                   May 2026


   level collaboration context, and make informed decisions on
   discovery, routing, and coordination support in a scalable and
   interoperable manner.

5.  DMSC Architecture Overview

5.1.  DMSC Infrastructure Architecture

   Figure 1 illustrates the overall architecture for dynamic multi-agent
   collaboration from an infrastructure-centric perspective.  The
   architecture positions the network infrastructure as an active
   participant in agent collaboration, while preserving the autonomy and
   task-level reasoning of individual agents.  In this architecture, the
   network does not execute agent logic or interpret task semantics.
   Instead, it provides generic support functions that enable agents to
   collaborate more efficiently and reliably.  Agents remain autonomous,
   while the network supplies shared infrastructure capabilities.

   From an infrastructure perspective, the architecture is organized
   into three logical layers:

   *  Management Plane: governs authentication, capability taxonomy,
      observability and policy aspects.

   *  Control Plane: Manages agent registration, discovery, invocation,
      lifecycle, and capability information maintenance and so on.

   *  Forwarding Plane: Supports semantic routing for agent
      interactions.






















Li, et al.              Expires 23 November 2026                [Page 5]

Internet-Draft              DMSC Architecture                   May 2026


   +------------------------------------------------------------------------------------+
   |                         Management & Orchestration Plane                           |
   |  +--------------+   +-------------------+   +-----------------+  +--------------+  |
   |  |  Agent       |   |Capability Taxonomy|   | Observability & |  |Policy Manager|  |
   |  |Authentication|   |(Agent,Capability) |   | Analytics       |  | (Rules...)   |  |
   |  +--------------+   +-------------------+   +-----------------+  +--------------+  |
   +------------------------------------------------------------------------------------+
                                       |        ^
                                       v        |
+-------------------------------------------------------------------------------------------+
|                                  Network Infrastructure                                   |
| +---------------------------------------------------------------------------------------+ |
| |         AGW 1                              AGW 2                      AGW 3 ...       | |
| | +-------------------------+    +-------------------------+     +--------------------+ | |
| | |      Control Plane      |    |      Control Plane      |     | Control Plane      | | |
| | |-------------------------|    |-------------------------|     |--------------------| | |
| | | - Agent Registration    |<-->| - Agent Registration    |<--> | ...                | | |
| | | - Agent Invocation      |    | - Agent Invocation      |     |                    | | |
| | | - Agent Discovery       |    | - Agent Discovery       |     |                    | | |
| | | - Capability Directory  |    | - Capability Directory  |     |                    | | |
| | +-------------------------+    +-------------------------+     +--------------------+ | |
| |            | Control & Policy               | Control                   | Control     | |
| |            v                                v & Policy                  v & Policy    | |
| | +------------------------+     +-------------------------+      +-------------------+ | |
| | | Forwarding Plane       |     |      Forwarding Plane   |      | Forwarding Plane  | | |
| | |------------------------+     +-------------------------+      +-------------------+ | |
| | | - Semantic  Routing    |     |    ...                  |      |  ...              | | |
| | | - ...                  |     |                         |      |                   | | |
| | +------------------------+     +-------------------------+      +-------------------+ | |
| +---------------------------------------------------------------------------------------+ |
+------------------^  ------------------------^ ------------------------------^ ------------+
                   |Registration              |  Registration                 |Registration
                   |                          |                               |
         +--------------------+     +--------------------+         +--------------------+
         |        Agent A     |     |        Agent B     |         |        Agent C     |
         |--------------------|     |--------------------|         |--------------------|
         | - Capabilities     |     | - Capabilities     |         | - Capabilities     |   ...
         | - Local Reasoning  |     | - Local Reasoning  |         | - Local Reasoning  |
         +--------------------+     +--------------------+         +--------------------+
   Figure 1 The infrastructure architecture of dynamic multi-agent collaboration

   On top of this architecture, agents engage in collaborative
   activities driven by task intents, shared goals, and capability
   information.  Agents are responsible for local reasoning, decision-
   making, and execution of task-specific logic.  The network does not
   interpret agent semantics or execute agent logic; instead, it
   provides common infrastructure capabilities that support efficient
   and scalable collaboration among agents.  Above the network



Li, et al.              Expires 23 November 2026                [Page 6]

Internet-Draft              DMSC Architecture                   May 2026


   infrastructure, a Management and Orchestration Plane provides non-
   real-time management functions, including agent authentication, agent
   capability taxonomy management, policy management, observability and
   analytics.  This plane supplies policy, trust, and state-related
   inputs to the network infrastructure.

   The network infrastructure itself is composed of multiple agent
   gateways, each implementing a common set of logical functions, and
   the gateways support hierarchical deployment.  Within each gateway,
   the Control Plane provides agent-aware control functions, including
   agent identity management, capability directory maintenance,
   registration, and discovery control.  These functions enable the
   network to recognize agents as first-class entities and maintain a
   consistent view of agent-related information across the
   infrastructure.  By decoupling agent identity from physical location
   through capability identifiers, the control plane supports dynamic
   agent lifecycle events such as mobility, instantiation, and
   termination.

   The Forwarding Plane supports semantic routing by forwarding requests
   based on capability identifiers—such as /capability/ocr—rather than
   static IP addresses.  When multiple instances of a capability are
   available, the forwarding plane may select a target based on real-
   time health and availability information—such as liveness or
   load—provided by the control plane.  In the event of failure, it can
   perform fast failover to an alternative instance within the same
   capability group, ensuring continuity of service.

   When an agent joins the network, it authenticates and obtains trusted
   authorization through network controller; only verified agents may
   register their capabilities—such as “supports high-precision OCR” or
   “performs GDPR-compliant de-identification”—which are stored locally
   to form a capability directory.  When another agent issues a
   capability-based discovery request (e.g., “find an OCR agent”), the
   local agent gateway either responds directly or securely synchronizes
   capability information with other agent gateways—including across
   domains or clouds—to locate eligible candidates.  Once a target is
   identified, the request is forwarded via semantic routing (e.g.,
   using /capability/ocr) to the appropriate instance.

   Overall, this architecture establishes a clear division of
   responsibilities: agents focus on intelligent behavior and task
   execution, while the network infrastructure provides capability-based
   control, semantic forwarding, and secure coordination mechanisms.
   This separation enables dynamic multi-agent collaboration to scale
   across heterogeneous environments—on-premises, at the edge, or in the
   cloud—while allowing agents and the network to evolve independently.




Li, et al.              Expires 23 November 2026                [Page 7]

Internet-Draft              DMSC Architecture                   May 2026


6.  Infrastructure Functions Enabling Active Network Participation

6.1.  Agent Identification and Capability Directory

   In large-scale dynamic multi-agent environments, agents cannot be
   effectively supported using traditional host- or service-based
   identifiers alone.  Agents may be instantiated dynamically, migrate
   across network locations, or operate concurrently on the same
   physical node.  As a result, the network requires a mechanism to
   identify agents as logical entities that are decoupled from network
   topology.

   The proposed architecture introduces network-visible agent
   identifiers that represent agents independently of their physical
   location or hosting environment.  These identifiers enable the
   network to consistently recognize agents across control and
   forwarding functions, even as underlying network bindings change.
   Beyond basic identification, the architecture supports forming an
   agent capability directory on agent gateways.

6.2.  Infrastructure-Level Agent Discovery

   Agent discovery is a fundamental prerequisite for collaboration, yet
   traditional discovery mechanisms are typically designed for
   relatively static services or tightly scoped environments.  In
   contrast, multi-agent collaboration requires discovery mechanisms
   that can operate across heterogeneous platforms, adapt to dynamic
   agent populations, and respect administrative boundaries.

   In DMSC architecture, agent discovery is provided as an
   infrastructure-level function, rather than being entirely implemented
   within agent frameworks.  The network supports discovery queries
   based on agent identifiers, advertised capabilities.  This allows
   agents to locate suitable collaborators without requiring global
   knowledge or centralized coordination.

6.3.  Semantic Routing

   Traditional routing mechanisms forward packets based on destination
   addresses without awareness of application intent.  In dynamic multi-
   agent collaboration, however, interactions are driven by *what* is
   needed—such as a specific capability—rather than *where* a fixed
   endpoint resides.  The DMSC architecture addresses this by
   introducing semantic routing: requests are expressed in terms of
   agent capabilities (e.g., "/capability/ocr").






Li, et al.              Expires 23 November 2026                [Page 8]

Internet-Draft              DMSC Architecture                   May 2026


   Semantic routing enables flexible agent invocation without hard-coded
   endpoints.  A request for a given capability can be routed to any
   authorized and available instance that has declared that capability.
   If the selected instance becomes unavailable, the network may fail
   over to another instance within the same capability group, provided
   such redundancy exists.

6.4.  Secure Collaboration Capability and Policy

   Effective collaboration among dynamic agents requires consistent
   handling of capabilities and policies, especially when interactions
   span multiple domains or network segments.  The DMSC architecture
   supports secure synchronization of capability declarations and policy
   constraints at the infrastructure level.

   Capability information associated with an agent—such as its declared
   functions (e.g., OCR, payment validation) and security attributes
   (e.g., GDPR compliance, authentication requirements)—can be
   registered with the control plane and synchronized across domains.
   Where appropriate, these capability descriptions may be bound to
   policy rules that govern access and interaction.  Security-related
   attributes, such as authorization scope or domain-specific
   constraints, can be attached to capability entries to ensure that
   interactions remain compliant with local regulations and trust
   boundaries.  In cross-domain scenarios, policy abstraction mechanisms
   support controlled translation or normalization to enable
   interoperability while respecting local governance.

6.5.  Operational Visibility

   As multi-agent systems scale, gaining visibility into collaboration-
   level behavior becomes essential for effective operation and
   troubleshooting.  Traditional network observability focuses on flows
   and endpoints, offering limited insight into agent interactions and
   coordination dynamics.  The DMSC architecture introduces operational
   visibility at the collaboration level by enabling controlled
   observation of key interaction events.

   Observable entities may include:

   *  Agent registration and abstract capability advertisements.

   *  Capability-based discovery activities and outcomes.

   *  Semantic routing decisions and high-level invocation outcomes.

   *  Association with network resources and applied policy controls.




Li, et al.              Expires 23 November 2026                [Page 9]

Internet-Draft              DMSC Architecture                   May 2026


   This visibility is not intended to expose agent internals or infer
   application logic, but to provide sufficient information for
   monitoring, auditing, root cause analysis, and performance
   optimization.  The collected telemetry can be used by management and
   orchestration systems to support long-term optimization—such as
   identifying underutilized capabilities or detecting policy
   violations.  It may also inform policy refinement and infrastructure
   planning, but does not drive real-time control-plane decisions or
   forwarding-plane behavior.  To address privacy and security concerns,
   exposure of observable data is controlled through policy mechanisms,
   ensuring that only authorized parties can access relevant
   information.

7.  Deployment Usecases

   This section presents two deployment cases for fixed network and
   mobile network environments respectively, illustrating the practical
   implementation of the proposed architecture.  This is not intended to
   restrict implementation solutions, but to demonstrate how network
   infrastructure defined in the architecture can be deployed by
   leveraging existing or upgraded network elements.

7.1.  Fixed Network

   In a fixed broadband network, gateways can be implemented as enhanced
   agent gateways deployed at aggregation layers or service edge nodes.
   These AGWs are positioned logically between access networks and
   service domains, enabling them to perform registration, authorization
   mediation, capability abstraction, and semantic routing functions
   without requiring changes to end-user access infrastructure.

   In such deployments as shown in figure 6:

   *  Agent registration and authentication are performed via the AGW
      and Agent Management Center (AMC).

   *  Capability digest exchange occurs between AGWs.

   *  Semantic resolution is handled hop-by-hop across AGWs.

   *  Agents establish peer-to-peer semantic sessions after gateway-
      mediated coordination.

   This example shows that agent gateways in fixed network can be
   equipped with logical coordination functions to serve as functional
   gateways, enabling agent registration, synchronization, scheduling
   and other related operations.




Li, et al.              Expires 23 November 2026               [Page 10]

Internet-Draft              DMSC Architecture                   May 2026


                                    +------------------------------+
                               +----|    Agent Management Center   |------+
                               |    +------------------------------+      |
                               |                                          |
      +----------+      +---------+                                  +---------+   +---------+
      | Agent A  | ---- | AGW 1   |<-------------+    +------------->|  AGW 2  |---| Agent B |
      +----------+      +---------+              |    |              +---------+   +---------+
                                                 |    |
                                             +------------+
                                             |  Routers   |
                                             +------------+

                     Figure 2  Deployment Example: Fixed Network with Agent Gateway Realization

7.2.  Mobile Operator Network

   In a mobile operator network (e.g., a 6G network), AI capabilities
   and technologies are expected to be leveraged subject to operator
   policies and configurations.  AI Agents, which refer generally to
   agents that autonomously perform tasks on behalf of users, systems,
   and/or applications, can understand complex requests and improve
   network efficiency.  In addition, capabilities and services such as
   sensing, real-time data processing, telemetry, analytics, and others
   within a 6G network may also be provided as “Tools” to third-party
   applications.

   Below figure shows an example of AI agents, an Agent Management
   Center and an Agent Gateway deployed in the mobile operator network.
   The architecture of 6G is still in discussion, thus some
   functionalities are described by using some 5G NFs as typical
   examples.

   User initiates intent in nature language and receive human-readable
   result.  Intent analysis takes place at two stages:

   *  (Optional, based on UE capabilities) The UE converts natural-
      language intent to operator-defined intent and also translates
      operator-defined results to human-readable results based on
      internal implementation.

   *  (Mandatory) The network function (NF) with agent capability in the
      mobile operator core network comprehends and analyzes the intent.
      Based on the analyzed intent, a subsequent workflow is generated.
      Typically, the NF that terminates NAS messages (e.g., AMF in 5G)
      can either comprehend the intent (when the AMF includes agent
      capability) or forward the intent to an agent-enabled NF in the
      core network (when the AMF does not include agent capability).




Li, et al.              Expires 23 November 2026               [Page 11]

Internet-Draft              DMSC Architecture                   May 2026


   Agent-enabled NFs request AIC allocation from the Agent Gateway.  The
   NF (e.g., AMF in 5G) that terminates NAS messages and manages UE
   registration may request AIC from the Agent Gateway on behalf of the
   agent in the UE.  The Agent Management Center is responsible for
   agent authentication and authorization.  The authentication and
   authorization procedure for agents (Agents ↔ Agent Gateway ↔ Agent
   Management Center) may reference the authentication and authorization
   procedure for UEs (e.g., UEs <-> AMF <-> UDM <-> AUSF in 5G).

   Agent-enabled NFs register with the Agent Gateway and discover each
   other by querying the Agent Gateway.  The registration and discovery
   mechanism is similar to the functionality provided by the NRF in 5G
   networks.  However, standardization of agent capabilities is
   essential for the accuracy and efficiency of agent discovery.  The NF
   (e.g., AMF in 5G) that terminates NAS messages and manages UE
   registration may interact with the Agent Gateway on behalf of the
   agent in the UE.  However, the discovery of the agent on the UE takes
   the UE connection state into account.

   Service-based interfaces may be enhanced to support agent
   communication, or agent-based interfaces may be introduced to support
   AI traffic carrying Agent-to-Agent semantic data.  The AI
   capabilities supported by the mobile operator network may be exposed
   as agent tools and invoked by third-party AI agents via the Agent
   Gateway, which performs protocol conversion for different agent
   communication protocols if necessary, while AI traffic transmitted
   through the mobile operator network may be identified to guarantee
   performance requirements.

   The NF supporting session management (e.g., SMF in 5G) can be
   enhanced, or a new NF may be introduced to support the management of
   Agent-to-Agent semantic sessions between the agent residing in the UE
   and the agent residing in the operator core network.


















Li, et al.              Expires 23 November 2026               [Page 12]

Internet-Draft              DMSC Architecture                   May 2026


     +-------+
     |  Uesr |
     +-+-----+
       |  ^
       |  |
       |  |
+------+--+-------+                 +----------------------------------------------------------------------+                +------------+
|      |  |       |                 |                                                   Mobile Operator    |                | Third Party|
|      v  |       |                 |                                                      Corenetwork     |                |            |
|  +------+----+  | Operator-defined|                                                                      |                |            |
|  |  UE APP   |  | <-------------> |    +--------+    +-----------+    +----------+                       |<-------------> |  +------+  |
|  +--+--------+  |                 |    |   NF   |    | NF with   |    |   Agent  |                       |                |  | Agent|  |
|     |   ^       |                 |    |        |    |   Agent   |    |  Gateway |                       |                |  +------+  |
|     v   |       |                 |    +---+----+    +-----+-----+    +-----+----+                       |                |            |
|  +------+----+  |                 |        |               |                |                            |                |  +------+  |
|  | UE OS Layer  |                 |        |               |                |                            |                |  | Agent|  |
|  |   Agent   |  |                 |        |               |                |     Service Based Interface|                |  +------+  |
|  +--+--------+  | Intent Execution|        |               |                |      (Agent Enhancement)   |                |            |
|     |   ^       | <-------------> |--------+----+----------+----+-----------+----+------------------     | <------------->|     .      |
|     |   |       |      Result     |             |               |                |                       |                |     .      |
|     |   |       |                 |             |               |                |                       |                |     .      |
|     v   |       |                 |             |               |                |                       |                |     .      |
|  +------+----+  |                 |      +------+----+     +----+---+    +-------+-----+                 |                |     .      |
|  | UE Modem  |  |                 |      |  NF with  |     |   NF   |    |    Agent    |                 |                |            |
|  |           |  |                 |      |   Agent   |     |        |    | Management  |                 |                |  +------+  |
|  +-----------+  |   AI traffic    |      +-----------+     +--------+    |    Center   |                 |    AI Traffic  |  | Agent|  |
|                 | <-------------> |                                      +-------------+                 | <------------->|  +------+  |
|                 |     Transfer    |                                                                      |     Transfer   |            |
| UE              |                 |                                                                      |                |            |
+-----------------+                 +----------------------------------------------------------------------+                +------------+
                                              Figure 3 Deployment Example: Mobile Operator Network

8.  Security Considerations

   This architecture introduces several security considerations,
   including risks related to agent identity spoofing, capability
   misrepresentation, semantic routing manipulation, cross-domain trust
   inconsistencies, and information leakage through enhanced
   observability.  Detailed security mechanisms are outside the scope of
   this document.

9.  IANA Considerations

   TBD







Li, et al.              Expires 23 November 2026               [Page 13]

Internet-Draft              DMSC Architecture                   May 2026


10.  Acknowledgement

   TBD

11.  Normative References

   [IoA]      L, J., "Internet of Agents – Definition, Architecture and
              Applications.
              https://aip.openatom.tech/explore/journalism/
              detail/501037383572131840", October 2025.

   [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/info/rfc2119>.

   [usecase]  Y, M., "AI Agent Use Cases and Requirements in 6G Network.
              draft-yu-ai-agent-use-cases-in-6g.
              <https://datatracker.ietf.org/doc/html/draft-yu-dmsc-ai-
              agent-use-cases-in-6g>", July 2025.

Authors' Addresses

   Xueting Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: lixt2@foxmail.com


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn


   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: leo.liubing@huawei.com




Li, et al.              Expires 23 November 2026               [Page 14]

Internet-Draft              DMSC Architecture                   May 2026


   Changwang Lin
   New H3C Technologies
   8 Yongjia North Road
   Beijing
   Haidian District, 100094
   China
   Email: linchangwang.04414@h3c.com












































Li, et al.              Expires 23 November 2026               [Page 15]
