6G Core: Can We Build an Autonomous Network Without a Nervous Breakdown?

Jimmy CHOW

Based on *Emil Olbrich*’s insights from the 3GPP Malta 6G standards discussions, this analysis explores various 6G Core Network (CN) proposals from a professional perspective, drawing on decades of personal R&D & other various experience in the field/industry.

The quote below is from Emil’s article for convenience here.

Part 4: The Core Network Moves From Debate to Architecture (SA2)

AI for 6G Architecture (KI#18): The Big One Got Approved

This is the first concrete foothold for “AI-native architecture” in the 6G core TR, and the range of competing architectural philosophies on the table is itself the story:

NVIDIA is proposing a dedicated 6G AI Plane network architecture with its own interfaces into the (optional) agentic 6G Core NFs. This is the most ambitious structural proposal on the table.

Ericsson, T-Mobile USA, and Deutsche Telekom are proposing an optional 6G CN AI domain that sits alongside the 6G CN PS domain and can evolve independently. That’s a more conservative, add-on architectural model.

China Mobile and Huawei are pushing a 6G AI Agent Network Architecture with intent interpretation built in.

Jio Platforms is proposing an INCF / GGF / AIAF framework — Intelligent Network Control Function for intent translation, Governance and Guardrail Function for pre-execution validation, AI Audit Function for real-time auditing and execution sandboxing. That’s a governance-first take that should get attention from regulated operators.

Lenovo is proposing an Agentic Interface Function (AIF) that translates agentic-protocol requests into SBA service invocations — the interesting angle here is that it treats the core NFs as the target of agentic actions rather than embedding agents in them.

Nobody knows what the heck “AI-native” means. Everyone agrees the core network should be AI-aware. The fight is whether AI lives in a parallel plane, in a bolt-on domain, distributed across agents, or embedded in every NF. That fight is going to shape every architectural decision for the rest of the study.

Before global operators “rolled up their sleeves” to rapidly deploy 5G, I said that large-scale commercialization would fail before 5G CN matured (cloud-native technology was immature). Many years later, now no one doubted this.

[embed]After the hustle and bustle, only reality remains Jimmy CHOWmedium.com

Today, the industry is welcoming the arrival of the next “G,” starting to formulate grand dreams. This time, based on the lessons of 5G failure and the hype surrounding AI, it’s even harder to reach a consensus on what 6G CN will look like. Perhaps, ultimately, 6G CN will again be an unattainable goal.

The clash of the five architectural solutions mentioned by Emil can be seen as five scenarios for “AI’s coronation”: radical disruption (Nvidia), conservative old-school (Ericsson), AI enthusiast (Huawei), timid and cautious (Jio), and the nosy newcomer (Lenovo).

1. NVIDIA

The Dedicated AI Plane is the most radical: AI is not a plug-in but a “third plane” equal to the User Plane and Control Plane. Computing is the network. This favours the deep integration of GPU resources within the network.

Analysis: The 6G AI Plane proposed by NVIDIA genuinely breaks the “siloed” architecture of traditional telecommunications. If we liken the traditional Control Plane (CP) to a “traffic warden” (responsible for directing traffic and allocating seats) and the User Plane (UP) to a “motorway” (responsible for carrying data), then NVIDIA’s AI Plane (AP) is more like a “city’s smart brain”. what a Beautiful concept!

Deconstruction:

1. Core Objective of the AI Plane: Shifting from “Process-Driven” to “Model-Driven”

Traditional 3GPP architectures (such as SBA) are based on “state machines” and “signalling flows”. When the network becomes extremely complex (e.g., 1024 antennas, ISAC, MTN, ISC,etc.), signalling flows explode. The goal of the AI Plane is not merely Autonomous Networks Level 4, but rather to become the “inference foundation” of the network:

• Centralised Inference Decoupling: Previously, every network element (CU/DU/UPF) had to learn AI independently, which was extremely inefficient. The AI Plane provides a unified pool of computing power and models, where network elements only need to request “predictions” or “decisions” via an API.
• Cross-Domain Data Fusion (Data Siphoning): It is the sole, legitimate “network-wide data vacuum”. It can simultaneously acquire signalling from the CU, channel metrics from the DU, and perception data from ISAC, thereby making more accurate judgements than a single network element.
• Bearing Physical Layer AI: NVIDIA’s core interest lies in GPUs. The AI Plane can take algorithms previously hard-coded in low-level hardware (FPGA/ASIC) — such as channel estimation and equalisation — and implement them in real-time using AI on cloud-based GPU clusters.

2. How to Communicate with CU/DU/RAN? (Implementation of Vertical Architecture)

This is why NVIDIA proposes it as a “plane” rather than a “network function”. It requires a completely new set of vertical interfaces:

• Data Collection Link (Perception Side): Obtains raw IQ data or CSI information from the DU.
• Model Update/Inference Link (Execution Side): Directly delivers trained beamforming weights to the antenna array.
• Control Feedback Loop (Control Side): Communicates with the CU to adjust handover strategies.

3. Why Make it an Independent “Plane”?

NVIDIA’s move is very much that of a “merchant”, but it is also highly rational:

• Normalisation of Computing Power: If AI is scattered across various network elements, you need to purchase many types of proprietary chips. If it is independent as a plane, operators can buy large-scale GPU clusters (NVIDIA’s home turf) to process AI tasks for the entire network in a unified manner.
• Breaking Protocol Lock-in: Traditional signalling protocols (such as RRC) are extremely slow to update. If the AI Plane is independent, models can be updated daily like App versions, without waiting for the lengthy 3GPP standardisation cycles.
• Supporting True “Semantic Communication”: It does not merely transmit bits; it is also responsible for understanding the semantics behind those bits.

4. Its Relationship with AN L4: Executor and Commander

TMF Autonomous Network Level 4 (AN L4) is a business classification objective, while the AI Plane is the infrastructure to achieve this goal.

AN L4 is the “Objective”: It refers to the network’s ability to automatically process intent and self-heal from faults.

The AI Plane is the “Means”:

• With only a Control Plane, you can only achieve rule-based (if-else) automation (L2/L3).
• With an independent AI Plane, the network possesses large-scale, real-time deep inference capabilities, thereby supporting true L4.
• Example: When an intent is issued, the AI Plane calculates the optimal path and then directs the Control Plane to modify routing via an “AI-Control interface”.

Summary: What exactly is the AI Plane?

It is not merely a functional module of AN L4; it is the “operating system kernel of 6G”. In NVIDIA’s vision:

• The Control Plane is responsible for “compliance” and “connection establishment”.
• The User Plane is responsible for “fast forwarding”.
• The AI Plane is responsible for “how to optimise” and “how to perceive”.

In-depth Analysis: The ambition behind NVIDIA’s proposal is “de-telecomisation”. If the AI Plane becomes the core, then the communication network of the future is essentially a distributed data centre, and the 3GPP protocol is merely a “peripheral interface” for this data centre.

Deployment:

The independent plane proposed by NVIDIA does not imply that all AI will run in core network data centres thousands of miles away. To resolve latency issues, the AP plane must be physically distributed:

• Near-Edge AP: Deployed within the base station (gNB) or on the O-RAN DU/CU side. It handles microsecond-level (μs) tasks.
• Regional AP: Deployed in edge data centres, handling millisecond-level (ms) tasks (such as multi-cell coordination and medium-to-long-term resource scheduling).
• Central AP: Responsible for model training, intent parsing (RDF/OWL), and network-wide strategies.

Unspecified Risks:

The Compute Black Hole: Does every base station require a GPU?

This is precisely NVIDIA’s strategic gambit. If we follow NVIDIA’s AI-RAN vision, the answer is yes, though the form it takes may vary:

A. Software-Defined Hardware (Software-Defined HW)

Traditional base stations use dedicated chips (ASIC/FPGA) for signal processing. NVIDIA considers this too rigid. If every base station possessed a Grace Blackwell-level compute unit:

• During Communication: It uses AI to perform channel estimation and interference cancellation.
• During Idle Time: It transforms into an edge compute node, leased to nearby enterprises for AI inference (returning to our previous discussion on Monetisation).

B. Compute Pooling (Pooling)

Through the Open-RAN architecture, computing power does not need to be allocated 1:1 to every antenna. Instead, the processing requirements of several sites are aggregated into a small Edge Data Centre (Edge DC) via high-performance fronthaul networks. This allows for statistical multiplexing, reducing the “depth” of the black hole.

C. How to resolve latency-sensitive services? (AI vs. Determinism)

The current solution involves “Hierarchical Loops”:

• Ultra-Fast Path: This remains within the hardware (e.g., Tensor Cores). For instance, the application of beamforming weights must be completed in nanoseconds; this cannot wait for AI inference results.
• Predictive Path: The AI Plane does not “operate physical quantities in real-time” but rather “predicts them in real-time”.
• Example: The AI predicts that the channel will collapse in the next millisecond and proactively delivers a set of parameters to the physical layer cache. When that moment arrives, the physical layer switches directly without waiting for confirmation from the AP.

D. The Deep Gambit: The Fear of Operators

This is why Ericsson, T-Mobile USA, and Deutsche Telekom preferred an “add-on” or “optional” architecture at the Malta meeting, rather than NVIDIA’s “independent plane”:

• Cost Fear: The cost of upgrading GPUs across the entire network is enough to bankrupt operators.
• Energy Efficiency Fear: The power consumption of a GPU is significantly higher than that of dedicated communication chips. If saving 15% of algorithmic energy consumption results in an additional 50% for cooling, it is logically unsound.
• Supply Chain Fear: If the 6G architecture is entirely based on the AI Plane, and the AI Plane is highly dependent on GPUs, then operators will be deeply locked into a single vendor (NVIDIA) (Vendor Lock-in).

Rational Summary: Is this AP plane reasonable?

Mathematically and in terms of performance, it is extremely reasonable. The efficiency of AI in processing non-linear channels is indeed higher than traditional mathematical formulas.

From a commercial and engineering perspective, it is a massive gamble. My previous articles analysed scenarios like CSI-RS, ISAC, and ISC, which traditional statistics-based algorithms cannot support; Machine Learning certainly has its place.

[embed]AI or Not AI, a Question from the Soul of 6G RAN Jimmy CHOWmedium.com

My Judgement:

NVIDIA’s Dedicated AI Plane may eventually be pared/crippled down into a “Logical Plane”. That is to say: the standard will define a set of AI interfaces, but the underlying hardware will not necessarily be a GPU.

• Huawei may promote the use of its own Ascend chips.
• Qualcomm will push for AI to run on the Hexagon DSP.
• Operators will choose to deploy GPUs in critical “hotspot areas” to gain performance, while continuing to use low-power traditional solutions in vast rural areas.

For operators, it has come to a soul-searching question:

Do you want an expensive “AI-everywhere” network, or an economical “intelligence-on-demand” network? Particularly for those companies whose share prices have already plummeted to single digits.

2. Ericsson, T-Mobile, and DT: The “Evolutionary Add-on” Model

While Huawei is busy installing a “brain” and NVIDIA is “demolishing and rebuilding,” the proposal from Ericsson, in collaboration with T-Mobile USA and Deutsche Telekom, resembles a “carefully planned sunroom extension” to an existing villa.

1. Core Logic: Decoupling and Independent Evolution (The Optional AI Domain)

The essence of the Ericsson proposal is the introduction of an Optional 6G CN AI Domain. This domain sits alongside the traditional Packet Switched (PS) domain, ensuring they coexist without interference.

• Dual-Track Architecture: AI capabilities are encapsulated within a dedicated domain rather than being forcibly embedded into every individual Network Function (NF).
• Independent Evolution: This allows AI algorithms to be updated and compute power to be scaled at the pace of the AI industry, without having to overhaul fragile core network signalling processes for every upgrade.

2. Reconstructing AN L4: From “Full-Time Surgeon” to “Consultant Specialist”

In Ericsson’s vision, AN L4 (Autonomous Networks Level 4) does not need to rewrite the genetic code of the core network. Instead, it establishes a “high-level advisory board” on the side.

• On-Demand Invocation: The core network handles standard traffic (via the PS domain) as usual. Data is only offloaded to the “AI Domain” for inference when complex optimisations — such as energy saving or massive network slicing scheduling — are required.
• Risk Isolation: The greatest advantage of this “pluggable” structure is fault tolerance. If the AI domain “goes rogue,” the operator can simply disable the AI plugin, and the core network continues to function as a traditional communication network. For Tier-1 operators like T-Mobile and DT, who are notoriously risk-averse, this is the safest path to L4 implementation.

3. Deep Insight: Why This is the “Commercial Comfort Zone”

• Legacy Protection: Operators have yet to fully recoup their massive investments in 5G Core. Ericsson’s proposal allows them to transition to 6G via “plug-ins” without dismantling their existing architecture.
• The Multi-Vendor Balancing Act: Unlike the deep “vendor lock-in” potentially caused by Huawei’s native-agentic approach, Ericsson’s “Independent Domain” makes it easier to define standardised interfaces. This ensures operators maintain bargaining power between AI providers and equipment vendors.

Conclusion: The Ericsson proposal represents the pinnacle of pragmatism. It may not chase the millisecond-level extreme performance of 6G native intelligence, but it removes the psychological barrier of “fear to use” for operators. It is the path of least resistance for L4 to achieve large-scale commercialisation.

3. Huawei and CMCC (China Mobile)

The “6G AI Agent Core Network Architecture” proposed by Huawei and China Mobile (CMCC) at 3GPP exhibits fundamental differences from NVIDIA’s “Compute-centric” school of thought.

Whilst NVIDIA seeks to “brute-force” the physical layer using GPU compute power, Huawei and CMCC are using AI Agents to “redefine” control logic.

Deconstruction:

1. Core Architecture: AI-Native Agentic Architecture

The core of Huawei’s proposal (as outlined in their white paper Vision and Key Technologies of 6G Network Architecture) lies in “Hierarchical Closed-loops” and “Knowledge-driven” mechanisms.

• Logical Entities: From Network Functions (NF) to Agents

Huawei’s proposal evolves traditional 5G Network Functions (e.g., AMF, UPF) into self-aware Agents.

Each Agent not only executes instructions but also carries its own Knowledge Base.

• Three-Layer Intelligent Architecture:

1. Node AI: Handles tasks with extremely high real-time requirements (such as physical layer scheduling). These are completed via embedded AI directly within the node, rather than through external attachments.
2. Network AI: Manages coordination across network functions. This is resolved through Agent-to-Agent communication (no longer rigid signalling flows) and negotiation.
3. Service AI: Responsible for interpreting complex Intents as defined by the TMF.

2. Key Proposal Points: Intent Interpretation & Logical Inference

This is the most significant point of divergence between the Huawei/CMCC proposal and NVIDIA’s: they place immense emphasis on “Semantics” and “Intent”.

• Built-in Intent Parser: Huawei proposes deploying an “Intent Management Function (IMF)” at the entrance of the core network. Rather than merely parsing JSON, it utilizes capabilities similar to Large Language Models (LLMs) to map natural language intents to network primitives.
• Logical Inference vs. Computational Inference: NVIDIA emphasises TFLOPS (computing power), whereas Huawei emphasises Reasoning (logic). Within Huawei’s architecture, the network uses logical rules to determine whether an “intent is legitimate” and whether “conflicts exist”.

3. Comparison with NVIDIA: Distributed vs. Centralised

Picture credit: Jimmy

4. “Guardrails” in Huawei’s Proposal: Shadows of the Jio Approach

Huawei has proposed a four-stage closed-loop: “Sensing-Decision-Execution-Evaluation”. Before execution, a simulation must be verified through a Digital Twin layer. This coincides with Jio’s “Governance and Guardrail Function (GGF)”, both of which aim to resolve the issue of “AI misinterpreting intent and causing network paralysis”.

5. Why does China Mobile (CMCC) support the “Agentic” architecture?

As an operator, CMCC’s pain points are very clear:

• Avoiding Hardware Lock-in: If NVIDIA’s solution were followed, the entire network would require GPUs, making OPEX prohibitively high. Huawei’s Agent architecture can run on general-purpose CPUs and self-developed NPUs, offering greater flexibility.
• Solving Extreme Complexity: 6G scenarios (satellite, industrial, ISAC) are too numerous for hard-coded signalling flows, which are already breaking down. Self-negotiation between Agents (akin to human social interaction) is the only way to keep the system concise.

Current Architectural Contention:

Do we truly need an independent “AI Plane”? Or do we simply need to add “Agent” attributes to the existing “Control Plane” and “Management Plane”?

Combining this with TMF AN L4 (Autonomous Networks), Huawei’s proposal resembles a “highly logically self-consistent AI Social Network”. In this architecture, if you — as an OSS maintenance engineer — issue an incorrect intent, the Agent within the system might question you like a colleague: “Are you sure you want to do this? It would violate the energy-saving rules defined by OWL.” In this regard, it aligns more closely with L4 objectives than a network relying solely on brute-force calculation.

Just guessing if Huawei can really delivery it.

Differences or Restructuring Regarding TMF AN L4

Huawei and CMCC’s “Agentic” proposal is essentially restructuring the “responsibility boundaries” of AN L4. In the traditional TMF AN framework, AN L4 is often perceived as an *external, centralised management layer (much like a senior executive in a command centre). However, Huawei’s approach embeds these capabilities directly into the Cloud-Native Functions (CNFs).*

This will inevitably lead to three profound transformations for AN L4:

1. From “External Closed-loop” to “Native Closed-loop” (Closed-loop Reconstruction)

• Old Model (TMF AN L2/L3):

Collect data -> Send to external OSS/Brain -> Brain makes decision -> Issue command to network element.

Problem: High latency; the external brain may lack real-time visibility into the network element’s specific details.

• Huawei Model (6G AI-Native CNF):

The closed-loop is completed within the network element (Agent). The element senses, decides, and optimises autonomously.

AN L4 Transformation: Centralised L4 no longer handles granular daily operations but evolves into a “Policy Distributor” and “Final Arbiter”. It only oversees whether the “Intent” is correct, rather than adjusting specific “Parameters”.

2. Semanticisation of Interface Language (Semantic Interop)

If L4 functions are built into the CNF, the way CNFs communicate with upper management systems must change.

• Past: L4 management systems issued specific commands (e.g., “Set PRB threshold = 80%”).
• Present: Since the CNF is now an “Intelligent Agent”, it does not accept micro-management. The management system simply issues an “Intent” (e.g., “Ensure VIP user experience”).
• AN L4 Transformation: The core function of the management system becomes “Intent Translation” — transforming business language into logic understandable by the Agent (hence Huawei’s push for logic-driven architecture).

3. Challenges in Governance and Observability

This is the change that gives operators the greatest headache.

• Black-box Risk: If AN L4 decision logic is hidden inside Huawei’s CNF, how can an operator ensure the Agent isn’t “lying”? Or that it hasn’t sacrificed safety in pursuit of performance?
• New Tasks for AN L4:

Audit: Monitoring the Agent’s decision-making process.

Guardrails: This is the GGF mentioned in Jio’s proposal. Even if L4 capabilities are pushed down, the upper layer must have an independent physical tier to intercept unsafe Agent behaviour in real-time.

Conflict Management: When internal Agent 1 (Energy Saving) and Agent 2 (Performance) within a CNF clash, the upper L4 must have a global perspective to set the final tone.

Summary of Decentralisation:

Huawei’s proposal is effectively driving the decentralisation of AN L4. Shifting from an independent software platform (OSS/EMS) to a distributed, embedded model, processing speeds will increase from minutes/seconds to milliseconds (due to being inside the element). Traditional L4 work, such as rule configuration and command orchestration, will change; instead, Agentic AN L4 within the CNF will handle intent arbitration, knowledge distribution, and compliance monitoring — functions previously held by the external AN L4.

Risks

Similar to TR 38.843’s risks, if AN L4 decision intelligence is “dissolved” within the respective CNFs of Huawei, Nokia, or Ericsson, the traditional “parameter-delivery” interoperability model will indeed collapse. Based on current TMF AN specifications and 3GPP SA2 evolution trends, to achieve multi-vendor interoperability, the industry must undergo a paradigm shift from “Command Interoperability” to “Semantic Interoperability”.

Possible Implementation Methods (Based on Current Specifications)

1. Standardised Intent Interfaces (Intent-driven API / TMF921)

Currently the most mainstream solution. Since the internal workings of the network element are a black box, we ignore the internal calculations and unify only the “Requirement Description”.

• Implementation: Regardless of the underlying CNF vendor, the upper management system (OSS) sends intents via the standard TMF921 Intent API.
• Interoperability Point: As long as Vendor A’s element understands the intent “Latency < 10ms” and reports “Achieved”, interop is successful.
• Bottleneck: Depth and granularity of intent. If Huawei’s Agent supports “ISAC Intent” but Nokia’s only supports “Traffic Intent”, the management system will face severe “functional inconsistency”.

2. Unification of Knowledge Models and Ontologies (The RDF/OWL Path)

If AI is built into elements, AI from different vendors must share a “common sense”.

• Implementation: 3GPP standardises a universal Information Model and Ontology.
• Interoperability Point: Huawei’s and Nokia’s Agents both follow the same RDF framework. When one Agent says “Network Congestion”, the other understands exactly what this implies via OWL logic, enabling coordination.
• Status: Extremely difficult to achieve. Vendors treat their model training data and logic as core Intellectual Property (IP), making unified semantic transparency nearly impossible.

3. Mandatory Guardrail Mediation (Guardrail Mediation)

Referencing Jio’s proposal: Since I cannot control your internal decisions, I will set up a “Security Checkpoint” at the interface.

• Implementation: Define a standardised Governance Function.
• Interoperability Point: Any operational request from an Agent must be converted into a standard “Operational Primitive” and submitted to the checkpoint. The checkpoint audits these against unified policies defined by the operator.
• Conclusion: This approach does not seek to “understand” the peer, but merely to “constrain” them. This is likely the most realistic commercial compromise for multi-vendor environments.

4. The Possibility of Failure: Towards “Full-stack Silos”

If the above standardisation fails, we face a dire situation: Full-stack Lock-in.

• Vertical Monopoly: If Huawei’s L4 functions are too deeply coupled with its CNF, an operator might find they cannot control Huawei’s Agents using a Nokia management system.
• Consequence: To ensure the efficiency of the AN L4 closed-loop, operators would be forced to use a single vendor’s products in specific geographic regions or business domains. The “Decoupling” dream pursued by Open-RAN would be re-locked by “Intelligence”.

Deep Insight

Current AN L4 specifications (like those published by TMF) are actually very fragile**(I said many times, AN L4 will be a dream 10–15 years later, and those L4 show-case actually are for show purpose, will never be massive deployed in production environment). Most are stuck at the **“what the interface looks like” stage, without touching the core of “how Agents interact and negotiate”. (I lack membership access; if anyone can share TMF L4 operator cases documents, it would help clarify the current maturity of those cases, nearly nothing can be hidden from my eyes).

If 6G truly moves towards Huawei’s proposed Agentic architecture, we need something akin to an “Agent Social Protocol”. Much like people of different nationalities communicating, they do not need to exchange DNA (internal algorithms), but they must collaborate through a common language (English/Standard Intent) and a shared social contract (Governance Guardrails).

Poor operators once again face a dilemma: pursue the ultimate performance of L4 and tolerate “Vendor Lock-in”, or lower the network’s IQ for the sake of “Multi-vendor Flexibility”? However, I have always believed that only the operators’ own technical capabilities and their understanding of their own networks can truly identify what they need.

4. Reliance Jio’s Proposal (INCF/GGF/AIAF)

We previously touched upon some of Jio’s requirements. The Reliance Jio proposal feels more closely aligned with AN L4 (Autonomous Networks Level 4); indeed, one might argue they should lead the discussions at the TMF (TeleManagement Forum). Their focus has shifted away from the debate over “whether to use AI, where to place it, or how to write the algorithms” towards “how to cage AI within a framework of rules”.

If Huawei’s proposal is about giving the network a “brain”, Ericsson’s is about “extending the back garden”, and NVIDIA’s is a “complete demolition and rebuild”, then Jio’s proposal is about establishing a “judicial system” for the network. In a complex multi-vendor environment, this is often the final piece of the puzzle that gives operators the confidence to actually deploy AN L4.

1. Jio’s Proposal: A “Battle-Hardened” Version of AN L4

The current TMF AN L4 specifications define “objectives” and “levels”, but remain relatively thin on “how to ensure safety” and “how to conduct cross-domain auditing”. The three core functional modules proposed by Jio effectively fill the void in the commercial implementation of L4:

• INCF (Intent Network Control Function): The “Translator” of L4.

It translates vague business intents into executable network policies and manages intent mapping across different vendors. This directly bolsters the intent-processing capabilities of L4.

• GGF (Governance and Guardrail Function): The “Security Guard”.

This is the most critical component. It performs Pre-execution Validation before any AI decision is implemented.

Scenario: If a Huawei Agent suggests shutting down a specific base station to save energy, the GGF will intercept this based on the operator’s “absolute rules” (e.g., “This base station is near a hospital and must never be deactivated”). This compensates for the lack of deterministic control in current L4 specifications.

• AIAF (AI Audit Function): The “Auditor”.

It records the “thought process” of the AI in the background. Should something go wrong in the network, it is used to “settle accounts”. This addresses the most practical issues of compliance and accountability in L4 deployment.

2. Deconstruction of the Strategy

A. High Compatibility with AN L4

Jio’s proposal is essentially tailor-made for a multi-vendor L4 environment. In such a network, it is impossible to unify the AI logic of every vendor. Jio provides a “greatest common denominator” architecture: regardless of whose network elements are at the bottom, as long as they connect to a unified GGF (Guardrail) and AIAF (Audit), the operator can achieve “secure and controllable autonomy” at the L4 level.

B. A “Dimensional Reduction” Enhancement of Existing Specifications

Existing AN specifications discuss “interfaces” and “models” in broader terms, whilst Jio introduces the concepts of “Sandboxing” and “Real-time Auditing”.

• This takes AN from “laboratory automation” to a “regulated production environment”.
• It transforms L4 from a “technical indicator” into a “manageable business process”.

Summary: The Entry Ticket for Large-Scale Commercialisation

From the perspective of an operations engineer (OSS) or an operator, the primary concern is not whether the AI is clever enough, but rather “what happens if it goes rogue?” or “what if it misunderstands the intent?”.

Jio’s proposal resolves the question of “whether one dares to use it” through the GGF (Guardrails) and the question of “who takes the blame” through the AIAF (Audit). This aligns far more closely with the commercial logic of L4 than a mere debate over the precision of AI algorithms.

5. Lenovo

Actually they should not come to waste time and $ on it.

Apr.28,2026

Jimmy CHOW

Professional Bio / Collaboration Offer

Strategic Network Transformation & Integration Expert

I am currently open to new professional opportunities and consulting engagements, yes, just want to do sth., otherwise I will do bricklayer works.

If your organisation is navigating the complexities of multi-generation network integration (2G/3G/4G/5G/6G) for a future-proof cloud-native core network or managing the intricate network architectures and fragmented service platforms that arise from mergers and acquisitions (M&A) aiming for an Autonomous Network Architecture, I offer the expertise to streamline your operations.

My focus is on driving operational efficiency and fostering competitive advantage by aligning current infrastructures with future-ready network evolution. Whether working independently or embedded within your existing team, I provide end-to-end support — from situational analysis and strategic roadmap design to hands-on implementation and seamless transition.

Let’s collaborate to transform your legacy complexities into a lean, agile, and future-proof digital foundation.