Opener : où en est la stack DECT NR+ open source ?

L'Opener Initiative en quelques mots

Nous l'avions évoqué dans notre article sur le protocole DECT NR+ : le standard est solide, le matériel existe, mais avant de construire un produit NR+, il faut aujourd'hui écrire ou acheter une stack complète. Universités, fondeurs, éditeurs de stacks et fabricants d'équipements ont souvent fini par écrire chacun leur propre stack partielle, et par résoudre les mêmes problèmes chacun de son côté.

Opener est la réponse commune : une stack DECT NR+ open source, développée en commun et ouverte à tous. Elle est publiée sous licence Apache-2.0, avec une concession expresse de brevets. La gouvernance est volontairement légère : un Technical Steering Group (TSG), une signature DCO pour chaque contribution, pas de CLA. Le projet OpenDECT-X, financé par le BMFTR allemand, soutient le travail depuis mai.

Les objectifs, eux, n'ont pas bougé depuis le lancement :

Le 2 novembre, nous avons fait le point sur tout cela devant les participants du pre-event DECT World 2026 : dix minutes de présentation, puis une session pratique sur trois tables de démonstration. Le récit de cette journée fait l'objet d'un article dédié. Ici, on se concentre sur le fond.

Zephyr et C : des choix pragmatiques

Zephyr s'est imposé parce que c'est là que les développeurs NR+ travaillent déjà : le nRF Connect SDK de Nordic et le SDK de Last Mile Semiconductor (LMS) reposent tous deux dessus. Zephyr fournit aussi beaucoup de briques prêtes à l'emploi : pile réseau, net_buf, Kconfig, devicetree et Twister pour les tests. Opener est un module hors arbre, développé contre Zephyr upstream et non contre un fork, ce qui le garde utilisable dans le SDK de chaque fondeur.

Le C est le langage de Zephyr et des SDK fondeurs, et c'est ce que les équipes embarquées savent écrire, relire et certifier. Le C++ a été discuté en mars, mais le consensus s'est fait sur le C. Les règles de codage suivent celles de Zephyr, elles-mêmes dérivées de MISRA, et le formatage est vérifié par clang-format en CI.

Zephyr d'abord, pas Zephyr seulement

L'expérience d'autres stacks sans-fil le montre : une stack qui dépend silencieusement d'un RTOS devient très coûteuse à porter ensuite. L'idée est donc de garder une frontière étroite et explicite. Le cœur de la stack ne s'appuie que sur quelques primitives (mutex, verrous, work queues, buffers réseau), et le contrat est l'API Zephyr elle-même. Un autre RTOS, ou Linux, n'aurait qu'à fournir une fine couche d'adaptation pour ce sous-ensemble. Le matériel n'est atteint qu'à travers l'API driver générique.

Soyons honnêtes : aujourd'hui, le code ne tourne que sur Zephyr. Rendre cette frontière explicite est un travail en cours.

L'architecture de la stack

L'architecture cible a été proposée par deveritec et sert de référence commune au TSG. Elle couvre tout ce qui va du driver radio jusqu'aux sockets et à la gestion, à l'intérieur de Zephyr.

De bas en haut, les grands blocs sont les suivants :

À côté de cette colonne, le schéma prévoit un module de sécurité, un stockage sécurisé, un module de persistance, ainsi qu'un gestionnaire d'appareils et de connexions. Rien de tout cela n'est en cours aujourd'hui : on construit de bas en haut, en partant de la radio.

Où en est-on aujourd'hui ?

Le premier jalon est atteint. Concrètement, la branche principale contient :

• Une API driver neutre vis-à-vis des fondeurs : démarrage et arrêt, capacités radio, configuration (identifiant réseau, filtres), lecture du temps modem et ordonnancement d'opérations TX, RX et RSSI1, immédiates ou planifiées à une date précise du modem. Les résultats remontent sous forme d'événements : trame reçue, erreur de réception, mesures RSSI, fin d'opération.
• Le driver nRF91x1, pour les nRF9151 et nRF9131 de Nordic avec le firmware modem DECT NR+ PHY 2.0.0. Fin octobre, il a gagné les modes de réception mono-coup, semi-continu et continu.
• Deux samples : un ping-pong, où deux cartes se synchronisent sur les trames l'une de l'autre et échangent des messages, et un sniffer dont les captures se décodent dans Wireshark.
• Une base à jour : migration vers le nRF Connect SDK 3.4.0 et Zephyr 4.4.0 début octobre.

De notre côté, nous avons apporté deux contributions. Nos cartes NR+Gate et NR+Node sont supportées nativement par Opener : notre SDK Zephyr, codz-sdk, fait partie du dépôt opener-samples de l'initiative, et les samples se compilent directement pour nos cartes. La NR+Gate est même livrée avec opener-samples et le SDK déjà installés : il suffit de s'y connecter en SSH, en Ethernet ou via son point d'accès Wi-Fi, pour commencer à développer sur la stack Opener. Nous avons aussi développé, sur notre fork public d'Opener, une interface Spinel qui permet de piloter le driver Opener depuis un processeur hôte, en SPI ou en UART. C'est elle qui fait tourner le sniffer et l'interface web de notre passerelle. Nous la détaillons dans un article technique dédié.

La feuille de route

La feuille de route reprend la proposition de deveritec. Elle avance couche par couche, et chaque jalon débouche sur quelque chose d'utilisable :

L'ordre n'est pas figé. Il se discute ouvertement lors des réunions bimensuelles du projet, et si une fonctionnalité compte pour vous, c'est là qu'il faut le dire.

Une deuxième stack pour tester l'interopérabilité

Une stack de référence n'a de valeur que si d'autres implémentations peuvent s'y confronter. hophop, une stack NR+ indépendante écrite en Rust sur Ariel OS, sera la première à interopérer avec Opener. Elle est asynchrone, sans allocation dynamique, orientée IPv6 et CoAP, et tourne sur le même nRF9151. Deux implémentations indépendantes, dans deux langages, sur deux systèmes : c'est comme cela que les bugs d'interopérabilité et les ambiguïtés de la norme font surface.

Ce qu'il faut en retenir

Rejoindre le projet

Toute contribution fait avancer Opener : du code, des relectures, des tests sur votre matériel, ou simplement un retour sur ce dont vous avez besoin.

• Code : github.com/Opener-Initiative (Apache-2.0, signature DCO)
• Site : opener-initiative.org
• Discussion : Matrix, #opener-initiative:matrix.org
• Réunions : un mercredi sur deux à 14 h (CET), ouvertes à quiconque souhaite contribuer. Il suffit de demander.