Sionna 2.1: A Differentiable Simulator Split Into Three Packages

The three packages answer three different research questions

Sionna is not one simulator. The README lists three packages, and they do not overlap. Sionna RT is described as a stand-alone ray tracer for radio propagation modelling. Sionna PHY is a link-level simulator for wireless and optical systems. Sionna SYS is a system-level simulator built on physical-layer abstraction. If you are estimating coverage in a specific building, you want RT. If you are evaluating a receiver chain, a coding scheme or a neural receiver, you want PHY. If you are looking at cell load and scheduling across many links, you want SYS. The audience is research, not deployment: the project describes itself as a library for research on communication systems, and the citation block asks you to cite a 2022 software entry with version 2.1.0. That framing matters when you weigh the dependency requirements below.

Differentiability is the design decision, and it constrains everything else

The repository topics include differentiable-simulation alongside gpu-acceleration and raytracing. That is the mechanism that separates Sionna from a conventional link-level simulator: the simulation chain is built in a framework that carries gradients, which is why the README requires PyTorch 2.9 or later and recommends Ubuntu 24.04. A gradient-carrying chain lets you put a neural component inside a physical model and train through it rather than around it, which is the whole reason the topics list both deep-learning and link-level-simulation. The cost is that you inherit PyTorch's release cadence and its CUDA driver requirements, and the README points you at the PyTorch get-started guide for GPU support rather than restating it. If your group is pinned to an older framework version, the README says earlier PyTorch releases may still work but are not recommended, which is a warning rather than a guarantee.

Sionna RT is a separate repository with a separate dependency chain

The README states plainly that the source code of Sionna RT is located in a separate GitHub repository, and that Sionna RT has the same requirements as Mitsuba 3. That is the sharpest structural fact in the material. It means the ray tracer is not maintained in lockstep with the rest of the library, and it means the install path differs. The README also notes that running Sionna RT on CPU requires LLVM, because Dr.Jit needs it, and links to the LLVM backend installation instructions. So a CPU-only machine is supported, but only after you satisfy a native dependency that has nothing to do with Python. Anyone who has tried to install a rendering stack on a locked-down cluster will recognise the shape of that problem.

Getting it running: three pip variants and a source build

The recommended install is a single command: pip install sionna. If you want only the ray tracer, the README gives pip install sionna-rt. If you want the rest without the ray tracer, the command is pip install sionna-no-rt. That third variant is the one to remember, because it is the escape hatch for environments where Mitsuba 3 or LLVM cannot be installed. The source route is more involved. You clone with git clone --recursive https://github.com/NVlabs/sionna, and if you forgot the flag the README gives git submodule update --init --recursive --remote. Then, from the repository root, you run pip install ext/sionna-rt/ . followed by pip install . Two install commands, in that order, because the ray tracer lives under ext/. Tests come from pip install '.[test]' followed by pytest from inside the test folder. Documentation builds need pip install '.[doc]', possibly a manual pandoc install, then make html from the doc folder, with make serve for a local preview and BASE_PATH= make html to drop the /sionna/ prefix during development.

Where Sionna is the wrong tool

The requirements are the limitation. Python 3.11 or later and PyTorch 2.9 or later, with Ubuntu 24.04 recommended, is a recent stack. Research groups running long-lived experiments on an older distribution, or on a shared cluster whose module system lags, will spend their first week on environment work rather than on simulation. The RT path adds a second constraint: Mitsuba 3 compatibility plus LLVM for CPU execution. If your only interest is system-level behaviour, note that Sionna SYS is defined as being based on physical-layer abstraction. You are still installing the physical-layer machinery, and if you use the plain sionna package you are also installing the ray tracer. The sionna-no-rt variant removes the ray tracer but not the rest of the dependency weight. The README does not state performance figures for any package, so treat the phrase describing Sionna RT as a ray tracer as a description of what it is, not as a measured claim you can plan capacity around.

What you would use instead, and how the approach differs

The obvious alternative for the propagation part is a general-purpose electromagnetic solver or a dedicated radio-planning tool. Those typically take a scene and produce path loss or coverage without exposing gradients, and they are usually driven through their own file formats and GUIs rather than from a Python training loop. The difference is not accuracy, it is what you can do with the result. Sionna's topics list differentiable-simulation, which means the propagation model can sit inside a chain that is optimised end to end. If your workflow is a fixed coverage study with a fixed scenario, that capability buys you nothing and costs you the PyTorch and Mitsuba install. If your workflow is training a learned component against a channel model, a non-differentiable planner forces you to treat the channel as data rather than as part of the model, and that is a different research programme. For the link-level side, the alternative is a classical simulator built around a scripting language and a fixed block library, which is easier to deploy but harder to place a neural network inside.

Maintenance, versioning and the licence

The release history in the material shows v2.0.0 in March 2026, v2.0.1 in April 2026 and v2.1.0 in September 2026. That is a fast minor cadence, and the 2.0 to 2.1 jump is the kind that can move APIs. Because Sionna RT ships from a separate repository and as a separate pip package, the version of the ray tracer you install is not necessarily the version the rest of the library was tested against. Pin both. Sionna is Apache-2.0 licensed according to the README, and the source headers carry SPDX-License-Identifier: Apache-2.0. The repository metadata reports the licence as NOASSERTION, which is a metadata classification rather than a statement about the licence itself; the README and the file headers are the clearer signal. Apache-2.0 is permissive and includes a patent grant, but if you redistribute Sionna inside a product you should read the LICENSE file and the NOTICE handling yourself rather than relying on a summary. This is not legal advice.

Editorial conclusion

Adopt Sionna if your research question needs a differentiable link-level chain or radio propagation maps produced from scene geometry, and if you can commit to Python 3.11 with PyTorch 2.9 on Ubuntu 24.04. Do not adopt it if you need a simulator that installs cleanly on an older Python stack, or if you only want system-level results and have no use for the physical layer, because the SYS package is defined as an abstraction of PHY. Before you build anything, verify two things on your own machine: that Sionna RT imports and runs in CPU mode with the LLVM backend that Dr.Jit requires, and that the version of the Sionna RT source you install matches the version of the rest of the library, since the two are versioned and shipped separately.

Official sources

1. Issues
2. NVlabs/sionna on GitHub
3. Project website
4. README
5. Releases