Agentic Interface to In-Network Computing Functions for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor#22, Daewangpangyo-ro 712beon-gilSeongnamGyeonggi-Do13488Republic of Korea+82 31 739 7463bman@keti.re.krhttps://www.keti.re.kr/eng/main/main.php
Department of Computer Science & Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor#22, Daewangpangyo-ro 712beon-gilSeongnamGyeonggi-Do13488Republic of Korea+82-31-739-7507pusik.park@keti.re.krhttps://www.keti.re.kr/eng/main/main.php
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor#22, Daewangpangyo-ro 712beon-gilSeongnamGyeonggi-Do13488Republic of Korea+82-31-739-7436shjang@keti.re.krhttps://www.keti.re.kr/eng/main/main.php
Network Management
Internet Research Task ForceIn-Network Computing Functions; Software-Defined Vehicle;
Cooperative Intelligent Transportation Systems; Agentic AI;
Agent-to-Agent Communication; Mobile Network Operator
This document specifies a structured framework for orchestrating,
managing, and monitoring In-Network Computing Functions (ICFs) for
Software-Defined Vehicles (SDVs) in Cooperative Intelligent
Transportation Systems (C-ITS), with a first-class role given to the
Agent-to-Agent (A2A) communication paradigm. SDVs decouple vehicular
functions from underlying hardware and expose them as software-driven,
continuously updatable services; this architectural shift makes them
natural participants in an agentic control plane that spans vehicles,
roadside infrastructure, and mobile networks. AI agents are co-located
with each functional entity of the C-ITS architecture (e.g., C-ITS
Center, Government Public Center, C-ITS Infra, Mobile Network Operator
(MNO), Roadside Unit (RSU), SDV, and Vulnerable Road User (VRU)) and
interact over an A2A protocol overlay to advertise capabilities,
discover peers, negotiate resources, and coordinate the placement and
execution of ICFs across multi-domain networks. In the context of
Vehicle-to-Everything (V2X) communications, this agentic overlay
enables efficient management of Vehicle-to-Vehicle (V2V) and
Vehicle-to-Infrastructure (V2I) communications and their integration
with C-ITS by leveraging in-network computing to optimize real-time
communication, streamline traffic management, and enhance data
processing and security services at the network edge. The framework
aligns with ongoing IRTF NMRG work on agentic AI and A2A applicability
to network management, and adapts these concepts to the specific
operational and safety requirements of SDV-centric C-ITS deployments.
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 RFC 2119.In-network computing has recently gained significant attention and has
been extensively explored as a promising research area. This growing
interest stems from the increasing accessibility of data plane programmability,
which has opened new opportunities for both application developers and network
operators to optimize network operations and application performance.
Over the years, rigorous research and numerous trials have validated
the effectiveness of certain in-network computing capabilities, collectively
referred to as In-Network Computing Functions (ICFs). These functions have proven to be
highly beneficial in various domains, such as machine learning, real-time data
processing, and large-scale distributed systems. For instance, in-network
aggregation techniques have been shown to accelerate collective communication
operations like Allreduce and Broadcast, which are critical in training
machine learning models. These advancements have led to the gradual
commercialization of many in-network computing capabilities.
Several other works, such as also provide additional
use cases and scenarios for in-network computing applications.Despite these promising developments, a critical challenge remains:
the absence of a unified framework and standardized interfaces to effectively
register, configure, manage, and monitor ICFs. The framework for
Interface to Network Security Functions (I2NSF) defined in
provides a solid foundation for managing and
orchestrating Network Security Functions (NSFs).
However, these frameworks fall short when it comes to supporting the unique
requirements of ICFs. Unlike NSFs, ICFs often require seamless coordination
between endpoint computing capabilities and in-network nodes, such as
Programmable Network Devices (PNDs), to accelerate application performance
collaboratively. This highlights the need for a new framework that can integrate
endpoint and in-network functionalities while leveraging and adapting existing
frameworks, such as I2NSF, to define interfaces for ICFs effectively.This document rigorously examines the applicability of ICFs within constrained
environments, particularly in data center networks, and introduces a structured
framework for their registration, configuration, management, and monitoring.
Additionally, it evaluates extended use cases, including Vehicle-to-Everything (V2X)
communication, wherein ICFs facilitate the efficient orchestration of
vehicle-to-vehicle (V2V) networks, seamless integration with
Cooperative Intelligent Transport Systems (C-ITS), and interoperability
with Mobile Network Operators (MNOs). By leveraging ICFs, these architectures
can achieve enhanced communication efficiency, improved traffic control,
and secure data exchange. Furthermore, this document underscores
the pivotal role of ICFs in strengthening cybersecurity measures for both private
and public data within such interconnected ecosystems, addressing the increasing
demand for resilient security mechanisms in contemporary networked infrastructures.
A distinguishing focus of this document is the Software-Defined
Vehicle (SDV) as the primary endpoint of the I2ICF framework. In an
SDV, traditionally hardware-bound vehicular functions (perception,
planning, control, infotainment, diagnostics) are realized as
software components running on a consolidated, zonal compute
platform and are continuously updated over the air. This
software-defined nature aligns naturally with the agentic AI model:
each SDV can host one or more AI agents that expose vehicle
capabilities (compute, sensing, connectivity, safety classes) as
A2A skills, negotiate ICF placement with peer SDV, RSU, MNO, and
Center agents, and dynamically adapt to changing road, network, and
mission contexts. Conversely, the surrounding C-ITS and MNO
infrastructure must evolve from static, message-based V2X delivery
toward an intent-driven, agent-mediated control plane that can
match the update cadence and behavioral diversity of fleets of
SDVs. The I2ICF framework defined here treats SDVs as first-class
agentic participants rather than passive V2X clients.In C-ITS, distributed agents across vehicles, Road-Side Units (RSUs),
and traffic management backends increasingly need to collaborate directly
in an Agent-to-Agent (A2A) manner for capability advertisement, peer discovery,
task delegation, and state exchange. Emerging IETF work on Artificial Intelligence
(AI) agent protocols formalizes such A2A interactions (e.g.,
messaging, capability schemas, and discovery) ,
while the IRTF NMRG explores applicability of A2A to multi-domain network
management and automation .
This approach provides a standards-based
application/control-plane overlay for ICFs: vehicle, infrastructure, and cloud agents
can discover and configure ICFs on programmable network devices, coordinate V2V/V2I compute
placement, and exchange low-latency signals for admission control, safety services,
and analytics, thereby reducing end-to-end delay and network overhead while improving
interoperability and manageability in C-ITS deployments.
The A2A paradigm itself has been actively discussed across recent IRTF NMRG
meetings (e.g., IETF 124 and IETF 125), where a body of work on agentic AI,
Large Language Model (LLM)-assisted operations, and agent-mediated control planes
for networks has emerged. Representative directions include problem statements
and motivations for agentic AI in network management
, agentic AI architectural principles
for autonomous networks ,
agentic network architectures supporting agent interconnection and multi-level
inference ,
agent-driven Network Digital Twin (NDT) architectures
, agentic sensing and network
optimization ,
and the applicability of model and tool-access protocols such as the
Model Context Protocol (MCP) to network management
. In parallel, industry initiatives
(e.g., Google's A2A protocol) have contributed reference patterns for
agent identity, capability cards (Agent Cards), task lifecycles, and secure
peer-to-peer messaging that can be adopted as the application-layer substrate
of an A2A overlay for C-ITS.
Building on these trends, this document positions A2A as the primary
coordination layer of the I2ICF framework for SDV-centric C-ITS.
Specifically, each major entity in the architecture (Center Cloud agents,
C-ITS Infra agent, MNO agent, RSU agent, SDV agents, and VRU agent)
hosts an AI agent that exposes standardized capability descriptions and
exchanges intent-based requests over A2A. SDV agents in particular act
as the bridge between in-vehicle software stacks (zonal controllers,
AI/ADAS workloads, IVN buses) and the external A2A overlay, so that
vehicle-side software updates and capability changes are immediately
reflected in the agent's advertised Agent Card. The I2ICF interfaces
(I1 to I10) defined in this document are realized as A2A interactions
between these agents, while the underlying transport, security, and
policy enforcement continue to rely on existing C-ITS, V2X, and mobile
network mechanisms. This split keeps the agentic control plane aligned
with the NMRG agentic-AI direction while preserving compatibility with
deployed C-ITS, SDV, and MNO infrastructures.
This section presents the detailed design of the agentic I2ICF
framework and interfaces for Software-Defined Vehicles (SDVs) in C-ITS
and MNO networking.
shows the agentic I2ICF framework for SDV, C-ITS, and MNO
networking. In this framework, every major functional entity hosts
an AI Agent that participates in an A2A overlay. SDV
agents are first-class peers of infrastructure and operator agents:
they advertise their in-vehicle software capabilities, sensing and
compute resources, supported autonomy levels, and ICF requirements
through signed Agent Cards. The A2A overlay provides capability
advertisement (e.g., Agent Cards), peer discovery, intent/task
delegation, and state exchange among agents, and is used to
register, configure, monitor, and coordinate ICFs across the
architecture. The A2A protocol runs as an application/control-plane
overlay on top of the existing I1 to I10 interfaces; wired
interfaces are typically depicted with solid links and wireless or
A2A signalling with dashed links.* Central Cloud: A system that comprehensively controls the entire C-ITS
(Cooperative Intelligent Transport Systems) environment. It manages information
from various C-ITS centers, including regional centers and highway centers,
and facilitates and oversees the connection between C-ITS data from the Government
Public Center and end users. Additionally, it provides security functions through
an integrated cybersecurity system. Within the Central Cloud, two cooperating
agents (a C-ITS Center Agent and a Government Public Center Agent) participate
in the A2A overlay to negotiate cross-domain data sharing and to delegate ICF
configuration requests downward to the C-ITS Infra and MNO agents.* C-ITS Center: The C-ITS Center is a comprehensive term that encompasses
both the Region Center and the Highway Center. It serves as the central hub
for managing and coordinating intelligent transportation systems across various
environments, including urban regions and highways. By integrating data from
Region Centers and Highway Centers, the C-ITS Center ensures efficient traffic
management, real-time data processing, and seamless communication between
infrastructure and connected or autonomous vehicles.* Region Center: The Region Center refers to local centers established at
key locations. These regional centers are connected to Roadside Units (RSUs)
and function as one of the C-ITS Centers. Each regional C-ITS center collaborates
with the Government Public Center to share collected data, ensuring seamless
integration and data exchange between local infrastructure and centralized
management systems.* Highway Center: The Highway Center operates similarly to the Region Center
but is managed separately due to the unique characteristics of highways,
which span multiple regions rather than being confined to a single city.
Given the higher traffic volume on highways compared to regular roads, there is
a significant increase in data generation, necessitating dedicated network management
for highway environments. Highways are equipped with a greater number of RSUs
than general roads, enabling the delivery of critical information to autonomous vehicles.
As a result, the Highway Center focuses on managing areas that require more
real-time processing to support safe and efficient autonomous driving.* Government Public Center: The Government Public Center is a C-ITS information
provision system managed by the government. Due to the nature of road traffic infrastructure,
it is challenging for private companies to manage this data effectively, and
concerns over reliability make it difficult for users to utilize privately managed data.
The Government Public Center ensures the delivery of highly reliable, government-provided
data to users, enabling them to effectively utilize infrastructure-based information.
It oversees the provision and management of trustworthy data essential for safe and
efficient transportation systems.* C-ITS Data Linkage System: The C-ITS Data Linkage System is a platform designed to provide
C-ITS data to external users. By offering data through methods such as Open APIs,
this system connects C-ITS infrastructure information with users, enabling seamless
access to real-time traffic and transportation data. It facilitates the integration of
C-ITS data into various applications and services, supporting the development of innovative
mobility solutions and enhancing the overall efficiency and safety of transportation systems.* Cyber Security System: The Cyber Security System is responsible for managing the security
of communications between Software-Defined Vehicles (SDV), Vulnerable Road Users (VRU),
RSU, Mobile Network Operators (MNO), and C-ITS infrastructure. Security technologies are
fundamentally integrated into all communications to ensure encrypted data transmission.
Outgoing data is encrypted using a public key, while receiving devices decrypt the data
using a private key to securely access the information. The Cyber Security System oversees
the protection of both private and public keys across all modules, ensuring robust security
against potential exposure and safeguarding the integrity and confidentiality of transmitted data.
In the A2A overlay, the Cyber Security System provides agent identity issuance,
capability attestation, mutual authentication between agents, and revocation/rotation
of agent credentials, so that all A2A interactions across I1 to I10 are
cryptographically protected.
* C-ITS Infra: The C-ITS Infrastructure is a system designed to collect and provide various
types of information, including traffic signal data, roadside environment information, VRU data,
and RSU data. The specific C-ITS information available may vary depending on the devices
and equipments installed on the road. This infrastructure enables real-time data exchange
between the transportation system and connected or autonomous vehicles, supporting safer
and more efficient traffic management. A C-ITS Infra Agent fronts this subsystem in the A2A
overlay, brokering interactions between Center Cloud agents (downstream policy and ICF
configuration) and RSU/SDV/MNO agents (upstream telemetry and capability advertisement).* RSU: The RSU is a device that connects the C-ITS Infrastructure
with SDVs. Through the RSU, SDVs can transmit and receive data between
vehicles via V2V and between vehicles and infrastructure via V2I.
RSUs play a critical role in enabling real-time communication, providing essential
information such as traffic signals, road conditions, and safety alerts, thereby
enhancing the safety and efficiency of autonomous and connected vehicle operations.
Each RSU hosts a lightweight RSU Agent that participates in the A2A overlay to
publish locally available ICFs (e.g., aggregation, filtering, perception offload),
discover SDV/VRU agents within its coverage, and accept intent-based tasks
delegated by the C-ITS Infra Agent or by neighboring SDV agents.* SDV1 and SDV2: SDV1 and SDV2 are examples depicted in the diagram, but in real-world
scenarios, there can be an arbitrary number of vehicles. A Software-Defined Vehicle (SDV)
is a vehicle whose functions (perception, planning, control, infotainment, diagnostics,
and connectivity) are realized as software components running on a consolidated, zonal
compute platform and are continuously updatable over the air. An SDV exposes two main
communication interfaces: an External Communication Interface that enables communication
with external systems such as RSUs, other vehicles (V2V), and infrastructure (V2I/V2N) for
seamless interaction within the C-ITS ecosystem; and an Internal Vehicle Network (IVN)
Interface that manages internal communication within the vehicle, connecting various
onboard systems and components to ensure smooth operation and integration of vehicle
functionalities. This dual-interface structure allows SDVs to efficiently exchange data
both externally with the C-ITS infrastructure and internally for optimized vehicle control.
Because vehicle-side software, models, and skills evolve continuously, an SDV's externally
visible capabilities are intentionally agentic: the SDV hosts an in-vehicle SDV Agent that
acts as the vehicle's representative in the A2A overlay, publishes a signed Agent Card that
reflects the currently installed software/skills, autonomy level, and safety class,
negotiates ICF placement with RSU, MNO, and Center agents, and coordinates directly with
other SDV agents for cooperative perception, platooning, and safety tasks. The SDV Agent
also mediates between the IVN (zonal controllers, sensors, actuators) and the external A2A
overlay, ensuring that only authorized, policy-bound intents reach in-vehicle subsystems.* IVN-Network1 and IVN-Network2: IVN-Network1 and IVN-Network2 are examples, but in practice,
the internal communication system of a vehicle can consist of N different networks. These networks
are part of the In-Vehicle Network (IVN), which facilitates communication within the vehicle.
In an SDV (Software-Defined Vehicles), the IVN is designed based on a Zonal Architecture,
where communication interfaces connect various devices and components within specific zones
of the vehicle. This architecture improves data transmission efficiency, reduces wiring complexity,
and enhances the integration of advanced systems for autonomous driving and vehicle control.
Through this zonal design, SDVs can effectively manage high-speed data exchange between sensors,
controllers, and actuators, supporting real-time processing and safer driving operations.* VRU: A VRU refers to users who can communicate either with an MNO
or directly with SDVs. VRUs typically include pedestrians, cyclists,
and motorcyclists who are more susceptible to traffic accidents due to
their limited protection. By connecting with MNO networks, VRUs can receive real-time
safety alerts and traffic information. Additionally, direct communication with SDVs enables
VRUs to exchange critical safety data, such as location and movement intentions,
which helps autonomous and connected vehicles detect and respond to nearby vulnerable users,
ultimately enhancing road safety. A VRU Agent, typically hosted on the VRU's personal
device, participates in the A2A overlay with a constrained capability profile,
announcing presence and intent (e.g., crossing, joining traffic) to nearby SDV and
MNO agents under privacy-preserving identifiers.
* MNO: An MNO is a service provider that owns and manages wireless communication infrastructure,
including network towers, core networks, and data centers. In the context of C-ITS, MNOs play a critical
role in enabling real-time communication between vehicles, infrastructure, and VRUs by providing seamless
connectivity through cellular networks (e.g., LTE, and 5G). MNOs facilitate the transmission of safety messages,
traffic updates, and vehicle data, ensuring low-latency, high-reliability communication essential
for autonomous driving and connected vehicle ecosystems. Additionally, MNOs collaborate with C-ITS
infrastructure to enhance data security and manage network resources for efficient traffic management
and mobility services. The MNO hosts an MNO Agent that exposes network-side capabilities
(e.g., slice selection, QoS modulation, edge compute placement) over A2A, so that SDV,
VRU, and Center agents can request connectivity and ICF execution in an intent-based,
cross-domain manner.
Center Cloud
********************************************************************
* *
* +------------------+-----+ +-----+---------------------+ *
* | C-ITS Center | | | | Government Public | *
* |------------------| | I1 | | Center | *
* | Region Center |Agent+<....>+Agent|---------------------| *
* |------------------| | | | C-ITS Data Linkage | *
* | Highway Center | | | |---------------------| *
* | | | | | Cyber Security Sys | *
* +------------------+--+--+ +--+--+---------------------+ *
* ^ ^ *
**************************:************:****************************
: I2 : I3
v v
+------------+----+ +-+------------------------+
| Agent | | Agent |
|-----------------|I4 |--------------------------|
I7 +...>| C-ITS Infra |<...>| MNO |
: +--------+--------+ +----------------+---------+
: ^ ^ ^
: : I5 I6 : I6 :
: : : :
v v v v
+-----+-----+ I8 +-+--------------++ I9 +-----+---+-+
| RSU |Agent|<...>| Agent |<...>|Agent| VRU |
+-----+-----+ |-----------------| +-----+-----+
| SDV1 |
| IVN-Network1 |
+-------+---------+
^
: I10
:
v
+-----+-------+
| Agent |
|-------------|
| SDV2 |
| IVN-Network2|
+-------------+
<...> A2A Protocol
According to the framework described in the previous section, there
are major interfaces that I2ICF of C-ITS and MNO networking should define.
Each interface listed below is realized as an A2A interaction between the
two corresponding agents: the two agents authenticate each other using
credentials issued by the Cyber Security System, exchange Agent Cards to
learn each other's ICF-related capabilities, and then use intent-based
request/response or publish/subscribe messages to register, configure,
monitor, or invoke ICFs. The interface descriptions below therefore cover
both the underlying data exchange and the A2A semantics layered on top.Interface 1 (I1): This is the registration interface between the C-ITS
Center and the Government Public Center. It facilitates the exchange of
C-ITS infrastructure data, such as traffic information and real-time road
conditions, ensuring the Government Public Center can provide accurate
and trustworthy data to external users. This interface also supports
secure data sharing through standardized protocols and encryption.Interface 2 (I2): This interface connects the C-ITS Center with the
C-ITS Infra. It is responsible for distributing infrastructure data,
such as traffic signal information, road environment data, and RSU status,
from the C-ITS Center to the C-ITS Infra for real-time processing and
delivery to connected vehicles. It ensures continuous data flow for
effective traffic and infrastructure management.Interface 3 (I3): This is the data exchange interface between
the Government Public Center and the MNO (Mobile Network Operator).
It enables the secure transmission of C-ITS data to MNOs, allowing mobile
networks to deliver critical traffic and safety information to VRUs
and vehicles. This interface must ensure data integrity and security
during transmission.Interface 4 (I4): This interface connects the C-ITS Infra with the MNO.
It supports the sharing of network resources and real-time communication between
infrastructure components and mobile networks. This connection allows for efficient
distribution of data, such as traffic alerts and safety notifications,
to mobile users and vehicles.Interface 5 (I5): This is the communication interface between the C-ITS
Infra and SDVs. It enables bidirectional data
exchange, allowing SDVs to receive real-time infrastructure information
(e.g., traffic signals, road hazards) and transmit vehicle status
data back to the infrastructure. This interface is critical for
supporting V2I communications.Interface 6 (I6): This interface connects the MNO with both VRUs and SDVs.
It is used to deliver real-time safety messages, navigation updates,
and other critical data. It also allows VRUs and SDVs to send status
or emergency signals back to the network. This interface must ensure
low-latency and secure data transmission to prevent accidents and
improve traffic efficiencyInterface 7 (I7): This is the management interface between the RSU
and the C-ITS Infra. It facilitates the configuration, monitoring,
and management of RSUs to ensure stable communication between roadside
infrastructure and vehicles. It also handles firmware updates and diagnostics for RSUs.Interface 8 (I8): This interface supports V2I
communication between SDVs through the RSU. It allows SDVs to exchange
critical information such as speed, direction, and emergency signals,
enabling collision avoidance and cooperative driving. This interface must
provide real-time and reliable data exchange in dynamic traffic environments.Interface 9 (I9): This is the communication interface between SDVs and VRUs.
It ensures that vulnerable road users receive immediate safety notifications
from nearby vehicles and infrastructure. For example, SDVs can warn pedestrians
of approaching vehicles or detect VRU movements in blind spots, enhancing road safety.Interface 10 (I10): This is the external and internal communication interface between
multiple SDVs It enables secure and efficient communication within the vehicle's
zonal architecture, facilitating seamless data exchange between various internal
systems (e.g., sensors, controllers) and supporting autonomous driving functions.This section introduces practical use cases of the agentic I2ICF
framework in the context of Software-Defined Vehicles (SDVs), C-ITS,
and MNO networking. These use cases focus on how the software-defined
and continuously updatable nature of SDVs, combined with the A2A
overlay, enables End-to-End (E2E) communication, cybersecurity, and
cooperative driving services that adapt to vehicle, road, and network
context in real time.* Real-Time Data Processing for SDV: The I2ICF framework enables seamless
communication between SDVs and C-ITS infrastructure through interfaces such as
I5 (C-ITS Infra <-> SDV) and I8 (V2V Communication via RSU). Real-time data such
as traffic signals, road conditions, and obstacle detection are transmitted to
SDVs for immediate processing. By offloading certain data processing tasks to network devices
(e.g., RSUs), SDVs can reduce internal computational load, allowing faster
decision-making for functions like emergency braking or lane changes.
This distributed data processing model improves the overall safety and efficiency
of autonomous driving.* E2E Communication for Cooperative Driving: The integration of
MNO networks with C-ITS through interfaces like I4 (C-ITS Infra <-> MNO) and
I6 (MNO <-> VRU/SDV) allows for reliable and low-latency E2E communication.
This connectivity is essential for cooperative driving scenarios, where multiple
SDVs coordinate lane changes, merging, or platooning in real time. The I2ICF framework
ensures that the network can dynamically manage traffic loads and prioritize
safety-critical data transmission, enabling vehicles to share and act on
real-time information seamlessly.* Enhanced Cybersecurity for C-ITS and MNO Integration:
Given the extensive data exchange between vehicles, infrastructure, and network operators,
cybersecurity is a critical component. The Cyber Security System within the I2ICF framework,
managed through interfaces like I3 (Government Public Center <-> MNO) and I10
(Internal SDV Communication), provides E2E encryption and secure key management.
Private keys are stored securely in the cloud and can be updated via Over-The-Air (OTA)
mechanisms if compromised. If a critical security breach occurs, the system can initiate
a global reset to reissue encryption keys, ensuring system-wide security integrity.
This proactive approach minimizes the risk of cyberattacks on connected vehicles
and infrastructure.* Dynamic Resource Allocation for High-Density Traffic Environments: In high-traffic
conditions such as highways or urban intersections, efficient data management is crucial.
The I2ICF framework, through I7 (RSU <-> C-ITS Infra) and I9 (SDV <-> VRU), enables dynamic
resource allocation. For example, RSUs can prioritize data transmission for emergency
vehicles or redirect network resources to manage traffic congestion. This adaptive data flow
management reduces latency and prevents network bottlenecks, ensuring that all vehicles
and infrastructure components receive critical information in real time.* Edge Computing for Latency-Sensitive Applications: Edge computing capabilities are
integrated into the I2ICF framework using RSUs and Programmable Network Devices (PNDs)
to handle latency-sensitive tasks. Interfaces like I1 (C-ITS Center <-> Government Public Center)
and I8 (SDV <-> SDV via RSU) allow certain computational tasks such as object detection or
predictive path planning to be processed at the network edge rather than relying on centralized
cloud servers. This significantly reduces response time for autonomous driving actions and
enhances road safety by enabling faster vehicle reactions. * These use cases demonstrate how the I2ICF framework can enhance the performance,
security, and reliability of intelligent transportation systems by integrating C-ITS infrastructure
with MNO networks. By supporting real-time data processing, secure communication, and dynamic
resource management, the framework addresses the complex demands of modern SDVs and
connected mobility solutions.The I2ICF framework for C-ITS and MNO Networking offers numerous advantages
for various applications. However, due to the framework's extensive connectivity
between diverse vehicles, devices, centers, clouds, and VRUs, a vast amount of information
and functionalities are exposed during network configuration, leading to potential security risks.
To ensure the overall security of the entire system, the following measures are recommended:
First, the application development system should be controlled by the same service providers
(e.g., cloud service providers or network operators) that own the network and computing infrastructure.
Second, devices within the cloud center should be pre-configured with security zones to isolate traffic,
preventing it from affecting other network traffic. Third, encryption keys for each device should
be centrally managed by the cloud center. In the event of key exposure, the system should
support Over-The-Air (OTA) updates to promptly replace compromised keys. Fourth, if a security breach
occurs within the centralized management system, exposing encryption keys, the entire system
should undergo a reset to perform a security initialization. This process will generate and
distribute new encryption keys to ensure the continued protection of sensitive data.Introducing an A2A overlay on top of I2ICF adds further security-sensitive
surfaces that need to be addressed. Each agent MUST have a verifiable identity
and a signed Agent Card whose contents (e.g., advertised ICFs, supported intents,
authorization scopes) are authenticated by the Cyber Security System. A2A
messages between agents MUST be mutually authenticated, integrity-protected,
and confidentiality-protected, and SHOULD carry replay protection suitable for
vehicular environments. Agents SHOULD operate under a least-privilege capability
model: an SDV Agent cannot reconfigure RSU or MNO ICFs unless explicitly
authorized, and a compromised agent's credentials MUST be revocable through the
same OTA mechanism used for cryptographic key rotation. Finally, because A2A
may carry LLM-generated or LLM-influenced content, deployments SHOULD apply
input validation, prompt-injection mitigation, and human-in-the-loop oversight
for safety-critical decisions, consistent with the agentic-AI principles discussed
in and
.In emerging SDV ecosystems, seamless coordination among vehicle agents, C-ITS infrastructure agents,
and MNO agents becomes essential for achieving real-time awareness
and adaptive network optimization. The A2A communication paradigm
enables direct interaction among these heterogeneous entities without relying solely on
centralized control mechanisms. For instance, SDV agents can dynamically negotiate
data offloading, perform network slicing, or compute resource scheduling with MNO agents in response
to vehicular mobility and network conditions, while roadside infrastructure agents exchange
situational context such as congestion level, edge compute availability, or safety alerts
with SDV agents to support cooperative perception and hazard prediction. These A2A interactions
facilitate distributed decision-making across application and network layers, forming the basis
for intelligent coordination and resilient service continuity in connected mobility.When integrated with the proposed I2ICF framework, such A2A-based orchestration allows SDVs,
RSUs, and MNO backends to jointly manage ICFs, thereby ensuring low-latency, secure, and
reliable service delivery across multi-domain C-ITS environments.
This approach follows recognized architectures and standards used in C-ITS and V2X systems,
including frameworks for security management and network data analytics. Leveraging these
industry standards, A2A coordination can extend beyond individual domains to enable
intent-driven, cross-layer management of communication, computation, and data analytics
among SDV, C-ITS, and MNO ecosystems.The following use cases illustrate concrete A2A interaction patterns
on top of the I2ICF framework. They are intentionally aligned with the
agentic-AI direction discussed in the IRTF NMRG at IETF 124 and IETF 125,
and with the broader industry A2A reference patterns (e.g., Agent Cards,
task lifecycles, and secure peer-to-peer messaging) so that C-ITS
deployments can interoperate with general-purpose AI agent
ecosystems.* Capability Advertisement and Discovery (I2, I4, I5, I7): C-ITS Infra
Agent, MNO Agent, RSU Agents, and SDV Agents publish Agent Cards
describing the ICFs they host (e.g., perception offload, message
aggregation, slice selection, OTA key rotation). Center Cloud agents
index these cards via I2/I3 and use them to plan ICF placement.
Discovery is intent-driven: an SDV Agent requesting "low-latency
cooperative perception within 100 ms" is matched with nearby RSU/MNO
agents whose Agent Cards advertise compatible ICFs.* Cooperative Perception via SDV-to-SDV and SDV-to-RSU A2A
(I8, I10): SDV agents directly negotiate sensor data exchange,
fusion responsibility, and confidence reporting with neighboring SDV
agents (I10) and RSU agents (I8). Heavy fusion ICFs can be delegated
to the RSU Agent when the SDV is compute-constrained, while the SDV
Agent retains decision authority. This pattern mirrors the
agent-interconnection and multi-level inference approach discussed in
.* Intent-Based Slice and Edge Negotiation with MNO (I4, I6):
An SDV Agent or a VRU Agent expresses a high-level intent (e.g.,
"platooning session, 50 vehicles, end-to-end latency budget 20 ms,
reliability 99.999 percent") to the MNO Agent via A2A. The MNO Agent
translates the intent into slice configuration and edge ICF placement,
consistent with the agentic network optimization patterns described
in .* Cross-Domain Safety Coordination (I3, I6, I9): When a Government
Public Center Agent detects a hazardous event, it issues an A2A task
to the MNO Agent and C-ITS Infra Agent, which fan out the task to
local RSU and SDV agents. VRU agents in the affected area receive
targeted alerts via I6/I9 under privacy-preserving identifiers
provided by the Cyber Security System.* Agentic Network Digital Twin for C-ITS (I1, I2, I4): Center Cloud
agents maintain an agentic NDT of the C-ITS network and use it to
simulate ICF placement before pushing configurations to C-ITS Infra
and MNO agents. This use case aligns with the agent-driven NDT
architecture in and with
the problem statement for agentic AI in network management in
.* Tool-Augmented Agent Operations via MCP (all interfaces): Agents
may expose their local management tools (e.g., RSU firmware update,
SDV diagnostic, slice reconfiguration) as MCP-style tools, and other
agents may invoke them under A2A authorization. The applicability of
MCP to such network management tasks is discussed in
; the I2ICF framework reuses this
pattern to keep tool invocation auditable and policy-bound.* Autonomous Reaction and Human-in-the-Loop Oversight: Following the
agentic-AI architectural principles in
,
I2ICF agents operate within explicit autonomy levels. Routine ICF
reconfiguration (e.g., adjusting aggregation thresholds at an RSU)
runs autonomously, while safety-critical reconfiguration (e.g.,
revoking a compromised agent or resetting cryptographic material)
requires escalation to a Center Cloud agent and, where appropriate,
a human operator.Following the A2A protocol model adopted by
, every agent in the I2ICF
framework MUST publish an Agent Card: a JSON metadata document that
describes the agent's identity, endpoint, advertised ICF-related
capabilities, skills, and authentication requirements. Agent Cards
are the basis for capability discovery and intent matching across
I1 to I10. Agent Cards are signed and attested by the Cyber Security
System and SHOULD be discoverable by peer agents either via a
well-known URI on the hosting entity or via a Center Cloud registry.The following non-normative examples illustrate Agent Cards for
representative C-ITS entities. The "capabilities" field lists ICF
classes exposed by the agent, and "skills" enumerate concrete
actions invocable through A2A messages.
{
"name": "RSUAgent-01",
"description": "Agent for a roadside unit that exposes
perception offload and message aggregation ICFs.",
"url": "https://rsu-01.cits.example.net/a2a/tasks",
"capabilities": ["PerceptionOffload", "MessageAggregation",
"V2X-Relay"],
"skills": [
{
"id": "offload_perception",
"name": "Cooperative perception offload",
"description": "Run sensor fusion on behalf of an SDV
within RSU coverage.",
"inputModes": ["application/json", "text/structured"],
"outputModes": ["application/json", "text/status"]
},
{
"id": "aggregate_cam",
"name": "CAM/BSM aggregation",
"description": "Aggregate and forward V2X awareness
messages to the C-ITS Infra.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
{
"name": "SDVAgent-VIN-XYZ",
"description": "In-vehicle agent representing an SDV in the
A2A overlay for cooperative driving.",
"url": "https://sdv-xyz.veh.example.net/a2a/tasks",
"capabilities": ["CooperativePerception", "Platooning",
"Telemetry", "OTA-KeyRotation"],
"skills": [
{
"id": "request_perception",
"name": "Request cooperative perception",
"description": "Request fused object lists from nearby
RSU or SDV agents.",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
},
{
"id": "join_platoon",
"name": "Join platoon",
"description": "Negotiate joining an existing platoon
session with neighboring SDV agents.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
{
"name": "MNOAgent-OpA",
"description": "Operator-side agent exposing slice selection
and edge ICF placement for C-ITS clients.",
"url": "https://mno-a.example.net/a2a/tasks",
"capabilities": ["NetworkSlicing", "EdgeICFPlacement",
"QoSModulation"],
"skills": [
{
"id": "select_slice",
"name": "Slice selection",
"description": "Select or instantiate a network slice
matching the requested intent.",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
},
{
"id": "place_edge_icf",
"name": "Edge ICF placement",
"description": "Place an ICF on an MEC node close to the
requesting SDV/VRU agent.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
While the A2A protocol natively supports unstructured textual
content for inter-agent exchange, the orchestration of ICFs in
C-ITS demands clarity, unambiguous intent transmission, and
machine-interpretable data, especially when safety-critical
actuation (e.g., emergency rerouting, key revocation, slice
reconfiguration) is involved. Natural-language-only payloads carry
the inherent ambiguity of human language and can lead to
inconsistent ICF configuration or large-scale service degradation,
which is unacceptable for C-ITS.This document adopts the approach of
, which uses YANG
as the structured data layer for A2A
payloads, with NETCONF and RESTCONF
as candidate underlying management
protocols when an agent needs to actuate an ICF on a programmable
network device. Building on that approach, this document
defines a non-normative YANG module, "ietf-cits-icf-intent",
whose data nodes are carried inside the "data" part of A2A
messages exchanged across I1 to I10. The module provides a
machine-interpretable representation of C-ITS ICF intents and
supplements the natural-language "text" parts that the same A2A
message may carry. The intent is that an SDV, RSU, MNO, or Center
agent that receives an A2A message can validate the "data" part
against this YANG module before acting upon it, and can use
existing NETCONF or RESTCONF tooling to persist or actuate the
intent on a programmable network device.In the C-ITS context, YANG-modeled payloads carried as the
"data" part of A2A messages are RECOMMENDED for the following
content categories:* ICF descriptors (capability schemas of RSU/MNO/SDV ICFs),
modeled by the "icf-descriptor" container of
"ietf-cits-icf-intent".* C-ITS intent objects (e.g., platooning, cooperative
perception, hazard alert) expressed as structured intents under
the "cits-intent" container of "ietf-cits-icf-intent".* Telemetry and incident reports between RSU/SDV agents and
Center Cloud agents, reusing the YANG model in
where
applicable.* Cryptographic material lifecycle events (rotation, revocation)
managed by the Cyber Security System.The high-level tree structure of the "ietf-cits-icf-intent"
module, expressed using the YANG tree diagram notation, is shown
in . The
corresponding YANG module skeleton is shown in
. Both artifacts
are non-normative and are intended as a starting point for a
companion YANG document.
module: ietf-cits-icf-intent
+--rw cits-icf-intents
+--rw intent* [intent-id]
+--rw intent-id string
+--rw type identityref
+--rw requester string
+--rw target-icf identityref
+--rw safety-class? enumeration
+--rw priority? uint8
+--rw response-deadline? yang:date-and-time
+--rw interface? enumeration
+--rw constraints
| +--rw max-latency-ms? uint32
| +--rw min-reliability? decimal64
| +--rw min-confidence? decimal64
| +--rw region-of-interest? string
| +--rw bandwidth-mbps? uint32
+--rw participants* string
+--ro status? enumeration
+--ro last-updated? yang:date-and-time
notifications:
+---n icf-intent-event
+--ro intent-id -> /cits-icf-intents/intent/intent-id
+--ro event-type enumeration
+--ro details? string
module ietf-cits-icf-intent {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cits-icf-intent";
prefix "cits-icf";
import ietf-yang-types {
prefix yang;
}
organization
"IETF NMRG (Network Management Research Group)";
contact
"WG Web: <https://datatracker.ietf.org/rg/nmrg/>
Editor: Byoungman An <bman@keti.re.kr>
Editor: Jaehoon Paul Jeong <pauljeong@skku.edu>";
description
"This YANG module defines a data model for representing
Cooperative Intelligent Transportation System (C-ITS)
In-Network Computing Function (ICF) intents that are carried
as the 'data' part of Agent-to-Agent (A2A) messages between
SDV, RSU, MNO, VRU, and Center agents of the I2ICF framework.";
revision 2026-02-05 {
description "Initial revision.";
reference "draft-an-nmrg-i2icf-cits-02";
}
/* Identities for ICF intent types and target ICF classes */
identity intent-type {
description "Base identity for C-ITS ICF intent types.";
}
identity cooperative-perception {
base intent-type;
description "Cooperative perception intent (e.g., SDV-RSU).";
}
identity platooning {
base intent-type;
description "Platooning session intent among SDVs.";
}
identity hazard-alert {
base intent-type;
description "Hazard alert dissemination intent.";
}
identity slice-request {
base intent-type;
description "Network slice/edge ICF placement intent to MNO.";
}
identity ota-key-rotation {
base intent-type;
description "OTA key rotation intent managed by the Cyber
Security System.";
}
identity icf-class {
description "Base identity for ICF capability classes.";
}
identity PerceptionOffload { base icf-class; }
identity MessageAggregation { base icf-class; }
identity NetworkSlicing { base icf-class; }
identity EdgeICFPlacement { base icf-class; }
identity OTAKeyRotation { base icf-class; }
/* Top-level data tree */
container cits-icf-intents {
description
"Collection of C-ITS ICF intents currently known to the
hosting agent.";
list intent {
key "intent-id";
description "A single C-ITS ICF intent.";
leaf intent-id {
type string;
description "Globally unique intent identifier.";
}
leaf type {
type identityref { base intent-type; }
mandatory true;
description "Intent type (e.g., cooperative-perception).";
}
leaf requester {
type string;
mandatory true;
description "Agent name of the requesting agent.";
}
leaf target-icf {
type identityref { base icf-class; }
mandatory true;
description "Targeted ICF capability class.";
}
leaf safety-class {
type enumeration {
enum QM; enum ASIL-A; enum ASIL-B;
enum ASIL-C; enum ASIL-D;
}
description "ISO 26262 ASIL classification of the intent.";
}
leaf priority {
type uint8 { range "0..7"; }
description "Relative priority (0 = lowest).";
}
leaf response-deadline {
type yang:date-and-time;
description "Latest acceptable response time.";
}
leaf interface {
type enumeration {
enum I1; enum I2; enum I3; enum I4; enum I5;
enum I6; enum I7; enum I8; enum I9; enum I10;
}
description "I2ICF interface over which the intent flows.";
}
container constraints {
description "Operational constraints attached to the intent.";
leaf max-latency-ms { type uint32; units "milliseconds"; }
leaf min-reliability { type decimal64 { fraction-digits 5; } }
leaf min-confidence { type decimal64 { fraction-digits 2; } }
leaf region-of-interest { type string; }
leaf bandwidth-mbps { type uint32; units "Mbit/s"; }
}
leaf-list participants {
type string;
description "Other agents participating in this intent.";
}
leaf status {
type enumeration {
enum requested; enum accepted; enum running;
enum completed; enum failed; enum revoked;
}
config false;
description "Lifecycle status of the intent.";
}
leaf last-updated {
type yang:date-and-time;
config false;
description "Time of the last status update.";
}
}
}
/* Event-driven A2A notification */
notification icf-intent-event {
description
"Notification emitted when an intent changes state, used by
event-driven A2A pub/sub channels (see Section
'Event-driven A2A for Safety Signalling').";
leaf intent-id {
type leafref {
path "/cits-icf:cits-icf-intents/cits-icf:intent"
+ "/cits-icf:intent-id";
}
}
leaf event-type {
type enumeration {
enum accepted; enum rejected; enum progress;
enum completed; enum failed; enum revoked;
}
}
leaf details { type string; }
}
}
The following non-normative example illustrates an A2A message
sent from an SDV Agent to an RSU Agent over I8 to request a
cooperative perception ICF. The "data" part carries an instance
of the "ietf-cits-icf-intent" YANG module shown above, encoded as
JSON per ("application/yang-data+json"),
while the "text" part preserves a human-readable summary.
POST /a2a/tasks HTTP/1.1
Host: rsu-01.cits.example.net
Content-Type: application/json
{
"jsonrpc": "2.0",
"method": "message/send",
"params": {
"message": {
"message_id": "c1ts-7f3e-4a21-9b12-0e2d6a8c4f10",
"context_id": "intersection-42:approach-east",
"role": "ROLE_USER",
"parts": [
{
"text": "Request cooperative perception within 100 ms
for intersection-42, eastbound approach.",
"media_type": "text/plain"
},
{
"data": {
"ietf-cits-icf-intent:cits-icf-intents": {
"intent": [
{
"intent-id": "intent-9921",
"type":
"ietf-cits-icf-intent:cooperative-perception",
"requester": "SDVAgent-VIN-XYZ",
"target-icf":
"ietf-cits-icf-intent:PerceptionOffload",
"safety-class": "ASIL-B",
"priority": 6,
"response-deadline": "2026-02-10T06:00:00Z",
"interface": "I8",
"constraints": {
"max-latency-ms": 100,
"min-confidence": 0.85,
"region-of-interest":
"intersection-42:east"
},
"participants": ["RSUAgent-01"]
}
]
}
},
"media_type": "application/yang-data+json",
"metadata": {
"yang_module": "ietf-cits-icf-intent",
"revision": "2026-02-05"
}
}
]
},
"configuration": {
"accepted_output_modes": ["application/yang-data+json",
"text/status"],
"blocking": false,
"history_length": 3
},
"metadata": {
"request_type": "icf_invocation",
"priority": "high",
"response_deadline": "2026-02-10T06:00:00Z"
}
}
}
The YANG module shown above is non-normative and is expected
to be refined in a companion YANG document, reusing IETF building
blocks for incident management
and existing
C-ITS/V2X data dictionaries.The introduction of an A2A overlay on top of the I2ICF framework
has several operational implications that need to be considered
when deploying the architecture in large-scale, safety-critical
C-ITS environments. This section is aligned with the operational
considerations discussed in
and adapts them to C-ITS.General-purpose AI agents do not natively possess C-ITS domain
expertise (e.g., V2X message semantics, RSU operational
procedures, MNO slice templates). C-ITS operators SHOULD package
such expertise as Agent Skills (e.g., the
"diagnose_rsu_link_loss" or "build_platoon_session" skill) so
that a generic I2ICF agent can be specialized for a given
deployment without re-training the underlying model. Skills
SHOULD be versioned and signed so that the Cyber Security System
can attest the skill set advertised in an Agent Card.To mitigate hallucinations of LLM-based agents, deployments
SHOULD provide a shared, machine-interpretable knowledge base
covering C-ITS topology, RSU/SDV configuration baselines, MNO
slice templates, regulatory policies, and historical incident
records. Agents retrieve from this knowledge base when reasoning
over A2A tasks. The Model Context Protocol (MCP)
is a candidate substrate
for standardized knowledge-base access in I2ICF.The task-based A2A request/response model is sufficient for
slow-loop ICF configuration but insufficient for safety-critical
C-ITS events (e.g., emergency electronic brake, hazard
detection). For such events, agents SHOULD also support an
event-driven publish/subscribe pattern, where a Hazard Agent
publishes to a topic on a message broker and interested SDV,
RSU, MNO, and Center agents subscribe to receive
near-real-time notifications. This pattern reuses the
event-driven A2A architecture described in
.A national-scale C-ITS deployment may include thousands of
RSUs, millions of SDVs and VRUs, and multiple cooperating MNOs.
A2A messaging volume is therefore significantly higher than
static RPC-based interfaces. Operators SHOULD:* Adopt hierarchical/federated agent structures so that local
decisions (e.g., intersection-level cooperative perception)
remain local to RSU and SDV agents.* Apply rate-limiting, backoff, and prioritization on A2A
messages, with the highest priority reserved for safety
signalling.* Localize Agent Card registries per region (e.g., per Region
Center or Highway Center) to avoid global discovery hotspots.Many C-ITS use cases (cooperative perception, platooning,
intersection management) impose tight end-to-end timing budgets
(tens of milliseconds). Implementations SHOULD define
performance envelopes for:* Maximum A2A message processing latency for each interface
(I1 to I10).* Timeout and retry behavior, with deterministic fallback to
direct controller APIs or pre-provisioned static ICF
configurations when A2A interactions cannot meet the deadline.* Bounded LLM inference time when an agent relies on
generative reasoning; safety-critical paths SHOULD NOT depend
on unbounded LLM inference.A2A workflows in C-ITS may span vehicles entering and leaving
coverage, intermittent wireless links, and partial cloud
failures. Implementations SHOULD provide:* Workflow checkpointing so that long-lived tasks (e.g., a
platoon session) can survive agent restarts.* Idempotent retry semantics for ICF invocations.* Transactional ICF reconfiguration with confirmed-commit-like
semantics (analogous to NETCONF confirmed-commit) when multiple
devices must be updated atomically.* Circuit breakers and automatic escalation to a human
operator when sustained failures threaten safety.I2ICF agents are long-running production components and
require lifecycle management: onboarding and registration
through the Cyber Security System, controlled model/skill
updates (with rollback), decommissioning, and revocation of
compromised agents through the same OTA mechanism used for
cryptographic key rotation. Operators SHOULD monitor agent
resource consumption (CPU, memory, inference workload),
especially on constrained RSU and SDV platforms.C-ITS is inherently multi-domain: Government Public Center,
Region/Highway Centers, multiple MNOs, vehicle OEMs, and
third-party service providers may each operate independent
agent populations. Cross-domain A2A interactions therefore
require:* Federated trust establishment among Cyber Security Systems
of different domains.* Interoperable Agent Card schemas and YANG models for ICF
intents.* Policy reconciliation (e.g., differing privacy regulations
for VRU data) before sharing tasks across administrative
boundaries.* Auditing and accountability records for every cross-domain
A2A invocation, retained by the receiving domain.TBD.
This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
Ministry of Science and ICT (MSIT) (No.RS-2024-00397615,
Development of an automotive software platform for Software-Defined-Vehicle (SDV)
integrated with an AI framework required for intelligent vehicles).
This work was in part supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
Ministry of Science and ICT (MSIT) (No. RS-2024-00398199 and RS-2022-II221015).