An Agentic AI Framework for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems
Intelligent Information R and D Division Mobility Platform Research Center
Korea Electronics Technology InstituteGlobal 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 4957pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Intelligent Information R and D Division Mobility Platform Research Center
Korea Electronics Technology InstituteGlobal 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
Korea Electronics Technology InstituteGlobal 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 ForceAgentic AI, Framework, Software-Defined Vehicle,
Cooperative Intelligent Transportation Systems,
Agent-to-Agent Communication, Mobile Network Operator
This document specifies an Agentic AI Framework for orchestrating,
managing, and monitoring AI Computing Functions (ACFs) for
Software-Defined Vehicles (SDVs) in Cooperative Intelligent
Transportation Systems (C-ITS). AI agents as ACFs communicate with
each other via the Agent-to-Agent (A2A) protocol. 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 ACFs 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 proposed
framework aligns with the up-to-date 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.This document proposes an Agentic AI framework for coordinating
AI Computing Functions (ACFs) across Software-Defined Vehicles
(SDVs), roadside infrastructure, and mobile networks in Cooperative
Intelligent Transportation Systems (C-ITS). An ACF is a processing
function that uses AI techniques, for example perception inference,
sensor fusion using an AI model, or traffic prediction. An AI agent
is the entity that interprets an intent, selects and coordinates
functions or tools, and monitors the resulting task. An agent and
an ACF are therefore distinct roles.In-network and edge computing provide relevant deployment and
resource-management foundations. Prior work describes use cases
for In-network Computing Functions called ACFs
. However, computation inside a
network is not necessarily AI computation. Message forwarding,
deterministic aggregation, network-slice configuration, and key
rotation can remain conventional supporting services or tools
invoked by an agent. This document does not classify them as ACFs
solely because they participate in an agentic workflow.The proposed framework addresses registration, configuration,
orchestration, and monitoring of ACFs and their supporting
services across vehicles and infrastructure. The Interface to
Network Security Functions (I2NSF) framework
provides relevant management concepts for Network Security
Functions (NSFs), but an AI agent's coordination role is distinct
from the function that it invokes. The following architecture
applies agent-to-agent coordination to C-ITS and MNO integration.
The use cases describe intended behaviors, not measured performance
or deployment results.A distinguishing focus of this document is the Software-Defined
Vehicle (SDV) as the primary endpoint of the Agentic AI framework. In an
SDV, traditionally hardware-bound vehicular functions (e.g., perception,
planning, control, infotainment, and 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 (e.g., compute, sensing, connectivity, and safety classes) as
A2A skills, negotiate ACF 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 Agentic AI 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 ACFs: vehicle, infrastructure, and cloud agents
can discover and configure ACFs 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 Agentic AI framework for SDV-centric C-ITS.
Specifically, each major entity in the architecture (e.g., 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 (e.g., zonal controllers,
AI/ADAS workloads, and 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 Agentic AI interfaces
(from 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. Therefore, 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 AI
framework and interfaces for Software-Defined Vehicles (SDVs) in C-ITS
and MNO networking.
shows the Agentic AI 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 ACF 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 ACFs 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 ACF
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 ACF
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 ACFs (e.g., AI-based perception offload)
and supporting tools (e.g., aggregation and filtering),
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 ACF 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 ACF 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 for Agentic AI coordination in C-ITS and MNO networking.
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 ACF-related capabilities, and then use intent-based
request/response or publish/subscribe messages to register, configure,
monitor, or invoke ACFs. 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 AI
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 Agentic AI 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 Agentic AI 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 Agentic AI 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 Agentic AI 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 Agentic AI 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 Agentic AI 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.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 Agentic AI framework, such A2A-based orchestration allows SDVs,
RSUs, and MNO backends to jointly manage ACFs, 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 Agentic AI 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 ACFs they host (e.g., AI-based perception offload)
and their supporting skills (e.g., message aggregation, slice
selection, and OTA key rotation). Center Cloud agents
index these cards via I2/I3 and use them to plan ACF 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 ACFs.* 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 ACFs 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
.For cooperative perception, an SDV Agent selects an advertised
RSU or MEC processing function and sends the region of interest,
processing deadline, and required output format. The provider
checks the request conditions and available resources, and returns
acceptance with a task identifier or rejection with a reason.
After acceptance, the provider invokes the ACF and reports its
processing status. A completed result includes the observation
time, source, and quality information so that the SDV can combine
it with its own observations.Agent coordination uses an IP-capable path, including connectivity
through LTE or 5G mobile networks. LTE-V2X and NR-V2X PC5 can carry
vehicle and roadside data in the same deployment. The coordination
path and the observation or result data path can differ, depending
on the available connectivity and application mapping.* 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 ACF 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 ACF 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 Agentic AI 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
,
Agentic AI agents operate within explicit autonomy levels. Routine reconfiguration of ACFs or supporting services (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 Agentic AI
framework MUST publish an Agent Card: a JSON metadata document that
describes the agent's identity, endpoint, advertised ACF-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 illustrative "capabilities" field lists ACF and supporting-service
classes exposed by the agent, and "skills" enumerate concrete
actions invocable through A2A messages.
{
"name": "RSUAgent-01",
"description": "RSU agent for AI perception offload and message aggregation.",
"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 SDV agent for cooperative driving over A2A.",
"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 a platoon with neighboring SDV agents.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
{
"name": "MNOAgent-OpA",
"description": "MNO agent for C-ITS slice selection and edge ACF placement.",
"url": "https://mno-a.example.net/a2a/tasks",
"capabilities": ["NetworkSlicing", "EdgeACFPlacement",
"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_acf",
"name": "Edge ACF placement",
"description":
"Place an ACF on an MEC node close to the requesting SDV/VRU agent.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
For a cooperative-perception capability, the Agent Card's skill
identifier and name identify the offered function, while its input
and output modes describe the supported formats. The associated
ACF descriptor additionally identifies the processing region and
endpoint. The "acf-descriptor" container below represents this
information. A request refers to the advertised capability using
"capability-id". The descriptor can be carried in or referenced
from the Agent Card according to the selected A2A version.While the A2A protocol natively supports unstructured textual
content for inter-agent exchange, the orchestration of ACFs and supporting services 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 ACF 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 ACF on a programmable
network device. Building on that approach, this document
defines a non-normative YANG module, "ietf-cits-acf-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 ACF 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:* ACF descriptors (capability schemas of RSU/MNO/SDV ACFs),
and their supporting services, modeled by the "acf-descriptor" container of
"ietf-cits-acf-intent".* C-ITS intent objects (e.g., platooning, cooperative
perception, hazard alert) expressed as structured intents under
the "cits-acf-intents" container of "ietf-cits-acf-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 cooperative-perception exchange uses the existing intent
object for Request, Response, and Result information. The Request
uses "intent-id" as its request identifier and adds
"capability-id" and "output-format" to the existing region and
deadline fields. The Response carries the same "intent-id", an
accepted or rejected status, and a "task-id" when accepted.
A rejected request includes a "reason" and does not allocate a
task identifier.After execution, the Result retains the request and task
identifiers and reports completed or failed status. The added
"result" container carries a result reference, output format,
observation time, source identifiers, and a quality metric and
value. The metric identifies how to interpret the quality value.
The SDV checks these fields and the result's age before using the
information. For cooperative perception, "response-deadline"
denotes the latest acceptable receipt time of the processing
result; admission is reported before that time.The added fields are optional in the module skeleton so that
existing intent objects remain representable. A cooperative-
perception request supplies the selected capability and output
format. Its provider assigns a task identifier after acceptance
and supplies the result information on completion. These data
fields supplement the existing A2A message and task mechanisms.The module name, namespace, prefix, and local identifiers below
use ACF terminology. These illustrative names are a proposal, not
registered or finalized identifiers. The model includes supporting
service classes such as NetworkSlicing and OTAKeyRotation; those
classes do not imply that the underlying operation uses AI.
Renaming the earlier module is a schema and namespace change,
not a backward-compatible alias. Implementations using earlier
names would require an explicit migration mapping.The high-level tree structure of the "ietf-cits-acf-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-acf-intent
+--ro acf-descriptor
| +--ro capability* [capability-id]
| +--ro capability-id string
| +--ro function-name? string
| +--ro endpoint? string
| +--ro input-format* string
| +--ro output-format* string
| +--ro service-region* string
| +--ro region-reference? string
+--rw cits-acf-intents
+--rw intent* [intent-id]
+--rw intent-id string
+--rw type identityref
+--rw requester string
+--rw target-acf identityref
+--rw capability-id? string
+--rw output-format? string
+--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 max-data-age-ms? uint32
| +--rw region-reference? string
| +--rw quality-metric? string
+--rw participants* string
+--ro task-id? string
+--ro reason? string
+--ro result
| +--ro result-reference? string
| +--ro output-format? string
| +--ro observation-time? yang:date-and-time
| +--ro source-id* string
| +--ro quality-metric? string
| +--ro quality-value? decimal64
+--ro status? enumeration
+--ro last-updated? yang:date-and-time
notifications:
+---n acf-intent-event
+--ro intent-id -> /cits-acf-intents/intent/intent-id
+--ro event-type enumeration
+--ro task-id? string
+--ro reason? string
+--ro details? string
module ietf-cits-acf-intent {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cits-acf-intent";
prefix "cits-acf";
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)
AI Computing Function (ACF) intents that are carried
as the 'data' part of Agent-to-Agent (A2A) messages between
SDV, RSU, MNO, VRU, and Center agents of the Agentic AI framework.";
revision 2026-11-02 {
description
"Align the illustrative module, namespace, and identifiers
with ACF terminology in the Agentic AI framework;
distinguish ACFs from supporting services.";
reference "draft-an-nmrg-i2icf-cits-03";
}
revision 2026-10-27 {
description
"Add capability, request, response, and result fields for
SDV-to-RSU/MEC cooperative perception.";
reference "draft-an-nmrg-i2icf-cits-03";
}
revision 2026-02-05 {
description "Initial revision.";
reference "draft-an-nmrg-i2icf-cits-02";
}
/* Identities for ACF intent types and target ACF classes */
identity intent-type {
description "Base identity for C-ITS ACF 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 ACF placement intent to MNO.";
}
identity ota-key-rotation {
base intent-type;
description "OTA key rotation intent managed by the Cyber
Security System.";
}
identity acf-class {
description "Base identity for ACF or supporting-service classes.";
}
identity PerceptionOffload { base acf-class; }
identity MessageAggregation { base acf-class; }
identity NetworkSlicing { base acf-class; }
identity EdgeACFPlacement { base acf-class; }
identity OTAKeyRotation { base acf-class; }
/* Top-level data tree */
container acf-descriptor {
config false;
description
"Advertised ACFs and supporting services of the hosting agent.";
list capability {
key "capability-id";
description "One computing function offered by the agent.";
leaf capability-id {
type string;
description "Identifier of the advertised function or service.";
}
leaf function-name {
type string;
description "Name of the offered processing function.";
}
leaf endpoint {
type string;
description "Endpoint for requesting the function.";
}
leaf-list input-format {
type string;
description "Supported input representations.";
}
leaf-list output-format {
type string;
description "Supported output representations.";
}
leaf-list service-region {
type string;
description "Regions for which processing is offered.";
}
leaf region-reference {
type string;
description "Coordinate or map reference for the regions.";
}
}
}
container cits-acf-intents {
description
"Collection of C-ITS ACF intents currently known to the
hosting agent.";
list intent {
key "intent-id";
description "A single C-ITS ACF 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-acf {
type identityref { base acf-class; }
mandatory true;
description "Targeted ACF or supporting-service class.";
}
leaf capability-id {
type string;
description "Selected capability advertised by the provider.";
}
leaf output-format {
type string;
description "Requested result representation.";
}
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 "Agentic AI 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 max-data-age-ms {
type uint32; units "milliseconds";
description "Maximum observation age at result receipt.";
}
leaf region-reference {
type string;
description "Coordinate or map reference for the region.";
}
leaf quality-metric {
type string;
description "Definition used to interpret min-confidence.";
}
}
leaf-list participants {
type string;
description "Other agents participating in this intent.";
}
leaf task-id {
type string;
config false;
description "Provider-assigned identifier after acceptance.";
}
leaf reason {
type string;
config false;
description "Reason for rejection, failure, or expiry.";
}
container result {
config false;
description "Information returned for a completed task.";
leaf result-reference {
type string;
description "Reference to the processing result.";
}
leaf output-format {
type string;
description "Representation of the returned result.";
}
leaf observation-time {
type yang:date-and-time;
description "Earliest observation contributing to result.";
}
leaf-list source-id {
type string;
description "Sources contributing to the result.";
}
leaf quality-metric {
type string;
description "Definition used to interpret quality-value.";
}
leaf quality-value {
type decimal64 { fraction-digits 5; }
description "Quality under the identified metric.";
}
}
leaf status {
type enumeration {
enum requested; enum accepted; enum running;
enum completed; enum failed; enum revoked;
enum rejected; enum expired;
}
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 acf-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-acf:cits-acf-intents/cits-acf:intent"
+ "/cits-acf:intent-id";
}
}
leaf event-type {
type enumeration {
enum accepted; enum rejected; enum progress;
enum completed; enum failed; enum revoked;
enum expired;
}
}
leaf task-id {
type string;
description "Task identifier assigned on acceptance.";
}
leaf reason {
type string;
description "Reason for an unsuccessful outcome.";
}
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 ACF. The "data" part carries an instance
of the "ietf-cits-acf-intent" YANG module shown above, encoded as
JSON per , using the media type
"application/yang-data+json" defined in ,
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":
"Cooperative perception within 100 ms: intersection-42 eastbound.",
"media_type": "text/plain"
},
{
"data": {
"ietf-cits-acf-intent:cits-acf-intents": {
"intent": [
{
"intent-id": "intent-9921",
"type":
"ietf-cits-acf-intent:cooperative-perception",
"requester": "SDVAgent-VIN-XYZ",
"target-acf":
"ietf-cits-acf-intent:PerceptionOffload",
"capability-id": "offload_perception",
"output-format": "application/json",
"safety-class": "ASIL-B",
"priority": 6,
"response-deadline": "2026-02-10T06:00:00Z",
"interface": "I8",
"constraints": {
"max-latency-ms": 100,
"min-confidence": "0.85",
"quality-metric": "fusion-confidence-v1",
"max-data-age-ms": 150,
"region-reference": "intersection-map-v1",
"region-of-interest":
"intersection-42:east"
},
"participants": ["RSUAgent-01"]
}
]
}
},
"media_type": "application/yang-data+json",
"metadata": {
"yang_module": "ietf-cits-acf-intent",
"revision": "2026-11-02"
}
}
]
},
"configuration": {
"accepted_output_modes": ["application/yang-data+json",
"text/status"],
"blocking": false,
"history_length": 3
},
"metadata": {
"request_type": "acf_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 within the Agentic AI 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 Agentic AI 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 this framework.The task-based A2A request/response model is sufficient for
slow-loop ACF 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 ACF
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 ACF invocations.* Transactional ACF 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.For cooperative-perception requests, the provider uses the
authenticated requester and "intent-id" to recognize a retry
of the same request. While the request record is retained, it
returns the recorded decision or task status without starting a
second execution. Reuse of that identifier with different
request conditions is rejected with a reason. Retention covers
at least the request's response deadline.If the deadline is reached before completion, the provider
reports expired status and a reason. Failed or expired tasks
retain the assigned task identifier. The SDV does not use a
result received after its deadline or maximum data-age limit.
For a completed task, the returned output format matches the
accepted request, and its source and quality information remain
associated with the same request and task identifiers.Agentic AI 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 ACF
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.The Agentic AI 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 within the Agentic AI framework 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 ACFs, 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 ACFs 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
.
This work was supported by the 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 the Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (No. RS-2024-00398199, Standard Development of SDV Software Framework for Intelligent Convergence Services).