The Opener Initiative in a nutshell
As we wrote in our article on the DECT NR+ protocol, the standard is solid and the hardware exists. But before you can build an NR+ product today, you have to write or license a complete stack. Universities, chip vendors, stack vendors and device makers each ended up writing their own partial stacks, solving the same problems separately.
Opener is the shared answer: an open source DECT NR+ stack, developed together and open to everyone. It is released under the Apache-2.0 licence, with an express patent grant. Governance is deliberately light: a Technical Steering Group (TSG), a DCO sign-off on every contribution, and no CLA. The OpenDECT-X project, funded by the German BMFTR, has supported the work since May.
The goals have not changed since the kick-off:
On 2 November, we presented all of this to the participants of the DECT World 2026 pre-event: a ten-minute talk, followed by a hands-on session at three demo tables. The day itself has its own dedicated article. This one focuses on the technical content.
Zephyr and C: pragmatic choices
We chose Zephyr because that is where NR+ developers already work: Nordic's nRF Connect SDK and the Last Mile Semiconductor (LMS) SDK are both built on it. Zephyr also provides a lot out of the box: the network stack, net_buf, Kconfig, devicetree and Twister for testing. Opener is an out-of-tree module developed against upstream Zephyr rather than a fork, which keeps it usable inside each vendor's SDK.
C is the language of Zephyr and of the vendor SDKs, and it is what embedded teams already write, review and certify. C++ was discussed in March, but the group settled on C. The coding rules follow Zephyr's guidelines, which are based on MISRA, and clang-format checks the formatting in CI.
Zephyr-first, not Zephyr-only
Other wireless stacks have taught us that once a stack quietly depends on one RTOS, porting it later is very expensive. The idea is therefore to keep a small, explicit boundary. The stack core relies only on a few primitives (mutexes, locks, work queues, network buffers), and the contract is the Zephyr API itself. Another RTOS, or Linux, would only need a thin platform layer implementing that subset. The hardware is reached only through the generic driver API.
To be fair: today, the code is still Zephyr-only. Making this boundary explicit is ongoing work.
The stack architecture
The target architecture was proposed by deveritec and serves as the TSG's shared reference. It covers everything from the radio driver up to sockets and management, inside Zephyr.
From the bottom up, the main blocks are:
Next to this column, the diagram also includes a security module, secure storage, a persistence module and a device and connection manager. None of these are in progress yet: we are building bottom-up, starting from the radio.
Where do we stand today?
Milestone 1 is done. In practice, the main branch contains:
- A vendor-neutral driver API: start and stop, radio capabilities, configuration (network ID, filters), modem time, and scheduling of TX, RX and RSSI1 operations, either immediately or at a precise modem time. Results come back as events: frame received, reception error, RSSI measurements, operation finished.
- The nRF91x1 driver, for Nordic's nRF9151 and nRF9131 running the DECT NR+ PHY modem firmware 2.0.0. At the end of October it gained single-shot, semi-continuous and continuous reception modes.
- Two samples: a ping-pong, in which two boards synchronise on each other's frames and exchange messages, and a sniffer whose captures are decoded in Wireshark.
- An up-to-date base: the code moved to nRF Connect SDK 3.4.0 and Zephyr 4.4.0 in early October.
On our side, we have contributed two things. Our NR+Gate and NR+Node boards are supported out of the box by Opener: our Zephyr SDK, codz-sdk, is part of the initiative's opener-samples repository, and the samples build directly for our boards. The NR+Gate even ships with opener-samples and the SDK already installed: just connect to it over SSH, through Ethernet or its Wi-Fi access point, and start developing on the Opener stack. On our public Opener fork, we have also developed a Spinel interface that lets a host processor drive the Opener driver over SPI or UART. It powers the sniffer and the web UI on our gateway, and we cover it in a dedicated technical article.
The roadmap
The roadmap follows deveritec's proposal. It moves up one layer at a time, and each milestone delivers something usable:
The order is not set in stone. It is discussed openly in the project's bi-weekly meetings, so if a feature matters to you, that is the place to say it.
A second stack to test interoperability
A reference stack is only valuable if other implementations can be tested against it. hophop, an independent NR+ stack written in Rust on Ariel OS, will be the first to interoperate with Opener. It is async, heapless and oriented towards IPv6 and CoAP, and it runs on the same nRF9151. Two independent implementations, in two languages, on two operating systems: that is how interop bugs and ambiguities in the standard come to light.
Key takeaways
Opener is not a production stack yet: today it is a solid driver and samples. But the foundations are right: a standard Zephyr module, a vendor-neutral radio API and a licence that allows commercial use. Milestones 2 and 3 will bring the first real MAC behaviour.
Join the project
Every contribution moves Opener forward: code, reviews, testing on your hardware, or simply feedback on what you need.
- Code: github.com/Opener-Initiative (Apache-2.0, DCO sign-off)
- Website: opener-initiative.org
- Chat: Matrix,
#opener-initiative:matrix.org - Meetings: every other Wednesday at 14:00 CET, open to anyone who wants to contribute. Just ask to join.