Sionna integration¶

Sionna is rfgen’s canonical choice for physical propagation: select a 3rd Generation Partnership Project (3GPP) statistical model or a geometry-backed ray-tracing realization when modelling the RF environment. Sionna does not own the scene composer, transmitter (TX) or receiver (RX) hardware, labels, storage, or a supported NR-emitter surface.

The current geometry-free composer still instantiates pure-Torch additive white Gaussian noise (AWGN) unless a Sionna backend is selected explicitly. That is an implementation gap against the canonical architecture, not a statement that AWGN is the recommended physical model. AWGN remains useful as an explicit lightweight test or sanity baseline; it does not model distance loss, multipath, or mobility.

Install the supported extra with pip install 'rfgen[sionna]', or from a source checkout with uv pip install -e '.[sionna]'. The supported Sionna range is declared by the sionna extra in pyproject.toml.

Choose a propagation model¶

Need	rfgen backend	What it models
Urban Macro (UMa), 3GPP TR 38.901 Urban Microcell (UMi), or Rural Macro (RMa) scenario	`SionnaUMa` → UMa, `SionnaUMi` → UMi, `SionnaRMa` → RMa	3GPP TR 38.901 large-scale effects: path loss (weakening with distance and carrier frequency) and shadow fading (slower obstacle attenuation), plus small-scale multipath and Doppler from typed TX/RX topology
Controlled link-level Tapped Delay Line (TDL) or Clustered Delay Line (CDL) fading experiment	`SionnaTDL` → TDL, `SionnaCDL` → CDL	A 3GPP delay profile: the delayed, fading-path specification that controls time spread; not complete deployment path loss or shadow fading
A particular indoor/outdoor site with material and path interactions	`SionnaRT` → PathSolver, Paths.cir, cir_to_time_channel, and ApplyTimeChannel	Site-specific ray-traced propagation from a geometry asset

Each is an explicitly selected Group.CHANNEL backend. rfgen owns the scene composer, per-path context, IQ shape conversion, labels, provenance, storage, and the physical TX/RX hardware chain. Sionna supplies the selected propagation realization only.

For ML experiments, the selected propagation configuration controls the path-loss and time-spread variation represented in generated records; it does not by itself establish transfer to a deployment environment.

Qualification boundary¶

UMi powers the narrowband Golden Path and TDL powers the chirp Golden Path. UMa, RMa, and CDL have installed-wheel smoke coverage only; they are not Golden Paths. Sionna RT is an explicit integration with dedicated provisioned sionna-rt-contract coverage on non-draft pull requests; it is not a Golden Path.

Configure it safely¶

The Propagation API is authoritative for constructor and runtime behavior; Scene API and Scene Geometry Assets define the associated configuration and asset contract.

Every Sionna backend currently requires typed TX/RX poses, positive absolute carrier frequency, and tx_power_dbm in rfgen’s composer/provenance context. The poses let rfgen record a consistent per-path provenance contract. The SionnaTDL and SionnaCDL link-level model mathematics does not itself consume topology; see the Propagation API.
SionnaRT additionally requires a compatible geometry asset. It supports one element and one polarization per stream, not a general MIMO or receiver-chain simulation, and always applies per emitter/RX path.
Configure Sionna with scene.channel_application: per_emitter: it is the intended path that supplies a concrete TX/RX provenance pair even for TDL/CDL, whose upstream link-level mathematics has no topology input. The current runtime does not fail fast on an incompatible selection. With scene, SionnaRT is silently fanned out per emitter because it requires geometry, while the statistical Sionna backends reach apply() without a TX pose and raise.
SionnaTDL and SionnaCDL are link-level models. Choose them for a controlled fading study, not as a complete deployment model.
Solver parameters live in the typed RTSolverConfig or StatisticalSolverConfig carried by the scene geometry configuration; do not pass untyped Sionna objects through rfgen configuration.

Boundary and availability¶

rfgen lazy-loads Sionna only when the selected backend needs it. Until the runtime default is migrated, an installation can run the lightweight AWGN baseline without Sionna; selecting a missing Sionna backend raises the documented backend-unavailable error.

Sionna’s own installation prerequisites and CPU/GPU support are upstream requirements, not an rfgen portability guarantee. Consult the official Sionna installation documentation before choosing a deployment environment.