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.

翻译：暂无翻译