- The paper introduces a standards-aligned Crypto Policy rApp and SOS xApp that schedule, resume, and place ML-KEM and ML-DSA security operations without inserting the RIC into the data path.
- The paper reports that session resumption and low-load handshake batching reduce average energy from 17.57 mJ to 7.06 mJ and improve p95 latency from 191 ms to 98 ms in simulation, with 98.2% SLA compliance.
- The paper shows that a constrained reinforcement-learning scheduler can prioritize URLLC traffic, adapt cryptographic suites and accelerator use, and suspend batching during handover or contention events, although testbed validation remains necessary.
Overview
The paper addresses a specific operational problem at the intersection of two trends: the migration of Open Radio Access Network (O-RAN) security to Post-Quantum Cryptography (PQC), and the energy cost that PQC handshakes impose on the RAN control plane. The authors argue that computationally expensive PQC handshakes—driven by NIST-standardized algorithms such as ML-KEM and ML-DSA—create a bottleneck for latency-sensitive control traffic, particularly for slices with tight delay budgets such as URLLC, while also inflating per-connection energy consumption. Their response is an energy-aware security orchestration framework embedded in O-RAN's native control architecture: a Crypto Policy rApp in the Non-RT RIC defines the strategic security envelope, and a Security Operations Scheduling (SOS) xApp in the Near-RT RIC converts policy into tactical timing and placement decisions (2602.11820).
Architectural design
The framework follows a strict separation between strategic policy and tactical execution. The Crypto Policy rApp publishes allowed PQC suites, rekey intervals, and scheduling guidance over the A1 interface; the SOS xApp operates on a 100–500 ms control cycle, translating these policies into timing hints, placement intents, suite selections, and accelerator offload requests via E2SM-RC profiles and O1/M-Plane configuration. A deliberate architectural constraint is that cryptographic enforcement remains entirely at standards-compliant endpoints: MACsec (IEEE 802.1AE) at the O-DU/O-RU for the Open Fronthaul, and IPsec/IKEv2 at tunnel terminators for midhaul and backhaul, consistent with 3GPP TS 33.210/33.501. This keeps the RIC as a scheduling and placement optimizer rather than inserting it into the data path—a Zero Trust-aligned choice that preserves O-RAN architectural integrity.
The SOS xApp employs three interlinked mechanisms:
- Handshake batching and placement: non-urgent rekeys are time-shifted into ~50 ms low-load windows, realized as hitless MACsec SAK rollover at the radio unit or batched IKEv2 child SA rekeys at IPsec terminators.
- Session resumption with mobility-aware pre-seeding: TLS 1.3 PSK resumption material is pre-seeded at likely target terminators ahead of handovers, and rekey timers are frozen during handover storms unless safety thresholds are breached.
- Adaptive suite and accelerator selection: within the Non-RT-defined allow-list, the xApp selects ML-KEM parameter levels, signature profiles, or hybrid modes based on real-time resource availability, requesting hardware offload only when predicted latency fits the slice budget and the energy model predicts net gain.
Decision logic
The core decision method is a constrained reinforcement learning policy minimizing joules per secure connection under hard constraints (p95 latency targets, minimum security levels). Because standardized hardware power telemetry is sparse, the authors use a characterization-based abstraction: energy costs for full handshakes (17.57 mJ) and session resumption (0.88 mJ) are profiled offline from published ARM Cortex-M4 measurements and stored as static cost coefficients, combined at runtime with E2SM-KPM/E2SM-RC counters for session state, cell load, and mobility. Carbon-aware scheduling is explicitly deferred to the Non-RT RIC or SMO layers because grid-intensity signals update too slowly (15 minutes or more) for Near-RT use.
The 100–500 ms control cycle is justified by three constraints: a lower bound of 100 ms because a full PQC handshake takes ~98.48 ms of computation (faster cycles cannot observe completion); an upper bound of 500 ms to act before eMBB SLA violations (300 ms delay budget); and alignment with fronthaul timing budgets where transport hops are limited to ~250 µs. URLLC flows bypass scheduling entirely.
Conflict resolution follows a satisfy-then-optimize hierarchy: URLLC is never deferred or batched; eMBB deferral is disabled when estimated queue residency plus service time approaches a safety margin of the SLA budget; and a functional safety shield suspends batching during handover storms or accelerator contention, reverting to safe default profiles if failure rates or p95 latency regress.
Evaluation and results
The evaluation is a discrete-event simulation of an urban macro-cell deployment with 100 O-RUs over 24 hours (~216,000 security events), using Poisson arrivals calibrated to 3GPP TR 38.913 vehicular mobility and cost parameters from verified hardware benchmarks. Three scenarios are compared: baseline (0% resumption), SOS-Low (40%, highway mobility), and SOS-High (63%, urban vehicular). Key results:
| Metric |
Baseline |
SOS-Low |
SOS-High |
| Relative energy |
1.00 |
0.62 |
0.40 |
| p95 latency (ms) |
191 |
150 |
98 |
| SLA compliance (%) |
85.7 |
— |
98.2 |
The headline claim is a ~60% reduction in per-handshake energy (17.57 mJ → 7.06 mJ average) alongside a 48% improvement in p95 latency, without violating the 150 ms eMBB-derived threshold. Notably, the paper asserts there is no trade-off between objectives: resumed handshakes are inherently faster and cheaper, so both metrics improve in parallel—an unusual result relative to typical energy-latency optimization problems. Sensitivity analysis shows savings ranging from 38% (highway, 120 km/h) to 85% (indoor/stationary), scaling with achievable resumption rates.
The authors argue the ~20-fold cost ratio between full and resumed handshakes is a property of TLS 1.3 PSK mechanics rather than any particular platform, making the approach robust across heterogeneous deployments. However, this rests on assumptions worth noting: the resumed-handshake cost is modeled as 5% of full-handshake cost—a conservative doubling of a classical PSK measurement from Restuccia et al., not a direct PQC measurement—and absolute energy figures derive from Cortex-M4 profiling at 180 MHz, which the authors themselves acknowledge is implementation-dependent even as they claim the relative benefits are hardware-agnostic.
Limitations and open questions
The paper concedes several limitations directly. The entire evaluation is simulation-based; validation on physical O-RAN testbeds with PQC-enabled RIC platforms remains outstanding. The proposed narrow E2SM-RC profile for security-aware scheduling nudges does not yet exist as a standard. Calibrated per-operation hardware energy counters—needed for accurate offload accounting—are absent from current O-RAN and 3GPP specifications, meaning the energy proxy remains an approximation. The resumption probability model is tied to mobility via an inverse relationship whose parameters are scenario-specific, so results may not transfer to deployments with different mobility mixes. Integration with conflict-aware coordination frameworks such as PACIFISTA, and extension to multi-connectivity and non-terrestrial 6G scenarios, are identified but unaddressed.
Conclusion
This work contributes a standards-aligned architecture for embedding energy-aware PQC orchestration into O-RAN's existing RIC control loops, with enforcement confined to compliant endpoints and a constrained RL scheduler enforcing strict SLA priority. Its central empirical finding—that session resumption scheduling simultaneously reduces handshake energy by up to 60% and tail latency by 48%—suggests software-level session management is the highest-leverage intervention for sustainable post-quantum hardening, complementing rather than replacing hardware acceleration. The strength of the claim is bounded by its simulation-only evaluation and modeled cost ratios; testbed validation and standardization of the security-aware E2SM-RC profile remain the principal open questions.