OpenURMA: Diverse Domain Implementations

• OpenURMA is a polysemous term defining domain-specific artifacts in hadronic simulation, datacenter networking, and web authorization.
• In the Geant4 interface, it bridges UrQMD outputs with native models, enabling direct comparison against experimental HARP-CDP pion spectra.
• In networking and authorization, it decouples traditional constraints by implementing open transport protocols and UMA–ODRL policies to enhance performance and policy expressiveness.

OpenURMA is a polysemous research term used for unrelated constructs in several technical domains. In the cited arXiv literature, it denotes: a tool that makes Ultra-relativistic Quantum Molecular Dynamics output visible inside Geant4’s hadronic model-comparison machinery; a clean-room open implementation of Huawei’s Unified Bus transport and transaction layers; and a Solid-compatible authorization architecture that combines User-Managed Access with ODRL-based usage-control policies. A separate uplink random-access paper also uses “OpenURMA” terminology interpretively to describe open or uncoordinated access rather than to name a distinct artifact (Abdel-Waged et al., 2010, Li, 27 May 2026, Slabbinck et al., 26 Jan 2026, Gao et al., 27 Oct 2025).

1. Name scope and disambiguation

The term does not designate a single protocol, codebase, or research lineage. Its meanings are domain-specific and should be read in context.

Usage of “OpenURMA”	Domain	Defining role
OpenURMA	Geant4/UrQMD hadronic simulation	Bridge for processing UrQMD output through Geant4
OpenURMA	Datacenter remote memory access	Open implementation of Unified Bus transport and transaction layers
OpenURMA	Solid/Web authorization	UMA-based architecture for ODRL usage control
“OpenURMA” terminology	Uncoordinated random access	Interpretive label for open, collision-tolerant URA

The resulting ambiguity matters because the three main usages operate at entirely different abstraction layers. One is a model-comparison interface inside a particle-transport toolkit, one is a synthesisable NIC-side transport realization with a matched RoCEv2 RC baseline, and one is an authorization architecture that decouples policy evaluation from storage. Treating them as a unified technology would therefore be incorrect.

2. Geant4–UrQMD interface for hadronic model comparison

In high-energy and nuclear interaction simulation, OpenURMA is the authors’ tool for linking UrQMD output into the Geant4 hadronic framework so that UrQMD-generated secondaries can be processed and compared side by side with native Geant4 hadronic models (Abdel-Waged et al., 2010).

The motivation is explicit. Geant4 already provides many hadronic physics models, but none fully described the HARP-CDP data in the energy range of interest. UrQMD, by contrast, is a well-established transport or reaction code for hadronic and nuclear interactions and may perform better in that regime. OpenURMA therefore does not replace Geant4; it makes UrQMD “visible” inside Geant4’s comparison machinery so that the same analysis chain can be applied to UrQMD and to Geant4 model generators.

The implementation is a bridge or interface layer. The user first runs UrQMD and obtains an output file; the paper chooses file19, which contains secondaries of the interactions, in OSCAR format. Two subdirectories are added in the Geant4 source tree, UrQMD and Mytest, containing the interface and test application code. The generator is exposed through Mytest.in, invoked from MyTestPhysics.cc, and handled in G4UrQMDInterface.cc, where final-state particles are processed in the model’s ApplyYourself() method. Cross sections, final-state production, and isotope production are managed by G4HadronicProcess. The build procedure also requires adding include paths in Gnumakefile and enabling granular libraries.

Within this framework, the paper compares UrQMD mainly against Geant4’s Binary and FTF generators. Binary treats hadron–nucleus interactions as binary collisions between a projectile or secondary and individual nucleons, does not include collisions between participants, propagates particles in a time-independent nuclear potential, and uses PDG or experimental cross sections, including Delta resonances up to 1.95 GeV and excited nucleons up to 2.25 GeV. FTF is Geant4’s Fritiof implementation, based on nucleon excitation and string fragmentation, with cascading of secondary interactions, diffractive and non-diffractive collision separation, secondary formation time, and use down to about 3–5 GeV/c. UrQMD is described as a microscopic transport model intended to cover roughly 100 MeV/A to 200 GeV/A.

The benchmark dataset is HARP-CDP, with numerical tests centered on charged pion production in $p+\mathrm{Cu}$ and $p+\mathrm{Pb}$ at 3, 8, and 15 GeV/c, including angular bins such as $30^\circ\text{–}40^\circ$, $60^\circ\text{–}75^\circ$, and $105^\circ\text{–}125^\circ$. The central result is that UrQMD reproduces the HARP-CDP charged pion spectra better than Binary and FTF overall for both Cu and Pb targets across the three beam momenta. Binary tends to overestimate the pion yield in the 0.1–0.3 GeV/c region at 3 GeV/c and to underestimate charged pion spectra at small angles at higher beam momenta. FTF tends to overestimate pion spectra in the 0.1–0.3 GeV/c region when both target mass and beam momentum increase and can underestimate spectra at higher transverse momentum, especially when mass number and incident momentum decrease. UrQMD shows overall good agreement but underestimates data at forward angles, specifically around $\theta \le 30^\circ\text{–}40^\circ$.

The paper attributes that forward-angle deficit to pion re-absorption that is too strong in UrQMD, linked to the resonance absorption channel $N+\Delta \to N+N$, discussed as $\Delta N \to NN$ by detailed balance. Higher $\Delta N \to NN$ absorption cross sections imply fewer outgoing forward pions. The significance of OpenURMA in this context is thus methodological: it creates a common evaluation framework in which UrQMD can be assessed as a candidate Geant4 hadronic model.

3. Clean-room open implementation of the Unified Bus protocol

In datacenter networking and remote memory access, OpenURMA is the first clean-room open implementation of Huawei’s Unified Bus protocol transport and transaction layers, realized at three tiers—synthesisable RTL on an Alveo U50, a cycle-level two-node SystemC simulator, and a gem5 full-system scaffold—each with a matched OpenRoCE baseline (Li, 27 May 2026).

The paper’s architectural claim is that the bottleneck in modern datacenter RDMA is no longer the wire but the NIC-side abstraction inherited from InfiniBand. Under RoCE or InfiniBand, per-connection state is maintained for every $(\text{application}, \text{remote-endpoint})$ pair, and small operations traverse PCIe repeatedly. Unified Bus changes this abstraction by decoupling per-application endpoint state from per-host transport state. The split is between a Jetty for per-application endpoint state and a TP Channel for per-remote-host transport state, yielding additive growth $p+\mathrm{Pb}$0 rather than multiplicative growth $p+\mathrm{Pb}$1. The reported byte counts are 20 B for a Jetty in the MVP, 56 B for a TP Channel, and 32 B for the per-application memory-region record. At $p+\mathrm{Pb}$2, OpenURMA uses about 110.6 KB of connection state versus RoCE’s 536.9 MB, summarized as 4,855× less state at that scale, or 3,855× even when projecting full UB-spec fields.

Unified Bus also changes the attachment model. Instead of placing the controller behind PCIe, it places it on the on-chip bus, allowing the CPU to reach it through ordinary loads and stores. The paper frames this as “native CPU load/store access to remote memory.” On the canonical 64-byte remote fetch, UB’s load/store path is a LOAD on UB-spec Sec.8.3, whereas RoCEv2 RC uses a READ on the work-request path. The reported end-to-end latency is approximately 500 ns for UB LD/ST versus 2,186 ns for RoCE DMA, a 4.37× improvement; against RoCE BlueFlame inline mode at 1,686 ns, UB is still 3.37× lower. The raw load/store cold path emits the first wire flit in 8 cycles, about 25 ns at 322 MHz, versus 24 cycles for the work-queue path.

Ordering is treated as opt-in rather than mandatory. UB exposes four orthogonal ordering axes—service mode, execution order, fence, and completion order—and the implementation uses separate reorder buffers at the transport and transaction layers. This separation is intended to allow multi-path packet spreading without breaking application-level ordering. The paper argues that operations not requesting gating pay zero extra pipeline cycles.

The implementation details are concrete. OpenURMA contains 39 pipeline elements total, versus 21 for the matched OpenRoCE baseline, and all 38 work-queue-driven OpenURMA elements and all 21 OpenRoCE elements close timing at 322 MHz post-route on the U50. Resource use is reported as 122,710 LUTs, 194,266 FFs, and 328 BRAM18s for OpenURMA, equal to 14.1% of the U50’s LUT budget, versus 46,636 LUTs, 91,900 FFs, and 67 BRAM18s for the baseline. The extra area is concentrated in the richer transport layer, opt-in ordering machinery, and glue logic.

The evaluation methodology is designed for comparability. All major figures come from the same element source lowered through a software emulator, a cycle-accurate SystemC simulator, and a Vitis HLS/Vivado RTL backend. The simulator sweeps 388 configurations across verbs, payload sizes, cache policies, and link delays. For throughput, the paper reports a 2.80× increase: in a 256-WR burst test, OpenURMA sustains 150.36 WR/$p+\mathrm{Pb}$3s versus 53.62 WR/$p+\mathrm{Pb}$4s for OpenRoCE. In the open-loop operating envelope, UB LD/ST reaches about 2.0 Mops/s with $p+\mathrm{Pb}$5 below $p+\mathrm{Pb}$6, while RoCE DMA knees around 0.75 Mops/s. For the canonical pointer-chase workload, UB LD/ST reaches about 2.5 Mops/s at concurrency 1 and scales linearly until the NIC pipeline floor dominates.

The paper is also explicit about limitations. The synthesis is out-of-context and does not include the full U50 platform shell, which would add roughly 50–80K LUTs of fixed overhead to both stacks. The design was not tested on physical FPGA silicon. Some UB features remain unimplemented or only partially covered, including per-Jetty access control, recoverable-fault drain logic, exception-mode policy, asynchronous event queues, reserved public-Jetty identifiers, and a full multi-flit loss-recovery path. The load/store path is non-coherent, so applications must use UB’s opt-in ordering and barriers to manage consistency.

4. UMA- and ODRL-based usage control for Solid

In Web authorization and data governance, OpenURMA is a proposed architecture for bringing usage control to Solid by replacing Solid’s built-in access-control mechanisms with User-Managed Access and using ODRL to express the actual policy logic (Slabbinck et al., 26 Jan 2026).

The motivation is regulatory and architectural. The paper argues that requirements associated with the GDPR and the Data Act demand more than document-centric access control; they require policy-based governance over use of data, including permissions, prohibitions, and obligations. Solid’s native authorization mechanisms, especially WAC and ACP, are described as tightly coupled to the storage layer and better suited to access control than to usage control. OpenURMA addresses this by decoupling authorization from storage.

The resulting architecture separates the Resource Server from the Authorization Server. The Resource Server continues to expose the LDP interface and thus remains compatible with Solid applications, but authorization decisions are delegated to UMA flows. If no valid Requesting Party Token is present, the RS denies the request, returns a permission ticket, and includes the AS endpoint in WWW-Authenticate. If a valid RPT is present, the RS verifies the token, checks whether it covers the requested operation, and permits the LDP action.

On the AS side, the ticket, claims, and optionally direct permissions are processed through four steps: parsing the request, figuring out requested permissions, extracting and verifying claims, and assessing authorization. The fixed UMA grant type is urn:ietf:params:oauth:grant-type:uma-ticket. The prototype also supports a direct mode in which permissions are sent directly instead of through a ticket. Claim verification is implemented through Components.js and, in the prototype, specifically supports OIDC 2.0 tokens aligned with Solid-OIDC, transforming them into trusted claims anchored by a verified WebID.

ODRL is used because UMA itself does not define a policy language or a policy decision algorithm. Policies are stored in Policy Storage and evaluated through an Evaluation Request derived from verified claims and requested permissions, together with a State of the World representing contextual facts such as current time. The evaluator returns Compliance Reports consisting of Rule Reports. A Rule Report is active only if all its premises hold; an active Permission Report supports granting access, and an active Prohibition Report blocks access. Because ODRL expression is standardized but its evaluation semantics are not fully standardized, the implementation adopts two explicit resolution strategies: default-deny if there are no active rule reports, and prohibition overrides permission if both are active. The effective decision rule is therefore: grant only if there is at least one active permission report and no active prohibition report.

The prototype is built on the Community Solid Server, replaces the default access-control layer with an RPT-driven authorizer, and is released under the MIT license at https://github.com/SolidLabResearch/user-managed-access/. The paper presents the main benefits as decoupling authorization from storage, better fit for decentralized ecosystems, richer usage-control expressiveness through ODRL, standards alignment, and reduced leakage of identity and policy information to the Resource Server. It also notes limitations: obligations such as deletion after a time period are not yet fully enforceable, claims support is presently limited, no dedicated policy-management interface is provided, and collection hierarchy from the RS is not used in policy evaluation.

5. Interpretive use in open or uncoordinated random access

A separate uplink access paper uses “OpenURMA” terminology to describe an open or uncoordinated random-access design rather than to name a distinct system titled OpenURMA (Gao et al., 27 Oct 2025).

The underlying protocol is an uplink SCMA-empowered uncoordinated random access scheme. Active users transmit without scheduling by randomly selecting one SCMA codebook in a slotted-ALOHA-style access procedure. In the paper’s terminology, this qualifies as open or uncoordinated access because there is no dedicated orthogonal resource assignment per user, each slot is open to any active user, access is contention-based, and collisions are expected. The system model uses $p+\mathrm{Pb}$7 orthogonal frequency resources, $p+\mathrm{Pb}$8 SCMA codebooks, $p+\mathrm{Pb}$9 codewords per codebook, and an overloading factor

$30^\circ\text{–}40^\circ$0

The key decoding contribution is an IC-first blind decoding strategy. The access point first exploits singleton frequency nodes created by the sparsity of SCMA codewords; if a user can be decoded from a single FN, that codeword is cancelled, which may create new singletons. Only after this interference-cancellation stage does the receiver fall back to JMPA for any remaining undecoded superposition. In collision-free examples, the paper contrasts conventional JMPA complexity $30^\circ\text{–}40^\circ$1 with IC-first complexity $30^\circ\text{–}40^\circ$2.

The throughput analysis is organized as

$30^\circ\text{–}40^\circ$3

where $30^\circ\text{–}40^\circ$4 covers the no-collision case, $30^\circ\text{–}40^\circ$5 covers cases in which the selected codebook has a single FN under collisions, and $30^\circ\text{–}40^\circ$6 is a lower-bound term for cases where IC creates a new single FN. For congestion sensing, the paper derives an idle codebook probability $30^\circ\text{–}40^\circ$7, emphasizes that it is a monotonically decreasing function of the traffic load $30^\circ\text{–}40^\circ$8, and uses it to disambiguate whether the system is underloaded or overloaded around the throughput-maximizing $30^\circ\text{–}40^\circ$9. The user-barring update is

$60^\circ\text{–}75^\circ$0

The numerical findings verify the throughput analysis, the idle-codebook probability analysis, and the barring mechanism. For a $60^\circ\text{–}75^\circ$1 SCMA codebook with $60^\circ\text{–}75^\circ$2, $60^\circ\text{–}75^\circ$3, and $60^\circ\text{–}75^\circ$4, the proposed SCMA-URA reaches a maximum throughput of 2.1 at $60^\circ\text{–}75^\circ$5, compared with the OMA-based benchmark $60^\circ\text{–}75^\circ$6. For a $60^\circ\text{–}75^\circ$7 SCMA codebook with overloading factor $60^\circ\text{–}75^\circ$8, the maximum throughput is 2.7 versus the OMA-based benchmark $60^\circ\text{–}75^\circ$9. In this literature, “OpenURMA” therefore functions as a descriptive label for open contention-based access with collision-tolerant multiuser detection, not as a separate named architecture comparable to the other OpenURMA usages.

6. Comparative interpretation and recurrent design themes

A common misconception is to treat OpenURMA as a single standard or protocol family. The literature instead uses the name for a Geant4 bridge, a UB transport implementation, a Solid authorization architecture, and an interpretive label for open or uncoordinated random access (Abdel-Waged et al., 2010, Li, 27 May 2026, Slabbinck et al., 26 Jan 2026, Gao et al., 27 Oct 2025).

The commonality is therefore not technical substrate but design stance. In the Geant4 setting, OpenURMA exposes UrQMD to an existing comparison and analysis framework. In the Unified Bus setting, it provides an open, synthesisable realization of a previously closed architectural idea and a matched baseline for controlled comparison. In the Solid setting, it decouples authorization from storage and operationalizes usage control through existing Web standards. In the URA paper, the term is used to emphasize open, uncoordinated access with receiver-side collision handling. This suggests that the recurrent naming marks openness, decoupling, or comparability rather than any shared implementation lineage.

Across the three principal meanings, the most important distinction is layer. One operates inside a simulation toolkit’s hadronic model interface, one at the NIC and memory-transport layer, and one at the authorization and policy-evaluation layer of decentralized Web data systems. Their evaluation criteria are correspondingly different: agreement with HARP-CDP pion spectra for $105^\circ\text{–}125^\circ$0 and $105^\circ\text{–}125^\circ$1, latency or throughput or state scaling on 64-byte remote fetches and burst tests, and policy expressiveness or enforceability under UMA–ODRL authorization flows. The term “OpenURMA” is therefore best understood as a domain-local name whose meaning must be recovered from the surrounding research context rather than from the string itself.