Measuring real-time app needs for faster AI control in 5G networks
Real-Time dApps for AI-RAN: Measured Interface Requirements for Inline PHY and Slot-Level Control
Networking and Internet ArchitectureDistributed, Parallel, and Cluster Computing
Summary
5G networks use smart software applications called dApps to manage data at very high speeds. This paper explains that the usual way these apps communicate with the network’s distributed units (DUs) is too slow for tasks that must complete within fractions of a millisecond. The authors studied different ways to connect these apps to the network, finding that some applications have to run directly inside the network unit to meet strict timing needs. They measured real network setups to confirm their ideas and propose improved interfaces that let dApps work quickly enough for advanced AI tasks in 5G.
distributed applications (dApps)5G NR (New Radio)distributed unit (DU)PHY layerMAC layerinline processinglatencyE3AP protocolslot-level timingAI-RAN
Authors
Timothy O'Shea, Matthew Pennybacker, Andriy Kharchenko
Abstract
Distributed applications (dApps) bring AI to the microsecond-to-millisecond band beside the 5G distributed unit (DU), but every public dApp framework realizes them the same way: an external process that receives an indication and returns a control message. That boundary is right for sensing and advisory workloads. It cannot express a neural receiver that must finish inside a slot, and it cannot hold a scheduling decision the MAC is waiting on. This paper asks what a dApp interface must deliver, in latency and bandwidth, for the AI-RAN use cases now filed under that name to be realized as dApps at all. It treats the coupling between a dApp and the DU as a design axis with two legitimate ends, a C ABI inside the DU process and a protocol-standard E3AP association over SCTP, and places the three OCUDU dApp classes on it. An audited corpus of 39 runtime AI-RAN use cases, sized by 5G NR timing, shows that more than half cannot cross the observer boundary: inline PHY work because an indication has no return path into the same slot, and bounded control because of the tail under load. Measuring the mechanisms each framework actually uses, on a quiet host and with a live cell on the air, shows that every carrier meets a 100 us control deadline on an idle host and that only the in-process paths still do once the DU is running. The asynchronous use cases remain feasible at every position, so the protocol-standard end is kept as a first-class option; what in-process placement adds for them is accountable staleness and an observation-to-decision path with no message on it. These measurements derive the released ABI, a stream for inline work, a validated call for bounded control, and a choice of lease, supervised ring, or portable E3 client for observation, and four dApps of all three classes are validated together on one over-the-air cell.