Execution-Finality for AI-Native 5G/6G and O-RAN
draft-das-ai-native-6g-execution-finality-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-29 (Latest revision 2026-09-08) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide — Zenodo
GitHub runnable reference implementation for AI-native 5G/6G, AI-RAN and O-RAN execution finality. |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-ai-native-6g-execution-finality-03
Network Working Group S. Das
Internet-Draft Independent Inventor
Intended status: Informational 8 September 2026
Expires: 12 March 2027
Execution-Finality for AI-Native 5G/6G and O-RAN
draft-das-ai-native-6g-execution-finality-03
Abstract
In programmable and AI-assisted mobile networks, successful
authentication of a network function or AI controller does not
establish authority for every routing, signaling, session, resource-
allocation, sensing, or subscriber-specific consequence that the
function can generate.
This document defines an informational execution-finality profile for
AI-native 5G, 5G-Advanced, IMT-2030/6G, O-RAN, and AI-RAN
environments. A proposed network operation is represented as a
Network Candidate Act and remains in a Non-Effective State while a
Protected Enforcement Domain validates act-specific predicates.
Protected validation evidence is committed before, or atomically
with, release of scoped non-bearer finality authority. A Network
Finality Sink at the enforcement boundary independently verifies that
authority immediately before live network state changes.
The governing rule is that network authentication is not network
finality, and computation is not authority. This revision also
defines a JSON interoperability profile for Candidate Acts,
validation decisions, scoped authority, and sink verification.
Das Expires 12 March 2027 [Page 1]
Internet-Draft AI-Native 5G/6G Finality September 2026
This profile is distinct from, and complementary to, present AI-
native 6G industry roadmaps that focus on radio, sensing, and
platform capability, including air-interface, MIMO, spectrum, and AI-
RAN infrastructure work described in Qualcomm's public AI-native 6G
platform material, and the broad native-trustworthiness and agentic-
core-network architectures described in Huawei's public 6G security
research. Those efforts address how a network becomes more
intelligent, autonomous, and platform-trustworthy. This document
addresses a narrower and later question: once an already-
authenticated, already-policy-approved AI-generated network operation
has been computed, whether that exact operation may become a live
network consequence. The Candidate Act, Non-Effective State,
Protected Enforcement Domain, and Finality Sink constructs defined
here, as an explicit pre-effectuation gate with act-bound non-bearer
authority and independent sink-side re-verification, are not
established as an equivalent primitive in publicly reviewed material
from those roadmaps.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Das Expires 12 March 2027 [Page 2]
Internet-Draft AI-Native 5G/6G Finality September 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Relationship to Existing Mechanisms . . . . . . . . . . . . . 11
5.1. 3GPP Authentication, SBA Authorization, and Policy . . . 11
5.2. CAPIF, NEF, and Network APIs . . . . . . . . . . . . . . 11
5.3. O-RAN A1, E2, and RIC Applications . . . . . . . . . . . 12
5.4. What This Profile Adds . . . . . . . . . . . . . . . . . 12
6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Core Invariant . . . . . . . . . . . . . . . . . . . . . 12
6.2. Non-Effective State . . . . . . . . . . . . . . . . . . . 14
6.3. Candidate Act Descriptor . . . . . . . . . . . . . . . . 14
6.4. First Boundary: PED Validation . . . . . . . . . . . . . 15
6.4.1. Validation Success . . . . . . . . . . . . . . . . . 15
6.4.2. Validation Failure . . . . . . . . . . . . . . . . . 15
6.4.3. Evidence-Gated Progression . . . . . . . . . . . . . 16
6.5. Scoped Non-Bearer Finality Authority . . . . . . . . . . 16
6.6. Second Boundary: Independent Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . . . 16
6.7. Successful Effectuation . . . . . . . . . . . . . . . . . 17
7. AI-Native 5G/6G and O-RAN Profile . . . . . . . . . . . . . . 17
7.1. Telecom Candidate Acts . . . . . . . . . . . . . . . . . 17
7.2. Example: AI-RAN Resource Reallocation . . . . . . . . . . 18
7.3. Telecom Finality Sink Placement . . . . . . . . . . . . . 18
8. JSON Interoperability Profile . . . . . . . . . . . . . . . . 18
8.1. NetworkCandidateAct Object . . . . . . . . . . . . . . . 19
8.2. NetworkValidationDecision Object . . . . . . . . . . . . 23
8.3. NetworkFinalityAuthority Object . . . . . . . . . . . . . 24
8.4. NetworkSinkVerify Request and Response . . . . . . . . . 26
8.5. Network-State Mismatch Denial . . . . . . . . . . . . . . 27
8.6. Complete AI-RAN Resource Allocation Example . . . . . . . 28
9. Protocol Operation and Failure Handling . . . . . . . . . . . 30
9.1. End-to-End Workflow . . . . . . . . . . . . . . . . . . . 30
9.2. PED Processing . . . . . . . . . . . . . . . . . . . . . 31
9.3. Finality Sink Verification . . . . . . . . . . . . . . . 31
9.4. Authority Consumption, Replay, and Revocation . . . . . . 32
9.5. Hot Path and Cold Path . . . . . . . . . . . . . . . . . 33
9.6. Failure Codes . . . . . . . . . . . . . . . . . . . . . . 33
9.7. Fail-Closed Requirements . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10.1. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. Candidate Act Substitution . . . . . . . . . . . . . . . 36
10.3. Sink Substitution . . . . . . . . . . . . . . . . . . . 36
10.4. Stale Policy, Revocation, and Protected State . . . . . 36
10.5. Failure of the PED or Finality Sink . . . . . . . . . . 36
Das Expires 12 March 2027 [Page 3]
Internet-Draft AI-Native 5G/6G Finality September 2026
10.6. Threat Model: Compromised xApp/rApp Attempting Sink
Bypass . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.6.1. Attacker Model . . . . . . . . . . . . . . . . . . . 37
10.6.2. Attempted Bypasses and Their Outcomes . . . . . . . 37
10.6.3. Residual Risk Not Closed by This Architecture . . . 38
11. Deployment Considerations . . . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
13. Intellectual Property Note . . . . . . . . . . . . . . . . . 40
14. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Related Internet-Drafts . . . . . . . . . . . . . . . . 40
14.2. Reference Implementation . . . . . . . . . . . . . . . . 41
15. Applicability to IETF Working Groups and Research Groups . . 41
16. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 43
17. Normative References . . . . . . . . . . . . . . . . . . . . 43
18. Informative References . . . . . . . . . . . . . . . . . . . 44
Appendix A. Frequently Asked Questions (Non-Normative) . . . . . 45
A.1. Does this replace 3GPP TS 33.501 authentication? . . . . 45
A.2. Does this replace O-RAN A1/E2/O1/O2 policy interfaces? . 45
A.3. How does scoped finality authority differ from an OAuth
access token? . . . . . . . . . . . . . . . . . . . . . 45
A.4. Why can't an upstream policy engine's ALLOW decision just
be trusted? . . . . . . . . . . . . . . . . . . . . . . 46
A.5. How does this relate to Zero Trust Architecture (NIST SP
800-207)? . . . . . . . . . . . . . . . . . . . . . . . 46
A.6. Does this require a blockchain or distributed ledger? . . 46
A.7. How is this different from audit logging or SIEM
alerting? . . . . . . . . . . . . . . . . . . . . . . . 46
A.8. How does this relate to RATS remote attestation? . . . . 47
A.9. How does this differ from Qualcomm's public AI-native 6G
roadmap? . . . . . . . . . . . . . . . . . . . . . . . . 47
A.10. How does this differ from Huawei's native-trustworthiness
and Agentic Core Network work? . . . . . . . . . . . . . 47
A.11. How does this relate to GSMA Open Gateway network
APIs? . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.12. Does this profile replace existing telecom security
architecture generally? . . . . . . . . . . . . . . . . 48
A.13. What about emergency services, lawful intercept, or
operator override? . . . . . . . . . . . . . . . . . . . 48
Appendix B. Carrier-Scale and Radio-Timescale Engineering FAQ
(Non-Normative) . . . . . . . . . . . . . . . . . . . . . 48
B.1. How can execution finality work when some RAN decisions
occur much faster than the reference implementation's
measured latency? . . . . . . . . . . . . . . . . . . . 49
B.2. Can this architecture scale to thousands of cells and large
numbers of RRM decisions? . . . . . . . . . . . . . . . 51
B.3. Who controls the keys in a multi-vendor O-RAN
deployment? . . . . . . . . . . . . . . . . . . . . . . 52
Das Expires 12 March 2027 [Page 4]
Internet-Draft AI-Native 5G/6G Finality September 2026
B.4. How many bytes does this add, and can constrained links
tolerate it? . . . . . . . . . . . . . . . . . . . . . . 53
B.5. Doesn't 3GPP already solve freshness and replay? . . . . 54
B.6. Does the Protected Enforcement Domain become a new
bottleneck, attack surface, or single point of failure? 55
B.7. Do the automated tests prove security? . . . . . . . . . 56
B.8. Is there an actual hardware implementation yet? . . . . . 56
B.9. The Core Engineering Distinction . . . . . . . . . . . . 57
B.10. Relationship to Existing 6G Work . . . . . . . . . . . . 58
B.11. Summary for IETF and Telecom Reviewers . . . . . . . . . 59
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction
Future telecommunications systems are increasingly programmable, API-
driven, AI-assisted, distributed, sensing-aware, and autonomous. An
authenticated network function, Near-RT RIC xApp, rApp, orchestrator,
or AI agent may be permitted to participate in the network while
lacking authority to cause every possible live-network consequence.
As 5G-Advanced and IMT-2030/6G systems move toward AI-native
operation, autonomous adaptation, and agentic control loops, more of
the operations that change live network state originate from a
computation rather than from a human operator issuing a discrete
command. That shift does not by itself create a new authentication
problem; it creates a new question about what happens between the
moment a computation completes and the moment its consequence becomes
real.
Existing mobile-network security mechanisms answer an earlier
question: whether an entity may enter a domain, invoke an interface,
or obtain a token. 3GPP security architecture [TS33501], O-RAN
security interfaces [ORAN-ARCH], transport-layer protections, and
upstream policy engines together establish that an entity is
recognized and, in many cases, that a class of operation it requests
is generally permitted. None of those mechanisms, taken individually
or together, answer a later and narrower question: whether one
particular, already-computed proposed operation may become effective
right now, for this exact subscriber or resource, this purpose, this
scope, this destination, this jurisdiction, this policy epoch, and
this specific enforcement boundary. An entity can be correctly
authenticated, and an upstream policy decision can correctly say
ALLOW, while the network state that decision was computed against has
already changed by the time the operation would take effect.
Execution finality is the name this document gives to that later,
narrower control point.
Das Expires 12 March 2027 [Page 5]
Internet-Draft AI-Native 5G/6G Finality September 2026
This distinction matters more, not less, as networks become agentic.
Public industry direction already anticipates increasingly autonomous
network operation: AI-native platform work describes context-aware
adaptation of scheduling, resource allocation, QoS, and protocol
behavior across device, RAN, and core, and separate public research
describes an agentic core network in which AI agents may autonomously
detect intent, generate services, execute them, and continuously
optimize them through multi-agent collaboration. Neither direction
is in question here, and this document does not claim that such
systems lack security architecture, guardrails, or trust models. The
question this document isolates is narrower and comes later in the
pipeline: once an AI-native or agentic system has computed a proposed
network operation, what technically determines whether that exact
operation is allowed to become a live consequence, independent of
whether the system that computed it was itself authenticated, policy-
compliant, and well-intentioned at the moment of computation.
This document specifies that later control as a two-boundary
architecture:
1. A Protected Enforcement Domain (PED) validates a Candidate Act
and, only after committing protected validation evidence, may
release scoped non-bearer finality authority.
2. A Finality Sink at the actual effectuation boundary independently
verifies that authority immediately before the live network state
changes, then consumes or otherwise invalidates the authority for
unauthorized replay.
Das Expires 12 March 2027 [Page 6]
Internet-Draft AI-Native 5G/6G Finality September 2026
Between these two boundaries, the proposed operation, termed a
Network Candidate Act, remains in a Non-Effective State: it may be
generated, evaluated, staged, queued, hashed, or otherwise prepared,
but it cannot yet become externally consequential. Validation at the
PED does not itself cause effectuation; it produces protected
evidence and, from that evidence, a finality-authority artifact that
is deliberately not a bearer credential. The artifact is bound to
one act, one effect, one resource and subscriber scope, one purpose,
one policy and revocation epoch, and one Finality Sink, so that
possessing a serialized copy of it is insufficient on its own to
produce the protected effect. The Finality Sink independently re-
checks the act digest, the actual effect parameters, the current
topology and policy state, and the authority's consumption status
immediately before the consequence occurs, and then consumes single-
use authority atomically with effectuation. This closes a specific
race condition that upstream authorization alone cannot close: a
decision computed against network state at one instant can be
presented for effectuation after that state has already changed, and
an ordinary ALLOW decision has no mechanism to detect or refuse that
staleness on its own.
The standards surface this document proposes is deliberately narrow:
a Network Candidate Act representation plus a Network Finality Sink
verification contract. This document does not replace 3GPP
authentication, O-RAN policy interfaces, PFCP or NAS freshness and
replay mechanisms, or ordinary routing procedures; those mechanisms
remain necessary and are treated throughout this document as inputs
to, not replacements for, finality validation. Nor does this
document propose a new waveform, MIMO technique, spectrum band,
channel code, scheduler, or AI accelerator; it does not compete with
air-interface, sensing, or platform-capability research. It defines
a single additional pre-effectuation gate that applies specifically
to AI-mediated and other autonomous network acts, positioned after
every other applicable authentication and policy mechanism has
already run and immediately before the live network state actually
changes.
Because the required gate differs by consequence class, this document
does not assume a single latency profile applies uniformly across the
network. Non-real-time control, such as rApp policy and long-lived
slice or optimization policy, can use a conventional Protected
Enforcement Domain and Finality Sink path without difficulty. Near-
real-time consequential control, such as xApp-generated E2 control or
cell-level configuration change, can plausibly use a DU, CU, or E2-
node-local Finality Sink operating on the order of the Near-RT RIC's
own control loop. Genuinely PHY/MAC-speed decisions are not expected
to carry a full act-specific authority exchange on every scheduling
event; instead, a stronger validation may establish a bounded, time-
Das Expires 12 March 2027 [Page 7]
Internet-Draft AI-Native 5G/6G Finality September 2026
limited, revocable execution envelope once, after which individual
high-speed decisions are checked locally against that envelope
without repeating the full exchange. Appendix B discusses this
profile distinction, together with carrier-scale throughput, multi-
vendor key management, wire-format overhead, and failure behavior, in
engineering detail, since these are the questions most likely to be
raised by RAN, core-network, and accelerator engineers evaluating
this proposal against present deployment constraints.
This document also positions itself explicitly against present AI-
native 6G industry roadmaps rather than presenting the problem as
unaddressed territory. Public platform-focused work on air-
interface, MIMO, spectrum, sensing, and AI-native RAN, core, and
device operation, and public native-trustworthiness and agentic-core-
network research addressing security, privacy, resilience, and
multilateral trust as a lifecycle property, both describe how a
network becomes more intelligent, autonomous, and trustworthy.
Neither, in the material publicly reviewed for this document,
establishes an explicit Non-Effective State, an act-bound non-bearer
finality authority, or independent sink-side re-verification
immediately before effectuation as a named, general-purpose
primitive. Appendix B and the abstract of this document address that
distinction directly, and this document should be read as
complementary to, not competitive with, that broader body of work:
the more capable and autonomous an AI-native network becomes, the
more consequential the question of what makes its guardrails
technically load-bearing at the moment of effect becomes.
The remainder of this document proceeds as follows. Section 3
defines the Candidate Act, Non-Effective State, Protected Enforcement
Domain, Protected Validation Evidence, Scoped Non-Bearer Finality
Authority, and Finality Sink constructs used throughout. Subsequent
sections define the problem scope, the two-boundary architecture, the
JSON interoperability profile, fail-closed requirements, and
deployment considerations. Non-normative appendices address
frequently asked questions comparing this profile against existing
mechanisms, including 3GPP authentication, O-RAN policy interfaces,
OAuth, RATS attestation, Zero Trust Architecture, ledger anchoring,
audit logging, and GSMA Open Gateway APIs, against present AI-native
6G industry roadmaps, and against the carrier-scale and radio-
timescale engineering questions described above. A companion
informational draft discusses the same finality pattern outside the
mobile-network profile [I-D.das-ef-interop], and a runnable reference
implementation with an accompanying test suite accompanies this
specification to demonstrate the described behavior experimentally.
Das Expires 12 March 2027 [Page 8]
Internet-Draft AI-Native 5G/6G Finality September 2026
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The protocol invariant is mandatory: failure to establish current
finality authority MUST NOT be converted into permission to
effectuate a protected network consequence.
3. Terminology
Candidate Act
An operation that has been generated, selected, requested, staged,
scheduled, routed, or otherwise prepared but has not yet been
permitted to become consequence-bearing. A Candidate Act MAY
already be fully computed. Computation alone MUST NOT cause
effectuation.
Network Candidate Act
A Candidate Act whose intended consequence is a change to live
telecommunications state, including routing, signaling, session,
QoS, slice, RAN parameter, UPF rule, sensing, RF enablement, or
network-API effectuation.
Non-Effective State
A state in which the Candidate Act may exist, be evaluated,
staged, queued, hashed, transformed, or prepared, but the
protected consequence cannot yet become externally effective.
Protected Enforcement Domain (PED)
A protected validation environment that evaluates whether a
Candidate Act is eligible to receive scoped finality authority.
The PED MAY be realized as a trusted execution environment, secure
enclave, HSM, protected operating-system service, protected
network function, confidential-computing environment, or
equivalent. The defining property is the validation role, not a
particular hardware product.
Das Expires 12 March 2027 [Page 9]
Internet-Draft AI-Native 5G/6G Finality September 2026
Protected Validation Evidence
Evidence committed by the PED establishing the validation state
associated with a Candidate Act. The evidence MAY be a Ledger-
Anchored Validation Receipt (LAVR) or an equivalent protected
commitment using hashes, signatures, MACs, sealed state, monotonic
counters, Merkle commitments, or append-only protected records.
External ledger anchoring is OPTIONAL and is not required on the
hot path.
Scoped Non-Bearer Finality Authority
An act-specific enablement artifact or protected authorization
state that permits a particular Candidate Act to cross a
particular effectuation boundary only under its validated scope.
Possession alone MUST NOT be sufficient to cause effectuation.
Finality Sink
The functional boundary at which a Candidate Act would become
externally, operationally, or network-effectively consequential.
A gateway, firewall, or policy engine is not a Finality Sink
merely because it performs security checks. It MUST control the
consequence such that the consequence is technically non-
completable without successful finality verification.
Network Finality Sink
A Finality Sink located at or associated with a carrier gateway,
UPF, control-plane function, session controller, network API
gateway, AI-RAN or O-RAN enforcement point, signaling gateway,
edge network function, or equivalent 6G enforcement node.
Effectuation
The transition of a Candidate Act from Non-Effective State into an
actual change of live network, subscriber, sensing, RF, or
resource state.
4. Problem Scope
Traditional network security controls primarily determine who may
enter a system, who may invoke an API, and whether a network function
is authenticated. Those controls remain necessary. They do not, by
themselves, decide whether one already-generated operation may become
a live-network consequence.
That distinction matters more as control loops become autonomous. An
AI-RAN controller, RIC xApp, or orchestrator can compute a resource
reallocation, traffic-steering decision, or sensing export without a
human decision point immediately before effectuation. Authentication
of the controller answers "who are you?". Execution finality answers
"may this exact network act become effective now?".
Das Expires 12 March 2027 [Page 10]
Internet-Draft AI-Native 5G/6G Finality September 2026
IMT-2030 work describes expected capabilities that widen the
consequence surface: native AI integration, distributed learning and
inference, integrated sensing and communication, high-precision
positioning, cloud-native and edge-native architectures, network
slicing, and heterogeneous multi-stakeholder environments
[ITU-IMT2030] [ITU-T-IMT2030-SEC]. In such an environment, location,
presence, and subscriber context may be derived from infrastructure
measurements rather than from a single application GPS API. Removing
one application's positioning permission therefore does not
necessarily control final disclosure or actuation.
This document does not claim that existing cybersecurity or privacy
controls will collapse. It claims that access-centric assumptions
are incomplete if they are relied upon without a separate control
over the transition from computation to consequence.
5. Relationship to Existing Mechanisms
Execution finality is intended to consume decisions from existing
systems, not to replace them. Those systems remain inputs to PED
validation. They do not replace independent Finality Sink
verification.
5.1. 3GPP Authentication, SBA Authorization, and Policy
3GPP security for the 5G system, including network-function
authentication and service-based interface authorization [TS33501],
establishes that an NF is a recognized party and that it may invoke a
service. Policy Control Function decisions and related session-
policy procedures govern QoS and charging rules. Those mechanisms do
not inherently bind a one-shot, act-specific digest to a particular
sink identity, topology epoch, nonce, and single-use consumption
state immediately before a live RAN or UPF mutation generated by an
autonomous controller.
5.2. CAPIF, NEF, and Network APIs
Exposure frameworks such as CAPIF and the Network Exposure Function
authorize API clients and can constrain API invocation. A permitted
API call is still not, by itself, proof that the resulting network
effect remains valid for the current topology and revocation epoch at
the moment of effectuation.
Das Expires 12 March 2027 [Page 11]
Internet-Draft AI-Native 5G/6G Finality September 2026
5.3. O-RAN A1, E2, and RIC Applications
O-RAN A1 carries policy from Non-RT RIC toward Near-RT RIC. E2
carries control and information between Near-RT RIC and E2 nodes
[ORAN-ARCH]. An xApp or rApp that is admitted to the RIC and
authorized on A1/E2 may still generate a control that is unsafe after
a topology or configuration-epoch change, or that exceeds a
subscriber, slice, or jurisdiction scope not encoded in the original
policy object. A Finality Sink at the E2 node or other RAN
enforcement point can verify act-bound authority at the last hop
without replacing A1 or E2.
5.4. What This Profile Adds
Relative to the mechanisms above, this profile adds:
* an explicit Non-Effective State for proposed network acts;
* protected evidence committed before or atomically with authority
issuance;
* non-bearer authority bound to act digest, sink, scope, freshness,
and policy/revocation/topology epochs;
* independent sink-side verification immediately before live-state
change; and
* mandatory fail-closed behavior on mismatch, replay, revocation, or
uncertainty.
6. Architecture
6.1. Core Invariant
A Candidate Act MUST NOT become consequence-bearing merely because it
has been generated, computed, selected, routed, scheduled, delegated,
authenticated, or permitted by an upstream application or AI system.
A Candidate Act MUST remain in a Non-Effective State until all of the
following have occurred:
1. a PED validates the applicable act-specific predicates;
2. protected validation evidence is generated or committed;
3. scoped non-bearer finality authority is released;
Das Expires 12 March 2027 [Page 12]
Internet-Draft AI-Native 5G/6G Finality September 2026
4. an applicable Finality Sink independently verifies that
authority; and
5. the finality authority and associated protected state are
consumed, invalidated, advanced, or otherwise made unsuitable for
unauthorized replay.
This is a two-boundary architecture rather than a single
authorization gate. The first boundary determines whether scoped
finality authority may be created. The second determines whether the
consequence may actually occur.
Candidate Act
|
v
Non-Effective State
|
v
Protected Enforcement Domain
|
v
Act-Specific Validation
|
v
Protected Validation Evidence
|
v
Scoped Non-Bearer Finality Authority
|
v
Independent Finality Sink Verification
|
+------ FAILURE ------> remain non-effective
|
`------ SUCCESS
|
v
authority consumed
|
v
permitted consequence
Figure 1: Execution-finality chain
No individual element substitutes for this chain. A policy engine,
application permission, access token, attestation, human approval,
LAVR, or Finality Sink without act-bound authority is insufficient by
itself.
Das Expires 12 March 2027 [Page 13]
Internet-Draft AI-Native 5G/6G Finality September 2026
6.2. Non-Effective State
An implementation MUST preserve the Non-Effective State whenever a
required element of the execution-finality chain is absent, invalid,
stale, expired, revoked, replayed, already consumed, act-mismatched,
scope-mismatched, policy-mismatched, jurisdiction-mismatched,
protected-state-mismatched, or Finality-Sink-mismatched.
Failure at a load-bearing point MUST leave the Candidate Act non-
effective. A warning or audit record alone is not sufficient.
6.3. Candidate Act Descriptor
A conforming implementation SHOULD create or derive a machine-
verifiable descriptor for the Candidate Act before effectuation. The
precise serialization is defined for the network profile in
Section 8. A conceptual descriptor includes:
* Candidate-Act-ID, Act-Type, Act-Digest
* Initiating principal, application, agent, and tool/function
identifiers
* Purpose, resource or data class, permitted scope, and permitted
consequence class
* Destination and destination jurisdiction
* Data precision and data-residency state, where applicable
* Policy, authority, and revocation epochs
* Nonce, freshness state, and protected-state reference
* Validation-evidence reference, Finality-Sink-ID, and effectuation-
boundary identifier
Not every field is required for every consequence class. Data
precision is particularly relevant to location or sensitive-data
release. Destination jurisdiction is relevant to cross-border
export. Tool or function identity is important for agentic
controllers. Permitted consequence class distinguishes a model
recommendation from a live network mutation.
A Candidate Act SHOULD have a stable digest over its load-bearing
attributes. Changing a load-bearing attribute MUST cause previously
issued authority to fail verification unless the changed operation is
separately authorized.
Das Expires 12 March 2027 [Page 14]
Internet-Draft AI-Native 5G/6G Finality September 2026
6.4. First Boundary: PED Validation
Upon receiving or resolving a Candidate Act, the PED MUST keep that
act non-effective while validation is performed. The PED SHOULD
evaluate all predicates required by the applicable consequence class.
Predicates MAY include authority, purpose, application and agent
identity, tool/function scope, instruction provenance, destination,
jurisdiction, data residency, data precision, policy epoch,
revocation state, freshness, nonce, protected state, permitted
consequence class, and Finality Sink identity.
PED approval alone MUST NOT make the Candidate Act effective.
Validation success is not external consequence.
6.4.1. Validation Success
If validation succeeds, the PED MUST:
1. establish or confirm the applicable protected-state transition;
2. generate or commit protected validation evidence;
3. bind that evidence to the applicable Candidate Act;
4. bind the permitted scope and applicable Finality Sink; and
5. release scoped non-bearer finality authority only after, or
atomically with, the evidence commitment.
At this stage the Candidate Act remains non-effective. The PED has
authorized issuance of finality authority. It has not yet caused
effectuation.
6.4.2. Validation Failure
If validation fails, the PED MUST NOT release usable finality
authority. The implementation SHOULD create protected denial state
or denial evidence sufficient to prevent unauthorized retry, replay,
rollback, substitution, or stale reuse where those risks apply. The
implementation MAY consume or lock a nonce, advance protected
monotonic state, generate a denial receipt, update revocation or
exposure state, quarantine the Candidate Act, or require renewed
authorization. The Candidate Act MUST remain non-effective.
Das Expires 12 March 2027 [Page 15]
Internet-Draft AI-Native 5G/6G Finality September 2026
6.4.3. Evidence-Gated Progression
The system MUST NOT treat a simple Boolean result such as ALLOW=TRUE
as sufficient execution-finality authority. The protected validation
result is committed into protected evidence before the act can
proceed. A LAVR, where used, is a pre-effectuation protected
commitment, not a post-event receipt. External blockchain finality
is NOT required for the hot path.
6.5. Scoped Non-Bearer Finality Authority
Following successful protected evidence commitment, the PED MAY
release an execution handle, capability fragment, protected
enablement state, or equivalent scoped non-bearer finality authority.
Regardless of representation, the authority MUST be sufficiently
constrained so that possession alone cannot authorize arbitrary
effectuation.
A conforming authority SHOULD be act-bound, evidence-bound, state-
bound, scope-bound, nonce- or freshness-bound, epoch-bound, and sink-
bound. Copying, observing, storing, forwarding, or possessing the
authority MUST NOT by itself create authority for effectuation.
An authority issued for one act, sink, scope, destination, precision
level, policy state, or protected-state transition MUST NOT be
reusable as authority for another consequence. Where single-use
effectuation is intended, the authority MUST be consumed,
invalidated, or rendered unusable before or atomically with
successful effectuation.
6.6. Second Boundary: Independent Finality Sink Verification
The Finality Sink MUST NOT merely trust that the PED previously
approved the Candidate Act. It MUST independently verify the
applicable finality authority immediately before effectuation.
The Finality Sink SHOULD verify, where applicable: authority
validity; Candidate Act identity or digest; protected validation
evidence; protected-state reference or transition; scope; purpose;
destination; jurisdiction; data precision; nonce; freshness; policy
epoch; revocation epoch; consumption state; permitted consequence
class; effectuation-boundary identity; and Finality Sink identity.
Das Expires 12 March 2027 [Page 16]
Internet-Draft AI-Native 5G/6G Finality September 2026
The Finality Sink MUST reject the Candidate Act if a required
verification fails. A failed verification MUST prevent effectuation.
It MUST NOT merely create an alert while allowing the consequence to
proceed. For a telecom failure, no governed network consequence
occurs. For a location-export failure, exact coordinates are not
released.
6.7. Successful Effectuation
If Finality Sink verification succeeds, the implementation MUST
ensure that the finality authority cannot be reused outside its
permitted semantics. For single-use operations, consumption,
invalidation, or protected-state advancement SHOULD occur before or
atomically with effectuation. The implementation SHOULD also create
sink-side finality evidence identifying the completed protected
consequence.
The execution sequence is:
1. Candidate Act created
2. Candidate Act held non-effective
3. PED validates act-specific predicates
4. Protected validation evidence committed
5. Scoped non-bearer finality authority released
6. Finality Sink independently verifies authority
7. Authority or state consumed or advanced
8. Permitted consequence becomes effective
9. Sink-side finality evidence recorded
7. AI-Native 5G/6G and O-RAN Profile
7.1. Telecom Candidate Acts
A telecom Candidate Act MAY include routing modification, signaling
operation, session establishment or modification, resource
allocation, service activation, slice orchestration, network API
invocation, traffic-steering decision, autonomous optimization,
machine-to-machine communication operation, AI-RAN action,
subscriber-specific network operation, sensing operation, RF
enablement, or another network-state transition.
Das Expires 12 March 2027 [Page 17]
Internet-Draft AI-Native 5G/6G Finality September 2026
7.2. Example: AI-RAN Resource Reallocation
An AI network controller proposes a NETWORK_RESOURCE_REALLOCATION for
cell-108 and slice emergency-services, with purpose congestion-
optimization and Finality Sink at a RAN enforcement boundary. The
controller may fully compute the optimization. The optimization
remains a Candidate Act. The PED validates the applicable network,
policy, subscriber, jurisdiction, resource, and authority predicates.
Only then may scoped finality authority be released. The RAN
enforcement point verifies that authority immediately before the
allocation becomes live.
7.3. Telecom Finality Sink Placement
Depending on deployment, a telecom Finality Sink MAY be located at or
associated with a carrier gateway, UPF, control-plane function,
session controller, network API gateway, AI-RAN enforcement point,
O-RAN E2 or A1-adjacent enforcement logic, signaling gateway, edge
network function, or a future 6G enforcement node.
Carrier and 6G deployments may require near-line-rate behavior. Such
deployments MAY rely on local protected state, cached short-lived
policy, current revocation epoch, sink-bound capabilities, SmartNIC
or DPU enforcement, secure network functions, or hardware-adjacent
validation. High-risk or anomalous operations SHOULD be escalated
rather than allowed as unverifiable network consequences.
8. JSON Interoperability Profile
This section defines a JSON interoperability profile for AI-generated
or AI-mediated network Candidate Acts. The schema makes the proposed
network effect, resource scope, subscriber scope, network-function
identity, policy state, and intended Network Finality Sink explicit.
This profile defines the semantic contract. It does not require one
transport.
Candidate Acts and finality authorities MAY be carried over protected
local IPC, operator-internal HTTPS, service-based interfaces, O-RAN
control interfaces, or other authenticated transports. A transport
binding MUST preserve object integrity, sink identity, freshness, and
the protected non-bearer semantics of the authority.
The JSON representation given below is chosen for readability and for
ease of interoperability experimentation, and is not proposed as an
optimized carrier wire format. For constrained interfaces, in
particular Open Fronthaul and other E2-adjacent transports where
payload size and parsing cost matter, a production transport binding
would more naturally map this same schema onto a compact binary
Das Expires 12 March 2027 [Page 18]
Internet-Draft AI-Native 5G/6G Finality September 2026
encoding. Plausible candidates include CBOR with COSE signing and
encryption structures [RFC9052], which preserve the same field
semantics defined here in a substantially smaller and faster-to-parse
encoding, or a binary encoding such as ASN.1 or Protocol Buffers
aligned with existing 3GPP or O-RAN information-element encoding
conventions for the interface concerned. This document defines the
semantic contract, that is, which fields exist and what they bind;
the choice of wire encoding is a transport-binding concern left to a
future companion specification or to the implementer, provided the
binding preserves the integrity, freshness, sink-identity, and non-
bearer properties required above.
8.1. NetworkCandidateAct Object
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:ietf:params:json-schema:network-finality:candidate-act:1",
"title": "NetworkCandidateAct",
"type": "object",
"additionalProperties": false,
"required": [
"version",
"object_type",
"candidate_act_id",
"act_type",
"created_at",
"expires_at",
"initiator",
"network_context",
"resource_scope",
"purpose",
"requested_effect",
"policy_state",
"freshness",
"finality_sink"
],
"properties": {
"version": { "type": "string", "const": "1.0" },
"object_type": { "type": "string", "const": "network_candidate_act" },
"candidate_act_id": { "type": "string", "minLength": 16 },
"act_type": {
"type": "string",
"enum": [
"ROUTE_CHANGE",
"SESSION_MODIFICATION",
"QOS_CHANGE",
"SLICE_RESOURCE_ALLOCATION",
"RAN_PARAMETER_CHANGE",
Das Expires 12 March 2027 [Page 19]
Internet-Draft AI-Native 5G/6G Finality September 2026
"POLICY_UPDATE",
"NETWORK_API_INVOCATION",
"UPF_RULE_CHANGE",
"BEAM_CHANGE",
"SENSING_OPERATION",
"RF_ENABLE",
"SERVICE_ACTIVATION",
"OTHER"
]
},
"created_at": { "type": "string", "format": "date-time" },
"expires_at": { "type": "string", "format": "date-time" },
"initiator": {
"type": "object",
"required": ["network_function_id", "function_type"],
"properties": {
"network_function_id": { "type": "string" },
"function_type": {
"type": "string",
"enum": [
"AI_RAN_CONTROLLER",
"RIC_XAPP",
"RIC_RAPP",
"SMF",
"AMF",
"PCF",
"UPF_CONTROLLER",
"ORCHESTRATOR",
"NETWORK_API_CLIENT",
"EDGE_AGENT",
"OTHER"
]
},
"agent_id": { "type": "string" },
"model_id": { "type": "string" },
"runtime_attestation_digest": { "type": "string" }
}
},
"network_context": {
"type": "object",
"properties": {
"plmn_id": { "type": "string" },
"network_domain": { "type": "string" },
"slice_id": { "type": "string" },
"cell_ids": { "type": "array", "items": { "type": "string" } },
"edge_region": { "type": "string" },
"jurisdiction": { "type": "string" }
}
Das Expires 12 March 2027 [Page 20]
Internet-Draft AI-Native 5G/6G Finality September 2026
},
"resource_scope": {
"type": "object",
"required": ["resource_type", "resource_ids"],
"properties": {
"resource_type": {
"type": "string",
"enum": [
"SLICE",
"CELL",
"QOS_FLOW",
"SESSION",
"UPF_RULE",
"ROUTE",
"SPECTRUM_RESOURCE",
"BEAM",
"NETWORK_API",
"SENSING_RESOURCE",
"OTHER"
]
},
"resource_ids": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
},
"subscriber_scope": {
"type": "object",
"properties": {
"scope_type": {
"type": "string",
"enum": [
"NONE",
"SINGLE_SUBSCRIBER",
"SUBSCRIBER_GROUP",
"TENANT",
"SLICE",
"CELL_POPULATION"
]
},
"scope_reference": { "type": "string" }
}
}
}
},
"purpose": {
"type": "object",
"required": ["purpose_id", "declared_purpose"],
Das Expires 12 March 2027 [Page 21]
Internet-Draft AI-Native 5G/6G Finality September 2026
"properties": {
"purpose_id": { "type": "string" },
"declared_purpose": { "type": "string" },
"service_intent_reference": { "type": "string" },
"purpose_epoch": { "type": "integer", "minimum": 0 }
}
},
"requested_effect": {
"type": "object",
"required": ["effect_type", "parameters_digest"],
"properties": {
"effect_type": { "type": "string" },
"parameters_digest": {
"type": "object",
"required": ["algorithm", "value"],
"properties": {
"algorithm": {
"type": "string",
"enum": ["SHA-256", "SHA-384", "SHA-512"]
},
"value": { "type": "string" }
}
},
"duration_seconds": { "type": "integer", "minimum": 0 },
"reversibility": {
"type": "string",
"enum": ["REVERSIBLE", "PARTIALLY_REVERSIBLE", "IRREVERSIBLE"]
}
}
},
"policy_state": {
"type": "object",
"required": ["policy_epoch", "authority_epoch", "revocation_epoch"],
"properties": {
"policy_epoch": { "type": "integer", "minimum": 0 },
"authority_epoch": { "type": "integer", "minimum": 0 },
"revocation_epoch": { "type": "integer", "minimum": 0 },
"operator_policy_profile": { "type": "string" },
"regulatory_profile": { "type": "string" }
}
},
"freshness": {
"type": "object",
"required": ["nonce"],
"properties": {
"nonce": { "type": "string", "minLength": 16 },
"sequence": { "type": "integer", "minimum": 0 },
"session_id": { "type": "string" }
Das Expires 12 March 2027 [Page 22]
Internet-Draft AI-Native 5G/6G Finality September 2026
}
},
"finality_sink": {
"type": "object",
"required": ["sink_id", "sink_type"],
"properties": {
"sink_id": { "type": "string" },
"sink_type": {
"type": "string",
"enum": [
"UPF",
"CONTROL_PLANE_GATEWAY",
"RAN_CONTROL",
"O_RAN_E2",
"O_RAN_A1",
"NETWORK_API_GATEWAY",
"RF_ENABLE",
"SESSION_CONTROLLER",
"OTHER"
]
}
}
}
}
}
8.2. NetworkValidationDecision Object
The protected network enforcement function evaluates whether the
proposed network consequence is valid for the current network state.
A successful AI recommendation or policy-engine decision does not
itself cause the network effect.
Das Expires 12 March 2027 [Page 23]
Internet-Draft AI-Native 5G/6G Finality September 2026
{
"version": "1.0",
"object_type": "network_validation_decision",
"decision_id": "nvd-1882bd",
"candidate_act_id": "net-39f8820b",
"decision": "ALLOW",
"validated_predicates": {
"initiator_attested": true,
"resource_scope_valid": true,
"subscriber_scope_valid": true,
"purpose_valid": true,
"requested_effect_valid": true,
"operator_policy_valid": true,
"regulatory_policy_valid": true,
"network_state_valid": true,
"policy_epoch_valid": true,
"revocation_state_valid": true,
"freshness_valid": true,
"sink_binding_valid": true
},
"network_state": {
"topology_epoch": 993,
"configuration_epoch": 771,
"slice_state": "ACTIVE",
"congestion_state": "NORMAL"
},
"protected_state": {
"state_reference": "net-ped-state-7801",
"monotonic_counter": 184991
}
}
8.3. NetworkFinalityAuthority Object
Das Expires 12 March 2027 [Page 24]
Internet-Draft AI-Native 5G/6G Finality September 2026
{
"version": "1.0",
"object_type": "network_finality_authority",
"authority_id": "nfa-7f51ca",
"candidate_act_id": "net-39f8820b",
"decision_id": "nvd-1882bd",
"scope": {
"act_type": "SLICE_RESOURCE_ALLOCATION",
"resource_type": "SLICE",
"resource_ids": ["slice-17"],
"subscriber_scope": {
"scope_type": "TENANT",
"scope_reference": "tenant-A"
},
"permitted_effect": {
"effect_type": "ALLOCATE_CAPACITY",
"parameters_digest": "base64url-effect-digest",
"duration_seconds_max": 300
},
"network_domain": "ran-domain-2",
"jurisdiction": "IN"
},
"binding": {
"candidate_act_digest": {
"algorithm": "SHA-256",
"value": "base64url-net-act-digest"
},
"protected_state_reference": "net-ped-state-7801",
"topology_epoch": 993,
"configuration_epoch": 771,
"policy_epoch": 42,
"authority_epoch": 8,
"revocation_epoch": 7,
"nonce": "C3929177AA801C55",
"finality_sink_id": "ran-finality-sink-04"
},
"lifetime": {
"issued_at": "2026-08-26T17:50:01Z",
"expires_at": "2026-08-26T17:50:05Z",
"single_use": true
},
"issuer": {
"ped_id": "operator-ped-1",
"key_id": "operator-finality-key-4",
"signature": "base64url-signature"
}
}
Das Expires 12 March 2027 [Page 25]
Internet-Draft AI-Native 5G/6G Finality September 2026
8.4. NetworkSinkVerify Request and Response
The Network Finality Sink verifies the actual requested network
effect immediately before the protected configuration, forwarding,
signaling, RF, or resource-allocation change becomes effective.
{
"operation": "NetworkSinkVerify",
"request_id": "net-verify-991",
"candidate_act_id": "net-39f8820b",
"authority_id": "nfa-7f51ca",
"sink": {
"sink_id": "ran-finality-sink-04",
"sink_type": "RAN_CONTROL"
},
"proposed_effect": {
"effect_type": "ALLOCATE_CAPACITY",
"resource_type": "SLICE",
"resource_ids": ["slice-17"],
"parameters": {
"additional_prb_percent": 12,
"duration_seconds": 120
},
"parameters_digest": {
"algorithm": "SHA-256",
"value": "base64url-effect-digest"
}
},
"current_network_state": {
"topology_epoch": 993,
"configuration_epoch": 771
},
"freshness": {
"nonce": "C3929177AA801C55"
}
}
Das Expires 12 March 2027 [Page 26]
Internet-Draft AI-Native 5G/6G Finality September 2026
{
"operation": "NetworkSinkVerify",
"request_id": "net-verify-991",
"decision": "ALLOW",
"verification": {
"authority_signature": "VALID",
"candidate_act_binding": "MATCH",
"initiator_scope": "MATCH",
"resource_scope": "MATCH",
"subscriber_scope": "MATCH",
"effect_parameters": "MATCH",
"topology_epoch": "CURRENT",
"configuration_epoch": "CURRENT",
"policy_epoch": "CURRENT",
"revocation_epoch": "CURRENT",
"nonce": "FRESH",
"consumption_state": "UNUSED",
"sink_binding": "MATCH"
},
"consumption": {
"authority_id": "nfa-7f51ca",
"status": "CONSUMED",
"consumed_at": "2026-08-26T17:50:02Z"
},
"effectuation": {
"permitted": true,
"network_effect_id": "net-effect-4481"
}
}
8.5. Network-State Mismatch Denial
If the topology or configuration changes between protected validation
and effectuation, the sink can deny the stale authority and require
revalidation. This matters for low-latency autonomous control
because a valid decision for one state may be unsafe in a later
state.
Das Expires 12 March 2027 [Page 27]
Internet-Draft AI-Native 5G/6G Finality September 2026
{
"operation": "NetworkSinkVerify",
"request_id": "net-verify-992",
"decision": "DENY",
"error": {
"code": "EF_NETWORK_STATE_MISMATCH",
"message": "Configuration epoch differs from the bound authority epoch.",
"retryable": true
},
"verification": {
"authority_signature": "VALID",
"configuration_epoch_expected": 771,
"configuration_epoch_observed": 772,
"resource_scope": "MATCH",
"sink_binding": "MATCH"
},
"effectuation": {
"permitted": false,
"required_action": "REVALIDATE_CANDIDATE_ACT"
}
}
8.6. Complete AI-RAN Resource Allocation Example
{
"step_1_ai_recommendation": {
"agent_id": "ai-ran-controller-7",
"recommendation": "Increase slice-17 radio capacity by 12% for 120s",
"effect_status": "NON_EFFECTIVE"
},
"step_2_candidate_act": {
"candidate_act_id": "net-39f8820b",
"act_type": "SLICE_RESOURCE_ALLOCATION",
"initiator": {
"network_function_id": "ai-ran-controller-7",
"function_type": "AI_RAN_CONTROLLER",
"agent_id": "ran-agent-7",
"model_id": "traffic-optimizer-v5"
},
"network_context": {
"plmn_id": "00101",
"network_domain": "ran-domain-2",
"slice_id": "slice-17",
"jurisdiction": "IN"
},
"resource_scope": {
"resource_type": "SLICE",
"resource_ids": ["slice-17"],
Das Expires 12 March 2027 [Page 28]
Internet-Draft AI-Native 5G/6G Finality September 2026
"subscriber_scope": {
"scope_type": "TENANT",
"scope_reference": "tenant-A"
}
},
"purpose": {
"purpose_id": "latency-optimization",
"declared_purpose": "Maintain latency SLO for tenant-A"
},
"requested_effect": {
"effect_type": "ALLOCATE_CAPACITY",
"parameters_digest": {
"algorithm": "SHA-256",
"value": "base64url-effect-digest"
},
"duration_seconds": 120,
"reversibility": "REVERSIBLE"
},
"policy_state": {
"policy_epoch": 42,
"authority_epoch": 8,
"revocation_epoch": 7,
"operator_policy_profile": "ran-autonomy-v3"
},
"freshness": {
"nonce": "C3929177AA801C55",
"sequence": 8821
},
"finality_sink": {
"sink_id": "ran-finality-sink-04",
"sink_type": "RAN_CONTROL"
}
},
"step_3_protected_validation": {
"decision": "ALLOW",
"topology_epoch": 993,
"configuration_epoch": 771
},
"step_4_authority": {
"authority_id": "nfa-7f51ca",
"single_use": true,
"expires_in_seconds": 4
},
"step_5_sink_verification": {
"decision": "ALLOW",
"authority_consumed": true
},
"step_6_network_effect": {
Das Expires 12 March 2027 [Page 29]
Internet-Draft AI-Native 5G/6G Finality September 2026
"slice_id": "slice-17",
"additional_prb_percent": 12,
"duration_seconds": 120,
"effect_status": "EFFECTIVE"
}
}
9. Protocol Operation and Failure Handling
9.1. End-to-End Workflow
Act Generator PED Finality Sink
| | |
|-- Candidate Act ---->| |
| | |
| NON-EFFECTIVE | |
|<---------------------| |
| | |
| |-- validate predicates |
| |-- verify protected state |
| |-- verify nonce/epochs |
| | |
| | [DENY] |
| |---- denial evidence ---->|
| | remains NON-EFFECTIVE |
| | |
| | [ALLOW] |
| |-- commit evidence |
| |-- create scoped |
| | finality authority |
| | |
|---------------------- finality authority ------>|
| |
| verify act |
| verify scope |
| verify nonce |
| verify state |
| verify epochs |
| verify sink |
| |
| [FAIL] |
| no effect |
| |
| [PASS] |
| consume |
| authority |
|<---------------- permitted consequence ---------|
Das Expires 12 March 2027 [Page 30]
Internet-Draft AI-Native 5G/6G Finality September 2026
Figure 2: PED and Finality Sink workflow
9.2. PED Processing
The following procedure is illustrative:
function PED_VALIDATE(candidate):
if candidate is malformed:
return DENY(MALFORMED_ACT)
if candidate.nonce is not fresh:
return DENY(REPLAY_OR_STALE)
if candidate.policy_epoch != current_policy_epoch:
return DENY(POLICY_EPOCH_MISMATCH)
if candidate.revocation_epoch != current_revocation_epoch:
return DENY(REVOCATION_STATE_MISMATCH)
if candidate.finality_sink_id is not authorized:
return DENY(SINK_NOT_AUTHORIZED)
if protected_state does not permit candidate:
return DENY(PROTECTED_STATE_DENIAL)
if purpose, jurisdiction, or scope checks fail:
return DENY(PREDICATE_DENIAL)
evidence = COMMIT_PROTECTED_VALIDATION(candidate)
authority = ISSUE_SCOPED_FINALITY_AUTHORITY(
candidate, evidence, current_protected_state)
return ALLOW(authority)
An implementation MAY evaluate additional predicates, including
attestation, instruction provenance, data residency, accelerator
identity, or cumulative disclosure state. The PED MUST perform these
checks while the Candidate Act remains non-effective.
9.3. Finality Sink Verification
Das Expires 12 March 2027 [Page 31]
Internet-Draft AI-Native 5G/6G Finality September 2026
function FINALITY_SINK_VERIFY(candidate, authority):
if authority is absent:
return DENY(NO_FINALITY_AUTHORITY)
if authority integrity check fails:
return DENY(INVALID_AUTHORITY)
if HASH(candidate) != authority.candidate_act_digest:
return DENY(ACT_MISMATCH)
if authority.finality_sink_id != THIS_SINK:
return DENY(SINK_MISMATCH)
if authority is expired or already consumed:
return DENY(STALE_OR_USED)
if authority.nonce is not current:
return DENY(NONCE_FAILURE)
if authority epochs do not match current protected state:
return DENY(EPOCH_OR_STATE_MISMATCH)
if candidate exceeds authorized scope, destination,
jurisdiction, or precision:
return DENY(SCOPE_OR_CONTEXT_MISMATCH)
ATOMICALLY:
consume(authority)
advance_replay_state()
permit_effectuation()
return EFFECTUATED
9.4. Authority Consumption, Replay, and Revocation
For a single-use operation, successful authority consumption SHOULD
be atomic with the state transition that enables effectuation. An
implementation MUST prevent verify- then-effectuate-then-replay of
the same authority. Replay protection MAY use nonce consumption,
monotonic counters, sequence numbers, protected consumed flags,
protected-state advancement, short expiration windows, epoch
advancement, or an equivalent mechanism.
A previously issued authority MUST NOT override a newer revocation
state. If an authority was created under Revocation-Epoch 51 and the
applicable protected state has advanced to Revocation-Epoch 52, the
older authority SHOULD fail unless an explicitly defined policy
permits continued validity. Revocation SHOULD be checked at the
Finality Sink, not merely when the authority was originally created.
The same principle applies to policy epochs. An authority issued
before a material policy change SHOULD NOT silently inherit authority
under the new policy state. Examples include a newly prohibited
location-export precision, a revoked AI tool, a telecom action
removed from authorized scope, a changed data-residency rule, or a
withdrawn model version.
Das Expires 12 March 2027 [Page 32]
Internet-Draft AI-Native 5G/6G Finality September 2026
9.5. Hot Path and Cold Path
Not every Candidate Act requires identical validation cost. A hot
path MAY be used for frequent, previously bounded, low-risk, or
latency-sensitive classes of acts, relying on local protected state,
fresh nonce state, cached policy, short-lived authority, pre-bound
sink identity, and current revocation epoch. A hot-path operation
MUST still perform Finality Sink verification. "Hot path" does not
mean "skip finality."
A Candidate Act SHOULD be escalated to a cold or higher-assurance
path where it involves exact location export, high-value sovereign
data export, cross-jurisdiction processing, RF emission, actuator-
class control, cryptographic-key release, unusual agent behavior,
unknown tool delegation, changed destination, uncertain jurisdiction,
policy anomaly, missing cached state, or high-consequence
infrastructure operation.
A Candidate Act MUST NOT obtain default permission merely because the
hot path cannot make a decision. Cache miss, policy miss, revocation
uncertainty, network failure, unknown destination, unknown
jurisdiction, changed sink, changed tool, or runtime anomaly SHOULD
result in cold-path escalation, delay, downgrade, or denial.
Timeout, cache miss, or uncertainty MUST NOT create default
authority.
A successful cold-path evaluation MAY establish a bounded policy
envelope for subsequent low-latency operations. Later Candidate Acts
within that exact envelope MAY use faster local validation. If any
bound condition changes, the system SHOULD escalate again.
Execution finality SHOULD be implementable without a remote ledger
round trip for every operation. Representative local paths may
operate in the millisecond range; stronger attestation or multi-party
validation may take longer. These figures are implementation
examples, not protocol requirements. External anchoring can
strengthen later evidence. It MUST NOT retroactively authorize an
act that was not valid when effectuation occurred.
9.6. Failure Codes
The following identifiers are protocol-design suggestions and are not
IANA assignments. A conforming implementation MAY expose equivalent
numeric or symbolic codes.
* EF-001 MALFORMED_ACT
* EF-002 NO_FINALITY_AUTHORITY
Das Expires 12 March 2027 [Page 33]
Internet-Draft AI-Native 5G/6G Finality September 2026
* EF-003 INVALID_AUTHORITY
* EF-004 STALE_AUTHORITY
* EF-005 AUTHORITY_ALREADY_USED
* EF-006 REPLAY_DETECTED
* EF-007 NONCE_FAILURE
* EF-010 ACT_MISMATCH
* EF-011 DESCRIPTOR_MISMATCH
* EF-012 SCOPE_MISMATCH
* EF-013 PURPOSE_MISMATCH
* EF-014 CONSEQUENCE_CLASS_MISMATCH
* EF-020 DESTINATION_MISMATCH
* EF-021 JURISDICTION_MISMATCH
* EF-022 DATA_RESIDENCY_MISMATCH
* EF-023 PRECISION_MISMATCH
* EF-030 POLICY_EPOCH_MISMATCH
* EF-031 REVOCATION_STATE_MISMATCH
* EF-032 PROTECTED_STATE_MISMATCH
* EF-033 NETWORK_STATE_MISMATCH
* EF-040 SINK_MISMATCH
* EF-041 EFFECTUATION_BOUNDARY_MISMATCH
* EF-050 ATTESTATION_FAILURE
* EF-060 VALIDATION_TIMEOUT
* EF-061 AUTHORITY_UNCERTAIN
* EF-062 POLICY_UNAVAILABLE
Das Expires 12 March 2027 [Page 34]
Internet-Draft AI-Native 5G/6G Finality September 2026
* EF-063 JURISDICTION_UNRESOLVED
* EF-070 ESCALATION_REQUIRED
* EF-080 FAIL_CLOSED
A denial response MAY specify an allowed remediation, such as
downgrade of precision, escalation to a cold path, or requirement for
fresh authority. Permitted denial actions MAY include deny, delay,
downgrade, redact, suppress, quarantine, request new authority,
escalate, or route for review.
9.7. Fail-Closed Requirements
A conforming implementation MUST fail closed for a protected
consequence when required execution-finality state cannot be
verified. Failure prevents consequence rather than merely
documenting that an unauthorized consequence occurred.
A timeout MUST NOT be interpreted as approval. Verification timeout
is not permission. The implementation MAY retry within policy,
escalate, delay, downgrade, or deny. If no permitted resolution is
available, the Candidate Act remains non-effective.
An implementation MUST consider alternate paths capable of producing
the same protected consequence. Moving the act to a different
interface, plugin, interconnect, or network function MUST NOT
inherently remove the execution-finality requirement if that path can
produce the same protected consequence. Routing around a cold path,
using stale cached authority, fragmenting an act, relocating the
Finality Sink, or moving effectuation to another component does not
create a bypass.
10. Security Considerations
The principal security objective is that a protected consequence MUST
remain technically non-effective unless current, act-specific, scoped
authority is verified at the applicable Finality Sink.
Implementations MUST consider attacks against every load-bearing
element of the finality chain.
Das Expires 12 March 2027 [Page 35]
Internet-Draft AI-Native 5G/6G Finality September 2026
10.1. Replay
An attacker may attempt to reuse a previously valid finality
authority after the original act has completed. Finality authority
SHOULD therefore be bound to Candidate Act identity or digest, nonce,
sequence state, policy and revocation epochs, protected state, scope,
Finality Sink identity, and consumption state. Single-use authority
MUST be consumed or otherwise made unusable before or atomically with
effectuation.
10.2. Candidate Act Substitution
An attacker may obtain valid authority for one Candidate Act and
attempt to substitute a different operation, for example replacing
coarse location with precise coordinates, one tool with another, or
one resource allocation with a broader change. The Finality Sink
MUST verify that the actual consequence corresponds to the act or
digest bound to the authority.
10.3. Sink Substitution
Authority issued for one Finality Sink MUST NOT automatically be
usable at another sink. A Finality Sink MUST verify its own identity
or protected boundary identity against the authority before
effectuation.
10.4. Stale Policy, Revocation, and Protected State
An act MAY have been valid when created but invalid when effectuation
is attempted. The Finality Sink SHOULD verify current policy and
revocation state immediately before consequence. An old upstream
approval MUST NOT automatically override current protected state.
An attacker may attempt rollback, deletion of consumed state, nonce
reset, epoch rollback, stale snapshot restoration, or protected-state
substitution. High-assurance implementations SHOULD use protected
monotonic state, sealed storage, secure counters, or authenticated
state transitions where rollback could produce a consequence.
10.5. Failure of the PED or Finality Sink
The PED is security-critical. If its integrity cannot be
established, the implementation SHOULD NOT release finality authority
for protected consequence classes. Depending on risk class, the
system MAY fail closed, downgrade, quarantine, require another
protected validator, require human approval, move to a cold path, or
disable the protected consequence.
Das Expires 12 March 2027 [Page 36]
Internet-Draft AI-Native 5G/6G Finality September 2026
The Finality Sink is equally load-bearing. An upstream PED cannot
compensate for a sink that permits consequence without checking
authority. A Finality Sink without act-bound authority is not
equivalent to the architecture described here.
10.6. Threat Model: Compromised xApp/rApp Attempting Sink Bypass
The preceding subsections analyze this architecture by attack
technique. This subsection instead analyzes it from a single
attacker's perspective, to make explicit what a compromised RAN-side
automation component can and cannot achieve against a conforming
implementation, and where the residual risk that this specification
does not close actually lies.
10.6.1. Attacker Model
The attacker controls an xApp or rApp that is legitimately admitted
to the RIC, holds valid transport credentials, and is authorized on
A1/E2 or an equivalent interface for some class of operation,
consistent with the description of that admission in Section 5. The
attacker does not hold the Protected Enforcement Domain's signing
key, does not hold sink-local protected activation state, and cannot
forge Finality Sink identity. The attacker can construct and submit
arbitrary Network Candidate Act payloads within the syntactic and
transport permissions its RIC admission already grants it.
10.6.2. Attempted Bypasses and Their Outcomes
The attacker submits a Candidate Act whose requested effect exceeds
its properly authorized purpose, resource, or subscriber scope, for
example broadening a slice-resource change beyond the scope any
legitimate policy would grant it. The Protected Enforcement Domain
validates resource scope, subscriber scope, purpose, and jurisdiction
against policy before evidence is committed, as described in
Section 6.4, and rejects the act; no authority is issued and the act
remains non-effective.
The attacker captures a previously issued, still-unexpired finality
authority for a legitimate act and attempts to resubmit it, either
verbatim or after the underlying act has already been consumed. This
is the Replay case analyzed above: authority is bound to nonce,
sequence state, and consumption state, and single-use authority is
consumed atomically with effectuation, so a replayed submission is
rejected by the Finality Sink even though the transport-layer
submission is otherwise indistinguishable from a legitimate one.
Das Expires 12 March 2027 [Page 37]
Internet-Draft AI-Native 5G/6G Finality September 2026
The attacker obtains a validly issued authority for one act and
attempts to alter the requested effect parameters before presenting
it at the sink, for example changing an approved resource-allocation
percentage or duration after issuance. This is the Candidate Act and
effect-parameter substitution case analyzed above: the Finality Sink
independently recomputes the effect-parameter digest and rejects the
mismatch, since the authority is bound to the original digest and not
to whatever payload is presented alongside it.
The attacker attempts to present a validly issued authority at a
Finality Sink other than the one it was issued for, for example a
different DU, UPF, or network-API gateway than the one named at
issuance. This is the Sink Substitution case analyzed above:
authority is bound to Finality Sink identity, and a sink verifying
its own identity against the authority rejects the submission.
The attacker delays presentation of a validly issued authority until
after the topology, configuration, policy, or revocation epoch has
changed, attempting to exploit the window between PED validation and
effectuation described in Section 8.5. The Finality Sink re-checks
current topology, configuration, policy, and revocation state
immediately before effectuation and rejects the now-stale authority,
independent of whether the authority was valid at the time it was
issued.
The attacker attempts to have its xApp revoked or otherwise disabled
after obtaining valid authority, then continues presenting that
authority at the sink. Because the sink verifies current revocation
epoch rather than trusting the revocation state that held at issuance
time, an authority issued before revocation is rejected once the
revocation epoch the sink checks has advanced, provided the
operator's revocation-epoch update has propagated to the sink before
the bypass attempt.
10.6.3. Residual Risk Not Closed by This Architecture
This threat model assumes the attacker's xApp is compromised but its
RIC admission and A1/E2 authorization are not themselves malicious
grants. If the compromise instead extends to the policy or
authorization system that decides what scope the xApp is legitimately
entitled to, for example a compromised Non-RT RIC policy source that
grants the xApp an overly broad but nominally valid scope, then a
Candidate Act submitted within that broadened scope will pass
Protected Enforcement Domain validation, because the PED is
validating the act against policy it has no independent way to know
is itself compromised. This architecture constrains what an already-
scoped attacker can do outside its granted scope, stale state, or
consumed authority; it does not by itself detect that a policy source
Das Expires 12 March 2027 [Page 38]
Internet-Draft AI-Native 5G/6G Finality September 2026
upstream of the PED has been compromised into granting a scope it
should not have granted. Closing that residual risk requires policy-
source integrity, least-privilege scope grants, and monitoring of
policy-source behavior, which are outside the boundary this
specification defines. Likewise, as discussed in Section 9.7, this
architecture provides no protection at all against a consequence-
bearing path that does not route through a Finality Sink in the first
place; a compromised xApp that can reach the same effect through an
unprotected administrative or legacy interface bypasses this
architecture entirely, not by defeating it.
11. Deployment Considerations
The architecture is an additional finality-control mechanism, not a
replacement for ordinary telecommunications authentication,
authorization, or routing procedures. In AI-native 5G, 5G-Advanced,
O-RAN, and future 6G environments, possible Finality Sink locations
include the UPF, carrier gateway, network API gateway, control-plane
interface, signaling gateway, session-control function, O-RAN
enforcement point, AI-RAN control boundary, packet-egress boundary,
or another consequence-bearing network function.
A valid network identity demonstrates that an entity is recognized.
It does not necessarily establish authority for this act, purpose,
subscriber, destination, jurisdiction, time, policy state, and
consequence. Authentication SHOULD NOT be treated as universal
network-consequence authority.
This profile MAY consume decisions or evidence from identity systems,
OAuth and access-control systems, RBAC, policy engines, AI safety
systems, attestation systems, telecom authentication, enterprise
policy, regulatory policy, human approval, and risk engines. Those
systems provide inputs to finality validation. They do not replace
Finality Sink verification.
12. IANA Considerations
This document requests no IANA actions at this time. It does not
define a new IP protocol number, transport port, DNS record type,
media type, URI scheme, or mandatory global registry.
This document does, however, introduce concrete enumerated values
that are candidates for future registration, including Network
Candidate Act types such as those illustrated in Section 7 and
Section 8 (for example, "ROUTE_CHANGE" and
"SLICE_RESOURCE_ALLOCATION"), and finality failure identifiers such
as those illustrated in Section 9 (for example,
"EF_NETWORK_STATE_MISMATCH"). All such values in this document are
Das Expires 12 March 2027 [Page 39]
Internet-Draft AI-Native 5G/6G Finality September 2026
illustrative and are not IANA assignments. A future version of this
specification intends to request creation of two IANA registries
under Expert Review or Specification Required policy: an "Execution-
Finality Network Act Types" registry, listing the permissible values
of the act_type field and the semantic consequence class each value
represents, and an "Execution-Finality Error Codes" registry, listing
the EF-xxx failure identifiers returned by a Protected Enforcement
Domain or Finality Sink and the mismatch condition each identifier
denotes. Registering these values centrally is intended to let
independently implemented PEDs, Finality Sinks, and interoperating
vendors agree on a common vocabulary for act types and failure
semantics without requiring every deployment to define its own
private enumeration.
13. Intellectual Property Note
Certain technical concepts described in this document are associated
with pending patent applications in the DAS Protocols family,
including PCT/IB2026/054453, PCT/IB2026/055615, PCT/IB2026/055760,
PCT/IB2026/055870, PCT/IB2026/056058, and PCT/IB2026/053385. Any
IETF intellectual-property disclosure required in connection with
this work should be handled in accordance with BCP 79 [RFC8179].
This section is informational and does not define licensing terms.
14. Resources
This section lists related Internet-Drafts in the same execution-
finality family and the reference implementation accompanying this
document. It is informational and is provided for the reader's
convenience; it does not modify the normative content of this
specification.
14.1. Related Internet-Drafts
The following Internet-Drafts apply the same execution-finality
architecture to other domains:
* Non-Terrestrial Network / RF execution finality:
https://datatracker.ietf.org/doc/draft-das-ntn-rf-execution-
finality/
* Payment execution finality: https://datatracker.ietf.org/doc/
draft-das-payment-execution-finality/
* AI-native 6G execution finality (this document):
https://datatracker.ietf.org/doc/draft-das-ai-native-6g-execution-
finality/
Das Expires 12 March 2027 [Page 40]
Internet-Draft AI-Native 5G/6G Finality September 2026
* MAP discovery / communication finality:
https://datatracker.ietf.org/doc/draft-das-map-discovery-
communication-finality/
14.2. Reference Implementation
A runnable reference implementation of the execution-finality
architecture described in this document, including the Candidate Act,
Non-Effective State, Protected Enforcement Domain, Protected
Validation Evidence, Scoped Non-Bearer Finality Authority, and
Finality Sink constructs, together with an automated test suite, is
published at the following repository:
https://github.com/sangmdas/Execution-Finality-for-AI-Native-5G-6G-
and-O-RAN---Runnable-Reference-Implementation
The methodology, experimental environment, measured performance,
variations, and limitations of that implementation are documented in
the repository itself and are summarized at a non-normative level in
Appendix B of this document.
15. Applicability to IETF Working Groups and Research Groups
This section discusses, on a non-normative basis, which existing IETF
working groups and IRTF research groups the subject matter of this
document most directly relates to. It does not itself request
adoption by any group; it is intended to help reviewers and list
participants route discussion of this work to an appropriate venue.
+=============+========================================+=============+
|Group / Area |Why It Fits |Relevance |
+=============+========================================+=============+
|NMOP (Network|NMOP is an active venue for AI/LLM- |High (primary|
|Management |mediated network automation governance |home) |
|Operations) |and operator-facing deployment concerns,| |
| |and this document's subject matter | |
| |directly complements existing NMOP- | |
| |adjacent work such as | |
| |[I-D.smith-opsawg-ai-network-governance]| |
| |on governance of AI-mediated autonomous | |
| |network device management. | |
+-------------+----------------------------------------+-------------+
|RATS (Remote |The Protected Validation Evidence and |High |
|ATtestation |Protected Enforcement Domain constructs |(security |
|ProcedureS) |defined in Section 3 are conceptually |underpinning)|
| |adjacent to RATS's concern with | |
| |verifying that an entity or environment | |
| |is in a trustworthy state before a | |
Das Expires 12 March 2027 [Page 41]
Internet-Draft AI-Native 5G/6G Finality September 2026
| |decision is made on that basis; | |
| |Appendix B.5 and the FAQ entry on RATS | |
| |in Appendix A.8 already describe | |
| |attestation evidence as one input | |
| |predicate to PED validation rather than | |
| |a replacement for it. | |
+-------------+----------------------------------------+-------------+
|NMRG (Network|If the mechanics described here are |Medium |
|Management |judged too early for a standards-track |(incubation) |
|Research |venue, the IRTF's NMRG is actively | |
|Group) |exploring AI-assisted network testing, | |
| |deployment, and management frameworks | |
| |and could provide an incubation venue | |
| |for the underlying architecture before a| |
| |standards-track group takes it up. | |
+-------------+----------------------------------------+-------------+
|WIMSE |WIMSE standardizes fine-grained, least- |Medium |
|(Workload |privilege authorization and token |(adjacent |
|Identity in |formats for workload-to-workload |token |
|Multi-System |interaction, and its charter already |architecture)|
|Environments)|names RATS and SCITT as directly | |
| |collaborating groups. The Scoped Non- | |
| |Bearer Finality Authority construct | |
| |defined in Section 3, and the non-bearer| |
| |contrast drawn against OAuth in | |
| |Appendix A.3, describe a token-like | |
| |artifact with narrower, per-act binding | |
| |than WIMSE's workload-identity tokens; | |
| |the two are adjacent but not identical | |
| |problems, since WIMSE authorizes a | |
| |workload's standing identity while this | |
| |document authorizes one specific | |
| |downstream act. | |
+-------------+----------------------------------------+-------------+
|SCITT (Supply|SCITT defines interoperable building |Medium |
|Chain |blocks, issuers, notaries, and |(evidence |
|Integrity, |transparency services, so that a signed |architecture)|
|Transparency,|statement about an artifact or action | |
|and Trust) |can be independently verified and made | |
| |accountable. The Protected Validation | |
| |Evidence construct in Section 3, and the| |
| |evidence-before-authority ordering | |
| |discussed in the audit logging FAQ entry| |
| |at Appendix A.7, describe a structurally| |
| |similar commitment made before authority| |
| |is usable; SCITT's transparency-service | |
| |model is a plausible realization for how| |
| |Protected Validation Evidence could be | |
Das Expires 12 March 2027 [Page 42]
Internet-Draft AI-Native 5G/6G Finality September 2026
| |committed and later verified in a | |
| |production deployment. | |
+-------------+----------------------------------------+-------------+
|SECDISPATCH |SECDISPATCH is the Security Area's |Process venue|
|(Security |standing venue for routing new security |(routing) |
|Dispatch) |proposals to an appropriate working | |
| |group, research group, or other next | |
| |step, rather than a venue that itself | |
| |develops technical content. Given that | |
| |this document's subject matter spans | |
| |security, network management, and | |
| |telecom-specific concerns, SECDISPATCH | |
| |(or the general DISPATCH working group | |
| |for topics spanning areas) is a | |
| |reasonable first stop for determining | |
| |which of the other groups in this table,| |
| |if any, should take up sustained | |
| |discussion. | |
+-------------+----------------------------------------+-------------+
Table 1
This document's normative content, including the Candidate Act
representation, the Protected Enforcement Domain and Finality Sink
roles, and the JSON interoperability profile in Section 8, is
independent of which group ultimately takes up this work; the table
above reflects venue applicability, not a change to the technical
content of this specification.
16. Conclusion
In AI-native telecommunications, network identity and upstream policy
approval should not automatically become authority for a live network
consequence. A proposed network operation remains non-effective
until protected validation, evidence commitment, scoped finality
authority, and independent sink verification complete successfully.
Network authentication is not network finality. Computation is not
authority.
17. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Das Expires 12 March 2027 [Page 43]
Internet-Draft AI-Native 5G/6G Finality September 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
18. Informative References
[I-D.das-ef-interop]
Das, S., "Execution-Finality for AI Interoperability",
Work in Progress, Internet-Draft, draft-das-execution-
finality-ai-interoperability-00, August 2026,
<https://datatracker.ietf.org/doc/html/draft-das-
execution-finality-ai-interoperability-00>.
[I-D.smith-opsawg-ai-network-governance]
Smith, A. and N. Palin, "Governance Framework for AI-
Mediated Autonomous Network Device Management", Work in
Progress, Internet-Draft, draft-smith-opsawg-ai-network-
governance-00, March 2026,
<https://datatracker.ietf.org/doc/html/draft-smith-opsawg-
ai-network-governance-00>.
[ITU-IMT2030]
ITU-R, "Framework and overall objectives of the future
development of IMT for 2030 and beyond",
Recommendation ITU-R M.2160-0, November 2023,
<https://www.itu.int/rec/R-REC-M.2160>.
[ITU-T-IMT2030-SEC]
ITU-T, "Technical security controls for IMT-2030
networks", 2024. ITU-T security study work addressing
expanded attack surface and trust boundaries for native-
AI, cloud-native, slicing, and integrated sensing
environments.
[ORAN-ARCH]
O-RAN Alliance, "O-RAN Architecture Description", 2026.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
Das Expires 12 March 2027 [Page 44]
Internet-Draft AI-Native 5G/6G Finality September 2026
[TS33501] 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501, 2024.
Appendix A. Frequently Asked Questions (Non-Normative)
This appendix answers questions commonly raised about how this
profile relates to existing telecommunications security mechanisms
and to public AI-native 6G industry roadmaps. It is informational
and introduces no new normative requirements.
A.1. Does this replace 3GPP TS 33.501 authentication?
No. TS 33.501 [TS33501] establishes whether a network function or
subscriber is a recognized, authenticated entity. This profile
operates after that question is answered. It governs whether one
specific, already-authenticated, already-computed operation may
become a live network consequence. An entity can be correctly
authenticated under TS 33.501 and still lack current finality
authority for a particular act.
A.2. Does this replace O-RAN A1/E2/O1/O2 policy interfaces?
No. O-RAN policy interfaces [ORAN-ARCH] deliver policy, intent, and
control decisions into the RAN. This profile does not compete with
that delivery function. It adds a pre-effectuation gate immediately
before the resulting act changes live network state, so that a policy
decision, once delivered, cannot be treated as self-executing, stale-
tolerant, or reusable without independent verification at the
enforcement boundary.
A.3. How does scoped finality authority differ from an OAuth access
token?
An OAuth access token is typically a bearer credential valid for a
scope and a time window; possession of the token is ordinarily
sufficient to invoke the authorized operation. Scoped non-bearer
finality authority is bound to one Candidate Act, one effect, one
resource and subscriber scope, one policy and revocation epoch, one
Finality Sink, and, where single-use is required, one consumption
event. Possession of the serialized authority alone is insufficient
without the corresponding protected validation state at the sink.
Das Expires 12 March 2027 [Page 45]
Internet-Draft AI-Native 5G/6G Finality September 2026
A.4. Why can't an upstream policy engine's ALLOW decision just be
trusted?
An ALLOW decision is a bearer-style signal: once issued, it is
ordinarily treated as sufficient on its own, and nothing prevents it
from being replayed, delayed, or acted upon after the network state
it was computed against has changed. The Network-State Mismatch
Denial example in Section 8.5 shows the resulting race: a decision
valid at T1 may be effectuated at T3 after topology, policy, or
revocation state changed at T2. Execution finality does not distrust
the upstream ALLOW; it requires that the exact act, exact effect
parameters, and current state be independently re-verified at the
effectuation boundary immediately before the ALLOW is permitted to
become a live consequence.
A.5. How does this relate to Zero Trust Architecture (NIST SP 800-207)?
Zero Trust Architecture centers on continuous verification of the
requesting entity, device, and session rather than perimeter-based
trust, and evaluates access per request against policy. This profile
is compatible with and can consume Zero Trust access decisions as PED
validation inputs. It differs in granularity and object: Zero Trust
principally re-verifies whether an entity or session may proceed;
execution finality re-verifies whether one specific, already-computed
act and its exact effect parameters may become effective, immediately
before the live consequence, and consumes the resulting authority so
it cannot be reused.
A.6. Does this require a blockchain or distributed ledger?
No. Protected Validation Evidence MAY be realized with hashes,
signatures, MACs, sealed state, monotonic counters, or Merkle
commitments, and external ledger anchoring is explicitly OPTIONAL and
not required on the hot path, as stated in Section 3. This differs
from architectures that require on-chain consensus for every
protected transaction; this profile's hot-path verification does not
depend on distributed consensus latency.
A.7. How is this different from audit logging or SIEM alerting?
An audit log or SIEM alert ordinarily records that an operation
occurred, after it occurred, so it can be reviewed, investigated, or
alerted on. Protected Validation Evidence is committed before, or
atomically with, release of finality authority, and participates in
the decision of whether the operation is permitted to occur at all,
as described in Section 3. Evidence-before-authority is a
precondition for effectuation; a conventional audit record is a
postcondition describing what already happened.
Das Expires 12 March 2027 [Page 46]
Internet-Draft AI-Native 5G/6G Finality September 2026
A.8. How does this relate to RATS remote attestation?
Remote attestation, including Evidence and Attestation Results as
described in the RATS architecture, MAY be consumed as one input
predicate to Protected Enforcement Domain validation. This profile
does not define, replace, or duplicate attestation verification. It
defines what happens after attestation and policy inputs are
available: whether the exact proposed act may cross the effectuation
boundary.
A.9. How does this differ from Qualcomm's public AI-native 6G roadmap?
Qualcomm's public 6G material describes a platform spanning the air
interface, Giga-MIMO, spectral and energy efficiency, AI-native
RAN/core/device operation, distributed compute, and wide-area
sensing. That work addresses how the network computes and adapts.
This document does not propose a waveform, MIMO technique, spectrum
band, scheduler, or accelerator. It addresses the later, narrower
transition: once such a platform has computed a proposed network
operation, whether that exact operation may become effective. An
explicit Non-Effective State, act-bound non-bearer authority, and
independent sink-side re-verification are not established as an
equivalent primitive in Qualcomm's reviewed public material.
A.10. How does this differ from Huawei's native-trustworthiness and
Agentic Core Network work?
Huawei's public research describes 6G native trustworthiness as a
lifecycle property spanning security, privacy, resilience,
multilateral trust, and continuous trustworthiness assessment,
together with an Agentic Core Network vision in which AI agents
autonomously detect intent and execute services. That work is
broader than this document and directly motivates it: the more
autonomous network execution becomes, the more consequential the
question of final authority over a live effect becomes. This profile
isolates one mechanically specific control point inside that broader
trustworthiness problem, defined by an explicit Non-Effective State,
evidence committed before authority release, and independent Finality
Sink re-verification immediately before effectuation. An equivalent
primitive is not established in Huawei's reviewed public material.
Das Expires 12 March 2027 [Page 47]
Internet-Draft AI-Native 5G/6G Finality September 2026
A.11. How does this relate to GSMA Open Gateway network APIs?
GSMA Open Gateway defines standardized, monetizable network APIs (for
example, quality-on-demand, number verification, and SIM-swap checks)
that expose carrier capability to third-party applications. It
addresses API exposure and commercial access, not whether an already-
authorized API call's exact effect should cross into live network
state at the moment of invocation. A Network Finality Sink MAY be
placed at an Open Gateway API boundary to gate the effectuation of an
invoked capability; the two are complementary rather than
overlapping.
A.12. Does this profile replace existing telecom security architecture
generally?
No. Section 11 states this directly: the architecture is an
additional finality-control mechanism, not a replacement for
authentication, authorization, routing, or policy procedures. It MAY
consume evidence from those systems as validation inputs.
A.13. What about emergency services, lawful intercept, or operator
override?
This document does not yet define emergency, lawful-intercept, or
operator-override consequence classes. A deployment that requires
such paths to bypass finality verification places those paths outside
this architecture's protection for the reasons given in Section 9.7.
Future revisions may define these as explicit, bounded consequence
classes rather than undocumented bypasses.
Appendix B. Carrier-Scale and Radio-Timescale Engineering FAQ (Non-
Normative)
This appendix addresses engineering questions expected from RAN,
core-network, accelerator, O-RAN, and carrier-system engineers. Its
purpose is not to claim that the current reference implementation is
carrier-ready. It defines where execution finality belongs, where it
does not belong, how it can compose with existing 3GPP/O-RAN
mechanisms, and what remains to be demonstrated experimentally.
Das Expires 12 March 2027 [Page 48]
Internet-Draft AI-Native 5G/6G Finality September 2026
B.1. How can execution finality work when some RAN decisions occur much
faster than the reference implementation's measured latency?
The full PED, evidence, signed authority, and Finality Sink path is
not intended to sit inside every PHY/MAC decision. Execution
finality should be applied at the appropriate consequence boundary.
O-RAN publicly describes the Near-RT RIC as operating on
approximately 10 ms to 1 s timescales, while the Non-RT RIC operates
above 1 second, communicating through E2 with E2 nodes including O-
CU-CP, O-CU-UP, and O-DU [ORAN-ARCH]. At least three distinct
finality profiles follow from this.
Profile A, non-real-time control (rApp policy, network configuration,
long-lived optimization policy, slice policy, model deployment,
cross-domain policy), can use a conventional PED/Finality Sink path
without creating a meaningful radio-timescale issue.
Profile B, near-real-time consequential control (xApp-generated E2
control, cell-level configuration, slice resource reallocation, RAN
parameter change, traffic-steering change, certain beam-policy
changes, network exposure actions, session/control-plane mutations),
can plausibly use a DU/CU/E2-node-local Finality Sink:
Near-RT RIC / xApp
|
| proposes control
v
Candidate Act
|
v
PED / local validation
|
v
scoped authority
|
v
E2 Node / DU / CU boundary
|
v
Finality Sink
|
v
actual configuration change
The local Ed25519 benchmark reported in this document's companion
reference implementation showed approximately mean 0.683 ms, p50
0.632 ms, p95 0.866 ms, and p99 1.195 ms for the synthetic PED-plus-
sink path. That result is encouraging for experimentation, but is
Das Expires 12 March 2027 [Page 49]
Internet-Draft AI-Native 5G/6G Finality September 2026
not yet sufficient to establish a production Near-RT RIC performance
claim, since it excludes network transport, E2 processing, real
protected hardware, scheduling contention, and carrier load. A
reasonable research target for this class is p99 finality processing
at or below approximately 1 ms, with PED and sink colocated or edge-
local and without a remote policy or ledger round trip. This is an
engineering target, not an IETF, O-RAN, or 3GPP requirement, and the
current p99 of approximately 1.2 ms does not yet meet it.
Profile C, PHY/MAC-speed decisions, requires a different
architecture. Requiring a full PED cycle, including asymmetric
signing, for every low-level radio scheduling event would be
inappropriate. Instead, execution finality can authorize a bounded
execution envelope, for example validating a cell, slice, maximum
additional PRB percentage, permitted beam set, maximum power delta,
validity window, policy epoch, revocation epoch, and sink once, after
which individual high-speed decisions execute locally only while
remaining inside that exact previously validated envelope:
Bounded Finality Envelope
|
v
DU-local protected state
|
+---- scheduler decision 1
+---- scheduler decision 2
+---- scheduler decision 3
+---- scheduler decision N
The full asymmetric authority issuance does not have to occur for
each micro-decision. A successful stronger or cold-path evaluation
may establish a bounded policy envelope for subsequent low-latency
operations, as described in Section 11; later Candidate Acts inside
the exact envelope may use faster local validation, and a change in a
bound condition requires escalation again. This document's
demonstration of act types such as beam change is a semantic
variation and should not be read as a claim that every physical beam
switch must receive a new asymmetric authority; the load-bearing
finality boundary for extremely fast control may instead be
authorization of the beam-control envelope followed by local
scheduler operation within it. A future DU, DPU, or accelerator
implementation should target a local envelope check on the order of
tens of microseconds or below, potentially much less in hardware; no
such performance has yet been demonstrated, and this remains a future
benchmark target rather than a current performance claim.
Das Expires 12 March 2027 [Page 50]
Internet-Draft AI-Native 5G/6G Finality September 2026
B.2. Can this architecture scale to thousands of cells and large
numbers of RRM decisions?
This has not yet been demonstrated. The current benchmark is a
latency experiment on a small allocation of visible CPUs. It is not
evidence of carrier-wide throughput, millions of operations per
second, thousands of simultaneous cells, line-rate UPF operation, or
real-time DU operation, and this document states that limitation
without qualification.
At scale, the PED should not be a single global instance that every
network action must synchronously contact; that creates an obvious
bottleneck and failure domain. A carrier-oriented deployment would
more likely distribute the function by region, cell, DU, site, slice,
edge region, UPF, network domain, or consequence class, making the
PED a logical role rather than one centralized server:
Operator Trust / Policy Root
|
+------+------+
| |
Region A Region B
| |
+----+----+ +--+---+
| | | | |
PED PED PED PED PED
| | | | |
DU DU UPF DU UPF
Amortization also matters: instead of issuing a complete asymmetric
authority for every scheduler decision, one stronger authorization
can establish a bounded envelope under which many locally verified
operations proceed, where those operations genuinely share the same
validated limits.
A credible carrier-scale evaluation still needs substantially more
than the existing benchmark, at minimum: authorities issued per
second per core, sink verifications per second per core, p50/p95/p99/
p99.9 latency, concurrent cell count, lock and contention behavior,
state-lookup cost, multi-thread and multi-process scalability, NUMA
behavior, persistent-state overhead, failure and failover time, key-
rotation overhead, and DPU/SmartNIC implementation throughput,
evaluated against simulated loads of hundreds, thousands, and tens of
thousands of simultaneously active control domains rather than one
repeated synthetic operation. The current implementation proves the
mechanism can be executed; it does not yet prove the mechanism can
operate at national-carrier scale, and that distinction should remain
explicit.
Das Expires 12 March 2027 [Page 51]
Internet-Draft AI-Native 5G/6G Finality September 2026
B.3. Who controls the keys in a multi-vendor O-RAN deployment?
This is one of the most important unresolved production questions.
In a deployment where the O-RU, O-DU, RIC, and SMO come from
different vendors, the answer should not require one vendor to trust
another vendor's proprietary root key. A cleaner model is an
operator (or another explicitly designated trust-domain authority)
controlling the root of trust through a Finality Issuing CA, with
vendors implementing interoperable verification:
Operator Finality Trust Anchor
|
Finality Issuing CA
|
+-------+-------+
| |
PED signing key PED signing key
Region A Region B
| |
v v
authority authority
| |
+-------+-------+
|
Finality Sinks
This does not require inventing an entirely separate certificate-
management ecosystem. O-RAN security work already specifies X.509
certificates, mTLS, TLS, IPsec, OAuth, and CMPv2, including
CMPv2-based initial enrollment, trust-anchor initialization and
update, certificate renewal, and CRL maintenance [ORAN-ARCH]. An
execution-finality profile could reuse existing operator PKI
infrastructure, but the keys should remain logically separate: a
transport identity key used for mTLS should not automatically become
the authority to sign network finality. A production profile would
need to distinguish a Transport Identity Key from a Finality
Authority Signing Key, with an explicit certificate profile, key
usage, and policy identifier for the latter; that profile does not
currently exist in this reference implementation, which uses a local
Ed25519 signer and verifier without X.509 chain validation, CMPv2
enrollment, certificate renewal, CRL/OCSP, cross-vendor trust, cross-
operator trust, or hardware-backed key storage.
A logical, rather than physical, home for the Finality Issuing CA and
the operator's distributed PED signing keys is the O-RAN Service
Management and Orchestration (SMO) function. The SMO already sits at
the trust apex of an O-RAN deployment, performs lifecycle management
and certificate distribution toward Near-RT RIC, Non-RT RIC, O-DU,
Das Expires 12 March 2027 [Page 52]
Internet-Draft AI-Native 5G/6G Finality September 2026
and O-RU components, and is a natural point from which an operator
could host the root Finality Issuing CA or cross-sign region-local
PED signing keys for multiple RAN vendors without requiring any one
RAN vendor to hold the root. For operations whose Finality Sink sits
at a core or interconnect boundary rather than in the RAN, an
equivalent role could be played by a 3GPP Security Edge Protection
Proxy (SEPP) or Network Exposure Function (NEF) environment, both of
which already terminate cross-domain or cross-operator trust and
could analogously host or cross-sign PED signing keys for finality
authorities whose consequence boundary is a core network function or
an exposed network API rather than a RAN enforcement point. Neither
placement is normatively required by this document; both are offered
as plausible integration points for a production Operator Finality
Trust Domain that reuses existing O-RAN and 3GPP trust apexes rather
than introducing a new one.
A production rotation model could generate key epoch N+1, trust N and
N+1 briefly, bump the authority epoch, stop issuing under N, allow
outstanding short-lived authorities to expire, and then revoke N.
The architecture's existing authority-epoch, revocation-epoch, and
short-authority-lifetime semantics support such rotation, but PKI
lifecycle behavior still needs a normative profile.
B.4. How many bytes does this add, and can constrained links tolerate
it?
Using compact JSON serialization, the current example objects are
approximately: a Network Candidate Act 1,369 bytes, a PED validation
decision 768 bytes, a Finality Authority 1,498 bytes, a Proposed
Effect 274 bytes, and a Sink Verify Request 701 bytes. A naive
transport of a Candidate Act, Authority, and Sink Request together
would therefore involve approximately 3,568 bytes before TLS, IPsec,
E2, PFCP, or other transport overhead. That is too verbose to treat
as a proposed fronthaul wire format; the present JSON profile is
intentionally human-readable and useful for interoperability
experiments, and should not be presented as an optimized carrier
encoding.
The cryptographic core is substantially smaller: an Ed25519 signature
is 64 raw bytes, a SHA-256 act digest 32 raw bytes, a SHA-256
evidence digest 32 raw bytes, and an activation commitment 32 raw
bytes, for 160 raw bytes before IDs, scope, epochs, lifetime, nonce,
and other required semantics. The JSON representation inflates these
values through field names and Base64URL encoding. A production
profile could evaluate CBOR, COSE, compact binary TLV, native E2
information elements, PFCP information elements, local shared-memory
descriptors, or DPU-local metadata rather than verbose JSON.
Das Expires 12 March 2027 [Page 53]
Internet-Draft AI-Native 5G/6G Finality September 2026
The architecture does not inherently require a remote round trip to a
cloud PED or external ledger for every action; this document allows
hot paths using local protected state and does not require an
external ledger round trip for every operation, as stated in
Section 3. PED and sink can be colocated on the same host, DU, DPU,
edge site, or protected network function while remaining logically
separate verification boundaries, and authority metadata may be
piggybacked on an existing control transaction rather than requiring
a separate application-layer exchange. For high-speed RAN operation,
the complete verbose Candidate Act and evidence chain should
generally not be transmitted across Open Fronthaul for every low-
level radio event; a bounded finality authorization followed by DU-
local protected state and fast local execution is more credible.
Overhead does scale with the number of genuinely subscriber-specific
protected operations; that cannot be hidden. But not every packet or
scheduler operation must be a distinct Candidate Act. A cell-level or
slice-level bounded consequence may represent many lower-level
operations, so the correct scaling unit is the protected consequence,
not automatically the packet or the subscriber packet.
B.5. Doesn't 3GPP already solve freshness and replay?
3GPP already contains substantial replay and freshness protection,
and this document does not claim otherwise. 5G NAS security uses NAS
COUNT and performs replay checking; PFCP includes a sequence number
in the message header, while session-related PFCP messages carry an
SEID [TS33501]. F-SEID, SEID, and F-TEID primarily identify
sessions, endpoints, and tunnels rather than functioning as freshness
mechanisms themselves; PFCP sequence numbers provide transaction
sequencing and correlation, and NAS COUNT specifically participates
in replay protection. These mechanisms are valuable, and execution
finality is intended to reuse them where appropriate rather than
duplicate them.
A sequence number answers whether a protocol transaction has already
been processed; a security COUNT helps answer whether a protected
message is replayed; an SEID answers which PFCP session is concerned.
Execution finality asks a broader consequence question: whether this
exact requested effect is authorized for this resource, this
subscriber scope, this purpose, this sink, this current topology and
configuration, this policy epoch, this revocation state, at this
moment, and whether its finality authority has already been consumed.
The distinction is protocol-message freshness versus consequence-
specific current authority. A perfectly valid, authenticated,
integrity-protected, fresh, non-replayed E2 or PFCP request to
increase a slice allocation can still arrive after the configuration
epoch or revocation epoch has changed, or after the requested
Das Expires 12 March 2027 [Page 54]
Internet-Draft AI-Native 5G/6G Finality September 2026
parameters have been altered in transit; execution finality is
intended to make those conditions load-bearing at the effect
boundary.
Execution finality does not require inventing a completely separate
transport protocol. This document's JSON profile defines the
semantic contract and does not require one specific transport; the
objects may be carried over authenticated transports including
operator-internal mechanisms and O-RAN control interfaces, as
described in Section 8. A future realization could carry finality
objects as a PFCP information element, an E2 service-model extension,
a network-API object, or a local IPC object. The research
contribution is the invariant that no protected consequence occurs
without current act-bound finality, not the creation of another
network transport.
B.6. Does the Protected Enforcement Domain become a new bottleneck,
attack surface, or single point of failure?
It can, if implemented badly. A centralized PED that every network
action must synchronously contact would concentrate latency,
availability dependence, denial-of-service exposure, key material,
and state, which would be a poor deployment architecture. The PED
should instead be treated as a distributed logical security role,
realized as needed as a DU-local PED, an edge-region PED, a UPF-local
PED, a SmartNIC/DPU PED, a secure network-function PED, a TEE-backed
local validator, or an HSM-backed authority issuer, depending on
consequence class.
If the PED becomes unavailable, no new valid finality authority can
be issued for an action requiring fresh authority, and therefore no
new protected consequence can occur; timeout is not approval, and
this document requires fail-closed behavior when required finality
state cannot be verified, as stated in Section 9.7. A previously
created bounded envelope may remain valid until its predefined expiry
if its scope, revocation state, network state, and sink verification
remain acceptable, so PED unavailability does not necessarily mean
every radio function immediately stops; it means new authority cannot
silently be invented because the validator is unavailable.
If the PED is compromised, the Finality Sink still provides useful
separation: a malicious or compromised PED cannot change the
candidate, sink, scope, network epoch, or effect parameters after
issuing authority without detection. This should not be overstated,
however. If an attacker controls both the PED signing key and its
policy inputs, and produces a valid authority for a malicious act
that still satisfies the sink's independently checked conditions, the
Finality Sink cannot itself determine that the PED was malicious.
Das Expires 12 March 2027 [Page 55]
Internet-Draft AI-Native 5G/6G Finality September 2026
Production security therefore still requires a protected signing key,
attestation where appropriate, key revocation, least privilege,
policy separation, evidence retention, and possibly multi-validator
approval for extreme-risk actions; this reference implementation does
not provide Byzantine-tolerant PED consensus.
If the Finality Sink is compromised, the consequence is more serious.
This document treats the sink as equally load-bearing: an upstream
PED cannot compensate for a Finality Sink that permits a consequence
without checking authority, as stated in Section 9. If the actual
consequence can bypass the sink, the finality architecture is
defeated, which is why alternate-path closure, described in
Section 9.7, is not optional.
B.7. Do the automated tests prove security?
No. They prove that the current implementation behaves as intended
for the tested cases, including replay, act substitution, sink
substitution, epoch changes, signature tampering, missing activation,
scope changes, and concurrent single-use attempts. They do not prove
protocol security, the absence of implementation vulnerabilities,
carrier safety, formal non-bypassability, correctness under all
concurrency, hardware trust, or Byzantine resilience. A stronger
research package should eventually include a formal threat model
covering at least a compromised AI agent or xApp, a malicious but
authenticated network function, a network attacker, stale
authorization, a replay attacker, PED compromise, sink compromise, a
rollback attacker, a privileged administrator, an alternate
effectuation path, and state-partition failure, with an explicit
statement of which components are trusted. Formal modeling with
tools such as TLA+, Tamarin, or ProVerif would strengthen this work
substantially.
B.8. Is there an actual hardware implementation yet?
No. The current implementation is a software reference
implementation that demonstrates the semantics and failure behavior.
It does not demonstrate an accelerator, RAN silicon, SmartNIC, DPU,
FPGA, secure enclave, O-DU accelerator, or UPF accelerator
implementation from any vendor. One possible future mapping locates
the PED's protected key and state in an HSM or TEE, issues a bounded
authority, and places the Finality Sink on a DU, DPU, or SmartNIC
performing a fast local state check alongside replay-state tracking:
Das Expires 12 March 2027 [Page 56]
Internet-Draft AI-Native 5G/6G Finality September 2026
PED
|
protected key/state
HSM / TEE
|
v
bounded authority
|
v
DU / DPU / SmartNIC
Finality Sink
|
+-------+--------+
| |
fast state check replay state
| |
+-------+--------+
|
v
consequence
For ultra-fast paths, asymmetric cryptography or attestation could
establish the bounded authority once, outside the tight loop,
followed by a cheaper local protected check, such as a MAC, state
comparison, or counter check, inside the loop for repeated bounded
operations. This is a future implementation direction that has not
yet been benchmarked in silicon.
B.9. The Core Engineering Distinction
The most useful way to explain execution finality to an experienced
RAN engineer is not that every 6G network decision must go through
another cryptographic server; that framing would immediately invite a
valid latency objection. The stronger formulation is that execution
finality governs the transition from autonomous computation into
authority. Slow or high-consequence changes may receive individual
act-specific finality, while high-frequency radio operations may
execute inside a previously validated, tightly bounded, and revocable
finality envelope enforced locally at the relevant consequence
boundary:
Das Expires 12 March 2027 [Page 57]
Internet-Draft AI-Native 5G/6G Finality September 2026
FULL FINALITY
|
v
create bounded authority
|
v
FAST LOCAL CONTROL
|
+-- allowed inside bounds
+-- allowed inside bounds
+-- allowed inside bounds
|
`-- bound exceeded
|
v
NON-EFFECTIVE
|
v
revalidation
This preserves the underlying invariant without requiring a
millisecond-scale public-key operation for every PHY event.
B.10. Relationship to Existing 6G Work
This framing is especially relevant because major vendors are already
pushing toward increasingly autonomous networks. Qualcomm publicly
describes 6G as AI-native across device, RAN, and core, including
context-aware operation, dynamic QoS, autonomous adaptation, and
network-defined guardrails, and has also announced agentic RAN
management and autonomous-networking technology. Huawei describes
broad 6G native trustworthiness covering security, privacy, and
resilience, and is publicly developing an agentic 6G core
architecture. This document does not claim that current telecom
vendors have no AI security or guardrails; that would be
indefensible.
Das Expires 12 March 2027 [Page 58]
Internet-Draft AI-Native 5G/6G Finality September 2026
The stronger research question is: when an AI-native RAN/core system
is operating autonomously inside network-defined guardrails, what
common mechanism makes those guardrails technically load-bearing at
the exact point where an autonomous computation becomes a live
network consequence? The proposed execution-finality answer is the
Candidate Act, Non-Effective State, Protected Validation, evidence
commitment, scoped or bounded authority, current-state verification
at the actual consequence boundary, and effect, as defined throughout
this document. Existing authentication, sequence numbers, secure
transport, PKI, access control, and O-RAN security mechanisms remain
essential; they become inputs and foundations for this final
consequence-authorization step rather than technologies this
architecture attempts to replace.
B.11. Summary for IETF and Telecom Reviewers
Execution finality is not proposed as another per-packet security
protocol. It is a vendor-neutral consequence-authorization invariant
that can reuse existing 3GPP/O-RAN identity, freshness, PKI, and
transport security while making an autonomous operation technically
non-effective until its current, act-specific, or bounded authority
is verified at the actual effectuation boundary.
Author's Address
Sangam Das
Independent Inventor
Balasore 756001
Odisha
India
Email: info@sangamdas.com
Das Expires 12 March 2027 [Page 59]