PaperlayerView exact revision on arXiv

Source-linked AI summary

Real-Time dApps for AI-RAN: Measured Interface Requirements for Inline PHY and Slot-Level Control

Timothy O'Shea, Matthew Pennybacker, Andriy Kharchenko

arXiv:2609.07805v1cs.NIcs.DCeess.SP

TL;DR

Existing dApp frameworks use an external-process observer boundary that suits asynchronous workloads but does not express some inline PHY and bounded-control use cases. The paper audits use cases and measures framework mechanisms to derive interface choices across a coupling spectrum; its results distinguish which workloads fit each boundary and under what load.

  • Problem

    Public dApp frameworks use an external-process observer boundary, which does not provide a same-slot return path for inline PHY work or a timely response path for some bounded control.

    Source: §I · p. 1

  • Method

    The paper audits 39 runtime AI-RAN use cases against NR timing and payload sizes, then measures shipped framework mechanisms on a quiet host and with the DU on the air.

    Source: §I · p. 2, §IV · p. 3

  • Results

    22 of 39 runtime use cases cannot cross the observer boundary, 13 for structural reasons; with the DU on air, P99.9 reaches 181 µs for SCTP and 787 µs for ZeroMQ, versus 5.22 µs for the validated call.

    Source: §I · p. 1

  • Takeaways & Limitations

    The measured costs derive an ABI stream for inline work, a validated call for bounded control, and Class C choices among a lease, supervised ring, or protocol-standard E3 association.

    Source: §IX · p. 10

    The reference Class A receiver meets its deadline only at the live shape; the 273-PRB kernels are not yet qualified.

    Source: §VIII · p. 10

Abstract

from arXiv · show

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.

I. INTRODUCTION

The paper asks which dApp–DU interfaces can support AI-RAN workloads with different timing and data-path needs. It argues that the observer boundary suits asynchronous work but not all inline PHY or bounded-control workloads, motivating a spectrum of interface choices.

I. INTRODUCTION

  • The observer model is right for sensing and advisory work, but it cannot return a tensor into the same slot or guarantee a control reply before a waiting MAC decision.The paper distinguishes a neural receiver that replaces a pipeline stage from a bounded call whose process boundary adds risk.Source: §I · p. 1
  • 22 of 39 runtime use cases cannot cross the observer boundary, 13 structurally; on-air P99.9 latency is 181 µs for SCTP, 787 µs for ZeroMQ, and 5.22 µs for the validated call.Every carrier meets the Class B deadline on a quiet host, but only the in-process validated call does with the DU on the air.Source: §I · p. 1
  • All 17 asynchronous rows remain feasible across the three frameworks; in-process Class C positions add accountable staleness and an observation-to-decision path without a message.The observer boundary remains suitable for asynchronous observation and advisory work.Source: §I · p. 1
  • The coupling spectrum has two legitimate ends—an in-process C ABI and protocol-standard E3AP over SCTP—and places the three dApp classes along it, with Class C spanning three positions.The paper also audits 39 runtime use cases, measures framework mechanisms, derives the released ABI, and validates four dApps of all three classes together on one over-the-air cell.Source: §I · pp. 1–2

II. PRIOR FRAMEWORKS AND THE BOUNDARY THEY ASSUME

  • Prior frameworks use external processes and exported indications; the Northeastern framework uses E3AP management and ZeroMQ or shared-memory data paths, while NVIDIA Aerial exports GPU tensors to another context.Vendor accelerator stacks expose configurable pipelines but do not support third-party in-pipeline stage replacement.Source: §II · p. 2

III. TWO AXES, THREE CLASSES, ONE SPECTRUM

The interface choice depends on who waits for a result and where the payload resides. The three classes correspond to the feasible combinations of those two properties.

III. TWO AXES, THREE CLASSES, ONE SPECTRUM

  • The blocking contract identifies who waits: inline work blocks PHY progress, bounded work blocks a MAC or PHY control loop, and nonblocking work is consumed later or dropped.Payload residency separately distinguishes GPU-resident grids, channel estimates, and LLRs from compact host scheduler state and larger GPU-resident observation data.Source: A. The Axes That Change the Interface · p. 2
  • Class A is inline over resident tensors, Class B is bounded over compact host state, and Class C is nonblocking over either payload residency.These are the three non-empty combinations of the two interface axes.Source: A. The Axes That Change the Interface · p. 2
  • An inline contract over exported data pays for a copy and wake on the slot’s critical path; nonblocking work over resident tensors is Class C with a lease.The paper identifies these as the combinations excluded by the interface’s physical constraints.Source: A. The Axes That Change the Interface · p. 2

B. The Coupling Spectrum

The coupling spectrum treats dApp–DU placement as a design choice rather than a ranking of classes. The audited corpus uses NR timing, payload sizes, and measured boundary costs to assess what each position can express.

B. The Coupling Spectrum

  • The spectrum places the three classes along one coupling axis, with Class C spanning three positions; the positions pair what the dApp author pays with what placement buys.The left-hand positions make inline and current-slot use cases expressible, while prior frameworks occupy the right-hand half.Source: B. The Coupling Spectrum · p. 2
  • The C ABI end loads a shared object into the DU process and passes device pointers, a CUDA stream, and a deadline without copying or serialization; E3AP over SCTP offers vendor neutrality, language independence, crash isolation, and flexible placement at codec and kernel-round-trip cost.A supervised same-host process shares memory with the DU, paying one copy and wakeup for crash isolation and restart.Source: B. The Coupling Spectrum · pp. 2–3
  • A native dApp reads a leased zero-copy view, a supervised dApp uses a shared-memory ring and can be restarted by the DU, and a portable dApp is any E3 peer.A latest-context cache lets Class C publish observations for a Class B call to read without a message.Source: B. The Coupling Spectrum · p. 3

IV. THE USE-CASE CORPUS, AUDITED

  • The audited corpus has 39 runtime rows—13 Class A, 9 Class B, and 17 Class C—and feasibility is judged by whether DU-on-air P99.9 latency fits the row’s deadline or a return path exists.The audit reexamines use cases against NR timing and payload sizes at the released testbed shape and the larger envelope, and separates rows that are outside the released platform’s scope.Source: §IV · p. 3
  • 11 of 13 Class A rows are inexpressible in either external framework, every Class B row has an observer-framework return path but misses its deadline with the DU on air, and all Class C rows are feasible in all three frameworks.The paper identifies an absent same-slot return path as the structural reason for most Class A exclusions, while 17 asynchronous rows remain suitable for out-of-process E3 clients.Source: §IV · p. 3
  • Table I highlights corpus rows that separate frameworks and identifies their required mechanism and measured or published cost; Class C comparisons include producer cost, restart survival, and observation-to-control return paths.The cited text names the interference map consumed by a scheduler and the quiet-period reservation admitted by a host authority as examples of those return paths.Source: §IV · p. 3

V. MEASURED INTERFACE COSTS

The measurements use the shipped mechanisms and corpus payload shapes on a host tested both idle and with the DU running an over-the-air cell. The study reports the benchmark and evidence conventions used to compare interface costs.

V. MEASURED INTERFACE COSTS

  • All rows were measured on one NVIDIA DGX Spark under quiet-host and DU-on-air contention conditions, with benchmarks pinned to six cores not used by the DU and raw nearest-rank percentiles.The contention run shares the host’s GPU with the released OCUDU cell; memory is locked and the run uses a 10% warmup.Source: A. Method · p. 3
  • Table I lists discriminating audited-corpus rows; its costs are P50 unless stated otherwise, and its measured entries come from the suite or released runtime while published entries come from cited papers.“Inexpressible” means no return path into the consuming stage exists.Source: Table I · p. 4
  • The measured paths include the OCUDU APER E3AP codec and SCTP, its shared ring and credential-checked SEQPACKET channel, Northeastern-style ZeroMQ, and NVIDIA-style device-to-host copying and notification.The study uses the mechanisms the frameworks ship and records copies and system calls on each path.Source: A. Method · p. 4
  • Payloads include 34 and 68 KB 51-PRB slots, 734 KB and 1.47 MB 273-PRB envelopes, 64 KB SRS occasions, and 3.2 KB scheduler requests returning 1.2 KB of intents.These are the corpus payload shapes used for the measurements.Source: A. Method · p. 4

B. The Protocol-Standard End: APER and SCTP

The protocol-standard E3AP/SCTP path can serve asynchronous Class C use cases, but its measured delivery boundary separates Class B deadlines on an idle host from those on a host running the DU. Class A rows fall below even the quiet-host boundary.

B. The Protocol-Standard End: APER and SCTP

  • Every Class C row lies above both delivery lines, while Class B rows fit the quiet-host line but not the DU-on-air line, and Class A rows fall below the quiet-host line.The figure maps each runtime use case by bytes per invocation and deadline against measured one-way E3AP indication delivery.Source: Figure 2 · p. 5, B. The Protocol-Standard End: APER and… · p. 5
  • APER indication encoding grows at 0.87 ns per byte; a 64 KB SRS indication costs 57.8 µs to encode and a 734 KB grid 681 µs.For control-sized messages, encoding and decoding a 2.2 KB action cost 2.27 µs and 2.29 µs, respectively; the FlatBuffers profile encodes and decodes the same grid in 42.1 µs and 11.3 µs.Source: B. The Protocol-Standard End: APER and… · pp. 4–5
  • A 1.5 KB indication arrives in 10.5 µs at the median; a 734 KB grid takes 1.43 ms (1.97 ms at P99.9), and a 1.47 MB four-port grid takes 1.68 ms.With the DU on the air, the 1.5 KB indication reaches 216 µs at P99.9, the 64 KB SRS indication 1.57 ms, and the control round trip 492 µs.Source: B. The Protocol-Standard End: APER and… · p. 5
  • On the quiet host, an E3AP control round trip takes 10.9 µs at the median and 12.6 µs at P99.9; with the DU on the air it reaches 492 µs.The SCTP carrier takes 10.5 µs median for a 1.5 KB indication and 1.43 ms for a 734 KB grid.Source: B. The Protocol-Standard End: APER and… · p. 5

C. Class C Egress: The Producer Rule

For Class C, the supervised ring keeps producer behavior bounded and makes consumer staleness and drops visible, unlike socket queues whose age or loss is unaccounted. For Class B, only the direct in-process call stays within the deadline under DU load without reserving a responder core.

C. Class C Egress: The Producer Rule

  • A full ring returns in 0.144 µs with a counted drop and never waits; copying 68 KB costs 1.97 µs median, and the 1.47 MB envelope costs 23.9 µs.With the DU on the air, ring producer P99.9 rises to 167 µs and consumer wake tail to 1.62 ms.Source: C. Class C Egress: The Producer Rule · pp. 5–6
  • With a sleeping consumer, the supervised ring bounds newest-data age at 3.15 ms median and 5.41 ms P99.9, while counting 4,457 dropped slots across 1,942 stalls.The default ZeroMQ high-water mark instead reaches 981.95 ms median and 1,045.61 ms P99.9 age without reporting drops; conflation discards 10,588 slots without a count.Source: C. Class C Egress: The Producer Rule · pp. 5–6
  • The SEQPACKET control channel completes a 256 B request/response in 3.20 µs median and 4.26 µs P99.9; waking from eventfd to a leased slot takes 3.92 µs median and 99.4 µs P99.9.Heartbeat completion is 3.06 µs, versus 8.52 µs for ZeroMQ request/reply; a native lease costs the producer only the unsubscribed check.Source: C. Class C Egress: The Producer Rule · p. 6

D. Class B: One Request, Six Boundaries

  • With the DU on the air, Class B message paths reach 181 µs at P99.9 for SCTP and 787 µs for ZeroMQ, while the validated direct call reaches 5.22 µs and SPSC 16.8 µs.The message paths miss the 100 µs deadline on 0.35% and 0.69% of requests, respectively.Source: D. Class B: One Request, Six Boundaries · p. 6
  • The direct call is the only measured path that stays within the Class B budget under DU load without reserving a core; SPSC stays within budget at the cost of a spinning responder core.The direct call includes validation; SPSC is not shipped, and the direct-call tail is 5.22 µs versus 16.8 µs for SPSC.Source: D. Class B: One Request, Six Boundaries · p. 6

E. jBPF: A Verified Hook, and Why It Was Not Adopted

The evaluation finds that jBPF’s hook is cheap, but its output path adds a ring and polling thread, so its request-response path is unsuitable for tight control. For inline PHY work, export alone can consume or exceed the available budget before inference, while the in-process path keeps data resident.

E. jBPF: A Verified Hook, and Why It Was Not Adopted

  • jBPF’s request/response through the hook costs 152 µs median because its output ring is drained by a polling I/O thread, so the platform adopts a validated direct call instead.The hook costs 1.54 µs for a 64 B context and 2.61 µs for 16 KB, but 95.4 µs for a 1.47 MB grid; its verifier excludes device pointers and CUDA calls.Source: E. jBPF: A Verified Hook, and Why It… · pp. 6–7
  • The OCUDU ring’s producer cost stays unchanged with a slow subscriber, whereas ZeroMQ’s producer inherits the subscriber’s backlog.A full ring is a counted drop.Source: Figure 4 · p. 7
  • On a quiet host every Class B carrier fits its deadline; with the DU on the air, only paths without a wake keep their tails within it.Fig. 5 compares one 3.2 KB-in, 1.2 KB-out request over six boundaries under three host conditions; bars show P99.9 and ticks P50.Source: Figure 5 · p. 7

F. Class A: What an Export Costs Before the Model Runs

  • At the 1.47 MB envelope, the NVIDIA-style export path takes 224 µs median and 306 µs P99, against a 300 µs planning budget; the outbound leg alone is about 450 µs round trip.At the live shape, the reference receiver completes in 81.6 µs / 112 µs P50 / P99.9 within its 150 µs deadline; at the 273-PRB envelope it takes 272 µs / 523 µs.Source: F. Class A: What an Export Costs… · p. 7

G. The Frameworks at Matched Contracts

Matched-contract measurements show resident paths fit the Class A and Class B workloads, while all compared paths fit Class C. The released ABI places each class at a different coupling point, including a stream for inline work.

G. The Frameworks at Matched Contracts

  • Only the resident path fits the Class A workload; the resident Class B path is more than two orders of magnitude inside budget while the observer path is outside, and all three Class C paths fit.Fig. 6 compares P50 and P99.9 paths with each workload’s budget; hatched bars denote paths outside the framework’s published scope.Source: G. The Frameworks at Matched Contracts · p. 7, Figure 6 · p. 8

VI. DESIGN CONSEQUENCES: THE RELEASED ABI

  • The three-class design places inline work on the PUSCH stream, bounded control at the scheduler decision boundary, and Class C at leased, ring, or E3 positions.Class C observations re-enter control through host-owned caches and authorities; one embedded E3 agent manages every class off the hot path.Source: Figure 7 · p. 8

A. Class A: A Stream, Not a Message

  • Class A uses the PHY’s own stream and device pointers; the DU records a completion event and keeps its conventional stage armed if the dApp misses its deadline.The ABI is frozen and size-tagged, and checks a module’s declared admission profile before its code runs.Source: A. Class A: A Stream, Not a Message · p. 8

B. Class B: A Call With a Contract

For bounded control, the ABI replaces process-boundary wakes with a direct call and validates returned intents against cell and operator constraints. Class C offers three producer-safe positions, while a host-owned cache lets an observation influence a per-slot decision without a message on that decision path.

B. Class B: A Call With a Contract

  • The Class B direct call avoids process-boundary wake tails; each intent is range-checked, its deadline is checked at commit, and a circuit breaker removes a module after eight recoverable failures.The outputs are 72 B each and fully validatable; the supervised Class B position is defined but not shipped because it fits only by spinning on a reserved core.Source: B. Class B: A Call With a Contract · pp. 8–9

C. Class C: Three Positions, One Producer Rule

  • Class C offers leased views, a supervised shared ring, and portable E3; the ring returns immediately with a counted drop when full, bounding staleness by ring depth.The supervised process uses a try-lock, reclaim read, memcpy, release store, and eventfd write; portable E3 is inside every Class C budget and is the only choice outside the host’s trust domain.Source: C. Class C: Three Positions, One… · p. 9

D. Closing the Loop Without a Message

  • A host-owned latest-context cache reaches the next Class B call in 48 ns P50 and 0.27 µs P99.9, letting the shipped interference map affect a per-slot scheduler decision without a message on that path.The protocol-standard route returns an action at a safe point after the observation’s slot; an observer-only framework cannot implement the cache on the consuming side of its boundary.Source: D. Closing the Loop Without a Message · p. 9

VII. VALIDATION ON THE RELEASED PLATFORM

The released platform composes four dApps from all three classes on one over-the-air cell. The validation is bounded by a single-host setup, light DU load, and loopback E3 measurements; the 273-PRB receiver kernels remain unqualified.

VII. VALIDATION ON THE RELEASED PLATFORM

  • Table IV places runtime per-class checkpoints beside this study’s same-host measurements of the same mechanisms.The table distinguishes released qualification figures from the study’s suite measurements with the cell stopped and GPU exclusive.Source: §VII · p. 9, Table IV · p. 10
  • Four dApps from all three classes ran together on one over-the-air n78 cell with three live UEs.The composition included an inline equalizer, a scheduler returning validated intents, two Class C publishers, and an external Python E3 client.Source: §VII · p. 10

VIII. LIMITATIONS

  • The reference receiver’s 92.5 µs figure is reproduced at live shape, but the 273-PRB kernels remain unqualified.The receiver meets its deadline only at the live shape.Source: §VII · p. 10, §VIII · p. 10
  • Measurements use one DGX Spark with a GB10 GPU and coherent CPU–GPU memory; PCIe device-to-host costs would be higher.Host-side tails also depend on kernel configuration and isolation.Source: §VIII · p. 10
  • The DU-on-air test used one 51-PRB cell with three UEs and six benchmark cores unused by the DU, so contention figures are a floor.A production supervised worker would share cores with the DU, and more UEs would lengthen DU bursts.Source: §VIII · p. 10
  • E3 measurements cover the codec and loopback carrier, while cross-host SCTP latency is fabric-dependent and the 273-PRB envelope was not tested over the air.Source: §VIII · p. 10

IX. CONCLUSION

The conclusion argues that observer-only dApp interfaces exclude 22 of 39 runtime use cases and derives class-specific interface choices from measured costs. It recommends standardizing blocking contract and payload residency, keeping E3AP as the management plane, and validating in-process interfaces at their boundary.

IX. CONCLUSION

  • More than half of the audited runtime use cases cannot cross the observer boundary because of slot-critical copying and waking or process-hop tails under load.The conclusion identifies 22 of 39 cases as excluded by an observer-only definition.Source: §IX · p. 10
  • The proposed dApp specification should make blocking contract and payload residency first-class attributes because they determine the interface before model choice.Source: §IX · p. 10
  • E3AP should remain the common management plane across classes; their data paths differ, while lifecycle, subscription, and control remain alike to operators.The paper says this also lets existing E3 dApps run unchanged.Source: §IX · p. 10
  • The in-process position needs a frozen, size-tagged, admission-checked, validated ABI; the released OCUDU interface is offered as one candidate.Source: §IX · p. 10

AVAILABILITY AND ACKNOWLEDGMENT

  • The benchmark suite, corpus, raw CSVs, and paper sources accompany the released platform, SDK, and quickstart images under the OCUDU WG2 AI-RAN group.The work acknowledges support from the DoD OUSD(R&E) FutureG Office.Source: AVAILABILITY AND ACKNOWLEDGMENT · pp. 10–11

APPENDIX THE AUDITED USE-CASE CORPUS

The audited corpus records runtime use cases, their payload sizes and timing bounds, and feasibility verdicts for observer-only and GPU-export boundaries. It distinguishes those runtime rows from applications that do not size the microsecond interfaces.

APPENDIX THE AUDITED USE-CASE CORPUS

  • Table V lists runtime corpus rows with per-invocation bytes at the live cell and envelope sizes, boundary verdicts, and released-platform status.Its verdict definitions distinguish no return path, a path whose measured P99.9 exceeds budget with the DU on air, and a path that fits.Source: Table V · p. 12, APPENDIX THE AUDITED USE-CASE CORPUS · p. 12
  • The corpus re-examines 45 earlier use cases against 5G NR timing, payload sizes at two shapes, and the released runtime’s contracts, splitting mixed rows and excluding out-of-scope cases.Source: APPENDIX THE AUDITED USE-CASE CORPUS · p. 12
  • Table VI contains management-plane applications, xApp/rApp policy, and a multi-DU research row, which do not size the microsecond interfaces.Source: Table VI · p. 13
Loading 2609.07805v1…