Secure, Privacy-Preserving and Revenue-Aware Orchestration of AI-Native 6G Radio Access Networks

1. Introduction and Motivation

Sixth-generation (6G) networks will be more than faster versions of 5G. They will be AI-native networks, where machine-learning models actively support important decisions. These models may decide how radio resources are allocated, how network traffic is routed, where computing tasks are processed, and which unusual activities should be investigated [1,2].

This creates major benefits, such as better flexibility, lower delay, and smarter use of network resources. However, it also creates new security risks that existing security methods may not fully address [3,4]. For example, an AI model that allocates radio resources becomes a security-critical component. An edge server processing a patient’s health data becomes an important privacy boundary. Similarly, traditional access control methods, such as one-time login and fixed user roles, may not be sufficient for highly dynamic environments such as connected vehicles. A vehicle may move between cells, operators, and different threat environments several times within a minute [5,6].

This article is motivated by recent work on RAN orchestration [7,8]. These studies show that major efficiency improvements can be achieved when common network functions are shared across multiple services. However, deciding where to place and share these functions is computationally difficult because it must consider delay, quality-of-service requirements, and revenue objectives.

The framework presented here extends that idea by adding security as a core design requirement. It asks an important question: how should function sharing, placement, and revenue optimisation change when every shared function must also satisfy authentication, trust, confidentiality, and auditability requirements?

Rather than treating security as an additional cost added after network optimisation, this article treats security as a factor that directly changes the optimisation problem. The goal is a complete cross-layer framework for secure and efficient orchestration of AI-native 6G networks, built from nine interlocking pillars, each presented with a research question, a precise problem formulation, and a candidate algorithmic solution strategy given as pseudocode.

Central Research Question (CRQ):

Each of the nine pillars addresses one facet of the CRQ; together they address it end-to-end. The per-pillar research questions (RQ1–RQ9) appear at the head of each pillar below.

1.1. What This Framework Covers

The framework is organised as a three-layer stack, with three pillars per layer:

• Layer 1 — O-RAN resource and placement foundation: Secure resource allocation, function placement, and service-sharing methods for AI-native 6G and O-RAN environments (Pillars 1–3).
• Layer 2 — Confidential edge intelligence: Federated learning, privacy-preserving AI, secure edge computing, and confidential processing built on top of the orchestration substrate (Pillars 4–6).
• Layer 3 — Network-wide orchestration, trust, and verification: A complete cross-domain orchestration framework focused on revenue-aware decision-making, trust management, auditability, resilience, and formal security verification (Pillars 7–9).

The framework is not a collection of nine separate and unrelated mechanisms. Instead, each pillar provides models, algorithms, security mechanisms, or evaluation methodology that the subsequent pillars depend on, so that the nine pillars form a coherent, buildable stack.

1.2. Why Now

This is the right time to develop security solutions for AI-native 6G networks because major 6G architecture and standardisation decisions are being made now. The security mechanisms selected during this period may shape how future networks operate for many years.

Several enabling technologies are also becoming mature at the same time. O-RAN interfaces are becoming more stable, making it easier to develop open and programmable radio networks. Post-quantum cryptographic standards, including ML-KEM, ML-DSA, and SLH-DSA, are now available for practical deployment. Confidential-computing technologies are also becoming more suitable for edge devices and distributed cloud environments.

However, these technologies are still mostly developed and studied separately. Current solutions do not fully combine AI-based network control, secure O-RAN orchestration, post-quantum authentication, confidential edge computing, trust management, and formal verification within one integrated 6G framework.

This creates an important opportunity. Developing such a framework now can help ensure that security is included from the beginning of AI-native 6G design, rather than being added later after major architectural decisions have already been fixed.

1.3. Organisation of the Article

Section 2 reviews the AI-native 6G security lifecycle, the six-layer reference architecture, and the state of the orchestration and security literatures, identifying the gap this framework fills. Section 3 presents the scope, common methodological template, and the nine pillars at a glance. Section 4, Section 5 and Section 6 develop the nine pillars in detail, grouped into the three layers of the framework. Section 7 shows how the pillars interlock through four vertical threads. Section 8 discusses expected impact and concludes.

2. Background, Related Work, and the Gap

2.1. The AI-Native 6G Security Lifecycle

Security in AI-native 6G networks should be viewed as a complete lifecycle rather than as a set of separate security functions. First, a device must prove its identity. Next, the network decides how much it can trust that device. Based on this trust level, the network grants, limits, or denies access. Communication must then be protected, sensitive tasks must be processed securely at the edge, and all important actions must be recorded for later auditing and possible revocation.

Each security stage depends on the previous stage. For example, the confidence obtained during authentication affects the trust score of a device. The trust score influences access-control decisions and determines whether the device can participate in collaborative or federated learning. Access control decides which sensitive edge-computing tasks are permitted. Finally, auditing and revocation identify malicious behaviour and send this information back to the access-control and enforcement points.

Therefore, these functions should not be designed independently. If authentication, trust, access control, confidential computing, and auditing are treated as separate problems, the overall security of the 6G system can become weak.

This framework uses a six-layer reference architecture based on this security lifecycle [9,10]:

• L1: Intelligent device layer – devices with hardware-based identity and secure credentials.
• L2: 6G radio access layer – gNBs, O-RAN components, reconfigurable intelligent surfaces, and non-terrestrial network components.
• L3: Edge intelligence layer – MEC servers, learning aggregators, and AI inference nodes that support low-latency processing [11].
• L4: Trust and access-control layer – policy decision points, policy enforcement points, trust evaluation, and dynamic access decisions.
• L5: Audit and revocation layer – distributed mechanisms for recording evidence, maintaining revocation information, and supporting accountability [12,13].
• L6: Cloud, digital-twin, and orchestration layer – cloud services, network digital twins, and cross-domain orchestration functions [2].

A key design principle is used throughout this framework. The distributed ledger is used only for important long-term records, such as device registration information, model hashes, revocation status, and security evidence shared across domains. Time-critical decisions, including packet-level authorisation, handover decisions, and real-time edge enforcement, remain at the edge because they must satisfy strict latency requirements.

This approach combines the accountability benefits of distributed audit systems with the speed required by AI-native 6G networks.

Figure 1. The six-layer AI-native 6G reference architecture that anchors this framework. The lifecycle (authenticate → trust → authorise → protect → compute confidentially → audit) climbs the stack; grey tags on the left show which of the nine pillars contribute at each layer.

Figure 1. The six-layer AI-native 6G reference architecture that anchors this framework. The lifecycle (authenticate → trust → authorise → protect → compute confidentially → audit) climbs the stack; grey tags on the left show which of the nine pillars contribute at each layer.

2.2. Where the Orchestration Literature Stands

Recent research has made important progress in O-RAN orchestration. Guo et al. [7] study how to maximise revenue when deploying machine-learning services with service dependencies, delay limits, and quality requirements. They show that this optimisation problem is difficult to solve because it is NP-hard. Their JADES solution simplifies the delay constraint and uses optimisation and rounding methods to find efficient placement decisions. Similarly, Mungari et al. [8] study how xApps can be deployed and shared across services in O-RAN. They also show that the problem is NP-hard. Their OREO framework uses relaxation, decomposition, pruning, and feasibility-restoration methods to identify efficient configurations for shared xApps.

These works build on a broader line of O-RAN research. Earlier studies have explored programmable and software-based RAN platforms [14], network-wide xApp selection [15], energy-aware scaling [16], and the use of learning functions inside the RIC [17]. They also use established optimisation methods, such as submodular maximisation [18] and convex optimisation methods [19].

A key finding from this literature is that sharing common AI or xApp functions across services can significantly reduce computing-resource use. For example, OREO shows that sharing a traffic-prediction function can reduce computing-resource requirements by up to two-thirds compared with deploying separate copies for every service. However, current orchestration work mainly focuses on performance, delay, quality of service, energy, and revenue. It does not fully consider the security risks created when functions are shared across different services or tenants. Sharing an xApp can save resources, but it can also create a security problem. Two services may have different sensitivity levels, different owners, different trust requirements, or different attestation requirements. Therefore, a shared function must not only be efficient; it must also satisfy authentication, confidentiality, trust, and audit requirements. Adding these security requirements changes the structure of the placement and sharing problem. Existing optimisation methods may no longer be directly suitable. This challenge forms the main orchestration problem addressed by this framework.

2.3. Where the Security Literature Stands, and Its Limits

The security literature provides many strong individual technologies, but these technologies are often studied separately. Traditional PKI-based authentication can reveal stable user or device identities and usually does not provide continuous, context-aware authorisation [6]. Role-based access control is also limited because it cannot easily adapt to changing behaviour, device location, network conditions, or the compromise of an AI agent. Blockchain-based trust systems can provide transparency and auditability, but blockchain alone may introduce delay and storage overhead. It also cannot by itself provide the low-latency confidentiality needed for many edge applications [12].

Federated learning can reduce the need to share raw data, but conventional federated averaging is vulnerable to poisoned or low-quality model updates and may not adequately consider the trustworthiness of participating devices [20]. Trusted execution environments can protect sensitive computation at the edge. However, they do not by themselves solve problems related to identity privacy, fine-grained access control, trust evaluation, or revocation [6]. Therefore, the main limitation is not the absence of individual security tools. The main limitation is that there is no complete method for making authentication, trust, access control, confidential computing, auditability, and AI-based orchestration work together in a coordinated way.

2.4. The Gap This Framework Fills

There is currently no proven cross-layer framework in which authentication supports trust evaluation, trust supports both access control and orchestration decisions, access control controls confidential edge computation, and the full system remains revenue-aware, post-quantum-ready, and auditable. More importantly, current work usually treats security as an additional requirement added after placement and sharing decisions have been made. This framework treats security as a core part of the optimisation problem from the beginning.

This framework calls for a framework in which security requirements directly influence where functions are placed, whether functions can be shared, which devices can participate, how confidential computation is authorised, and how evidence is recorded for auditing and revocation. The nine pillars are designed as connected steps towards this goal.

3. The Framework: Scope, Methodology, and the Nine Pillars

3.1. Overarching Goal

To design, formally prove, and experimentally validate a cross-layer security-and-orchestration stack for AI-native 6G in which the security lifecycle (authenticate → evaluate trust → authorise → protect → compute confidentially → audit and revoke) is co-designed with revenue-optimal function placement and sharing, and is resilient against classical, quantum-capable, and AI-specific adversaries.

3.2. Specific Goals

G1

Establish an O-RAN resource-optimisation substrate—functional-split-aware placement, conflict-aware RIC control-loop scheduling, and dynamic PRB–compute slicing (Pillars 1–3)—on which every higher-layer decision is placed, scheduled, and resourced.

G2

Build a confidential and robust intelligence layer—trust-driven federated learning, attested edge inference, and trust-gated xApp sharing—on that substrate (Pillars 4–6).

G3

Close the loop with security-aware revenue-optimal orchestration, cross-domain zero-trust slice access, and a resilience-and-formal-verification capstone (Pillars 7–9).

G4

Throughout, treat security constraints as first-class terms in the placement and sharing optimisation, rather than as post-hoc filters.

3.3. A Common Methodological Template Across All Nine Pillars

Each pillar follows the same disciplined arc, which keeps the framework coherent and the resulting contributions comparable:

• System (and threat) model A precise statement of entities, assumptions, latency and resource targets, and—for the security-facing pillars—the adversary set (external eavesdropper, malicious device, Sybil, compromised edge, honest-but-curious cloud, federated-learning attacker, AI adversary, DoS/jamming, quantum-capable). The optimisation-facing pillars instead state the workload, capacity, and SLA model.
• Problem formulation An explicit optimisation or protocol-design problem with objective, decision variables, and constraints. Where an NP-hardness or security-reduction argument is available, it is given.
• Solution approach A worked algorithmic strategy expressed as pseudocode (never full implementation), covering relaxation, decomposition, rounding, or the protocol message flow as appropriate.
• Analysis Security properties via ProVerif/Tamarin/AVISPA and game-based or UC proofs; performance via complexity analysis and simulation.
• Evaluation Benchmarks against the natural baselines (PKI, RBAC, FedAvg, TEE-only, OrchestRAN/JADES/OREO as relevant), on NS-3/Simu5G, SUMO+Veins, iFogSim/EdgeCloudSim, Flower, and a Colosseum-style O-RAN emulator.

3.4. The Nine Pillars at a Glance

Table 1 maps each pillar to its architectural layer and its core algorithmic or cryptographic machinery. Within each theme the pillars reinforce one another, and across themes the stack is built bottom-up.

4. The Orchestration Substrate: Pillars 1–3 (L2–L3, L6)

Before any security or intelligence layer can be trusted, the network needs a resource fabric that places functions well, schedules control loops without conflict, and divides radio and compute across slices efficiently. This first layer of the framework delivers exactly that substrate through three O-RAN optimisation contributions. Each is a mixed-integer problem, each is shown NP-hard, and each is solved with the relaxation, decomposition, and rounding machinery that the security-aware orchestration of the intelligence and assurance layers (Pillars 4–9) later extends. These three pillars are deliberately in the JADES [7] and OREO [8] tradition: revenue and resource efficiency first, with the placement and sharing structure that Pillars 6 and 7 build directly upon.

4.1. Pillar 1 — Functional-Split-Aware Placement of Virtualized O-RAN Functions with Joint O-Cloud Resource Allocation

 Research question (RQ1) How should functional-split selection and O-Cloud placement be jointly optimised across a disaggregated O-RAN so that energy and transport cost are minimised without violating fronthaul capacity or split-dependent latency—and does the joint problem stay tractable at network scale?

 Research problem In a disaggregated O-RAN, each base station is decomposed into O-DU and O-CU functions that can run at different functional split points (e.g. Option 6, 7.2x, 8) and be placed on different O-Cloud tiers—cell site, edge, or regional [21,22]. The split choice trades fronthaul bandwidth against centralisation gain; the placement choice trades energy and consolidation against midhaul latency and link capacity. Pick them badly and you either burn fronthaul spectrum or blow the latency budget. Prior work largely optimises the split for a fixed placement or the placement for a fixed split [23,24,25]; the closest joint treatment couples splitting with MEC placement for slicing [26], but leaves the energy-versus-transport trade-off across multi-tier O-Clouds open. The problem is to jointly choose the split point and the O-Cloud placement for every base station so as to minimise total energy and resource cost, while respecting fronthaul/midhaul capacity, split-dependent latency budgets, and per-node compute capacity.

 Problem formulation Let base stations be $b\in \mathcal{B}$, candidate split options $o\in \mathcal{O}$, and O-Cloud nodes $n\in \mathcal{N}$ arranged in tiers. Binary variable $x_{b,o,n}\in \{0,1\}$ indicates that b uses split o with its DU/CU functions placed on node n; $y_n\in \{0,1\}$ indicates node n is powered on; and ${\ell }_{b,o}$ is the split-dependent fronthaul load. We minimise energy plus transport cost,

$$\underset{\mathbf{x},\mathbf{y}}{min}\sum _n\left(P_n^{\mathrm{idle}}{y}_n+P_n^{\mathrm{dyn}}{u}_n\left(\mathbf{x}\right)\right)+\eta \sum _{b,o,n}{x}_{b,o,n}{\kappa }_{b,o,n},$$

(1)

where $u_n\left(\mathbf{x}\right)$ is the compute load on node n and ${\kappa }_{b,o,n}$ the fronthaul/midhaul cost, subject to

$$\begin{array}{cc}\hfill & {\sum }_{o,n}{x}_{b,o,n}=1,\forall b;{\sum }_{b,o}{x}_{b,o,n}{\rho }_{b,o}\le C_n{y}_n,\forall n;\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill & {\sum }_{b,o}{x}_{b,o,n}{\ell }_{b,o}\le F_{\mathrm{link}\left(n\right)},\forall n;{\sum }_{o,n}{x}_{b,o,n}{\tau }_{b,o,n}\le {\Gamma }_b,\forall b,\hfill \end{array}$$

(3)

i.e. one split-and-placement per base station, node compute capacity, fronthaul link capacity, and a split-dependent end-to-end latency budget ${\Gamma }_b$. The problem is a mixed-integer non-linear program; it is NP-hard by reduction from the Generalised Assignment Problem (each base station is an item, each node a bin, split options give item-dependent sizes and profits).

 Solution approach Benders-style decomposition: a master problem fixes the discrete split-and-placement, and a resource subproblem allocates compute and routes fronthaul, with cuts fed back. The relaxed placement LP is rounded greedily by marginal energy, then a repair pass fixes any capacity or latency violation by re-placing or downgrading a split.

Algorithm 1 Split-Aware Placement with Benders Decomposition and Rounding

Output:   Placement ${\mathbf{x}}^{★}$, power state ${\mathbf{y}}^{★}$, resource allocation 1: relax $x_{b,o,n}\in [0,1]$; initialise a feasible cell-site placement (all local, split 8) 2: repeat▹ Benders outer loop 3:     Master: solve MILP over $(\mathbf{x},\mathbf{y})$ minimising energy + transport, with current cuts 4:     Subproblem: given placement, solve convex resource/routing feasibility; get dual prices 5:     if subproblem infeasible then add feasibility cut else add optimality cut 6: until master–subproblem gap $\le ϵ$ 7: Rounding: sort fractional $x_{b,o,n}$ by marginal energy; fix highest-gain assignments first 8: Repair: for each violated node/link/latency constraint, re-place b to next-best tier or downgrade split o until feasible 9: power off nodes with zero load; return $({\mathbf{x}}^{★},{\mathbf{y}}^{★})$

Figure 2. Pillar 1 — functional-split-aware placement. Each base station selects a split point and an O-Cloud tier; centralising toward the regional tier saves energy but consumes fronthaul and risks the midhaul latency budget. The solver co-optimises split and placement across all base stations.

Figure 2. Pillar 1 — functional-split-aware placement. Each base station selects a split point and an O-Cloud tier; centralising toward the regional tier saves energy but consumes fronthaul and risks the midhaul latency budget. The solver co-optimises split and placement across all base stations.

4.2. Pillar 2 — Joint xApp/rApp Placement and Conflict-Aware Control-Loop Scheduling

 Research question (RQ2) Given a catalogue of xApps and rApps that may write overlapping RAN parameters, how do we jointly place and schedule their control loops on limited RIC compute so that deployed control value is maximised while conflicts are resolved and every loop still meets its timescale?

 Research problem The near-RT RIC hosts xApps that close control loops in sub-second time [27]; the non-RT RIC hosts rApps operating over seconds or longer. Two problems collide here. First, several control apps may write the same RAN parameter—two xApps both nudging PRB allocation, say—and their actions conflict, an issue only recently recognised as first-class in the O-RAN community [28,29,30]. Second, each app must be scheduled on limited O-Cloud compute so that its control loop still meets its timescale [31]. So the decision is threefold and coupled: which apps to deploy, where to place them, and how to schedule or serialise their loops—maximising deployed control value while avoiding conflicts and honouring both timescale and resource constraints.

 Problem formulation Let apps be $a\in \mathcal{A}$, each with value $p_a$, loop period $T_a$, compute demand ${\rho }_a$, and a write-set ${\Phi }_a$ of RAN parameters. Build a conflict graph $G=(\mathcal{A},E)$ with an edge $(a,a^{\prime })$ when ${\Phi }_a\cap {\Phi }_{a^{\prime }}\ne \varnothing$ and their actions are incompatible. Decisions: $z_a\in \{0,1\}$ (deploy), placement ${\pi }_a\in \mathcal{N}$, and a schedule offset/priority $s_a$. We maximise

$$\underset{\mathbf{z},\mathbf{\pi },\mathbf{s}}{max}\sum _a{z}_a{p}_a-\lambda \sum _{(a,a^{\prime })\in E}{w}_{a{a}^{\prime }}{\xi }_{a{a}^{\prime }}-\gamma \sum _a{z}_a\mathrm{cost}\left({\pi }_a\right),$$

(4)

subject to: conflicting deployed apps are serialised or one is dropped ($z_a+z_{a^{\prime }}-{\xi }_{a{a}^{\prime }}\le 1,\forall (a,a^{\prime })\in E$, with $\xi$ marking a resolved/serialised pair), per-node compute capacity (${\sum }_{a:{\pi }_a=n}{z}_a{\rho }_a\le C_n$), loop schedulability (${\sum }_{a:{\pi }_a=n}{z}_a{\rho }_a/T_a\le 1$, an EDF-style utilisation bound), and E2 subscription limits. Choosing the deployed, conflict-free set of maximum value contains maximum-weight independent set, so the problem is NP-hard.

 Solution approach Lagrangian relaxation decouples placement from scheduling; a greedy weighted-independent-set pass on the conflict graph resolves or drops conflicts; an EDF-style schedulability check enforces loop deadlines, with a repair loop that serialises or evicts the least valuable offender.

Algorithm 2 Conflict-Aware xApp/rApp Placement and Scheduling

Output:   Deployment $\mathbf{z}$, placement $\mathbf{\pi }$, schedule $\mathbf{s}$ 1: build conflict graph G from write-set overlaps ${\Phi }_a\cap {\Phi }_{a^{\prime }}$ 2: repeat▹ Lagrangian outer loop 3:     Placement: for fixed multipliers, assign each candidate app to the min-cost feasible RIC node 4:     Conflict resolution: greedy max-weight independent set on G (keep highest $p_a$, serialise ties) 5:     Schedulability: per node, sort by period (EDF); admit while utilisation $\sum {\rho }_a/T_a\le 1$ 6:     Repair: if a node is infeasible, serialise or evict the lowest-value app; update $\mathbf{z}$ 7:     update Lagrange multipliers by subgradient on the coupling constraints 8: until bound gap $\le ϵ$ or step size small 9: return$(\mathbf{z},\mathbf{\pi },\mathbf{s})$

Figure 3. Pillar 2 — joint control-app placement and scheduling. Apps from both RIC tiers are checked for write-set conflicts; a scheduler then serialises or drops conflicting apps and enforces per-loop deadlines on limited RIC compute, maximising the value of the deployed, conflict-free set.

Figure 3. Pillar 2 — joint control-app placement and scheduling. Apps from both RIC tiers are checked for write-set conflicts; a scheduler then serialises or drops conflicting apps and enforces per-loop deadlines on limited RIC compute, maximising the value of the deployed, conflict-free set.

4.3. Pillar 3 — Dynamic RAN Slicing: Joint PRB and O-Cloud Compute Co-Allocation Under SLA

 Research question (RQ3) When a slice’s achievable rate depends on both radio and compute, how can the two coupled resources be co-allocated online, under time-varying demand, to maximise SLA-weighted revenue while keeping every slice’s rate and latency targets satisfied and the slices isolated?

 Research problem A slice needs two things at once: radio (physical resource blocks) and compute (O-Cloud cycles). Give it PRBs but starve its compute and the extra spectrum is wasted; give it compute but too few PRBs and the same happens in reverse. Demand shifts constantly, so the allocation has to track it online. Most slicing work optimises radio and compute separately, or handles a single resource with deep reinforcement learning [32,33]. What the slice controller actually needs is a single online mechanism that co-allocates PRBs and compute across slices to maximise SLA-weighted revenue, subject to inter-slice isolation, per-slice rate and latency SLAs, and radio/compute capacity, over a time horizon.

 Problem formulation Let slices be $s\in \mathcal{S}$ with revenue weight $r_s$ and SLA $(R_s^{min},L_s^{max})$. Per slot t, decide PRB allocation $b_s\left(t\right)$ and compute allocation $c_s\left(t\right)$; the achievable rate couples both, ${\varphi }_s\left(t\right)=g\left(b_s\left(t\right),c_s\left(t\right)\right)$ (processing-limited when compute is scarce, spectrum-limited otherwise). We maximise the time-averaged revenue minus SLA-violation penalty,

$$max\underset{T\to \infty }{lim}{\displaystyle \frac{1}{T}}{\displaystyle \sum _{t=0}^{T-1}}\sum _s\left(r_s{\varphi }_s\left(t\right)-{\beta }_s{[R_s^{min}-{\varphi }_s\left(t\right)]}^{+}\right),$$

(5)

subject to ${\sum }_s{b}_s\left(t\right)\le B$, ${\sum }_s{c}_s\left(t\right)\le C$, isolation across slices, and latency-queue stability. The per-slot integer PRB-block assignment makes each slot’s subproblem NP-hard; the horizon adds an online dimension. We handle it with Lyapunov drift-plus-penalty [34], which decomposes the horizon into per-slot convex problems while provably tracking the long-run optimum.

 Solution approach Two-timescale control: virtual queues track SLA deficits; each slot solves a drift-plus-penalty subproblem (relaxed then rounded to integer PRB blocks) that co-allocates radio and compute; an optional learned predictor anticipates demand to warm-start the subproblem.

Algorithm 3 Online PRB–Compute Co-Allocation (drift-plus-penalty)

Output:   Per-slot allocation $\{b_s\left(t\right),c_s\left(t\right)\}$ 1: initialise virtual SLA-deficit queues $Q_s\left(0\right)\leftarrow 0$ 2: for each slot t do 3:     (optional) predict demand ${\widehat{d}}_s\left(t\right)$ to warm-start the subproblem 4:     solve ${max}_{b,c}{\sum }_s\left(V{r}_s+Q_s\left(t\right)\right){\varphi }_s(b_s,c_s)$ s.t. $\sum b_s\le B,\sum c_s\le C$ (relaxed) 5:     round $b_s$ to integer PRB blocks; enforce inter-slice isolation; rebalance residual capacity 6:     update queues: $Q_s(t+1)\leftarrow {[Q_s\left(t\right)+R_s^{min}-{\varphi }_s\left(t\right)]}^{+}$ 7: end for 8: return the realised allocation trajectory

Figure 4. Pillar 3 — online PRB–compute co-allocation. Each slice’s achievable rate depends on both radio and compute; a drift-plus-penalty controller with SLA-deficit virtual queues tracks demand across slots, co-allocating the two coupled resource pools to maximise SLA-weighted revenue.

Figure 4. Pillar 3 — online PRB–compute co-allocation. Each slice’s achievable rate depends on both radio and compute; a drift-plus-penalty controller with SLA-deficit virtual queues tracks demand across slots, co-allocating the two coupled resource pools to maximise SLA-weighted revenue.

5. Confidential and Robust Intelligence: Pillars 4–6 (L3–L4, L6)

With the O-RAN orchestration substrate of Pillars 1–3 in place, the second layer of the framework builds the intelligence layer that actually runs the AI, and introduces the security primitives the later layers depend on. Its theme is confidentiality and robustness: collaborative training that resists poisoning and protects gradients (Pillar 4), edge inference that a device can verify before trusting (Pillar 5), and—the pivot of the whole framework—xApp sharing that stays a resource win without becoming a trust hazard (Pillar 6). Two reusable primitives are born here: the dynamic trust score (defined in P4) and the hybrid post-quantum secure session (ECC + ML-KEM, developed in P5); both are consumed unchanged by the assurance layer (Pillars 7–9).

5.1. Pillar 4 — Trust-Weighted Robust Federated Learning for the 6G Edge

 Research question (RQ4) How can federated training across O-RAN edge nodes keep raw data and gradients private, bound the influence of poisoned or low-quality updates, and let a dynamic trust score steer participation—all at once, inside a per-round latency budget?

 Research problem Federated learning lets base stations, RSUs, and MEC nodes train a shared model without pooling raw data [35]. That is a privacy win and an attack surface in equal measure: a handful of malicious participants can poison the global model, inject a backdoor, or free-ride, and honest-but-curious aggregators can try to invert gradients [20,36]. We want aggregation that keeps raw data and gradients private, bounds the influence of poisoned or low-quality contributions, and lets a dynamically computed trust score—defined here and reused across the rest of this framework—steer who participates and how much their update counts.

 Problem formulation Round t: participant i submits update ${\theta }_i^{(t+1)}$ with local sample count $n_i$, quality signal $q_i$, and trust ${\mathrm{TS}}_i$. The trust-weighted aggregate is

$${\alpha }_i={\displaystyle \frac{{\mathrm{TS}}_i{q}_i{n}_i}{{\sum }_j{\mathrm{TS}}_j{q}_j{n}_j}},{\theta }^{(t+1)}=\sum _i{\alpha }_i{\theta }_i^{(t+1)}.$$

(6)

We want an aggregation rule that (i) keeps updates confidential (secure aggregation, so the server sees only the sum), (ii) satisfies an $(ϵ,\delta )$-differential-privacy budget, and (iii) bounds the deviation of ${\theta }^{(t+1)}$ under up to a fraction $\beta$ of Byzantine participants: $\parallel {\theta }^{(t+1)}-{\theta }^{★}\parallel \le \kappa$ for $\beta \le {\beta }_{max}$. Objective: maximise converged accuracy subject to the DP budget, the robustness bound, and a per-round latency cap.

 Solution approach Layer three defences that classical FL treats separately. Secure aggregation via pairwise masking [37] hides individual updates; a robust filter (trimmed mean / Multi-Krum [38]) removes gross outliers; and trust-weighting plus a gradient-anomaly score demotes the subtle poisoners the robust filter misses. Repeated offenders are escalated to the revocation path.

Algorithm 4 Trust-Weighted Robust Secure Aggregation (round t)

Output:   Global model ${\theta }^{(t+1)}$; updated trust; escalations 1: recover only the sum via secure aggregation; obtain per-group robust statistics 2: compute gradient-anomaly score $a_i$ for each i (distance to robust centre) 3: $\mathcal{S}\leftarrow$ Multi-Krum/trimmed-mean survivors (drop top-$\beta$ by $a_i$) 4: for$i\in \mathcal{S}$do 5:     ${\mathrm{TS}}_i\leftarrow \mathrm{update}\_\mathrm{trust}({\mathrm{TS}}_i,a_i,q_i)$▹ good update raises, anomaly lowers 6: end for 7: ${\alpha }_i\leftarrow {\displaystyle \frac{{\mathrm{TS}}_i{q}_i{n}_i}{{\sum }_{j\in \mathcal{S}}{\mathrm{TS}}_j{q}_j{n}_j}}$ for $i\in \mathcal{S}$ 8: add calibrated DP noise to meet $(ϵ,\delta )$; ${\theta }^{(t+1)}\leftarrow {\sum }_{i\in \mathcal{S}}{\alpha }_i{\tilde{\theta }}_i$ 9: fori with ${\mathrm{TS}}_i<{\tau }_{\mathrm{ban}}$ over w rounds: signal revocation (Pillar 2) 10: commit $H\left({\theta }^{(t+1)}\right)$ to audit ledger; return${\theta }^{(t+1)}$

Figure 5. Pillar 4 — three stacked defences that classical FL treats separately. Secure aggregation hides individual updates, a robust filter removes gross outliers, and trust-weighting demotes the subtle poisoners the filter misses; repeated offenders are escalated to the Pillar 2 revocation path.

Figure 5. Pillar 4 — three stacked defences that classical FL treats separately. Secure aggregation hides individual updates, a robust filter removes gross outliers, and trust-weighting demotes the subtle poisoners the filter misses; repeated offenders are escalated to the Pillar 2 revocation path.

5.2. Pillar 5 — Attested, Verifiable Confidential Edge Inference

 Research question (RQ5) Before a device offloads sensitive data to an edge node, how can it verify in one bounded-latency exchange that the node is genuine, running the approved model, keeping the input confidential during computation, and returning a result it can trust?

 Research problem When a device offloads an inference task—say, a health wearable sending biosignals to an MEC node [11]—it faces three worries at once. Is the edge server genuine and running the approved model? Will my raw input stay private during computation, not just in transit [39,40]? And can I trust the result it hands back, or could the node have fabricated or tampered with it? The device needs verifiable assurance on all three before it commits sensitive data, and it needs that assurance inside a 6G latency budget. This pillar is also where the hybrid post-quantum secure session (ECC + ML-KEM [41,42]) reused by later layers is established.

 Problem formulation Let edge $E_j$ hold model parameters $\theta$ with approved hash $h_{\theta }$. The device requires $\mathrm{Attest}\left(E_j\right)=1$ (remote attestation succeeds), then sends $C_i={\mathrm{Enc}}_{\mathrm{SK}}(D_i\parallel {\mathrm{Policy}}_i\parallel N_i)$, and receives $Y_i=f_{\theta }\left(D_i\right)$ with a proof $\pi$ that the output was produced by the approved model inside the TEE. We minimise end-to-end task latency $T_{\mathrm{task}}$ subject to: input privacy (raw $D_i$ never leaves the enclave in the clear), model confidentiality ($\theta$ not extractable), output verifiability ($Pr\left[\mathrm{accept}\mathrm{forged}Y\right]\le ϵ$), and freshness. Where a full TEE is too costly, allow a split: sensitive layers run confidentially, the rest in the open.

 Solution approach Attestation-gated offload: verify the enclave and the model hash first, then stream encrypted input into the enclave, execute, and return the result bound to a signed attestation quote and a lightweight verifiable- computation tag. Split-inference fallback keeps latency bounded on constrained edges.

Algorithm 5 Attested Confidential Edge Inference (device i, edge $E_j$)

Output:   Verified result $Y_i$ or ⊥ 1: i: request attestation quote from $E_j$ 2: $E_j\to i$: quote Q over enclave measurement and loaded-model hash $h_{\theta }^{\prime }$ 3: if$\mathrm{Verify}\left(Q\right)=1$and$h_{\theta }^{\prime }=h_{\theta }$then proceed else return⊥ 4: if device budget or edge load high then split: run sensitive layers in enclave, rest outside 5: $i\to E_j$: $C_i={\mathrm{Enc}}_{\mathrm{SK}}(D_i\parallel {\mathrm{Policy}}_i\parallel N_i)$ 6: $E_j$: decrypt inside enclave; $Y_i\leftarrow f_{\theta }\left(D_i\right)$; produce proof $\pi$ and tag ${\mathrm{MAC}}_{\mathrm{SK}}(Y_i\parallel N_i)$ 7: $E_j\to i$: ${\mathrm{Enc}}_{\mathrm{SK}}\left(Y_i\right)\parallel \pi \parallel \mathrm{MAC}$ 8: i: verify $\pi$, MAC, freshness, and $T_{\mathrm{task}}\le \Gamma$; if all hold accept $Y_i$else⊥ 9: log $H({\mathrm{PID}}_i\parallel h_{\theta }\parallel \mathrm{Decision}\parallel T)$ to audit ledger; return$Y_i$

Figure 6. Pillar 5 — attestation-gated confidential inference. The device verifies the enclave and the approved model hash before sending encrypted input; the result returns bound to an attestation proof and a verifiable-computation tag, with a split-inference fallback when the edge is resource-constrained.

Figure 6. Pillar 5 — attestation-gated confidential inference. The device verifies the enclave and the approved model hash before sending encrypted input; the result returns bound to an attestation proof and a verifiable-computation tag, with a split-inference fallback when the edge is resource-constrained.

5.3. Pillar 6 — Security-Aware xApp Sharing and Placement

 Research question (RQ6) Can xApp sharing—the single biggest source of resource savings in O-RAN orchestration—be made security-aware, so that instances are shared only between services whose tenancy, sensitivity, and attestation class are compatible, without sacrificing the efficiency that made sharing worthwhile?

 Research problem This is the pillar where the security stack meets the orchestration stack head-on. OREO [8] showed that sharing an xApp—one traffic predictor feeding two services instead of two copies—saves up to two-thirds of the computing resources. But sharing an xApp across two services that sit at different sensitivity levels, belong to different tenants, or carry different attestation requirements is a trust violation waiting to happen [3,43]. The problem is to decide xApp deployment and sharing so that resource use is minimised and sharing only ever happens between services whose security context is compatible.

 Problem formulation Following the xDeSh model [8], let $z_{c_s}\in \{0,1\}$ select configuration $c_s$ for service s, and $v_{c_s,f_{\chi }^{\left(j\right)}}\in \{0,1\}$ indicate that service s uses xApp instance $f_{\chi }^{\left(j\right)}$. We add a security-compatibility predicate $\mathrm{compat}(s,s^{\prime })$ that holds only when two services may share an instance (same tenant/attestation class or an explicit cross-tenant policy). The objective augments the OREO objective with a sharing-legality constraint:

$$\underset{z,v,\rho }{max}\sum _s\sum _{c_s}{z}_{c_s}{p}_s-\frac{1}{K}\sum _{f,\chi ,j,k}{\displaystyle \frac{{\rho }_{f_{\chi }^{\left(j\right)},k}}{B_k}}$$

(7)

subject to the OREO constraints (one configuration per service, resource budget, quality and latency targets) plus

$$v_{c_s,f_{\chi }^{\left(j\right)}}=v_{c_{s^{\prime }},f_{\chi }^{\left(j\right)}}=1\Rightarrow \mathrm{compat}(s,s^{\prime })=1,\mathrm{attest}-\mathrm{class}\left(f_{\chi }^{\left(j\right)}\right)⪰\underset{s:v=1}{max}\mathrm{sens}\left(s\right).$$

(8)

The compatibility constraint breaks the clean facility-location reduction, so the OREO solver must be extended rather than reused verbatim.

 Solution approach Keep OREO’s Lagrangian-relaxation-plus-subgradient skeleton, but partition the sharing graph into security-compatibility cliques before the LR2 (instantiation) subproblem, so that sharing is only ever proposed within a clique. Feasibility restoration also checks the attestation-class dominance and splits an instance when a new, higher-sensitivity service would otherwise contaminate a shared one.

Algorithm 6 Security-Aware xApp Sharing and Placement

Output:   Feasible $(z,v,\rho )$ minimising resources with legal sharing 1: partition candidate instances into compatibility cliques via $\mathrm{compat}(·,·)$ 2: repeat (LR outer loop) 3:    LR1: per-service knapsack ⇒ tentative config z 4:    LR2: facility-location within each clique only ⇒ instantiation v (sharing legal by construction) 5:    LR3: convex CPU allocation $\Rightarrow \rho$ 6:    update Lagrange multipliers via subgradient 7: until bounds converge or step size $<\Gamma$ 8: Feasibility restoration: 9:    ensure functional coverage; if a service needs an xApp missing from its clique, instantiate fresh 10:    if attest-class$\left(f\right)$≺ sens of a would-be sharer then split instance 11:    adjust quality/latency (complexity bump / CPU bump); drop lowest-priority service if budget exceeded 12: return$(z,v,\rho )$

Figure 7. Pillar 6 — why security-aware sharing is a distinct problem. Left: OREO-style sharing across services at different sensitivity levels or tenants creates a trust-boundary violation. Right: the solver first partitions candidate instances into security-compatibility cliques, so sharing is proposed only where it is legal by construction; a would-be higher-sensitivity sharer triggers an instance split instead.

Figure 7. Pillar 6 — why security-aware sharing is a distinct problem. Left: OREO-style sharing across services at different sensitivity levels or tenants creates a trust-boundary violation. Right: the solver first partitions candidate instances into security-compatibility cliques, so sharing is proposed only where it is legal by construction; a would-be higher-sensitivity sharer triggers an instance split instead.

6. Network-Wide Orchestration, Cross-Domain Trust, and Assurance: Pillars 7–9 (L4–L6)

The final layer of the framework lifts the work from individual mechanisms to the network as a whole. Pillar 7 makes the revenue-optimal orchestrator security-aware. Pillar 8 extends trust and access control across operator and edge-domain boundaries. Pillar 9 is the capstone: an end-to-end resilience, audit, and formal-verification treatment that ties the eight preceding contributions into a single system with provable properties.

6.1. Pillar 7 — Revenue-Optimal Secure Service Orchestration

 Research question (RQ7) When the cost of admitting a request includes its security overhead—attestation, confidential computation, trust evaluation—and sharing must respect the legality constraint of RQ6, can revenue-optimal orchestration still be posed as a tractable relaxation-and-rounding problem, and how much revenue does security-awareness actually cost?

 Research problem The operator wants to maximise revenue by choosing which service requests to satisfy, at what quality, with what compute allocation—the JADES problem [7]. But in an AI-native network, satisfying a request now also means paying its security cost: attestation, confidential-computation overhead, trust-evaluation cycles, and the resource fragmentation that Pillar 6’s legal-sharing constraint imposes. The problem is to extend revenue-optimal orchestration so that these security costs are inside the objective and the constraints, not bolted on afterwards, and to show the resulting problem is still tractable via relaxation and rounding.

 Problem formulation Building on JADES, let $x_u\in \{0,1\}$ select user request u with price $r_u$, and ${\mu }_{f_q}$ the compute allocated to function f at quality q. The security-aware profit is

$$\underset{\mathbf{x},\mathbf{y},\mathbf{z},\mathbf{\mu }}{max}\sum _u{x}_u\left(r_u-s_u\right)-\eta \sum _f\sum _q{\mu }_{f_q}$$

(9)

where $s_u$ is the per-request security overhead (attestation + confidential-compute + trust cycles), subject to the JADES delay, quality, and capacity constraints ${\tau }_u^a\le {\Gamma }_u^a$, $q_u^a\ge x_u{Q}_u^a$, ${\sum }_{f,q}{\mu }_{f_q}\le C$, plus security side-constraints: only trust-admitted requests are eligible ($x_u\le \mathbf{1}[{\mathrm{TS}}_u\ge {\tau }_T]$), and shared instances obey Pillar 6’s legality. The problem remains mixed-integer non-convex and NP-hard (the JADES KNAPSACK reduction carries over), but the delay constraint still convexifies under the $\mu \leftrightarrow \tau$ change of variables.

 Solution approach Reuse the JADES machinery—linear relaxation, block coordinate descent between a delay-budget block and a placement block, then dependent randomised rounding—but fold the security overhead into the price and the trust-eligibility into the placement block. Rounding is followed by a security-feasibility pass mirroring the quality/delay feasibility check.

Algorithm 7 Security-Aware Revenue-Optimal Orchestration (SA-JADES)

Output:   Selection ${\mathbf{x}}^{★}$, placement ${\mathbf{y}}^{★},{\mathbf{z}}^{★}$, allocation ${\mathbf{\mu }}^{★}$ 1: drop u with ${\mathrm{TS}}_u<{\tau }_T$; initialise placement greedily by $(r_u-s_u)$ density 2: repeat (BCD) 3:    Block 1: fix placement, solve convex delay-budget allocation over $\left\{{\tau }_{f_q}\right\}$ 4:    Block 2: fix delays, solve LP for relaxed $\{x_u,y,z\}$ with legal-sharing constraints 5: until objective change $<ϵ$ 6: for$n=1\dots N$do 7:     dependent randomised rounding of $(\widehat{x},\widehat{y},\widehat{z})$ 8:     quality-adjust; security-feasibility pass: verify attestation/trust/legal-sharing 9:     check delay + capacity via Block 1; if infeasible drop lowest-price users 10:     keep best feasible solution by profit 11: end for 12: return best $({\mathbf{x}}^{★},{\mathbf{y}}^{★},{\mathbf{z}}^{★},{\mathbf{\mu }}^{★})$

Figure 8. Pillar 7 — SA-JADES. The JADES skeleton (relaxation, block coordinate descent between a convex delay-budget block and an LP placement block, dependent randomised rounding) is reused, but security overhead is folded into the price ($r_u-s_u$), trust gates eligibility, Pillar 6’s legal-sharing enters the placement LP, and a security-feasibility pass follows rounding.

Figure 8. Pillar 7 — SA-JADES. The JADES skeleton (relaxation, block coordinate descent between a convex delay-budget block and an LP placement block, dependent randomised rounding) is reused, but security overhead is folded into the price ($r_u-s_u$), trust gates eligibility, Pillar 6’s legal-sharing enters the placement LP, and a security-feasibility pass follows rounding.

6.2. Pillar 8 — Cross-Domain Zero-Trust Slice Access

 Research question (RQ8) How can a slice be authorised continuously and explainably across operator and edge-domain boundaries under zero-trust principles, so that a visited domain verifies a roaming principal without ever learning its raw context, and decisions adapt to live risk rather than resting on a one-time grant?

 Research problem A 6G service seldom lives inside one operator. A vehicle roams across operators; an edge task may run on a partner’s O-Cloud; a slice may span administrative domains. Zero-trust says “never trust, always verify” [44,45]—but verifying continuously across domains, without any domain having to expose its raw context or its users’ identities, and while keeping decisions explainable and auditable, is genuinely hard in an O-RAN setting [46]. What this pillar builds is continuous, risk-adaptive, explainable authorisation for users, devices, and AI agents accessing slices across multiple domains, with privacy-preserving cross-domain evidence.

 Problem formulation Access to slice s by principal i is a continuous decision function of attributes ${\mathrm{Attr}}_i$, trust ${\mathrm{TS}}_i\left(t\right)$, AI risk ${\mathrm{Risk}}_i$, slice sensitivity, location, and time:

$$\mathrm{Decision}=\left\{\begin{array}{cc}\mathrm{Grant}\hfill & {\mathrm{TS}}_i\ge {\tau }_T\wedge {\mathrm{Attr}}_i\vDash {\mathrm{Policy}}_s\wedge {\mathrm{Risk}}_i\le {\rho }^{★}\hfill \\ \mathrm{Limited}\hfill & {\tau }_L\le {\mathrm{TS}}_i<{\tau }_T\hfill \\ \mathrm{Deny}\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(10)

We minimise cross-domain decision latency and information leakage subject to: continuous re-evaluation (no long-lived unconditional grant), explainability (every decision carries a reason code), and privacy—domain A learns a verifiable trust attestation about i from domain B without learning i’s raw context. The objective is to bound both decision latency and the mutual information between the exchanged evidence and the principal’s identity.

 Solution approach Capability tokens carry attribute assertions; cross-domain trust is exchanged as signed, privacy-preserving attestations anchored in the shared audit layer; a risk-adaptive policy engine re-scores continuously and degrades rather than revoking abruptly. Reason codes are emitted for every grant, limit, or denial.

Algorithm 8 Cross-Domain Zero-Trust Continuous Authorisation

Output:   Streaming decisions with reason codes 1: A requests a privacy-preserving trust attestation for i from B (no raw context) 2: B returns signed $\langle {\mathrm{TS}}_i,\mathrm{attr}-\mathrm{commitments},\mathrm{validity}\rangle$ anchored on shared ledger 3: A verifies signature and freshness against revocation state 4: loop every evaluation window 5:     recompute ${\mathrm{Risk}}_i$ from live behaviour; combine with ${\mathrm{TS}}_i$, ${\mathrm{Attr}}_i$, sensitivity 6:     evaluate decision function; emit reason code 7:     if Grant/Limited: issue/refresh capability token scoped to s 8:     if Deny: revoke token, log ${\mathrm{Record}}_i$, notify B 9:     if ${\mathrm{Risk}}_i$ crosses escalation: quarantine + trigger cross-domain revocation 10: end loop

Figure 9. Pillar 8 — cross-domain zero-trust. The visited domain A authorises a roaming principal from its home domain B using a signed, privacy-preserving trust attestation (anchored on a shared ledger) that reveals no raw context; a risk-adaptive engine re-scores continuously, emits reason codes, and degrades rather than revoking abruptly.

Figure 9. Pillar 8 — cross-domain zero-trust. The visited domain A authorises a roaming principal from its home domain B using a signed, privacy-preserving trust attestation (anchored on a shared ledger) that reveals no raw context; a risk-adaptive engine re-scores continuously, emits reason codes, and degrades rather than revoking abruptly.

6.3. Pillar 9 — Resilience, Auditability, and End-to-End Formal Assurance (Capstone)

 Research question (RQ9) Does the composition of the eight preceding mechanisms actually hold together—can the full stack be formally verified end-to-end, and does it survive simultaneous, coordinated attacks while remaining fully auditable from a ledger that never stores raw data?

 Research problem Eight pillars give eight mechanisms. The capstone must answer the question a sceptical reviewer—or a network operator—will ask: does the whole thing hold together in practice, and does it survive attack? The problem is to formally verify the composed protocol end-to-end, to quantify resilience under simultaneous attacks (DDoS + poisoning + compromised edge + jamming), and to prove that the audit-and-revocation layer can reconstruct any security decision without ever exposing raw sensitive data.

 Problem formulation Given the composed system $\Sigma$ = (Pillars 1–8), establish the security-property set $\mathcal{P}$ = {mutual authentication, anonymity, unlinkability, forward secrecy, replay/MITM/impersonation resistance, access-control correctness, confidentiality & integrity, model confidentiality, poisoning resilience, auditability, graceful degradation}. Formally, we require $\Sigma \vDash p$ for each $p\in \mathcal{P}$ under the full adversary set. For resilience, define survival rate $\mathrm{SR}\left(\mathcal{A}\right)$ under attack mix $\mathcal{A}$ and containment time $T_{\mathrm{cont}}$; the objective is to characterise the frontier $\mathrm{SR}$ vs. $T_{\mathrm{cont}}$ and to show auditability: every ${\mathrm{Record}}_i=H({\mathrm{PID}}_i\parallel H\left({\mathrm{Request}}_i\right)\parallel {\mathrm{Decision}}_i\parallel T_i)$ is verifiable while raw data stays off-chain.

 Solution approach A composition proof: verify each protocol phase in ProVerif/Tamarin [47,48], then argue secure composition across phases (session keys and pseudonyms are the shared state; show no cross-phase leakage). Game-based / UC reductions for the computational properties (hybrid KEM secrecy, anonymity, unlinkability). Resilience is measured empirically on the integrated emulator under injected attack mixes; auditability is proved by a replay-from-ledger construction.

Algorithm 9 End-to-End Assurance and Resilience Evaluation

Output:   Verification verdicts; resilience frontier; audit-replay proof 1: for each phase $\varphi$ in {auth, revoke, admit, FL, inference, share, orchestrate, x-domain} do 2:     model $\varphi$ in ProVerif/Tamarin; check its properties ${\mathcal{P}}_{\varphi }\subseteq \mathcal{P}$ 3: end for 4: Composition: show shared state (SK, PID, tokens) leaks nothing across phases $\Rightarrow \Sigma \vDash \mathcal{P}$ 5: Computational: game-based reductions for hybrid-KEM secrecy, anonymity, unlinkability 6: for each attack mix $m\in \mathcal{M}$ (DDoS+poison+compromise+jam) do 7:     run integrated emulator; record $\mathrm{SR}\left(m\right)$, $T_{\mathrm{cont}}\left(m\right)$, revocation-propagation delay 8: end for 9: Audit replay: reconstruct each decision from ledger records; verify no raw data required 10: return verdicts, $\left\{(\mathrm{SR},T_{\mathrm{cont}})\right\}$, replay proof

Figure 10. Pillar 9 — the assurance capstone. Each phase is verified independently, a composition argument shows the shared state (session keys, pseudonyms, tokens) leaks nothing across phases, and the full property set is discharged; empirically, the integrated emulator characterises the survival-rate vs. containment-time frontier under simultaneous DDoS, poisoning, compromise, and jamming.

Figure 10. Pillar 9 — the assurance capstone. Each phase is verified independently, a composition argument shows the shared state (session keys, pseudonyms, tokens) leaks nothing across phases, and the full property set is discharged; empirically, the integrated emulator characterises the survival-rate vs. containment-time frontier under simultaneous DDoS, poisoning, compromise, and jamming.

7. How the Nine Pillars Fit Together

It would be easy to read the list above as nine loosely related research pillars. It is not. This framework is engineered so that each contribution consumes the guarantees of earlier ones and produces guarantees the later ones depend on. Table 2 makes the dependency chain explicit.

Four threads run vertically through the whole stack and give it its coherence:

The

placement–sharing thread The O-Cloud placement and resource model built in P1, extended by P2’s control-app deployment model and P3’s slice model, is exactly the structure that P6 makes security-aware and P7 turns revenue-optimal. The optimisation spine of this framework runs unbroken from Pillar 1 to Pillar 7, in the JADES/OREO lineage.

The

trust thread A single trust score ${\mathrm{TS}}_i\left(t\right)$ is defined where it is first needed (P4, for federated-learning eligibility and weighting) and then reused unchanged: it decides orchestration eligibility (P7) and drives cross-domain authorisation (P8). One definition, many consumers—this is what prevents the “each mechanism in isolation” failure mode.

The

post-quantum thread The hybrid ECC + ML-KEM session construction is designed in P5 (where attested confidential offload first needs it) and reused by P4 and P8, so the confidential-intelligence and cross-domain layers inherit quantum resilience from a single well-analysed primitive rather than re-inventing it per pillar.

The

audit thread The append-only, hash-only ledger discipline (model hashes, attestation outcomes, revocation, cross-domain evidence—never raw data) is set in P4/P5 and honoured by P7 and P8, so that P9 can prove auditability by construction.

The payoff of this design is that Pillar 9 is not a heroic after-the-fact integration effort; it is the natural closing of a loop that was engineered from Pillar 1 onward. And the orchestration pillars (P6, P7) are where this framework’s central scientific claim is tested: that security constraints reshape—rather than merely tax—the revenue-optimal placement and sharing problem laid down by Pillars 1–3, and that the reshaped problem is still solvable at scale.

8. Expected Impact and Concluding Remarks

8.1. Scientific Impact

The main scientific message of this article is that security should not be treated as an additional cost in RAN orchestration. Instead, security requirements should directly influence how network functions are placed, shared, scheduled, and managed. Current orchestration research mainly focuses on delay, resource use, energy, and revenue. Security research mainly focuses on authentication, privacy, trust, and cryptography. The framework presented here brings these two areas together through its nine pillars.

Realising this framework yields secure O-RAN optimisation methods for function placement, conflict-aware control-loop scheduling, and joint radio-compute resource allocation. It also yields reusable trust mechanisms, post-quantum secure sessions for confidential edge computing, and an end-to-end security framework for AI-native 6G networks. A key outcome is formal proofs and practical experiments showing that secure orchestration can remain scalable and efficient even when authentication, confidentiality, trust, auditability, and post-quantum security requirements are included.

8.2. Practical and Societal Impact

6G systems are currently being designed and standardised. Security decisions made during this period may influence deployed networks for many years. Therefore, it is important to develop secure and practical solutions before major network designs become fixed. The framework can support future 6G networks in areas where security failures may have serious consequences. These include connected vehicles, intelligent transport systems, healthcare monitoring, industrial automation, and critical infrastructure.

For example, a security failure in a vehicular network may affect road safety. A failure in healthcare edge computing may expose sensitive patient information or delay important medical decisions. The mechanisms sketched in Pillars 4, 5, and 8 are aimed precisely at improving trust, confidentiality, secure access, and resilience in such environments [5,49].

8.3. Concluding Remarks

This article addresses one central question: how can AI-native 6G networks remain trustworthy, confidential, post-quantum secure, and economically efficient at the same time? It answers it through a cross-layer framework built from nine interlocking pillars. The first layer develops the secure O-RAN orchestration foundation. The second adds confidential edge intelligence, federated learning, and post-quantum security. The third develops network-wide trust, revenue-aware orchestration, cross-domain security, resilience, and formal verification.

The final goal is a complete cross-layer framework in which authentication supports trust, trust supports access control and orchestration, access control controls confidential edge computing, and auditing supports accountability and revocation. By treating security as a central part of network optimisation rather than as an afterthought, the framework provides a path towards secure, scalable, and practical AI-native 6G networks.