Most discussions around AI-RAN begin with computing power. They focus on GPUs, accelerated signal processing, AI-assisted scheduling, radio optimisation, and the possibility of running AI and RAN workloads on common infrastructure. But there is another challenge that receives far less attention: how much engineering effort is required to make independently developed RAN components work together?
A high-performance Layer 1 may be technically advanced. An open-source Layer 2 may offer flexibility and rapid innovation. Yet neither provides much architectural freedom if connecting them requires extensive code changes, project-specific patches, or a permanently coupled deployment.
This creates what can be called the integration tax of AI-RAN. It is the recurring engineering cost of translating interfaces, maintaining custom adapters, synchronising release cycles, and revalidating the stack whenever one component changes.
The recent NVIDIA Aerial, OCUDU, and Duranta integrations through coRAN LABS xFAPI provide an important opportunity to examine this problem from a wider architectural perspective. The most important result is not simply that two integrations worked. It is that the integrations demonstrate a different way to design the boundary between Layer 1 and Layer 2.
A RAN Is Not Modular Just Because Its Components Are Separate
The word disaggregated is often used when network functions are placed in separate processes, containers, or servers. But physical separation alone does not make an architecture modular. Two components may run independently and still remain tightly coupled through:
- Proprietary communication mechanisms
- Implementation-specific FAPI representations
- Shared-memory assumptions
- Custom message mappings
- Hardcoded timing behaviour
- Release-specific patches
- Expectations that both sides evolve together
True modularity requires more than separate software components. It requires each component to be replaceable or upgradeable without forcing a redesign of the component on the other side of the interface.
That is particularly difficult at the Layer 1 to Layer 2 boundary. This boundary carries time-sensitive scheduling, configuration, control, and indication messages. Different implementations may support similar functions while representing and transporting those messages in very different ways.
NVIDIA Aerial, for example, communicates through its native NVIPC mechanism using SCF FAPI. OCUDU Layer 2 uses its own xSM shared-memory mechanism and corresponding FAPI representation. The information may be functionally related, but the two implementations do not naturally communicate through the same transport or message representation. The problem is therefore not merely connectivity. It is semantic and transport interoperability.
The Many-to-Many Integration Problem
Consider an ecosystem with several Layer 1 and Layer 2 implementations. Without a common interoperability framework, each Layer 1 may require a separate custom integration for every Layer 2. Adding one new implementation does not create one new integration. It can create several new integration combinations.
As the ecosystem grows, engineering effort is repeatedly spent on:
- Translating similar messages
- Adapting different IPC mechanisms
- Handling buffer and memory differences
- Maintaining compatibility with upstream releases
- Repeating integration testing
- Troubleshooting behaviour distributed across both stacks
This is one reason open ecosystems can still behave like closed systems. The source code may be available, but the practical cost of replacing one component remains too high.
The architectural answer is to move the translation complexity away from the individual Layer 1 and Layer 2 projects and place it at a controlled boundary. For this article, that boundary can be described as an interoperability plane. This is an architectural description, not a new standards-defined RAN plane. Its purpose is to allow independently developed components to retain their native interfaces while a dedicated layer manages the differences between them. That is the role xFAPI is beginning to demonstrate.
What the NVIDIA Aerial and OCUDU Integration Actually Proves
The NVIDIA Aerial and OCUDU demonstration should not be viewed only as a new software combination. It tests whether two independently designed communication models can coexist without either project being redesigned around the other. The logical path is:
NVIDIA Aerial L1 [SCF FAPI / NVIPC] ⇄ xFAPI ⇄ [OCUDU FAPI / xSM] OCUDU L2
NVIDIA Aerial continues to use NVIPC. OCUDU continues to use xSM. xFAPI performs the bidirectional translation between their FAPI representations and communication mechanisms.
This distinction matters. A direct integration could have been achieved by modifying OCUDU to understand NVIPC, or by adding xSM-specific behaviour directly into NVIDIA Aerial. Such an approach might solve the immediate problem, but it would move integration-specific complexity into the core projects.
Instead, the translation is isolated at the boundary. This protects the internal architecture of both implementations and reduces the need for one project to follow the communication design decisions of the other. The demonstrated integration specifically preserves the native Aerial and OCUDU mechanisms while xFAPI bridges them in both directions.
Preserving Native Interfaces Is an Operational Advantage
"No code changes" can sound like a development convenience. In practice, it has deeper operational value. When an organisation maintains a custom fork of a Layer 1 or Layer 2 project, every upstream release creates additional work. Teams must determine whether:
- Their patches still apply
- Interface behaviour has changed
- Timing assumptions remain valid
- Security fixes can be adopted safely
- Performance optimisations conflict with the integration
- Regression testing must be repeated
Over time, a small integration patch can become a permanent maintenance dependency. Separating translation from the native stacks reduces this risk. It does not eliminate the need for compatibility testing, but it creates a cleaner ownership model:
- Layer 1 teams remain responsible for Layer 1.
- Layer 2 teams remain responsible for Layer 2.
- The interoperability layer owns adaptation between them.
This is a more scalable model for an ecosystem in which software components are expected to evolve at different speeds.
Disaggregation Requires a Transport Transition
The NVIDIA Aerial and Duranta integration demonstrates a different boundary problem.
Shared-memory and local IPC mechanisms are effective when Layer 1 and Layer 2 operate within the same physical host. However, they cannot by themselves support communication across separate servers. Physical disaggregation therefore requires more than relocating a process. It requires a transition from a local communication model to a network-capable transport while preserving the expected Layer 1 to Layer 2 behaviour.
In the demonstrated architecture:
- NVIDIA Aerial Layer 1 and xFAPI operate on the GPU server.
- Aerial communicates locally with xFAPI through NVIPC.
- xFAPI converts the communication into nFAPI.
- P5 communication uses SCTP.
- P7 communication uses UDP.
- Duranta, the OAI-based Layer 2, operates on another physical server.
The resulting path is:
NVIDIA Aerial L1 [SCF FAPI over NVIPC] ⇄ xFAPI ⇄ [nFAPI over IP: P5/SCTP, P7/UDP] Duranta (OAI) L2
This demonstrates that xFAPI is addressing two different interoperability dimensions. The Aerial to OCUDU mode translates between different local interface and FAPI representations. The Aerial to Duranta mode translates between a local IPC model and a network-disaggregated deployment model. These are related challenges, but they are not the same problem. Recognising this distinction is important when evaluating RAN interoperability solutions.
Disaggregation Is About Independent Decisions
The real value of physical disaggregation is not that two servers can communicate. Its value is that Layer 1 and Layer 2 infrastructure decisions can become less dependent on each other.
A GPU-accelerated Layer 1 may require infrastructure selected for accelerator availability, deterministic processing, high-throughput data movement, real-time CPU isolation, and radio and fronthaul connectivity. Layer 2 may have different requirements related to general-purpose compute, virtualisation, scaling, service management, deployment automation, and integration with higher-layer functions.
When both components must remain on one host, these requirements must be satisfied through a common infrastructure decision. A network-based Layer 1 to Layer 2 interface creates the possibility of managing those decisions separately. That does not automatically guarantee cloud-scale deployment or unlimited geographical separation. Timing, latency, and reliability constraints still apply. But it creates an architectural foundation on which more flexible deployment models can be evaluated.
What This Changes for AI-RAN Testbeds
This interoperability model has particular importance for research and test environments. Many AI-RAN labs want to evaluate:
- Different accelerated Layer 1 implementations
- Alternative Layer 2 schedulers
- AI-assisted control logic
- CPU, GPU, and ARM-based platforms
- Different server placements
- Open-source and commercial combinations
- New scheduling and radio algorithms
In a tightly coupled stack, changing one component can require rebuilding a large part of the environment. A dedicated interoperability boundary can reduce that dependency. Researchers can focus on the component they want to evaluate rather than repeatedly rebuilding the connection between all other components. This does not remove integration testing. It makes the testing boundary more explicit.
The release's inclusion of NVIDIA Aerial and ARM-based platform support also suggests that xFAPI is moving toward an architecture that must operate across heterogeneous compute environments, rather than assuming one fixed processor and software combination.
Openness Should Be Measured by Replaceability
Open RAN is often evaluated through specifications, source-code availability, and interface declarations. Another useful measure is replaceability.
- Can one Layer 1 be replaced without rewriting Layer 2?
- Can one Layer 2 evolve without forcing changes into Layer 1?
- Can local and network-disaggregated models be supported without creating separate permanent forks?
- Can new compute platforms be introduced without rebuilding the complete stack?
If the answer is no, the architecture may be open in principle but remain tightly coupled in practice.
The xFAPI demonstrations are valuable because they begin testing openness at this practical boundary. NVIDIA Aerial contributes accelerated Layer 1 processing. OCUDU and Duranta provide independent Layer 2 ecosystems. xFAPI attempts to prevent the interface differences between them from becoming permanent architectural dependencies.
That is a different and potentially more important story than the announcement of another software release. The future of AI-RAN will depend not only on how quickly each component can process data. It will also depend on how easily those components can be combined, replaced, upgraded, and independently evolved.
Acceleration determines how fast a RAN can execute. Interoperability determines how freely the RAN ecosystem can innovate.
Explore the Project
- GitHub: github.com/coranlabs/xFAPI
- Documentation: NVIDIA Aerial L1 + xFAPI + OCUDU L2 and NVIDIA Aerial L1 + xFAPI + OAI L2
- Demo video: youtu.be/RCUMIlRVGPg