The Shift from AI-Assisted to AI-Native
5G treats AI as an add-on optimization layer. The RAN, core, and transport were designed first, then machine learning was bolted on for tasks like traffic prediction and anomaly detection. 3GPP captured this approach in TR 38.843, which studies AI/ML for NR air interface enhancement within a fundamentally human-designed protocol stack.
6G inverts this relationship. In an AI-native architecture, intelligence is not an enhancement — it is the foundation. The protocol stack, control plane, and resource management are designed from day one to be driven by learned models rather than hand-crafted algorithms.
This distinction matters because traditional networks hit a complexity ceiling. A modern 5G RAN has over 2,000 configurable parameters per cell. No human team can jointly optimize these across thousands of cells in real time. AI-native design acknowledges this reality and builds the network around autonomous decision-making.
5G AI (Add-On) vs 6G AI (Native): A Structural Comparison
The table below captures the fundamental architectural differences between the two paradigms.
| Dimension | 5G AI (Add-On) | 6G AI (Native) |
|---|---|---|
| Architecture role | External optimization layer | Core architectural component |
| Protocol design | Fixed algorithms, ML-tuned parameters | Learned protocols, data-driven decisions |
| Model scope | Per-function (e.g., scheduler, handover) | Cross-domain foundation models |
| Training paradigm | Offline, periodic retraining | Continuous online learning |
| Specification basis | TR 38.843 (Rel-18 study) | ITU-R M.2160 framework (IMT-2030) |
| Control loop speed | Minutes to hours | Milliseconds to seconds |
| Autonomy level | TMF Level 2-3 (conditional) | TMF Level 4-5 (high/full autonomy) |
| Data dependency | Siloed per domain | Unified cross-layer data fabric |
What Changes in the Protocol Stack
In 5G, the MAC scheduler follows algorithms defined in TS 38.214 — proportional fair, round-robin, or max-throughput with ML-tuned weights. In a 6G AI-native stack, the scheduler itself is a neural network that learns scheduling policy directly from channel state, traffic patterns, and QoS targets.
This extends across layers. PHY layer channel estimation can use neural receivers instead of LMMSE. RLC segmentation can adapt to learned traffic models. RRC state transitions can be governed by reinforcement learning agents that optimize jointly for latency, energy, and reliability.
The AI-Native Control Plane
A 6G AI-native control plane replaces traditional state machines with inference engines. Three core components define this architecture:
Data plane: Carries user traffic as in legacy networks, but with AI-optimized forwarding tables and adaptive coding. AI plane: A new logical plane that hosts model training, inference, and model lifecycle management. This plane collects telemetry from all network layers and domains, maintaining a real-time network digital twin. Intent plane: Translates operator business objectives into network policies without requiring manual parameter configuration. An operator expresses "ensure 99.99% reliability for factory automation traffic" and the AI plane determines the resource allocation, redundancy scheme, and scheduling policy.Foundation Models for Network Management
Large-scale foundation models — pre-trained on diverse network telemetry — are emerging as the backbone of AI-native management. Rather than training narrow models per task, a foundation model learns general representations of network behavior that can be fine-tuned for specific operations:
| Application | Traditional Approach | Foundation Model Approach |
|---|---|---|
| Fault prediction | Rule-based thresholds + per-KPI ML | Unified anomaly model across all KPIs |
| Capacity planning | Offline traffic forecasting tools | Real-time multi-domain demand prediction |
| Configuration optimization | Parameter sweep + A/B testing | Single-shot policy generation from intent |
| Security threat detection | Signature-based + per-protocol ML | Cross-protocol behavioral anomaly detection |
Nokia's MantaRay network AI platform demonstrates early foundation model concepts, using transformer-based architectures trained on telemetry from over 300 operator networks to generate configuration recommendations and predict faults up to 4 hours before impact.
Autonomous Network Levels (TMF AN 0-5)
The TM Forum Autonomous Networks framework defines six maturity levels that provide a roadmap from today's manually-operated networks to fully autonomous 6G systems. These are specified in TMF IG1230.
| Level | Name | Description | Human Role | Target Era |
|---|---|---|---|---|
| 0 | Manual | All operations require human action | Full control | Legacy |
| 1 | Assisted | System provides recommendations | Decision-maker | 4G |
| 2 | Partial | System executes approved actions | Approver | Early 5G |
| 3 | Conditional | System acts autonomously in defined scope | Supervisor | 5G-Advanced |
| 4 | High | System handles most scenarios independently | Exception handler | Early 6G |
| 5 | Full | Zero-touch, self-governing network | Auditor | Mature 6G |
Most operators today operate at Level 1-2. SK Telecom's AI Network Operations Center (AI NOC), launched in 2024, automates fault detection, root-cause analysis, and resolution for over 60% of common alarms, placing it firmly at Level 3. Their target is Level 4 by 2027, where the AI NOC handles multi-domain incidents — RAN, transport, and core — without human intervention except for catastrophic scenarios.
Worked Example: Autonomous Healing Loop Latency
Consider a cell outage scenario. Under Level 2 automation:
`
Detection (alarm correlation): 2 minutes
Root cause analysis (ML-assisted): 5 minutes
Human approval: 15 minutes (average)
Parameter adjustment execution: 3 minutes
Verification: 5 minutes
Total: 30 minutes
`
Under Level 4 AI-native automation:
`
Detection (real-time anomaly model): 8 seconds
Root cause (causal inference engine): 12 seconds
Decision (RL policy, no human): 0.5 seconds
Execution (closed-loop actuation): 3 seconds
Verification (KPI regression check): 30 seconds
Total: 53.5 seconds
`
This represents a 33x improvement in mean-time-to-repair (MTTR), directly translating to higher network availability.
Closed-Loop Automation: OODA for Networks
AI-native networks operate on closed-loop automation cycles modeled on the OODA (Observe-Orient-Decide-Act) framework. Each loop iteration executes without human intervention.
Observe: Collect real-time telemetry — KPIs, counters, traces, and probes — across all network layers. Modern RAN generates over500 KPIs per cell per 15-minute interval.
Orient: Contextualize observations using the network digital twin. Correlate across domains — a transport congestion event may manifest as RAN throughput degradation.
Decide: Apply trained policies (reinforcement learning agents, neural optimizers) to determine corrective or proactive actions.
Act: Execute decisions through standardized interfaces — O1/O2 in O-RAN, or ETSI ZSM management function APIs.
The loop granularity varies by use case. Near-real-time loops (10 ms - 1 s) handle beam management and scheduling. Non-real-time loops (1 s - 1 min) manage load balancing and energy saving. Strategic loops (minutes to hours) handle capacity planning and network evolution.
ETSI ZSM Framework
The ETSI Zero-touch network and Service Management (ZSM) framework, defined in ETSI GS ZSM 002, provides the architectural blueprint for closed-loop automation. It specifies:
- Management domains — isolated automation scopes (e.g., RAN domain, core domain, transport domain)
- Cross-domain integration fabric — enables coordination across domains via a service bus
- Data services — unified data collection, storage, and analytics
- Closed-loop governance — policies that define automation boundaries, escalation rules, and safety constraints
ZSM explicitly supports nested and coordinated loops. A RAN-domain loop adjusting antenna tilt can trigger a transport-domain loop to re-optimize backhaul routing, all coordinated through the cross-domain fabric.
Intent-Based Networking
Intent-based networking (IBN) abstracts network management from imperative (configure parameter X to value Y) to declarative (achieve outcome Z). The operator states business intent, and the AI-native system determines the implementation.
Worked Example: Intent Translation
An enterprise customer requests: "Provide 99.999% availability for my autonomous guided vehicle (AGV) fleet across factory floor zones A through D."
The AI-native IBN system translates this intent through successive refinement:
`
Intent: 99.999% availability for AGV traffic
↓
Service policy: URLLC bearer, dual connectivity,
packet duplication enabled
↓
Resource policy: Reserve 2x PRBs for redundancy,
configure 4 cells with overlapping coverage
↓
Cell config: Cells 1-4: dedicated BWP for AGV UEs,
configured grant (grant-free UL),
SCS = 60 kHz for 0.25 ms latency
↓
Verification: Continuous monitoring, automatic
reconfiguration if availability drops
below 99.9995% threshold
`
The operator never touches a single cell parameter. The system continuously monitors the intent fulfillment metric and adapts when conditions change — for example, adding a fifth cell if a new obstruction degrades coverage in zone C.
Federated Learning for Privacy-Preserving Intelligence
AI-native networks require massive training data, but privacy regulations (GDPR, local data sovereignty laws) restrict centralized data collection. Federated learning (FL) solves this by training models locally on each network node and aggregating only model updates — never raw data.
In a federated RAN optimization scenario:
- Each gNB trains a local model on its traffic patterns, channel conditions, and user behavior
- Model weight updates (not user data) are sent to an aggregation server
- The server combines updates using algorithms like FedAvg or FedProx
- The updated global model is distributed back to all gNBs
Deutsche Telekom's autonomous driving networks pilot applies federated learning across 15 sites in Germany, training traffic prediction models without sharing subscriber data between regions. Early results show federated models achieve 92% of the accuracy of centrally-trained models while fully complying with GDPR requirements.
Real-World Implementations
SK Telecom AI NOC
SK Telecom's AI NOC processes over 1.2 million alarms daily across 170,000 base stations. Key capabilities:
- Alarm compression: reduces 1.2M alarms to ~3,000 actionable incidents
- Root cause accuracy: 87% first-time correct diagnosis
- Automated resolution: 60% of incidents resolved without human intervention
- MTTR improvement: 42% reduction compared to manual operations
Nokia MantaRay
Nokia's MantaRay platform uses graph neural networks to model network topology and predict cascading failures. Deployed across 15 operator networks, it processes telemetry from over 2 million cells and delivers:
- Fault prediction: 4-hour advance warning with 78% precision
- Energy optimization: 18% power reduction through AI-driven sleep scheduling
- Configuration recommendations: 3x faster parameter optimization compared to manual tuning
Deutsche Telekom Autonomous Networks
Deutsche Telekom targets TMF Level 4 autonomy by 2028. Their pilot in Munich covers 500 cells with:
- Closed-loop energy management saving 22% power consumption
- Federated traffic prediction across 15 sites
- Intent-based slice management for enterprise customers
- Zero-touch fault remediation for 45% of incident types
Key Takeaway: AI-native networks represent the defining architectural shift of 6G. Moving intelligence from an optimization add-on to the core design principle enables autonomous operations (TMF Level 4-5), millisecond-scale closed loops, and intent-based management. Engineers preparing for the 6G era must understand not just ML algorithms but how AI reshapes every layer of the protocol stack — from neural receivers at PHY to foundation models for cross-domain orchestration.